## 3 Novel Taxonomy for SSNs
### Low Level Virtualization
#### 3.1.1. LLV Based on Operating System Virtualization Solutions
LiteShell subsystem is a command shell interface that runs on the base station PC side, it is responsible for interacting with sensor nodes only when a user is present to execute file commands, process operation commands, debugging commands, environment commands, and device commands. The LiteFS subsystem contains the description of the hierarchical file system, its architecture is divided into three modules: RAM, EEPROM, and Flash memory, and RAM is concerned about keeping the opened files and their allocation and data information in both of EEPROM and flash, EEPROM handles the information of the hierarchical directories, finally Flash is responsible for storing the actual data. Although the kernel subsystem is based on thread based programming, it allows for user applications to handle events using a callback mechanism. Kernel also implements hybrid scheduling mechanisms priority-based and round-robin, and it supports dynamic loading and un-loading of user applications. The performance evaluation for LiteShell studies the average command response time that is sent by it for different commands, and the average delay of common network commands. Subsequently, the performance evaluation of LiteOS is compared with TinyOS, which proves that the length of the source code for one program written by LiteOS is less than it when written by TinyOS, while it consumes more memory than TinyOS; which is due to the multi-threading support. * **Contiki**[39]: is a highly portable, multi-tasking open source operating system, and the one of the most popular systems for WSNs, which leads it towards the Internet of Things technology. Where it is able to connect tiny low-cost, low-power microcontrollers to the Internet, with its main features are wireless dynamic loading and the unloading of a code at run time using over-the-air protocol and the possibility of multi-threading on the top of an event driven kernel. Thus, Contiki is highly applicable in SSNs, because it supports multiple applications that are typically independent of the OS and can invariably run on top of it. Applications are written in C language and can be ported to many hardware platforms and updated/installed without reinstalling the entire OS. Additionally, it does not provide a hardware abstraction layer. Thus, communication between processes (applications or services) and hardware is direct and it always goes through it. The Contiki architecture consists of kernel, libraries, program loader, and a set of applications, as shown in Figure 8.0  
Figure 8.1 LiteOS Architecture. Figure 8.2 Contiki Architecture. Kernel is based on protothreads (the concept that shares the features of thread-based and event-driven approaches to attain a low memory overhead). There are three core libraries: core program libraries, loadable program libraries, and specific service libraries; all of them are connected to programs if an application explicitly uses it. The program loader uses the run-time relocation function to load programs into the system, which uses the loader to test the available memory space, if enough of the program will be loaded, otherwise it will be aborted, then the loader will call the program's initialization function. Processes can only be executed through the event handler and poll handler functions. Before actual deployment, Contiki offers a network simulator, called Cooja. The performance evaluation was not studied in the original paper of Contiki OS [39], but a comparison for it with TinyOS was presented in [40], which was concerned with resource usage where the memory usage and task execution time for Contiki programs were found to be higher than them in TinyOS, also the flexibility of both was considered, and proved that the Contiki was more flexible than TinyOS; that is due to the dynamic reprogramming of sensor nodes that only updates the changes, while it updates the whole application in TinyOS.