Page 136 - ITU Kaleidoscope 2016

2016 ITU Kaleidoscope Academic Conference

IoTronic service, the former being the point of contact with
OpenStack S4T OpenStack Cloud
command the Cloud infrastructure where the MCS application has to be
line clients OpenStack services
OpenStack
OpenStack services
OpenStack services deployed, the corresponding subsystem of which is the latter.
services
Web Application Messaging Protocol (WAMP) [14], as a sub-
Web
browser protocol, belongs to the IETF WebSocket (WS) standard, and
Users s4t IoTronic defines some communication semantics for WS-transported
messages, providing publish/subscribe (pub/sub) primitives,
s4t IoTronic
command and remote procedure calls (RPC) as well, either simple or
line client ...
routed ones.
GCM control channel Service forwarding The S4T IoTronic service is designed as an OpenStack one,
WS channel node OS
tools, exposing the capability to manage one or more smart boards,
WAMP control channel OS level calls s4t lightning-rod
services, and remotely. This may be done either via a command-line in-
IoT resources
Virtual networking REST communication (mobile) smart device terface, an OpenStack CLI, or a specific S4T IoTronic CLI,
WS channel
or even a Web browser though either set of REST APIs, as
Figure 2. Stack4Things overall architecture for MCS. provided by the core OpenStack services and S4T IoTronic.
4. STACK4THINGS MCS PLATFORM
these ideas and challenges have been framed into a novel util-
ity paradigm for IoT [12], mainly highlighting, from a func-
With respect to the node-side runtime, and specifically mo-
tional perspective, its focus, i.e., to establish a sensing-Cloud.
biles, in particular focusing on Android, there are the Sensing
Key aspects of SAaaS paradigms are the i) device-centric APIs and the environment-provided notification subsystem
philosophy [13] of providing actual (sensing and actuation) as key elements of the underlying platform at the basis of our
devices or things, even if virtualized, to higher levels (users, design choices. The Sensing APIs are opaque in terms of
app developers or providers) and the ii) unified management our MCS platform, as any sensor tuning and reconfiguration
and control of all the underlying resources. This implies to requests are expected to be relayed to some environment-
provide, on the one hand, mechanisms for customize and native subsystem managing this kind of requests, as the Sens-
contextualize the resources, pushing intelligence to the ex- ing APIs in case of the Android ecosystem. The Android-
treme edge by injecting code on them and, on the other, a native notification subsystem is useful to minimally involve
control surface able to manage these resources and provide provider-enabled Cloud-based mechanisms for push-based
them as a “utility”, in a Cloud-oriented model. S4T design communication to devices, thus avoiding to track network
has thus been tackled by extending certain OpenStack sub- conditions in general.
systems, a well-known and widely adopted Cloud manage-
Google Cloud Messaging (GCM) [15], the most current
ment framework, to smoothly integrate and leverage as much
Google-provided notification service, is leveraged for ex-
existing functionalities as possible.
changing (bootstrapping) asynchronous messages in Android
Figure 2 shows the S4T overall architecture for MCS, derived mobiles, an enabling step to support runtime customization
from the one defined in [1] by specializing its modules in the mechanisms and other Cloud-initiated primitives, includ-
MCS domain, in particular considering mobile devices. It ing on-demand activation of any WAMP-/WebSocket-based
highlights interactions and communication facilities between facilities, when not overly restricted in terms of limits on
end users, the Cloud and mobile nodes hosting sensing (and, generated traffic. The choice of supporting the instantiation
sometimes, even actuation) subsystems. of WAMP-/WS-based channels, actually a custom commu-
On the MCS node side, the S4T lightning-rod runs un- nication bus, under a provider-supported mobile platform
der the device-native (typically SDK-enabled) environment such as Android, stems from the inherent limitations (and
available for developers and interacts with a (subset of) OS costs) linked to the usage of (Android-native) GCM, which
services and tools available on the device for which au- does not support significant payloads (e.g., file transfers), but
thorizations have been granted, as well as with (physical is designed and marketed specifically for push notifications,
or even virtual) sensing and actuation resources, through and in our case employed also for bootstrap signaling.
UNIX-style filesystem-based abstractions of the underlying Figure 3 shows the S4T MCS platform architecture in terms
interfaces, either GPIO for embedded boards or, typically, of the node-side components. The Sensing APIs provide the
(SDK-specific) API-mediated for mobiles. As well, it con- corresponding abstractions at the lowest level, upon which
nects to the Cloud and anchors the node to the (centralised) the node-side subsystem, called S4T lightning-rod, is built
infrastructure, allowing the end users to manage node-hosted to arbitrate access to sensors/actuators, through a set of li-
resources even when nodes are behind gateways or other braries for transducer virtualization, the S4T virt libraries,
network appliances implementing NAT, firewall rules, or any which provide interfaces for reading (and writing) sensors
other restrictive policies. Among mechanisms enabling this (and actuators, respectively), as well as settings parameters
flexibility, a key role is played by WebSocket-based tunnel- for devices’ operating modes. Such operations are therefore
ing, and either Google Cloud Messaging (GCM)- or WAMP- available at the proper level of abstraction semantics. This
based messaging between the S4T lightning-rod and the S4T means either locking or releasing resources in accordance to

– 118 –