# A Middleware Solution for Wireless IoT Applications in Sparse Smart Cities
## 4 The Link Connectivity Component  
To develop and deploy Wireless IoT Applications actually fitting the sparse Smart City environment, it is required to thoroughly and realistically consider not only the dynamicity of nodes carried by users, but also the actual availability of wireless interfaces in off-the shelf devices. On the one hand, in Smart Cities characterized by sparse nodes collaborating with one another to support Wireless IoT Applications, the dynamicity of the network mainly depends on the mobility of users; by moving from a location to another they access different IP subnets, increasing the probability of spreading packets towards their destinations. However, if users (and thus their smartphones) do not move for a relatively long time period, packet spreading is not possible, since smartphones keep exploiting the same IP subnets. On the other hand, to provide a solution that can be realistically adopted, requirements and constraints stemming from real-world environments must be taken into proper consideration. In particular, since nodes composing the overlay network are mainly based on off-the-shelf devices such as smartphones and laptops, device-to-device communication can be based on either IEEE 802.11 or Bluetooth, the only wireless medium-range protocols that are currently widely available. A main consequence of adopting IEEE 802.11 and Bluetooth is that each device can typically perform one-hop connections; IEEE 802.11s meshes and Bluetooth scatterers are not easily available on off-the-shelf devices. In other words, real-world scenarios do not allow typical WSN deployments where packets flow from node to node exploiting a single wireless interface in a multi-hop fashion as is possible by employing technology such as ZigBee. In fact, IP subnets provided by smartphones communicating in a device-to-device fashion may represent many connectivity islands of a statically partitioned network. Even the adoption of a multi-hop overlay layer based on opportunistic networking (with its capability of persisting and dispatching packets again) may be inadequate to correctly deliver packets, since the limited dynamicity of networks can prevent to disseminate packets towards their destination. In sparse Smart City scenarios, the probability of successfully dispatching packets to destination can be maximized by dynamically modifying the attachment network to increase the number of nodes where packets are transmitted to. To this purpose (and inspired by WiFi-Opp [35]), we have designed and developed the Link Connectivity Component (LCC) that allows re-configuring IP subnets by: (i) dynamically accessing different hotspots; and (ii) dynamically switching the role of smartphones from client to hotspot (and vice versa). It is worth noting that the overall network is still partitioned, since the adoption of IEEE 802.11 and Bluetooth does not allow to create multi-hop wireless links. However, the increased dynamicity of the connected networks allows to spread packets to a larger set of nodes, by taking advantage of the different network opportunities and IP subnets that may become available. Delving into finer details, LCC is based on three layered sub-components (see Figure 2, left):  
* the Configuration Component (CC) layer provides an abstract access to networking devices, hiding the complexity of accessing heterogeneous wireless protocols such as IEEE 802.11 and Bluetooth. In particular, it provides API to discover available hotspots, to connect to a given peer, and to switch the role from client to hotspot and vice versa. In addition, it provides a listener interface to allow external components to be notified about any network configuration modification in an event-based fashion, that is, to notify state change from client to hotspot or the modification of the hotspot a client is attached to;
* the Runtime Component (RC) exploits CC to dynamically modify network interface configurations, by periodically modifying the accessed hotspots and switching between client and hotspot roles.