The OpenIoT Approach to Sensor Mobility with Quality-Driven Data Acquisition Management - Interoperability and Open-Source Solutions for the Internet of Things - page 55

transmitted to the X-GSN. The QoS Manager simply pushes sensor data readings
from mobile sensors to the adequate X-GSN virtual sensors immediately after
receiving such readings. Apart from sensor data readings (e.g., temperature,
humidity, pressure, etc.), we include the exact geolocation of a mobile sensor
and send it the X-GSN. This way, if somebody is interested in data readings
of a specific mobile sensor node, he/she can access those readings through the
LSM-Light component.

4.2 Interaction with LSM-Light

Figure 5 depicts interactions between the QoS Manager component and LSM-
Light. The CPSP engine provides sensor readings from mobile sensors to the QoS
Manager and the rest of the OpenIoT platform. Moreover, as the engine does not
include a permanent storage, but rather performs the matching and forwarding
of mobile sensor data, the QoS Manager stores sensor data in memory only for
a 30 min period. All sensor data requiring permanent storage are stored and
maintained by LSM-Light.
To enable the forwarding of mobile sensor readings from the CPSP engine
to the OpenIoT platform, the engine regards the QoS Manager as a general
subscriber to all publications and forwards all sensor readings to the QoS Man-
ager, as previously described in Sect. 2.2 . When the QoS Manager receives a
new sensor publication, it checks if in the observed area there exists a virtual
sensor that is previously registered with the X-GSN component, and if not, the
QoS Manager first registers a new virtual sensor with X-GSN. Afterwards, the
QoS Manager forwards received sensor readings to the X-GSN through the vir-
tual sensor instance in which the mobile sensor is currently located. The X-GSN
component registers the virtual sensor and stores received data streams for the
corresponding virtual sensor instance in the LSM-Light. All sensor readings for
which there is current interest, either among subscribers of the CUPUS mid-
dleware or among the OpenIoT platform users, are forwarded to the OpenIoT
platform. Otherwise, the readings from inactivated publishers are not forwarded
to the OpenIoT platform. Note that a publisher on a mobile device is active
if the mobile broker running on the device has received subscriptions matching
publisher data from the CPSP engine, and the QoS Manager did not turn it off.
For a full integration of mobile sensors with the rest of the OpenIoT plat-
form, mobile sensors mapped to virtual sensors need to be discovered by the
OpenIoT platform and selected as resources for service provision. Thus, in case
there is an OpenIoT service request which requires readings from mobile sensors,
we need a mechanism which is initiated by the OpenIoT platform to activate
adequate mobile publishers in a certain area. This can be achieved by sending an
explicit subscription from the OpenIoT platform via a web interface of the QoS
Manager to the CPSP engine, as depicted in Fig. 6 . Since the OpenIoT platform
does not know if these publishers are currently active or not, it has to request
a new subscription over the area of interest. After receiving such instruction,
the QoS Manager sends an explicit subscription to the CPSP engine which acti-
vates available mobile sensors. If there were no previously active sensor nodes in