# A Middleware Solution for Wireless IoT Applications in Sparse Smart Cities
## 8 Experimental Results  
We have thoroughly tested our prototype to quantitatively evaluate effectiveness and responsiveness along two primary guidelines:  
1. evaluation of the RON component while dispatching packets in a sparse Smart City scenario exploiting our LCC and RAMP-WIA. In this case, the main purpose is to quantitatively demonstrate that the proposed solution effectively dispatches packets at multi-hop distance also in a sparse wireless network composed by off-the-shelf devices;
2. evaluation of the quorum-based distributed actuation and resilience policy solution. In this case, the goal is to test the effectiveness of the proposed solution by showing how sensor nodes dynamically discover/join controller nodes and adopt the resilience policy in case a controller node is not available anymore. In order to estimate the RON component behavior, we have deployed our middleware in a multi-hop spontaneous environment with: Android smartphones with 2.1 GHz Cortex-A53 processor and 3 GB of RAM, running Android 7.0; Raspberry Pi 3 Single Board Computers (SBC) with 1.2 GHz ARM processor and 1 GB of RAM, running Linux Raspbian 8.0; laptops with a 2.70 GHz Intel Core i7-7500U CPU and 16 GB of RAM, running Ubuntu 17.04 Zesty Zapus; laptops with a 2.70 GHz Intel Core i7 CPU and 12 GB of RAM, running Ubuntu 16.04.02 Xenial Xerus. Let us stress that the main goal of this section is to verify and assess the effectiveness of the proposed approach by focusing on a few key aspects of the implemented RAMP-WIA middleware. In particular, performance results reported below are based on experimentation over real and off-the-shelf devices, with the main purpose of testing the technical soundness and practical feasibility of the communication and coordination mechanisms used in RAMP-WIA. More extensive and comprehensive performance results, based on a city-wide large-scale testbed, are out of the scope of this paper and one of the most relevant foci of our future research work. First of all, we have tested the two-hop environment in Figure 5, formed by a Bluetooth hop between an android device (A\({}_{1}\)) and a laptop (L\({}_{1}\)) and a IEEE 802.11 hop between L\({}_{1}\) and a Raspberry Pi 3 (RPi), performing the following steps:  
* [noitemsep,topsep=0 pt]
* t\({}_{0}\): A\({}_{1}\) sends a packet to RPi but the Bluetooth is not available and the packet is persisted by RON;
* t\({}_{1}\): A\({}_{1}\) (manual configuration) creates a Bluetooth link with L\({}_{1}\);
* t\({}_{2}\): after a while RON on A\({}_{1}\) retrieves the persisted packet and looks for the destination node RPi;
* t\({}_{3}\): RON on A\({}_{1}\) does not find any available path towards RPi since the IEEE 802.11 link is not available. Therefore, it sends the packet to the neighbor node L\({}_{1}\);
* t\({}_{4}\): L\({}_{1}\) receives the packet and tries to dispatch it to RPi. However, since there is no path currently available, RON on L\({}_{1}\) persists the packet;
* t\({}_{5}\): L\({}_{1}\) creates a IEEE 802.11 link with RPi (manual configuration);
* t\({}_{6}\): after a while RON on L\({}_{1}\) retrieves the persisted packet and looks for the destination node RPi;
* t\({}_{7}\): RON on L\({}_{1}\) finds a path towards RPi via the IEEE 802.11 link and thus it sends the packet to RPi. We have tested the sequence above 10 times, achieving an average end-to-end packet dispatching time of 115.8 s with a standard deviation of 4.8, demonstrating that the proposed solution can dispatch packets towards the destination in environments characterized by frequent network partitions, by fully exploiting any connectivity opportunity. Note that the previous values also include the time required to manually configure the network, which comprises the time between t\({}_{0}\) and t\({}_{1}\) and the time between t\({}_{4}\) and t\({}_{5}\) estimated in 55 s per-hop.