## 3 Novel Taxonomy for SSNs
### Low Level Virtualization
#### 3.1.2 LLV Based on Virtual Machine Solutions  
SSNs offer diverse Virtual Machine (VM) solutions to abstract the sensor node heterogeneity (diverse HW and diverse OSs) from the application developers, and to offer one controlling interface for developing and controlling the required applications; this makes the sensor node platform independent by offering separate execution environments for each application over the operating system. Thus, the VM is responsible for separating the sensor HW platform from the hosted applications by creating a separate virtual environment for each application over the operating system. Therefore, this section will focus on briefly listing them:  
* **Mate**[41]: is a tiny event-driven VM built on TinyOS, which is developed to enable energy efficient code propagation for reprogrammable sensor networks to serve different applications over the same network. Therefore, it may not necessarily be the most viable for SSNs, because it is mainly event-driven, offers sequential code execution under a stack of byte code interpreter, and only three concurrent applications can be run on the sensor node. To achieve optimal energy utilization, it divides the program codes into capsules, and each capsule contains 24 instructions with one byte long attached to its version to inform the sensor whether it needs to install this code or not. These capsules are propagated through the network using a distribution scheme among the sensors, where each sensor propagates it to its neighbors. When the instructions reach the destination, it starts to execute it in sequence, until the halt instruction is reached. The instructions are saved in two different stacks, one that is called operand stack to store normal instructions and the other is called return address stack to store the control instructions, which control the program flow. Implementing an adhoc routing protocol over TinyOS tested the performance evaluation of Mate, and the instruction rate, CPU utilization, and infection rates of the network were measured. The results proved that the instruction rate overhead from Mate is 10,000 times more than native TinyOS. While CPU utilization was increased by 33 cycles more than native TinyOS during simple operations, like (and-rand-send-sense) in the worst case. Finally, the infection rate of Mate was only 120 s to update all of the sensors over the network. * **VMSTAR**[42]: is a software framework that is based on java for building a runtime environment for WSN applications. Developers use it to develop required applications in java language through a rich programming interface; the resulting application can be portable to diverse of hardware platforms. It supports hybrid programming models with sequential and parallel task execution. Regarding SSNs, VMSTAR does not support the simultaneous use of multi-thread application tasks; instead, it only supports single-threaded Java applications. The framework consists of three components: the first one is BOTS component language, which defines the components with specified attribute values, the connection among them, and the conditions that trigger its selection. The second is the composition tool that analyzes the written component and determines the relations between them to satisfy specific constraints. The third is the updating mechanism, which is responsible for the incremental software updates after deployment, thus it updates the sensor software by accurate changes only. Notice that two models handle the hybrid programming models, the first one is called Select and it defines the sequential thread execution for simple applications by registering the interested events handlers for each application, which execute when the event occurs. While the second is called Action Listener and it handles complex applications by defining both of them, in this model, the applications do not resister for events, but it creates an application specific handling list through invoking event handlers.