## 3 Novel Taxonomy for SSNs
### Low Level Virtualization
#### 3.1.3 LLV Based on Middleware Solutions
The upper layer contains the mobile agents, as mentioned above, while the middle layer contains the Agilla middleware, which consists of multiple components that are controlled by the Agilla engine, including the agent code, context, tuplespace, and reaction managers, with each of them providing a different service, where the agent manager provides the agent execution state, the code manager provides a dynamical allocation service of code memory for each agent and fetches instructions as the agent executes, the context manager provides an updated list services of neighboring nodes, the tuple space manager provides the local tuple space services that implements the nonblocking operations (both local and remote), and the reaction manager provides a store of registered reaction services by the local agents and determines when a reaction should fire. The performance of Agilla was evaluated using two physical testbeds, which consisted of 25 nodes with different vendors (Mica2 and TelosB) to measure its feasibility and efficiency. The Agilla programming model was demonstrated while using three real applications (fire detection, tracing, and Monitoring Cargo Containers); the results show that the migration latency linearly scales with the number of hops, where the migration succeeded by 99% for three hops and then decreased as the number of hops increased, although the additional overhead for reliable operations is justified by their resilience to message loss across multiple hops. Figure 14: Agilla’s model. * **TinyLime**[50]: is a data-sharing middleware for WSNs that aims to provide a centralized approach for data gathering and aggregation that is based on location dependent applications. This implementation is typically plagued by challenge in weak abstraction support, and a lack of dynamic topology. Thus, it is not suitable for SSNs. Where, instead of gathering data using a central station, it offers multiple mobile stations to gather data from nodes in their proximity. It shares the sensor data using a tuple space interface, which hides memory sharing between the applications and sensor nodes, allowing for information sharing among neighbors and supports application tunable energy utilization by giving the user the ability to turn the logging of values on the sensors on and off. The internal architecture of TinyLime consists of MoteLimeTupleSpace, MoteLimeTuple, MoteLimeTemplate, and the condition and aggregation classes, which are needed by a client application, as can be seen in Figure 16. Where MoteLimeTupleSpace presents the illusion of a single tuple space containing sensor data to the client, which is internally divided into two Lime tuple spaces, one to hold sensor data and the other for communicating requests from the client. A user can create a MoteLimeTemplate to access the allowed applications. The performance of TinyLime was evaluated using the Crossbow MICA2 platform (Cisco,; the results showed that the response times varied from 0.0049 s to 0.20 s, depending on CPU load. With the low CPU usage, the average was approximately 0.008 s and, as the number of motes increased, the response time is decreased. Figure 16: TinyLime Architecture. Figure 15: Agilla Architecture. * **TinySOA**[51]: is a service oriented middleware that abstracts the low-level details of WSNs from application programmers and it allows them to access it from their applications by using a simple service-oriented API via the language of their choice to facilitate the way of accessing and controlling WSNs, because TinySOA aims to integrate the internet applications and the WSNs. As can be seen in Figure 17, the TinySOA architecture consists of a node, gateway, registry, and server cooperated to serve internal and external services that are provided by TinySOA.