Cloud Based IoT Applications Mobile Crowdsensing, Social and Big Data as Innovation Enablers for Future Internet Cloud-based Architectures and Services Cloud Based IoT Applications Prof. Antonio Puliafito apuliafito@unime.it Athens - March 18, 2014

“Game Changers” “Just On” Cloud Computing is … “Biggest Paradigm Shift in 20 years” “Game Changers” “Just On” “Pay As You Go” “Tremendous Cost Cutting”

Hype cycle for Cloud Computing Source: Gartner, Hype Cycle for Cloud Computing, 2011 David Mitchell Smith Publication Date: 27 July 2011 ID Number: G00214915 © 2011

Cloud Services Beyond the IT Industry Business (Process-as-a-service) Every Other Industries’ Cloud Services Cloud Applications (Apps-as-a-service) App Dev/Test Cloud (Application) Platforms App Deploy The IT Industry’s Cloud Services Cloud Infrastructure (Infrastructure-as-a-Service) Source: IDC Executive Telebriefing 29 September 2009

NIST Cloud Computing New Reference Architecture “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This Cloud model promotes availability [...].”

Why Cloud Computing? Cloud computing brings a new level of efficiency and economy to delivering IT resources on demand just like public facilities and it opens up new business models and market opportunities. It offers more than a “pay-per-use” model. The major trends are: IT Efficiency. Companies are minimizing costs, converting them from capital expenses to operating expenses through technologies such as virtualization (i.e. an enterprise do not have to buy expensive equipments to build its business but can build its infrastructure compousing services). Business Agility. Companies are maximizing return using IT as a competitive weapon through the rapid time to market, by mean of integrated application stacks, instant machine image deployment, and parallel programming

Virtualization Virtualization is the main technology behind the clouds. It allows servers, storage devices, and other hardware to be treated as a pool of resources rather than discrete systems. These resources can be allocated on-demand. It allows also to exploit and migrate resources, regardless of the underlying real physical infrastructure. Virtualization solves several core challenges of datacenter managers and delivers specific advantages, including: Higher utilization rates Resource consolidation Lower power usage/costs Space savings Disaster recovery/business continuity Reduced operations costs

WSNs/mobiles: towards the IoT smart things get linked through the Net IoT/Future Internet, the current trends underlying the ubiquitous convergence of devices and Web

Next frontiers for IoT Key features Abstraction Virtualization semantic enablement autonomous cooperation Key features Abstraction Virtualization Management

Cloud towards sensing Widespread availability of cheap sensing devices On-board components built into a wide range of systems (e.g., smartphones, indash units, body sensor networks...) Advances in pervasive computing techniques Many application scenarios: healthcare, smart city, domotic, traffic assistant, ... Many concepts, standards and projects: Internet of Things (IoT) OGC Sensor Web Enablement (SWE),W3C Semantic Sensor Networks (SSN),...  SIMONE(Sistema Integrato per il MONitoraggio della produzione di Energia elettrica), DAMOCLES (Developing Arctic Modeling and Observing Capabilities for Long-term Environmental Studies), CASA (Center for Collaborative Adaptive Sensing of the Atmosphere), Portolan Network Sensing Architecture,... Sensing devices expose an all-round smart behavior, thus becoming active devices able to e.g., selfprobe and advertise hardware equipment and software components

Towards a sensing Cloud: a new take Geographic SN IaaS-like, on-demand service provisioning of (virtual) sensing and actuation resources Device-driven approach, i.e. provisioning of actual (even if virtual) sensing resources – vs data-driven i.e. SaaS-like Basic functionalities: Abstraction, virtualisation, customisation of sensing resources Enrolment, management of contributing nodes (static and mobiles – SN and smart devices) On-demand provisioning of virtual sensing resources: discovery, monitoring, management, etc.

New challenges Heterogeneous sensing environments smart sensors/actuators embedded systems sensor networks ... Uniform management of resources data monitoring application deployment remote system control ... on the one hand… on the other hand A framework able to abstract many types of HW and SW resources enabling an integration between application requirements and sensors capabilities

Cloud computing Cloud computing might be the GLUE for aggregating heterogeneous systems able to gather information from the environment Data Consumers Sensing Devices (SDs) Sensor Networks (SNs) A Cloud Data provisioning system: for capturing information from the physical world interacting with heterogeneous devices and observation environments HW and SW sensing able to store and manage huge amount of data virtualization, it is the most suitable approach to guarantee the high level of interoperability. It allows a world-wide and cross-related range of services

From IaaS/DaaS to SAaaS traditional Infrastructure as a Service: computing and storage resources the next step, SAaaS: Sensing/Actuating resources as new infrastructure to be served according to the current Cloud paradigm

Volunteer approaches glueing in-advance (steady) and opportunistic participation enabling fully unassisted contributing node setup exploiting optional crowd-sourced content to build metadata, thus adding value and building new services

C@H architecture PRIN 2008 A new computing paradigm merging Volunteer computing and Cloud computing allowing open computing service market.

SIGMA: SISTEMA INTEGRATO DI SENSORI IN AMBIENTE CLOUD PER LA GESTIONE MULTIRISCHIO AVANZATA Goal acquire, integrate and compute heterogeneous data, from various sensor networks (weather, seismic, volcanic, water, rain, car and marine traffic, environmental, etc.), in order to strengthen control and monitoring systems to provide useful data for the prevention and management of risk situations through services provided to citizens and businesses, both public and private. Innovations Cloud platform: develop a federated cloud management systems Security: technology for specifying/enabling security features Sensors and Cloud integration: define methods to grab data and interact with sensors Advanced Capabilities for Cloud-based Storage: support delivery of data-intensive services securely, at the desired QoS, at competitive costs Data Mobility and Federation: enable comprehensive data migration and interoperability across remote locations Facts A 2-year project, started May 2013 €20.660 M (total budget all partners)

Sensor Cloud: scenarios

Data-driven approach Storage of information related to the physical and virtual resources, middleware working status and data for clients Management of physical sensing resources hiding underneath technologies. Management of physical resource in a datacenter, providing user accounting, Service Level Agreements (SLAs), Billings,...

Data-driven approach Sensor Web Enablement standard, defined by the Open Geospatial Consortium SOS (Sensor Observation Service) interface for requesting, filtering, and retrieving observations and sensor system information; SPS (Sensor Planning Service) interface for requesting user-driven observations; SAS (Sensor Alert Service) interface for publishing and subscribing alerts from sensors. SensorML models and XML schemas for describing sensors systems and processes; O&M (Observation and Measurements) models and XML Schema for encoding observations from a sensor network;

C-SENSOR Architecture It implements the SWE-SOS standard (Sensor Observation Service) request, filter, and retrieve observations and sensor system information SEDNA DB It implements the SWE-SAS (Sensor Alert Service) and the SWE-SPS ((Sensor Planning Service) standards provisioning of sensing information towards Data Consumers actuation of remote Data Consumers directives

Inter host (inter cluster) Communication: p2p Zero configuration: ZeroConf Monitoring Advanced Security features XMPP based: host presence, open standard Fault Tolerance: no central point of failure Official CLEVER's web site http://clever.unime.it. The source code hosted on https://github.com/clever-unime

ST Microelectronic testbed Monitoring Energy consumption in an industrial site MeshNetics devices FRER Q96U4 analyzer WhereX middleware

Device-driven approach: SAaaS High Level Architecture The SAaaS reference architecture comprises three modules, Hypervisor, Autonomic Enforcer and VolunteerCloud Manager. The Hypervisor allows to manage, abstract, virtualise and customise sensing and actuation resources that could be provided by enrolling either mobile device or SN nodes. Among key features are: abstraction of devices and capabilities, virtualization of abstracted resources, communications and networking, customization, isolation, semantic labeling, and thing-enabled services. At a higher level with respect to the Hypervisor, the Autonomic Enforcer and the VolunteerCloud Manager deal with issues related to the interaction among nodes. The former is responsible of the enforcement of local and global Cloud policies, subscription management, cooperation on overlay instantiation. The VolunteerCloud Manager is in charge of exposing the Cloud of sensors via Web service interfaces, indexing of resources, monitoring Quality of Service (QoS) metrics and adherence to Service Level Agreements (SLAs).

SAaaS: Hypervisor The Hypervisor is a foundational component of our device-driven approach to infrastructure-focused Clouds of sensors: it manages the resources related to sensing and actuation, introducing layers of abstraction and mechanisms for virtualization, operating at the level of a single SAaaS node, defined either as an entire sensor network, as long as under exclusive tenancy, or a set of sensors, as built-in to a standalone device. The Hypervisor is split among a centralized (nodal) device, possibly embedding one or more sensors, and the motes, i.e. small-footprint edge devices in a SN. The Adapter, plays several distinct roles mainly related to the interface with on-board resources and its customisation. The Node Manager works only at the node level and is in charge of sensing resources operations and implementing policies. The Abstraction Unit replicates facilities of the Adapter but on a node-wide scale, combining the pool of resources of the whole SN or smartphone. The Virtualization Unit main task is slicing, i.e. generating possible partitioning schemes for the cluster of resources exposed by the Abstraction Unit.

SAaaS: Adapter The Observation Agent requests, retrieves and eventually pre-processes measurements. In terms of both behaviour and implementation details, the Planning Agent pushes requests for actions (tasks) to the device, for preparing the resource to carry out a variety of duties (reservation of functionalities, tuning of parameters, scheduling of observations). These commands allow management of operating parameters such as duty cycle, sampling frequency, etc. The jargon we are using talking about observation and planning operations traces back to our aim to be compliant with the SWE standards. These two agents rely on the presence of a platform-specific driver, the Translation Engine, responsible for converting the high-level directives in native commands. The Hypervisor is also in charge of processing requests for reconfiguration of the device, using the Customization Engine, an interpreter able to execute on the sensing device the code needed to tailor the sensing activities to customer-mandated requirements. Finally, an autonomic approach is adopted delegating some management tasks of the Adapter to the Mote Manager running mote-side, performing specific operations such as power-driven self-optimization in collaboration with the Node Manager.

The Planning Agent (PA) The main functionalities provided by the SAaaS PA are: tuning of sampling parameters according to user-defined preferences Extensible standards-compliant encoding of requests for tasks, and corresponding responses scheduling of observations following a predefined schedule, or upon the occurrence of a particular event, or simply on user demand exposing all underlying knobs to make them available for customers to operate on transparently

PA Architecture – Interaction Workflow Request Dispatcher has to identify and demultiplex a request to the modules underneath. The lowest Interface has to interact with low-level services, i.e. the Customization Engine, the Translation Engine and the Mote Manager. The Sensor Prober is in charge of enumerating all the sensors and actuators within a sensors platform. The Task Explorer is responsible for enumeration of available tasks, to be provided by probing sensors as listed by the Prober. The Task Manager controls tasks’ lifecycle, since feasibility assessment through reservation/submission stages, then following up, and acting upon, running task progress. The Feasibility Controller has to check if a task is feasible. The Task Updater is in charge of updating configuration parameters of a task, if some modifications have to be pushed after tasks enter into processing stages. The Task Canceller empowers users to stop and therefore retire a task, when already submitted or under reservation. Finally, once a task has been serviced, resulting observations get stored. Any observation will be accessible through the Observation Agent only. In terms of observations, the sole duty up to the PA lies in the Observation Access Provider ability to provide endpoints to access measurements. A possible User SAaaS provider is highlighted on the left and can be described into three phases: i. Sensors & Tasks Acquisition: providing users with all available tasks, as offered by the SAaaS provider; ii. Sensor Use / Interaction: selecting and preparing a task to be then submitted to the SAaaS provider, while keeping the ability to manage the task during its execution; iii. Observation Access: in case one or more observations were the expected output of the task (e.g. scheduling or confirmed reservation), providing users with methods to retrieve stored measurements.

PA Android Implementation – SAaaS4Mobile Example of the previous described interactions on SAaaS4Mobile Discovery Task Listing Task Submission Results Retrieval

SAaaS killer application: Mobile CrowdSensing

Mobile Crowdsensing: current issues volunteer enrolment: requires out-of-band campaign (social network) to get attention involves user-initiated activity (website download) to begin contributing slow and unpredictable uptake app/service availability/reliability: degradation with node churn real-time info may translate into severe burden on resources (battery)

Mobile Crowdsensing: SAaaS possibities MCS app providers may leverage automatic management of SAaaS-enabled infrastructure: no need for targeted ads or direct interaction (app) provider-initiated involvement workflow uptake rates just limited by chosen area of interest and widespread coverage of SAaaS contributors (and by willingness to pay/barter) in typical PaaS fashion: placing a platform layer over Cloud-enabled infrastructure leaving no dependency (either explicit or strictly needed) between the two levels

MCSaaS - MCS as a Service

MCSaaS: a Cloud platform for deploying MCS apps on SAaaS infrastructure readily available infrastructure: a platform provider only needs booking resources for MCS, sending client-side platform code SAaaS will take care of (one-time) client deployment automatic deployment: fire-and-forget experience for the app provider - just send a request to MCSaaS provider for resources, attaching the payload (SAaaS-unaware) dissemination carried out by the platform

MCSaaS: a Cloud platform for managing MCS apps on SAaaS infrastructure churn management(s), each at its own layer: transparent built-in, as part of the framework(s) management real-time info: built-in, platform-level sharing of monitoring data low device-side load from infrastructure-level stats collection optional on-demand feature, may be disabled at will lower strain on constrained resources

Mobile Crowdsensing application: PotHole Detector based on two components: an Android app running on volunteer-owned mobiles a Back-End system to collect data, and also filter, analyze and mine it exploiting mobile-carrying volunteering commuters to detect and classify automatically road surface conditions combined sampling of: acceleration data from on-board motion detection sensors geospatial coordinates as provided by the GPS

Mobile Crowdsensing application: PotHole Detector enables generating a quality map of traversed roads, pinpointing any distress condition and potential presence of potholes performs uninterrupted sampling of parameteres coming from accelerometers computes changes in the sampled values for acceleration (intuitively, when bumping into a pothole on the way, or more generally going down a distressed road surface, these changes may turn out to be hefty) and marks the presence of a potentially critical condition at the corresponding geospatial coordinates info thus acquired to be stored in a centralized DB, as data source for a Web application in order to enable monitoring of roads condition the same information base could be useful for local government and competent authorities to plan carefully targeted maintenance actions and aptly arranging those according to levels of priority most business logic, data filtering and analysis routines reside inside the Web aplication, in order to keep computational duties for involved mobiles at a minimum, e.g. just essential mechanisms and filtering rules to drop false positives

Mobile Crowdsensing application: PotHole Detector

Mobile Crowdsensing application: PotHole Detector

Arduino Yún

Arduino Yún The Yún distinguishes from other Arduino boards in that it can communicate with the Linux distribution onboard, offering a powerful networked computer with the ease of Arduino. The Atheros AR9331 processor supports a Linux distribution based on OpenWRT named Linino.

A MIPS GNU/Linux box for Arduino Combining the Linux OS with Arduino HW + certified WiFi 802.11n connectivity and use OpenWRT and Peer-to-Peer (AllJoyn) technology to customize your own project. Linino.org is a dog hunter-sponsored community project. An installation of Python is included with Linino, with which you can write applications or scripts. Linino uses REST for clients and servers. It is a software architecture that exposes various parts of the Arduino hardware through URLs.

A Common Language for the Internet of Everything The other great thing about the Yún is the integration with AllJoyn™ AllJoyn™ is the open source project that lets the compatible smart things around us recognize each other and share resources and information across brands, networks, and operating systems.

AllSeen Alliance is a Linux Foundation Collaborative Projects. provides a software framework and set of Services that enable interoperability among connected products and software applications, across manufacturers, to create dynamic proximal networks. Originally developed by Qualcomm Innovation Center, Inc. (QCE), and now hosted on AllSeen Alliance. AllSeen Alliance is a Linux Foundation Collaborative Projects. Reference http://www.alljoyn.org http://allseenalliance.org http://wiki.allseenalliance.org Andrea Rocco Lotronto AllJoyn Framework

AllJoyn bus The most basic abstraction of the AllJoyn system is the AllJoyn bus. It provides a fast, lightweight way to move marshaled messages around the distributed system

What new experiences can AllJoyn enable?

Conclusions a novel approach: IaaS-like sensing Cloud through the SAaaS Device-driven vs Data-driven basic low-level mechanisms for interfacing with the device SAaaS4mobile: an Android implementation of the stack (Planning agent and SWE std.) first design and implementation steps into an IaaS-enabled platform

Future work SAaaS engineering of customisation, virtualisation, self-management and volunteer- Cloud features porting core SAaaS4mobile logic to other embedded platforms, e.g. typical WSN nodes extending MCSaaS with user preference profiles and sandboxing capabilities Cloud of Things, Things as a Service (TaaS) semantically tagging devices Integration of CLEVER modules inside YUN Integrazione con CoAP

A journey of a thousand miles begins with a single step Lao - tzu

Antonio Puliafito University of Messina apuliafito@unime.it