«Carles Gómez Josep Paradells José E. Caballero Edita: Fundación Vodafone España Autores: Carles Gómez Montenegro* Universitat Politècnica de ...»
Middleware research is a well known topic in traditional computing environments. However, it is quite new in the area of WSNs and exhibits several key differences from the traditional middleware. Some of them are as
Traditional middleware tries to hide context information to make an application independent of the scenario where it is used. WSNs constitute the opposite case, since applications usually require context-awareness.
Mobile computing middleware is focused on facilitating applications running in the terminal, with the aim of maximizing the interests of the user. In WSNs, the objective is to facilitate the development of sensor based applications, which can be consumed anywhere, and from which the generated data need to be collected and processed, so a whole network should be optimised.
Traditional middleware is focused on the end-to-end paradigm of the Internet54. In WSNs, it is assumed that sensor nodes, sink nodes or gateways might have a relevant role in the communication; therefore the middleware needs to adapt the different functions of these nodes.
Middleware in WSNs should be light due to the limited resources of the nodes. This is not the general case in traditional middleware.
According to the end-to end paradigm, communications protocol entities should be placed at the end-points of a communications system.
Chapter 16. Middleware
In the recent years, several researchers have tried to give a general view of middleware for WSNs [1, 2, 3, 4, 5], but they provide only partial views (system architecture, programming paradigms and run-time support, etc.) and hence do not cover all aspects. The problem is probably related with the availability of different middleware proposals for different specific applications, and the close relationship between application, middleware and WSN. This situation makes it difficult to state which components should be present in a middleware solution. The only valid approach is to take a general view, in the knowledge that in a real implementation only the required components and the most efficient approach should be used.
16.2. Components of a generic middleware solution for WSNs
Middleware functions can be located in different places, either individually or in a distributed approach, such as sensor nodes, sink nodes, high level application terminal, etc.
A complete middleware solution should at least include the following
• Programming abstraction: this defines the interfaces to the middleware for the application programmer.
• System services: implemented functions to enable programming abstractions.
• Run time support: extensions to the embedded operating system to support middleware services.
• QoS mechanisms: they define the QoS constraints of the system.
16.2.1. Programming abstractions A WSN should be offered to the application programmer through the middleware. The way the programmer views the system is referred to as the abstraction level. The model used to program the application is known as
the programming paradigm. Finally, the programming interface used corresponds to the mechanism used by the application to access the middleware functions.
184.108.40.206. Abstraction level The system can be seen at different levels, offering more or less insight
into the WSN, as for example:
Local (i.e. node level abstraction): this allows the individual node to be reached and presents the system as a collection of distributed nodes. This approach is useful for building efficient communications between nodes and is flexible, depending on the application. One disadvantage is that it requires certain knowledge of the sensor node from the programmer.
Global (i.e. system level abstraction): this abstracts the WSN as a single virtual system and allows the single centralized program to be expressed into subprograms that can be executed on local nodes. It also allows the programmer to concentrate on the application, while avoiding the details of the nodes. Applications might prove to be less efficient in terms of resources consumed in the WSN.
220.127.116.11. Programming paradigms
Programming depends on the application to be carried out by the WSN.
Since some of the most widely used applications are related to data collection, the WSN can be seen as a database where sensor data is the information stored in the database, or as a publish/subscribe service where data from sensors generate an event for the application. To cope with the mobility of the WSNs, or with the phenomena the WSN wants to capture, mobile agents are also proposed as a programming paradigm. Another approach is the use of rule-based declarative languages for command execution. On the other hand, because the sensor node operating systems do not provide enough support for middleware services, virtual machines are used to support runtime. Finally, some middleware solutions come with graphical user interfaces, which include a query-builder and result display.
18.104.22.168. Interface type
The way the application relates with the middleware can either be:
i) declarative, providing data about which information is required and ii) imperative, offering commands that should be carried out. The first one may be based on Structured Query Language (SQL) languages or XML, and is used for database programming paradigms. The second is used for publish/subscribe programming paradigms.
16.2.2. System services
WSN middleware is based on a set of functionalities that form the middleware core. They are offered to the application programmer through the abstraction interface and provide the support for application deployment, execution and WSN management. System services, which are the key
middleware services, can be divided into two categories:
• Common services: basic services shared by all WSN applications. A detailed description of the common services is presented in Section 16.3.
• Domain services: services that facilitate the development of an application in a specific domain. They use the common services and add application oriented functions.
It is quite common to define the middleware in two layers. The lower one corresponds to common services, whilethe upper layer has the application specific functionalities.
16.2.3. Run-time support
Run-time support may be regarded as an extension of the functionalities provided by the operating system of the sensor node needed to support the functionalities of the middleware. Some of these functions are: scheduling of tasks, process communication, memory control and power control (with voltage scaling or component activation and deactivation).
16.2.4. QoS mechanisms The QoS for WSNs is an open issue, mainly due to the lack of understanding about the QoS concept in WSNs and how it can be implemented. In addition to the traditional QoS parameters (such as delay, jitter or bandwidth), there exist other QoS parameters in WSN, such as data accuracy, aggregation delay or system lifetime. This fact makes the implementation of QoS techniques even more complex. The positive point of view for supporting QoS is the role of the middleware between the application and the WSN. The middleware can act as a broker by collecting the requirements of applications and status of the WSN and allocating resources to offer the demanded QoS.
16.3. Middleware system common services As mentioned above, the system services are the key functionalities of the middleware. They can be classified into code management, data management, data storage, resource and information discovery, resource management, integration and security.
16.3.1. Code management A distributed WSN uses pieces of code that are allocated to certain nodes and are executed. This code should be installed and updated, and even moved according to the QoS criteria or the location of the phenomena the WSN is monitoring. Code migration can be implemented at OS level, as in some specific OSs such as BertaOS or MagnetOS. However, since WSN OSs do not support code interpretation, this code migration is difficult to implement in a heterogeneous network. Some middleware support task migrations such as in SensorWare (with Tool Command Language (TCL) Scripts), SINA55 (with SQL Scripts) or TinyLime56 (with Java Objects) . Mobile Agent SINA stands for Sensor information networking architecture  TinyLime is an extension of Lime for the sensor network environment 
is a further approach where the code, the state and the data are encapsulated and moved from one node to another. Code management is offered on top of a virtual machine to hide the sensor node heterogeneity.
16.3.2. Data management As previously mentioned, WSNs are data-oriented and must support the following functions: data acquisition, data processing and data storage.
The first task, data acquisition, implies collecting relevant and accurate data. Most of the WSN middleware proposed solutions use mechanisms that are event based , such as TinyDB, DSware, Mires or Impala. Other solutions use a query based model  such as TinyDB, Cougar or SensorWare.
Data processing can either be done in a centralised manner (i.e. in a node outside the WSN), at node level, and hence delivering processed data to the rest of the network, or at a network level, also known as distributed processing. There is a compromise between communication costs and computation costs. However, it is well known that processing is much cheaper than communication in terms of power consumption.
Data fusion and data aggregation are interesting functionalities supported in a network level data processing implementation. These functions can be supported at lower layers, but placing them in a middleware layer seems the best solution since data can thereby be fully analysed.
Finally, data from the WSN can be stored externally, either in the sensor node where the data have been generated or in the node where the data have significance.
16.3.3. Discovery of nodes, resources and characteristics
These types of service are responsible for discovering newly joined sensors, resources associated to the nodes and information about the network and nodes (network topology, neighbour nodes and node locations). Some WSNs re-use existing discovery services protocols such as Service Location Protocol (SLP) or Bluetooth Service Discovery Protocol (SDP).
Resource and information discovery middleware provides underlying network information to applications that are required to be adaptive. It also provides information to the underlying network to support the adaptive resource management services.
16.3.4. Resource management Resource management is related to the usage of resources according to applications and lower layer protocols. Resource management is responsible for cluster service (for organizing nodes into groups), schedule service (to decide the order and time for using the network) and data routing service (offering an upper layer or selecting a routing protocol at network layer).
WSNs do not work in isolation from the rest and require to be connected to other networks, in particular to the Internet. Several approaches are offered through middleware. The most popular one employs a proxy server that translates the protocols between the two networks. A service oriented approach is also possible, based on Web Services Description Language (WSDL) and Simple Object Access Protocol (SOAP).
16.3.6. Security It provides all the security mechanisms not available by the WSN. In particular, key management is one of the more important aspects.
16.4. Examples A significant number of middleware solutions have been proposed. Some of them have been built as a prototype and tested, while others have only been simulated. Tables 16.1 and 16.2 summarize the features of the most relevant solutions.
Note1: SensorSim, TOSSIM, GloMoSim, ZnetSim and Mica2 are general purpose simulation and testing tools Table 16.2. Development status of some of the middleware proposals available for WSNs (adapted from )
In general, the different middleware proposals are not yet sufficiently mature. The global objective is too complex and solutions only address one set of requirements. Existing proposals require a bandwidth and a processing power that are currently not available in WSNs. This limitation will tend to disappear in the future as advances are made in processor development.
As technology evolves, better processors with the same power consumption will emerge on the market.
 S. Hadim, N. Mohamed, “Middleware for Wireless WSNs: A survey”, Journal of Computer Science and Technology, 23(3), pp. 305-326, May 2008.
 K. Henricksen, R. Robinson, “A survey of Middleware for WSNs: State-ofthe-Art and Future Directions”, in proc. of MidSens’06, Melbourne, Australia, December, 2006.
 E. Yoneki, J. Bacon, “A survey of Wireless WSN Technologies: Research Trends and Middleware’s Role”, Technical Report Number 646, University of Cambridge, September 2005.
 M. Wang, J. Cao, J. Li, S. K. Das, “Middleware for Wireless WSNs: A Survey”, Journal of Computer Science and Technology. Vol. 23, Nº 3, pp. 305 – 326, May 2008.
 I. Chatzigiannakis, G. Mylonas and S. Nikoletseas “50 ways to build your application: A Survey of Middleware and Systems for Wireless Sensor Networks” in proc. of MidSens’06, Melbourne, Australia, December, 2006.
 C. Srisathapornphat, C. Jaikaeo, C. Shen; “Sensor information networking architecture”. In Proc. the Int. Workshop Parallel, IEEE CS Press, pp.
23-30, 2000  [http://lime.sourceforge.net/tinyLime/] Future directions in wireless sensor networks Chapter 17. Future directions in wireless sensor networks