## 2 Virtualization in Wireless Sensor Networks
### Middleware and Virtual Machine-Based Approaches  
The middleware approach affords a developer the opportunity to operate at a layer above the host OS, as exemplified in Figure 2. Middleware is intended to satisfy a wide range of system design goals that are a challenge in traditional WSN. Some of the goals are to provide a high QoS [60], ease of programming, efficient resource management [61], scalability [62], agility support, reconfiguration of nodes [63], heterogeneity [64], virtualization [65], interoperability [66], large data sets and multi-radio support [67; 68]. Several academic research efforts have been put into modelling and implementing middleware for sensor nodes. Early efforts in this regard include Impala [69], EnviroTrack [70], Mires [71], Cougar [72], Smart Message [10], MiLAN [62], TinyLime [73], DSWare [74], TinyCubus [75] and TinyDB [76]. These implementations are typically plagued by different challenges, ranging from weak abstraction support and data fusion to a lack of dynamic topologies, rigid programming models, a lack of QoS support and a limited security policy [77; 60; 78; 79]. Some further research efforts are noted to have addressed the challenges concerning the middleware and VM-based approaches to WSNs. They yielded better efficiencies than the previous implementations. State-of-the-art implementations include among others include Agilla [80], VMStar [81], SenaaS [82], UMAPE [83], Squawk VM, Mate [84], Nano-CF [44] and SenShare [85]. The programming model is predominantly threaded and event driven. Event driven paradigms enable energy conservation by only sending data/information when critical threshold conditions have been reached, otherwise the messages will not be critical and energy-worthy of transmission. The threaded model allows for the design of distributed algorithms while enabling the underlying network to conceal the heterogeneous nodes. However, programming overheads are experienced in [69]. There are limited emphases on real-time performance in the surveyed platform. Earlier implementations may not have focused on this aspect, however, both SenShare [85] and Pavenet [86] are noted to have elements of real-time performance evaluations. The dynamic nature of virtualized platforms indicates that highly-deterministic behavior is required for the success of distributed logically connected layers. A few notable VM based solutions are briefly discussed with regards to VWSN, and summarized in Table 2, as follows:  
1. VMSTAR: It is a Java-based software framework for developing application-specific virtual machines [81]. It supports the sequential and simultaneous use of thread-based applications. For VWSN, VMSTAR does not support the simultaneous use of multi-thread application tasks, instead, it supports only single-threaded Java applications. However, concurrent events can be handled using action listeners [81]. This can be used to identify high priority threads so that expired threads can be relied of system resources to cater for other application tasks. 2. Squawk: This is also a Java virtual machine that runs on sensor hardware [84]. Different from VMSTAR, Squawk does not require an OS in order to run, instead, all its basic requirements are inbuilt. For VWSN, Squawk adopts a different approach compared to other solutions. First, it provides an application isolation mechanism, which enables multiple application tasks to be  
Figure 2: Middleware Approach. treated as Java objects [84]. Thus, applications can have multiple threads, which are managed by the Java Virtual Machine (JVM). * Agilla: It is a mobile agent-based middleware that runs over the TinyOS along with a VM engine to conduct sequential execution of multiple applications [80]. This is normally done in a round robin manner. For VWSN, Agilla depends on the TinyOS in order to provide simultaneous execution of tasks. It also guarantees this via the mobile agents executed in a round-robin style [80]. However, the difficulty in the programming language adopted by Agilla typically limits its use for VWSN.