## 3 Novel Taxonomy for SSNs
### Low Level Virtualization
#### 3.1.4 An Insight on the Application of LLV  
This section will provide us with the result of studying virtualization in LLV, where Table 2 provides a summarization of some characteristics for each virtualization solution. At the beginning from the study, it is concluded that the preferred programming model in virtualization solutions is the thread-based rather than the event-driven. Although it is more complex, it provides better execution for the concurrent tasks. As for the OS, it is concluded that:  
The extremely popular OS are TinyOS, Contiki, and RIOT; they have a good support community. However, TinyOS provides a weak form of virtualization, because it is based on event-driven programing model, and the relation between the OS and the application is tightly coupled. Additionally, its task scheduler is sequential (FIFO based) and, thus, the task execution runs until entire completion. However, Contiki is a better choice, because it provides many innovative features over the last years that makes it a better platform for IOT. Nevertheless, looking for future trends and large-scale deployments, like smart cities, the RIOT is a fresh approach that provides general purpose solutions for divers of IOT devices, because it uses a real-time thread-based programming model. Threads execution is based on its given priority. The application tasks are codes decoupled from hardware and software, which makes it suitable for a wide range of devices. All other OSs solutions that are covered by this review are less popular than the three described above as SenSmart, SenSpire, MANITS, LiteOS and PAVENET and can be evaluated, as follows:  
* SenSmart: To support SSN, it provides application codes programmed and compiled in binary code for each, then combines them together in a single code image and links it to the kernel to be tested and then generate the final code. This strategy of compiling and linking to the kernel means that there is no separation between the OS and application tasks. Therefore, any application updates should update all the sensor software. While its main drawback is the lack of portability, it is the approach that shows how a better hardware design can lead to an efficient sensor OS. * SenSpire: It supports a hybrid programming model, where system tasks are implemented as event-based tasks, while the application tasks are implemented as thread-based tasks with low priority than the event-based. Thread-based follows the run-to-completion model, which executestasks in a sequential (FIFO) manner. Additionally, programming with Cspire is a learning curve for developers. Due to the application being tightly coupled to the OSs, there is a need for updating all sensor software in the case of any application updates. Finally, it has lack of portability. * MANTIS: This OS is considered to be suitable for SSNs because it provides a complete thread-based system with a multithreading approach that simultaneously runs application tasks without the need to manage low-level details of the stack/memory. Applications threads are coded in C and they are loosely coupled with the OS. However, it has a weak support community. * LiteOS: It is highly flexible for SSNs, because it uses a programming environment that is based on C and it allows a hybrid programming model that combines the simultaneous execution of application threads and events through a call-back mechanism. The application is loosely coupled with the OS through call gates pointers. * PAVENET: In order to support SSNs, it supports thread-based programming and the use of C language. It is possible to ensure varying priority levels via the use of programmed multithreaded applications. However, task execution is sequential, because time-slicing is not supported. Additionally, the application is tightly coupled with the OS, thus any application updates will reinstall all sensor software. However, its main drawback is the lack of portability.