## 5 Overlay Virtualized WSN: Some Design Requirements  
The use of Overlay networks in shared sensor networks will require the deployment of resource rich hardware. According to [PERSON] [151], the processors are getting more efficient and faster. Thus, sensor nodes may soon be less limited by the available resources at the hardware level. Advances in silicon fabrication will also enable sensor nodes to be resource rich and energy efficient. Following this, it is envisaged that elastic network designs will ensure that routing protocols are capable of catering for the demands of virtual network implementations. As more multiple applications concurrently access the available resources, there is need to have a robust resource management and utilization framework. This framework will be able to adjust to the changing demands of the network. The co-existence of resource rich and constrained nodes will entail a high level of heterogeneity support. [PERSON] et al., in [12] addressed the challenge of heterogeneity support by adding a gate-to-overlay node. This node assists other resource limited nodes to participate in the overlay network via cooperation. Such an implementation introduces complexities in the architecture. The application services need to be isolated to ensure that the entities of the next application does not intrude into the next application without relevant authorization. This is done in conjunction with the security framework that needs to be put in place to mitigate the risks of concurrent execution of applications. Nodes that enter the network at runtime will be managed through the same security framework. As the network scales on the physical side, the overlay architecture should be able to adjust dynamically to the underlying hardware. Connections between the overlay network and the physical network are not permanent are normally established on-demand. Consequently, their reliability becomes a function of the QoS. Over-the-air (OTA) firmware updates remain a crucial aspect of the design requirement, as they enable wireless reprogramming. Generally, sensors should not be recalled from the field in order to conduct a firmware upgrade. Thus, a modular design will provide an ease of programming OTA. Modularity will enhance the system design and provide pluggable units that make maintenance and development manageable and efficient. Furthermore, network interfaces on the application side should be IIoT compliant [152] by being ready and lightweight with a robust interoperability context. In this regard, resource discovery plays a pivotal role in the overall architecture of an OVWSN. Concurrent resource requests from different applications demand that the discovery techniques be highly efficient and flexible. The creation of the overlay topology should be fault tolerant and immune to single-point-of-failure problems. OpenThread is a potential solution to the self-healing demands of network topologies offering a mesh topology. Following the above notes on some design requirements for OVWSN, the following summary is provided:  
1. _Multiple application execution_--The loose coupling between the application tasks in the overlay network and the underlying infrastructure enables dynamic resource sharing and for several applications to utilize same hardware with the illusion of lone ownership, which forms the core of shared sensor systems. 2. _Robust and IoT ready routing protocols_--Several lightweight routing protocols exist in the IoT domain that are poised to take the lead in framing the standard protocols for data exchange in WSN. A few protocols like CoAP [153] have exhibited dynamic response to their operation in virtual frameworks as well as in overlay networks. 3. _Resource-rich nodes_--Recent advances in silicon technologies have produced a rise in the number resource rich sensor nodes being used for WSN. With the increase in the demand for shared sensor systems, it is imperative that resource rich nodes allow for energy efficiency, yet producing high throughput.