Page 137 - ITU Kaleidoscope 2016

ICTs for a Sustainable World

S4T OpenStack
IoTronic Cloud
communication with internal services command
smartphone OS line client IoTronic IoTronic WS tunnel
AMQP
command/response stream (from/to the Cloud) s4t lightning-rod services browser dashboard IoTronic APIs conductor agent agent
IoTronic
queues
GCM
IoTronic
s4t wstunnel lib
Web
IoTronic
...
IoTronic
ADB
s4t lightning- plugin database
s4t
command/response communication with
rod engine plugin loader package GCM signaling WS REST interaction AMQP pub/sub other interaction stream (to/from smartphone services
communication smartphones)
manager
Figure 4. Stack4Things Cloud-side MCS platform architec-
s4t virt lib
ture.
Sensing APIs
IoTronic is characterized by the standard architecture of
an OpenStack service. The IoTronic conductor includes the
GCM signaling WS IPC RPC local (service)
communication interaction
core logic of the service, and manages the IoTronic database,
which stores required information about IoT devices, e.g.,
Figure 3. Stack4Things node-side MCS platform architec-
unique identifiers of nodes, any ownership or delegation
ture.
role nodes may obey to with respect to users and tenants,
board properties and hardware/software characteristics. The
conductor also dispatches RPCs among other components.
successful booking requests, and to constraints dependent on
the APIs granularity, specific to the transducing resources. The IoTronic APIs exposes RESTful interfaces for end users.
The OpenStack Horizon dashboard has been extended to ex-
The S4T lightning-rod engine sits at the core of the node-
pose all the functionalities provided by the IoTronic service
side software architecture, and communicates with the Cloud
and other S4T subsystems. The dashboard exposes also ac-
through a GCM-based messaging channel, at the very least,
cess to node-side services, relaying traffic from the user to
and, when needed, switching to a WebSocket-based full-
the IoTronic WS tunnel agent. This agent acts as a controller
duplex channel for WAMP messaging (see also Figure 4), in
for the WS endpoint to which nodes connect through wstun-
particular to support a wider range of functionalities, such as,
nel libraries.
e.g., sending data to (and receiving data from) the Cloud, or
Likewise, the IoTronic GCM agent works as a bridge for
even executing commands input by the users via the Cloud,
GCM-based communication between any node and other
respectively. User-provided commands may be related to the
components. The command stream gets delivered by this
interaction with the node-hosted resources (through the S4T
agent during bootstrapping phases, as well as under situa-
virt libraries) and with operating system-level resources and
tions of restrictions on traffic. It converts AMQP messages
tools (e.g., package manager, background services, filesys-
on the wire into GCM-compliant ones, and brokers from
tems). Bootstrapping communication with the Cloud is thus
GCM to AMQP as well, conversely. In accordance to the
enabled by primitives for push-based messaging available
current philosophy among OpenStack contributors, any com-
through the platform-native SDK. Furthermore, WebSocket-
munication occurring among Cloud-side subsystems, in this
based libraries (S4T wstunnel libraries) augment the engine
case IoTronic components, is implemented as pub/sub mes-
to act as a WS-powered (reverse) tunneling server, connect-
saging over the network via AMQP queues. This enables the
ing to a specific WS endpoint in the Cloud. This mecha-
whole design to be as scalable as needed, as all components
nism [16] enables internal services to be exposed through the
may be deployed on different hosts without affecting service
tunnel for direct access by external users, whose incoming
behaviour. Also, multiple tunnel agents and GCM/WAMP
traffic is forwarded automatically to any internal service of
agents may be instantiated, in that case each dealing with a
choice running in the background. Outgoing traffic is cap-
subset of enrolled mobiles. Given all of the aforementioned
tured and redirected into the tunnel and eventually reaches
options, high availability and redundancy may be guaranteed
the end user that connects to the WS server in the Cloud, a
as well.
user then ready, at last, to consume the node-hosted service.
The S4T lightning-rod subsystem also provides a plugin
loader. By this component, custom plugins may be injected 5. AN EXAMPLE
into the node environment from the Cloud, and loaded at run-
time to expose specific (user-defined) primitives, including As an example of a S4T-powered MCS application, let us
system-level interactions, albeit subject to sandboxing, such feature Smart City-like traffic service, specifically focusing
as, e.g., involving the system-native package manager, or any on a Pothole Detection and Mapping (PDM). aiming at de-
service automatically started at boot-time. The S4T Cloud- tecting and identifying road potholes through traveler mo-
side MCS platform architecture (see Figure 4) features an biles. The PDM application is based on two components: an
OpenStack service newly designed for IoT, named IoTronic. Android app, running on S4T-enabled mobiles and a central-
– 119 –