# Demo : Dynamic Management of Wireless Sensor Networks using Virtual Objects and a Rule Engine

Alexandre Veremme, Carol Habib, Nathalie Mitton

► To cite this version:

Alexandre Veremme, Carol Habib, Nathalie Mitton. Demo : Dynamic Management of Wireless Sensor Networks using Virtual Objects and a Rule Engine. 28th Conference on Innovation in Clouds, Internet and Networks, Mar 2025, Paris, France. hal-04946062

HAL Id: hal-04946062

https://hal.science/hal-04946062v1

Submitted on 17 Feb 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Dynamic Management of Wireless Sensor Networks
using Virtual Objects and a Rule Engine

Alexandre Veremme, Carol Habib, Nathalie Mitton

Inria, France - Email: {firstname.lastname}@inria.fr

***Abstract***—In this demonstration paper, we present the im-
plementation of a virtualized Wireless Sensor Network (WSN)
following a specific software stack called Virtual Object Stack
(VOStack). This stack, proposed by the *Horizon Europe (HE)*
NEPHELE project, promotes openness and interoperability in
the Cloud-to-Edge-to-IoT continuum. The demonstration focuses
on the management of a dynamic WSN through VOStack,
the interactions between the physical objects and their virtual
counterparts, and a rule engine enabling data processing and
alert triggering.

***Index Terms***—Cloud Continuum, Virtual Object, Web of Things, Wireless Sensor Network, Dynamic Properties, Rule Engine, NEPHELE project.

# I. INTRODUCTION

Wireless Sensor Networks (WSNs) typically consist of
sensor nodes that are constrained in processing power, memory
and energy resources. These nodes are equipped with sensing,
processing, and wireless communication units, enabling them
to generate and collect large amounts of data. This data is
transmitted to more powerful devices, known as gateways,
which serve as aggregation and decision-making hubs within
the network and act as connection points to edge or cloud
servers. WSNs are naturally dynamic, with nodes forming self-
organizing networks capable of adapting their connectivity,
distributing decision-making processes, and using intelligent
routing algorithms and collaborative protocols to respond to
external or internal changes.

In the Cloud-to-Edge-to-IoT paradigm, the concept of a
virtual object plays a crucial role. It enables the creation of
a digital counterpart for any physical device, supporting the
development of complex applications and facilitating remote
device management. For WSNs, virtual objects support energy
efficiency while ensuring interoperability and scalability. Vir-
tualizing unconstrained devices within the WSN, such as gate-
ways, offers numerous advantages, including improved flexi-
bility and easier management of dynamic networks. On the
one hand, this virtualization empowers application developers
to extend the capabilities of WSNs by adding functionalities
to the virtual objects of gateways that are deployed on edge
ressources. On the other hand, it provides application users
with remote access to the WSN and its status while abstracting
the complexity of a self-organizing network.

This paper showcases an implementation of a use case
defined in the *Horizon Europe (HE)* NEPHELE project: a post-
disaster recovery scenario to improve situational awareness
[1], [2]. The proposed implementation is built on VOStack,
an IoT and edge computing software stack developed as part

<figure><img src="image_2.png" /><figcaption>Fig. 1: Application architecture.</figcaption></figure>

of this project [3]. VOStack is designed in accordance with the
standardized Web of Things (WoT) recommendations from the
World Wide Web Consortium (W3C) [4].

II. IMPLEMENTATION

In this paper, we explore the management of constrained
devices by unconstrained devices (Section II-A). We then
focus on the interactions between the physical gateway and
its virtual counterpart (Section II-B). In the end, we explain
the rule engine used by virtual gateways to process sensor
data and trigger alerts (Section II-C). A simplified version
of the architecture is presented in Figure 1. As shown, we
differentiate between constrained and unconstrained devices,
as these require distinct handling at both the logical and soft-
ware perspectives. Unconstrained devices, such as gateways,
operate on Raspberry Pi 3, allowing them to support Python
and a VOStack runtime with "almost" unlimited resources.

Alternatively, as already mentioned, constrained devices are
limited in terms of computing power, memory, and energy.
Since their actions are inherently low-level and their autonomy
is minimal, we have deliberately chosen not to create their
digital twins: they are instead represented as *Properties* of
the physical gateway that manages them. In fact, the W3C
<figure><img src="image_3.png" /><figcaption>Fig. 2: UML state diagram from the physical gateway's perspective. States correspond to node statuses. Actions are exposed in the TD.</figcaption></figure>

WoT framework offers a standardized approach to streamline development and maintenance while ensuring seamless interoperability across applications. At the core of this framework, lies the *Interaction Model* [4]. This model defines three key types of *Affordances* that define how a *Thing* can interact with others: *Actions*, *Events* and *Properties*.

## A. Physical gateway level: management of dynamic Properties

In this use case, we have a huge number of sensor nodes that can be added, updated or removed in the field. In the real world, this set is inherently dynamic, so it should also be perceived as dynamic from the gateway's perspective. That's why this section treats a node as an element of a dynamic *array-Property* named *nodes*, which is defined and exposed in the Thing Description (TD) of the physical gateway. Taking inspiration from the WoT RFC, we designed an intuitive process to manipulate the array through defined *Actions*. Since *nodes* is modified by *Actions* and external calls, the TD is dynamically refreshed, and the new data is re-exposed by the physical gateway. Subscribers with access to this TD can access the newly exposed data. As shown in Figure 2, these are the main *Actions*:

* `register_new_node()`: registering a new node with the gateway, status set to `REGISTERED`;

* `deploy_node()`: deploying a node, action initiated on the field during the physical deployment of a node, status set to `DEPLOYED`;

* `unregister_node()`: unregistering a node from the gateway, action performed when the mission has ended, status changed to `UNREGISTERED`.

Additional node statuses are also used during the gateway's VOStack-runtime. Upon receiving new data from the sensors, the status is set to `RUNNING` by `valid_data_on_next_callback()`. A status

<figure><img src="image_4.png" /><figcaption>Fig. 3: UML sequence diagram illustrating interactions between physical and virtual gateways.</figcaption></figure>

`IN_ERROR` is triggered when an unexpected event occurs (e.g., receiving malformed data) or when a time limit is exceeded.

## B. Interactions between physical gateway and virtual gateway

The complementarity between MQTT and InfluxDB has already been highlighted e.g., [5]. In a concise manner, temporal data is transmitted via MQTT from constrained devices layer to the cloud layer, where it is stored in a time-series database, like InfluxDB. Our approach follows the same idea, as shown in Figure 3. The physical gateway manages sensor nodes as WoT *Properties*. It collects data and stores it locally in a SQLite database. If the virtual gateway is offline, the physical gateway continues to accumulate data in its SQLite storage. When the virtual gateway is back online, the physical gateway transmits the stored data sequentially, maintaining chronological order. The virtual gateway stores the received data in a cloud-hosted InfluxDB database. After successfully processing each item, the virtual gateway sends an acknowledgment back to the physical gateway, confirming the data has been handled. When receiving this *ACK*, the physical gateway deletes the corresponding data from its SQLite.

The advantage of this mechanism lies in its ability to preserve data even when communication between the physical and virtual gateways is interrupted. The *ACK* frees up the memory used on the physical gateway. Furthermore, The virtual gateway evaluates each received data against a set of rules and generates an alert if a violation occurs, forwarding it to the cloud layer to notify users of the risk.

## C. Virtual gateway level: threshold-condition rules engine

One main reason for separating physical and virtual gateways is to delegate the responsibility of managing constrained devices to the physical gateways. Therefore, a physical gateway serves as an intermediary. Tasks requiring more resources,
<figure><img src="image_5.png" /><figcaption>Fig. 4: UML class diagram to represent the threshold-condition rules engine.</figcaption></figure>

i.e. data analysis, are moved to the edge side. Consequently, for anomaly detection, such as sensor monitoring, out-of-range detection, or trend and breakpoint analysis, we opted to implement a rule engine at the virtual gateway level. To implement this detection mechanism and guarantee a flexible and dynamic engine, we wanted to align our approach with the existing literature on Service-Oriented Architectures (SOA) and Business Rule Management Systems (BRMS) [6]. A wide range of tools is available on the market. For instance, ThingsBoard appears to be gaining importance in the field of IoT and offers an interesting rule engine [7]. Inspired by this solution but with the aim of accelerating and simplifying its integration into VOStack, we developed a custom rule engine adapted to data coming from IoT devices.

We developed Python classes to handle what is called an *engine for threshold-condition rules*. A class *Rule* contains three properties:

* `sensor_type`: a sensor type of a constrained device, such as `"temperature"`, `"light"`, `"acceleration"`, etc.;

* `operator`: a custom *Enum* that is restricted to: `GREATERire THAN`, `LESS THAN`, `EQUAL`, `GREATER_OR_EQUAL`, `LESS_OR_EQUAL`, built over the native Python module `Operator`;

* `threshold`: a numerical value against which the sensor value will be compared.

For each rule, we then have a 3-tuple (`sensor_type`, `operator`, `threshold`) used to trigger alert events, propagated to the cloud layer.

This implementation allows chaining the `add_rule()` methods to execute the engine, as illustrated in Figure 5.

### III. DEMO DESCRIPTION

During the conference, attendees will be able to watch a video explaining the entire architecture [8]. They will also

<figure><img src="image_6.png" /><figcaption>Fig. 5: Python example of using the rule engine to trigger alert(s) if the temperature is out-of-range, below 11°C or above 25°C.</figcaption></figure>

have the opportunity to interact with some Pycom devices that we will bring along with a personal computer. Attendees will then be able to adjust live *threshold-condition rules* through a web application deployed on that computer.

### IV. CONCLUSIONS AND FUTURE WORK

In this demo, we have presented an implementation of a virtualized WSN using VOStack, an IoT and edge computing software stack proposed by the HE NEPHELE project. We have focused on the management of a dynamic WSN and presented the sequence diagram defining interactions between a physical gateway and its virtual counterpart. We have highlighted the integration of a *threshold-condition rules* engine enabling alerting and data processing deployed on the edge side. For future work, we intend to integrate a routing protocol to enable multi-hop communication within the virtualized WSN.

### ACKNOWLEDGMENT

This work has been supported by the European Union's Horizon Europe research and innovation project under grant agreement No. 101070487 (NEPHELE).

### REFERENCES

[1] L. Militano, A. Arteaga, G. Toffetti, and N. Mitton, "The Cloud-to-Edge-to-IoT Continuum as an Enabler for Search and Rescue Operations," *Future Internet*, vol. 15, no. 2, 2023.

[2] A. Arteaga-Arce, A. Veremme, C. Habib, and N. Mitton, "Demo: Virtualized Wireless Sensor Networks for Distributed Applications over the Cloud Continuum," in *7th Conference on Cloud and Internet of Things (CIoT)*. IEEE, 2024.

[3] D. Spatharakis, I. Dimolitsas, G. Genovese, I. Tzanettis, N. Filinis, E. Fotopoulou, C. Vassilakis, A. Zafeiropoulos, A. Iera, A. Molinaro et al., "A Lightweight Software Stack for IoT Interoperability within the Computing Continuum," in *19th International Conference on Distributed Computing in Smart Systems and the Internet of Things (DCOSS-IoT)*. IEEE, 2023, pp. 715-722.

[4] W3C Web of Things Working Group, "Web of Things (WoT) Architecture 1.1," https://www.w3.org/TR/wot-architecture/, 2023, accessed: February 13, 2025. See especially section "6.5 Interaction Model".

[5] I. Hindi, M. Alyaman, A. AboZenah, A. Zaid, and M. Shrara, "Smart Alarm IoT System: Monitoring Elevator Traffic and Meteorological Data on Job Sites Using MQTT and InfluxDB integrated with Grafana," in *2024 15th International Conference on Information and Communication Systems (ICICS)*. IEEE, 2024, pp. 1-6.

[6] I. Graham, *Business Rules Management and Service Oriented Architecture: A Pattern Language*. John wiley & sons, 2007.

[7] ThingsBoard Inc., "Thingsboard rule engine overview," https://thingsboard.io/docs/user-guide/rule-engine-2-0/overview/, accessed: February 13, 2025.

[8] "NEPHELE - Demo (use case 1): VOStack integration: interactions between physical and virtual gateways," https://youtu.be/SBe-qorrE1M, 2024, on Youtube, accessed: February 13, 2025.