## 2 Virtualization in Wireless Sensor Networks
### Operating Systems  
Operating Systems (OSs) for shared sensor networks are typically designed to alleviate the redundant deployment of sensor nodes in WSNs. We evaluate several OSs that consider resource sharing in their implementation. The design of the architecture for a WSN OS can be considered from a technical and a non-technical perspective. Technical considerations include WSN architecture, modularity, scheduling model, memory allocation, networking, programming model, debugging tools, programming language and hardware abstraction layers. Non-technical issues include  
Figure 1: A smart IIoT concept utilizing resource sharing. documentation, certification, code maturity and licensing. A wide range of OSs for shared sensor systems is evaluated. Our review covers the following OSs: Contiki [29], RIOT [30], TinyOS [31], OpenWSN [32], LiteOS [33], nuttX [34], PAVENET [35], MANTS [36], FreeRTOS [37], mbed OS, SenSmart [38] and SenSpire [39]. Other OSs that exist but are not covered in the table are eCOS [40], uClinux [41], ChibiOS/RT [42], CoOS [43], nanoRT [44], Nutt/OS, ERIKA Enterprise, ManOS [45], NanoQPlus [46], RTEMS, Lorien [47], ThreadX [48], QNX, PikeOS [49] and Nucleus RTOS [50]. A lack of highly-deterministic performance levels are typically exhibited by the platforms provided in Table 1, which is a critical factor to be considered when developing virtual frameworks. Future platforms need to address the lack of real-time performance in OS paradigms. Tiny OS lacks dynamic resource allocation while its counterparts provide dynamic resource management. Dynamic resource allocation is critical in decoupled ecosystems because the entire framework relies on on-demand resource utilization. Resources are not fixed to an application and thus they are shared among multiple application tasks. Virtualization techniques for resource sharing are implemented across the different OS platforms with a view to examine their efficiency levels. Contiki offers a rich networking stack that supports IoT ready protocols. It is imperative for IoT platforms to enable interactions between existing IPv4 networks, IPv6 and IEEE 802.015.4 based protocols [17]. Contiki supports \(\upmu\)IP, which is compatible with IPv4, \(\upmu\)IP6, IPv6, Rime stack, and with IEEE 802.15.4 related protocols. It is also imperative for the operating systems to support routing protocols for low power and lossy networks (RPL) [51] as they are integral components of the future progression of WSNs. The maintenance of sensor nodes should also be considered as it becomes daunting to maintain these nodes if they do not support over-the-air (OTA) updates. This means that for every firmware upgrade each sensor needs to be physically recalled for programming, which becomes a very difficult exercise to manage, considering the scale of future WSN. The need to support OTA is inextricably bound to the evolution of WSN towards shared ecosystems. In addition to the specific VWSN OS compared in Table 1, we provide further discussion regarding some well-known OSs particularly considered for VWSN as follows:  
1. [leftmargin=*]
2. SenSmart: SenSmart is a sensor based OS that supports simultaneous application tasks in resource constrained nodes [38]. In order to provide concurrent execution of different application tasks, SenSmart is designed with a stack allocation system that is managed dynamically at run time. This enables an unused stack space to be reclaimed from expired tasks that no longer require it. When a new task is initiated to run, the content of the current task is compressed and saved in a circular buffer for its resumption. This mechanism typically supports the concept of virtualization in WSN as it enables more nodes to access limited system resources as required. SenSmart is an event-driven programming model and thus follows a sense-and-send workflow model. This further supports its use in VWSN. It has been implemented in some hardware platforms including Mica2/MicaZ [38].