# A Middleware Solution for Wireless IoT Applications in Sparse Smart Cities
## 5 The RON Component for Networking Overlay  
The RAMP Opportunistic Networking (RON) component (Figure 3) extends the RAMP middleware by enhancing features already provided by the Continuity Manager (CM) component [3]. Figure 2: Link Connectivity Component (LCC) architecture (**left**) and Android GUI (**right**). In particular, CM is in charge of detecting path disconnections and packet dispatching failures (notified by the Dispatcher RAMP component) and trying to take proper countermeasures. CM waits for a short time interval, interacts with the Resolver component in charge of looking for alternative paths to the destination, and sends the packet towards the (possibly discovered) new path. It is worth noting that CM only keeps packets on volatile memory, periodically looks for other paths only for brief intervals (typically in the range of some seconds), and forwards packets only if a path to the destination is found. In cases where a path is not found, the packet is dropped. RON interacts with CM to intercept packets that would otherwise be dropped, and adopts opportunistic networking techniques [37] to maximize packet delivery probabilities. To this purpose, we have extended the header of RAMP packets by specifying two new metadata:  
* an Expiry value in seconds (4 bytes). The sender application exploits novel sendUnicast(... ) API to (optionally) specify the Expiry value. Then the RON component exploits this value to understand if and for how long the packet should be managed opportunistically;
* a unique Packet Id (P-ID) that should be valid till the expiration of the packet itself. To this purpose, on the sender side, the RAMP middleware transparently adds a random P-ID (4 bytes) in the header. This solution is envisioned as a proper tradeoff between simplicity of implementation and soundness of the solution, since it is very unlikely that two nodes in the same opportunistic network create the same random packet id, also considering that in most actual scenarios the packet expiry value is typically in the range of hours. In particular, the primary activities of RON are:  
1. RON drops the packet if it is expired (Expire \(\leq\) 0) or if it is a duplicated (by exploiting a volatile database containing the set of P-ID related to already managed packets);
2. in case the packet is still valid, it saves it on persistent memory, eventually removing other persisted packets in case the amount of dedicated memory (configured by the user, mainly dependent on the storage capacity of the node) is full, such as by adopting traditional \"remove oldest/biggest\" policies (out of the scope of this paper);
3. then, it deserializes packets from the persistent memory in a periodic fashion (typically every 10 s, user configurable) and whenever the CC layer of LCC notifies a network modification. For each deserialized packet, it appropriately decreases the Expiry value, and (if the packet is not expired) exploits the Resolver component to look for a path towards the destination: 1. if a path is found, the packet is sent to the destination and discarded by the local memory; 2. if a path is not found, the packet is duplicated based on the known spray & wait [38] policy (different, more articulated policies can be adopted, but they are out-of-the-scope of this paper) and sent to N one-hop neighbor nodes (N set by the user, default value is 3), with the main purpose of maximizing the probability of correctly dispatching the packet to the destination. To limit networking overhead, nodes take care of not sending the same packet to the same one-hop neighbor more than once. In addition, the destination node should be aware that the same packet could be received more than once, for example, dispatched via different multi-hop paths, taking advantage of the P-ID value to discard duplicated packets.