## 3 Virtualization: A Solution to Some Challenges in WSN  
Having presented an overview of VWSN, in this section we consider VWSN in view of some of the existing challenges in WSN. Future IIoT applications will most likely require the sharing of infrastructures as opposed to the lone ownership of the infrastructure by a specific provider. Many sectors of the global economy are shifting towards resource sharing models and the management of sharing is offered using on-demand service platforms. Traditional WSNs are deployed to a specific application area for sensing, communication, actuation, and for computational purposes. With increasing number of sensing applications, sensors might need to access data/information that lie outside the designated network or privileged data/information meant for specific users. Thus, sensor hardware infrastructures can be shared by various applications. Sharing sensor nodes are given access to the underlying hardware while being separate from each other in order to carry out their different roles. It further requires that the application tasks are not fixed to a particular node but are rather dynamically assigned to a node resource whenever they are required. Therefore, an application task is not guaranteed to use the exact sensor node it used in a previous task allocation. Access is granted using a distributed and dynamic key management technique [98] that allows multiple applications to access the underlying hardware. To this effect, the interaction between different applications and sensor nodes are not physical but logical leading to the concept of VWSN. \begin{table}
\begin{tabular}{c c c c c c c c c} \hline \hline
**Platform** & \begin{tabular}{c} **Programming** \\ **Model** \\ \end{tabular} & \begin{tabular}{c} **Resource** \\ **Discovery** \\ \end{tabular} & **Type** & **Heterogeneity** & \begin{tabular}{c} **Platform** \\ **Independence** \\ \end{tabular} & \begin{tabular}{c} **Multi-radio** \\ **Support** \\ \end{tabular} & \
\begin{tabular}{c} **Programming** \\ **Language** \\ \end{tabular} &
\begin{tabular}{c} **Protocols** \\ \end{tabular} \\ \hline
**Contiki**[99] & Protthreads & No & OS & Yes & Yes & Yes & C &
\begin{tabular}{c} HTTP, COAP, UDP, \\ TCP, RPL, \&LoWPAN \\ \end{tabular} \\ \hline
**RIOT**[30] & Threaded & Yes & OS & Yes & Yes & Yes & ANSI C/C++ & 6 LoWPAN, RPL \\ \hline
**TinyOS**[31] & Event-driven & No & OS & Yes & Yes & Yes & neS C & 6 LoWPAN, ZigBee \\ \hline
**OpenWSN**[32] & State-machine & No & OS & Yes & No & No & C & 6 LoWPAN, RPL, CoAP \\ \hline
**FreeRTOS**[37] & Threaded & No & OS & Yes & Yes & No & C &
\begin{tabular}{c} Third-party network \\ stacks \\ \end{tabular} \\ \hline
**VMStar**[81] & Threaded & No & VM & No & No & Java & NA \\ \hline
**SenaaS**[82] & Event-driven & No & VM & Yes & Yes & No & NA & NA \\ \hline
**SenSmart**[38] & Event-driven & No & OS & Yes & Yes & No & neS C & NA \\ \hline
**SenSpire**[39] & \
\begin{tabular}{c} Event-driven \\ and threaded \\ \end{tabular} & No & OS & Yes & Yes & No & CSpire &
\begin{tabular}{c} CSMA, CSMA/CA, \\ B-MAC, X-MAC \\ \end{tabular} \\ \hline
**Agilla**[80] & Tuple space and & Yes & VM & Yes & No & No & Assembly-like & NA \\  & mobile agent & & & & & & & \\ \hline
**LiteOS**[33] &
\begin{tabular}{c} Event-driven \\ and Threaded \\ \end{tabular} & No & OS & Yes & Yes & No & C & NA \\ \hline
**PAVENET**[86] & Threaded & No & OS & No & No & No & C & TMA \\ \hline
**MANTS**[36] & Threaded & No & OS & No & No & No & C & TMA \\ \hline
**UMADE**[83] & Event-driven & No & VM & No & No & No & neS C & NA \\ \hline
**Squawk VM**[83] & Threaded & No & VM & No & Yes & No & J2 ME &
\begin{tabular}{c} CTP, 6 LoWPAN, \\ AODV, LQRP \\ \end{tabular} \\ \hline
**Nano-CF**[44] & Event-driven & No & VM & Yes & Yes & No & Nano-CL & DSR, TDMA, B-MAC \\ \hline \hline \end{tabular}
\end{table} 
Table 3: A comparison of different virtualization platforms.