# A Middleware Solution for Wireless IoT Applications in Sparse Smart Cities
## 8 Experimental Results
In other words, measured values include, on the one hand, the time to wait for manual network configuration and, on the other hand, the time required for RON to periodically retry packet transmissions (period of 10 s). However, it takes only 5.8 s (115.8 s-55 s \(\times\) 2) to dispatch packets if not considering the time required to manually reconfigure the network. In particular, when a node activates a new link with another RAMP node, it spends about 2.9 s to forward packets due to RAMP neighbor discovery and RON procedures (comprising periodic waiting time, packet restoring, and packet forwarding to new neighbors). Then, we have extended the previous scenario with additional devices between A\({}_{1}\) (the sender) and RPi (the receiver) and by making LCC work by automation with lazy and hectic policies (see Figure 6). This scenario also includes an always-on Ethernet link, while IEEE 802.11 and Bluetooth links are periodically activated and deactivated by LCC (at startup wireless links are not available). Furthermore, LCC on node A\({}_{2}\) is in client-only role, switching among the two IEEE 802.11 networks towards L\({}_{2}\) and RPi. When adopting lazy and hectic policies, the end-to-end packet dispatching takes on average 365.4 s and 158.9 s respectively. Therefore, it is possible to see that the hectic policy relevantly lowers the required time thanks to reduced HC, RS, and RW values. However, the required time is still  
Figure 5: Two-hop deployment scenario. relatively high due to two main issues. First of all, when the Bluetooth link between A1 and L2 is used, LCC requires about 93 s to actually activate IP connectivity (considering Bluetooth connection and DHCP protocol) while RON takes about 10 s to become aware that there is no path towards RPi (7.5 s to retry 3 times to send the packet towards the previously known path and 2.5 s to unsuccessfully look for an alternative path). Secondly, when node A2 receives the packet from L2, it has just switched network and then it has to wait for the following hotspot change period. It is worth noting that whenever LCC modifies network configurations it sends a message to the local RON, thus activating the latter as soon as additional connectivity opportunities arise and improving the efficiency of packet delivery. Considering only RON tasks and packet transmission, the delay of the first three hops is about 2.7 s per hop, of which 2.5 s to look for RPi (always unsuccessfully since there is no multi-hop path towards RPi) and the rest to transmit the packet to the newly discovered one-hop neighbor (since RPi is not available). Instead, in the last hop A2 successfully looks for RPi (the final destination of the packet) and sends the packet in about 0.2 s.  
To evaluate the quorum-based distributed actuation and resilience policy solution we have developed a PresenceSensor Java application (based on the Sensor component) running on two webcam-enabled Raspberry Pis and a laptop (nodes \(\text{RPi}_{\text{x}}\), \(\text{RPi}_{\text{y}}\), and L2, Figure 7) periodically acquiring images webcam and sending alert messages only if the previous and current images differ more than a threshold. In addition, a PresenceController application (based on the Controller component) runs on a laptop (node L1, Figure 7). Delving into finer details:  
* PresenceController on node L1 registers itself as a controller node offering the \"presence\" application;
* PresenceSensors on nodes \(\text{RPi}_{\text{x}}\) and \(\text{RPi}_{\text{y}}\) look for a controller node offering the \"presence\" application, and then join it;
* PresenceSensors on nodes \(\text{RPi}_{\text{x}}\), \(\text{RPi}_{\text{y}}\), and L2 periodically take pictures and broadcast alert messages whenever images differ more than 40% (default value);
* PresenceController on node L1 periodically sends pre-command messages to sensor nodes in the \"presence\" group;
* PresenceSensors on nodes \(\text{RPi}_{\text{x}}\), \(\text{RPi}_{\text{y}}\), and L2 reply with an here-I-am message to node A.