## 3 Middleware for WSN Virtualization
### Middleware for Sensor Virtualization
Performance evaluation shows the design reduces the cost of network, execution time and CPU usage. However, the overhead caused by the multi applications on memory and, the lack of energy awareness of the design needs more attention. At the University of Cambridge the Federated Secure Sensor Network Laboratory (**FRESNEL**) carried a project that includes monitoring social events of users in real-time. Middleware facilitates sensor virtualization. Several sensors were deployed in the users' working environment. These sensing devices monitor the behavior of the employee. The privacy issue was the main concern in social networking. **SenShare** under **FRESNEL** project at the Cambridge University takes into account the middleware running multi applications on different networks [20, 47]; Instead of traditional fit for purpose sensor networks [48]. The SenShare middleware tackles few challenges regarding the management of the services, communication links of a single application running on different network nodes, and the isolation of applications within the network. SenShare decouples the applications from the network making virtual sensor network on top of the physical sensor network. Furthermore, SenShare middleware supports two applications: office occupancy and environmental monitoring in a building. An application running on SenShare can span across the whole network or selected subset of the physical network. Dynamic subsets of the sensor network are constructed through an overlay topology. The middleware is implemented on power sensor nodes. The main concentration of SenShare is sensor virtualization. Middleware is implemented on top of the embedded Linux (v.2.6.29) OS platform. SenShare uses cross-application Hardware Abstraction Layer (HAL) as a middleware instead of Virtual Machine, which defines set of interfaces for decoupling of the sensors from the applications. Middleware supports split-phase interrupt handling technique. Furthermore, SenShare supports TinyOS applications in the shared environment. The major components of the middleware are network and sensor interface, application control. Access to hardware is made asynchronously through Multitasking OS that acts a HAL. The key challenges for SenShare is to limit the overhead of sensor I/O which is caused by the additional layer of abstraction, and the race conditions caused by applications demanding high access rate to the same source. SenShare runtime adds application packet with an application routing header of 6 bytes. The overhead is likely to increase with the number of applications increasing. The virtualization layer causes linear overhead that grows gradually and slowly. The virtualization generated traffic is also the overhead on the network, but it gradually becomes low as the network life increases. The application cannot change the transmission radio of the interface, thus limits the access to the communication modules. **Servilla** middleware is aimed to tackle the heterogeneity of different sensor nodes, and facilitate them to run different applications over heterogeneous nodes. Using Servilla developers can develop platform independent applications. It supports the discovery and use of local and remote services in a heterogeneous environment. Moreover, its bases lie in the modular SOA. Servilla address decoupling of the application from the hardware while considering energy saving as one of its key attributes. Servilla encourages different types of nodes in a single WSN (e.g., Imote2 and TelosB). Several devices with different hardware specifications like processing capabilities, storage and communication range should execute the task according to their strengths and weaknesses [49]. This would result in an efficient utilization of the WSN resources. Furthermore, servilla provides a platform to build applications that are long lived, wide-range and based on different tasks with respect to their scale, power consumption and complexity for both resource rich and resource poor devices in a single network.