3 Middleware for Wireless Sensor Networks - A Survey

7/27/2019 3 Middleware for Wireless Sensor Networks - A Survey

1/22

Wang MM, Cao JN, Li J et al. Middleware for wireless sensor networks: A survey. JOURNAL OF COMPUTER SCIENCE

AND TECHNOLOGY 23(3): 305326 May 2008

Middleware for Wireless Sensor Networks: A Survey

Miao-Miao Wang1,2 (), Jian-Nong Cao2 (), Jing Li1 ( ), and Sajal K. Dasi3

1Department of Computer Science, The University of Science and Technology of China, Hefei 230027, China2Internets and Mobile Computing Lab, Department of Computing, The Hong Kong Polytechnic University, Kowloon

Hong Kong, China3Department of Computer Science and Engineering, The University of Texas at Arlington, Arlington, U.S.A.

E-mail: {csmmwang, csjcao}@comp.polyu.edu.hk; [email protected]; [email protected]

Received January 15, 2008, revised March 4, 2008.

Abstract Wireless Sensor Networks (WSNs) have found more and more applications in a variety of pervasive computing

environments. However, how to support the development, maintenance, deployment and execution of applications over

WSNs remains to be a nontrivial and challenging task, mainly because of the gap between the high level requirements frompervasive computing applications and the underlying operation of WSNs. Middleware for WSN can help bridge the gap

and remove impediments. In recent years, research has been carried out on WSN middleware from different aspects and

for different purposes. In this paper, we provide a comprehensive review of the existing work on WSN middleware, seekingfor a better understanding of the current issues and future directions in this field. We propose a reference framework to

analyze the functionalities of WSN middleware in terms of the system abstractions and the services provided. We review

the approaches and techniques for implementing the services. On the basis of the analysis and by using a feature tree, weprovide taxonomy of the features of WSN middleware and their relationships, and use the taxonomy to classify and evaluate

existing work. We also discuss open problems in this important area of research.

Keywords middleware, wireless sensor network, pervasive computing

1 Introduction

In recent years, a new wave of networks labeled Wire-less Sensor Networks (WSNs) has attracted a lot of at-tentions from researchers in both academic and indus-trial communities. WSNs can be used for forming theunderlying sensing and network infrastructure in per-vasive computing environments. A WSN consists of acollection of sensor nodes and a sink node connectedthrough wireless channels, and can be used for build-ing distributed systems for data collection and process-ing, covering the functions of on-field signal sensingand processing, in-network data aggregation, and self-organized wireless communication. WSNs have foundmany applications in different areas, including environ-mental surveillance, intelligent building, health moni-toring, intelligent transportations, etc.[1]

This survey paper is concerned with middleware forWSNs. Middleware refers to software and tools thatcan help hide the complexity and heterogeneity of theunderlying hardware and network platforms, ease themanagement of system resources, and increase the pre-

dictability of application executions[2]. WSN middle-ware is a kind of middleware providing the desired ser-vices for sensing-based pervasive computing applica-tions that make use of a wireless sensor network andthe related embedded operating system or firmware ofthe sensor nodes.

The motivation behind the research on WSN mid-dleware derives from the gap between the high-level re-quirements from pervasive computing applications andthe complexity of the operations in the underlyingWSNs. The application requirements include high flex-ibility, re-usability, and reliability. The complexity ofthe operations with a WSN is characterized by con-

strained resources, dynamic network topology, and lowlevel embedded OS APIs. WSN middleware providesa potential solution to bridging the gap and removingthe impediments. In the early time of the research onWSN, people did not pay much attention to middlewarebecause the simplicity of the early applications did notshow much demand for the support from the middle-ware. Along with the rapid evolution in this area, thegap becomes increasingly obvious and hinders the pop-

SurveySupported by Hong Kong Polytechnic University under the ICRG Grant No. G-YE57, Hong Kong RGC under the Grant of A

Research Center Ubiquitous Computing, and the National Hi-Tech Development 863 Program of China under Grant No. 2006AA01Z231.


2/22

306 J. Comput. Sci. & Technol., May 2008, Vol.23, No.3

ularity of WSN-based applications.

WSN middleware helps the programmer develop ap-plications in several ways. First, it provides appropriate

system abstractions, so that the application program-mer can focus on the application logic without caringtoo much about the lower level implementation details.Second, it provides reusable code services, such as codeupdate, and data services, such as data filtering, so thatthe application programmer can deploy and execute theapplication without being troubled with complex andtedious functions. Third, it helps the programmer innetwork infrastructure management and adaptation byproviding efficient resource services, e.g., power man-agement. It also supports system integration, monitor-ing, as well as system security.

Although middleware is a well established researcharea in distributed computing systems, WSN posesnew challenges to middleware research. The tradi-tional middleware techniques cannot be applied di-rectly to WSNs. First, most distributed system mid-dleware techniques[3,4] aim at providing transparencyabstractions by hiding the context information, butWSN-based applications should usually be context-aware. Second, although many mobile computingmiddleware[5,6] supports context awareness, their ma-jor concern is how to continuously satisfy the interestsof individual mobile nodes in the presence of mobil-ity. In contrast, WSN-based systems are data cen-tric, reflecting the whole applications interests. Thus,the locations and mobility of the sensor nodes shouldbe handled by WSN middleware in a different way.For example, a node moving away from a phenomenonmay choose to hand off the monitoring responsibilityto a nearby node. Also, WSNs mostly use attribute-based addressing[1,7] rather than relying on network-wide unique node addresses. Third, data aggregationin intermediate nodes of the forwarding path is desir-able in a WSN, but no such kind of support is providedin traditional distributed system middleware because ofthe end-to-end paradigm used. Finally, WSN requires

the middleware to be light weight[79] for implemen-tation in sensor nodes with limited processing and en-ergy resources. WSNs also have new requirements onhardware (e.g., various sensors and computing nodes),operating systems and routing protocols[10], as well asthe applications[11].

In recent years, a lot of work has been doneon WSN middleware, focusing on different aspectsand for different purposes. Although several sur-vey papers can be found in literature[79,1218],each of them addresses only a subset of the issues,e.g., the system architecture[79,16], the programming

paradigm[13,14,17], and the run time supporting[12,18].There is no reference model for classifying and ana-lyzing the middleware functionalities, and no detaileddiscussion on the implementation techniques.

This paper presents a systematic study of recent re-search on WSN middleware to help identify the keyservices, challenging issues, and important techniques.Compared with the existing surveys, this paper makesthe following distinct contributions. First, it proposesa reference model for analyzing the functionalities andkey services of WSN-middleware. Second, it provides adetailed review of the existing work on the most impor-tant aspects in developing WSN middleware, coveringthe major approaches to and corresponding techniquesof implementing the services. Third, the paper pro-poses a feature tree-based taxonomy[19] that organizes

WSN-middleware features and their relationships intoa framework to help understand and classify the exist-ing work. The paper also discusses the open problemsand identifies the directions in future research.

The remainder of this paper is organized as follows.In Section 2, we describe a reference framework to an-alyze the functionalities of and identify the key ser-vices to be provided by WSN middleware. In Section 3,we survey the approaches and the corresponding tech-niques for implementing the key services. In Sections 4and 5, we look into the WSN runtime support and QoSsupport, respectively. In Section 6, we propose a fea-

ture tree-based taxonomy for classifying the features ofWSN-middleware, and highlight the representative ex-isting middleware projects with the evaluation of theiradvantages and disadvantages. In Section 7, we discussthe challenges, open problems, and future directions ofWSN middleware research. Finally, we conclude thispaper in Section 8.

2 Reference Model of WSN Middleware

2.1 Model Overview

As shown in Fig.1, a complete WSN-middleware so-lution should include four major components: program-ming abstractions, system services, runtime support,and QoS mechanisms. Programming abstractions de-fine the interface of the middleware to the applicationprogrammer. System services provide implementationsto achieve the abstractions. Runtime support serves asan extension of the embedded operating system to sup-port the middleware services. QoS mechanisms definethe QoS constrains of the system.

By analyzing the requirements of WSN-based appli-cations and the characteristics of WSNs, we propose areference framework, shown in Fig.2, to describe the or-


3/22

Miao-Miao Wang et al.: Middleware for Wireless Sensor Networks: A Survey 307

ganization and relationships of the above components.It should be mentioned that it is not necessary for a spe-cific WSN-middleware to include all the components.Also, functions of several components may be combinedtogether and implemented as one component.

In the deployment, the functions of WSN-middleware can be distributed to the sensor nodes, thesink nodes, and high level application terminals, asshown in Fig.3. The distributed middleware compo-

nents located in different nodes of the network commu-nicate with each other to achieve some common goals.

Fig.1. Major components of WSN-middleware.

Fig.2. Reference model of WSN middleware.

Fig.3. System architecture of WSN-middleware.

2.2 Programming Abstractions

Programming abstractions are the foundation ofWSN-middleware. They provide the high-level pro-gramming interfaces to the application programmer,which separate the development of WSN-based appli-cations from the operations in the underlying WSN in-frastructures. They also provide the basis of developingthe desirable middleware services. Three aspects are

involved in developing the programming abstractions:abstraction level, programming paradigm, and interfacetype.

Abstraction Level refers to how the application pro-grammer views the system. Node level abstraction ab-stracts the WSN as a distributed system consisting ofa collection of sensor nodes, and provides the program-mer the support for programming the individual sensornodes for their actions and cooperation[2022]. System

level abstraction abstracts the WSN as a single virtualsystem and allows the programmer to express a sin-gle centralized program (global behavior) into subpro-grams that can execute on local nodes (nodal behav-ior), leaving only a small set of programming primitivesfor the programmer while making transparent the low-level concerns such as the distributed code generation,remote data access and management, and inter-nodeprogram flow coordination[23,24]. Generally speaking,node level abstraction facilitates the development of ap-plications with more flexibility and energy saving, andless communication and interpretation overheads. On


4/22


the other hand, system level abstraction is easier touse because nodal behaviors can be generated auto-matically so the programmer can concentrate on thenetwork-level actions, without worrying about how thesensor nodes collaborate with each other to perform theassigned tasks.

Programming paradigm refers to the model of pro-gramming the applications. It is often dependent onthe applications. WSN applications can be classifiedin two dimensions: application data collection fea-ture and application dynamic feature. Data collec-tions can be continuous, event-driven, or query-based.Application can be totally static and has some mo-bility characteristic, such as mobile target or mobilesink. Correspondingly, for different applications, WSNmiddleware may use different programming paradigms,such as database, mobile agent, and Publish/Subscribe(Pub/Sub). For example, the data base paradigm isoften used for query-based data collection, while thePub/Sub paradigm can be a good choice for event-driven applications. Mobile agent paradigm may bea choice for tracking mobile target applications.

Interface type refers to the style of the programminginterface. As a matter of fact, programming abstrac-tion is embodied as the programming interface. De-scriptive interfaces provide SQL-like languages for dataquery[25,26], rule-based declarative languages for com-mand execution[27], or XML-based specification files

for context configuration[28]. On the contrary, imper-ative interfaces provide imperative programming lan-guages for writing the code to interact with the WSNnetwork[29]. Descriptive interfaces usually require theinterpretation of the queries and thus consume moreresources, while imperative interfaces require the pro-grammer to specify the logic of execution, and are moreflexible but more difficult to use.

The consideration of adopting a particular abstrac-tion level and selecting an appropriate programmingparadigm and applicable interface depends on thespecific application requirements and the underling

WSN infrastructure. Middleware providing similarparadigms may share the implementation techniques.For example, the database-based paradigm is usuallyimplemented with a descriptive interface, while theevent-driven paradigm can be implemented either withan imperative interface by providing the handlers to berecalled or with a descriptive interface by providing anevent description scheme. We will discuss them in moredetails in the later sections.

2.3 System Services

System services embody the functionalities and form

the core of WSN-middleware. They are exposed to theapplication programmer through the abstraction inter-face, and provide the support for application deploy-ment, execution, as well as sensor and network manage-ment. We classify the system services into two broadcategories: common services and domain services.

Common services are the basic services shared by allWSN applications. They help manage the applicationinformation and the WSN infrastructure. The func-tionalities provided by the common services include:

Code Management: responsible for code migratingand code updating in a deployed network;

Data Management: responsible for data acquisi-tion, data storage, data synchronization, data analysis,and data mining;

Resource Discovery: responsible for discoveringnewly joined sensor nodes and detecting nodes, whichare becoming inaccessible either as a result of mobilityor loss of battery power;

Resource Management: responsible for managingthe node resources (e.g., energy, memory, A/D device,communication module) and network resource (e.g.,topology, routing, system time);

Integration: responsible for integrating WSN andits applications into other networks, such as the Inter-net and Grid, for broader use.

We will explain the implementation details of theabove services in the next section.

Domain services facilitate the development of ap-plications in a specific domain. They can make useof the common services and add application-orientedfunctions of providing domain specific services. For ex-ample, EnviroTrack[30] is a WSN middleware that sup-ports environmental Target tracking. Impala[22] is amiddleware for the ZetbraBet project, a wildlife moni-toring project. It has two layers: the upper layer con-tains the application specific protocols and functions,and the lower layer contains the common services suchas code management. WSN-SHM middleware[31,32] isdesigned for developing structural health monitoringapplications which have the requirements of high fre-quency sampling and high resource consumption.

2.4 Runtime Support

Runtime support provides the underlying execu-tion environment of applications and can be seen asan extension of the embedded operating system whichprovides functions of scheduling of tasks, inter-processcommunication (IPC), memory control, and power con-trol in terms of voltage scaling and component activa-tion and inactivation. The need for runtime support in


5/22


WSN middleware comes from the facts that the hard-ware and firmware of the sensor nodes may not alwaysprovide enough support for the implementation of themiddleware services described above.

The functionalities of the runtime support in WSNmiddleware include local processing support, communi-cation support, and storage support. More specifically,the support is provided for multi-thread processing,smart task scheduling, and synchronization of memoryaccess.

Runtime support of WSN-middleware is always em-bodied as a virtual machine over a specific embeddedoperating system. An example is Mate[20] built on topof TinyOS[33].

2.5 QoS Mechanism

Quality of Service (QoS) mechanism is an advancedfeature of WSN-middleware. Providing QoS support inWSN is still an open issue for research[34]. QoS fea-tures are always crossing layers and crossing compo-nents, and are embodied in various functional services.For example, the data management service is requiredto be reliable and of high accuracy.

Typical parameters for expressing QoS of WSN net-work infrastructure include message delay, jitter, andloss, network bandwidth, throughput, and latency.Typical parameters for expressing QoS of WSN appli-

cations include data accuracy, aggregation delay, cover-age, and system lifetime. Middleware acts as a brokerbetween the applications and the network infrastruc-ture. QoS support may translate and control the QoSmetrics between the application level and the networklevel[35]. If the QoS requirements from an applicationare not feasible to fulfill in the network, the middlewaremay negotiate a new QoS guarantee with both the ap-plication and the network. QoS support may also pro-vide the implementation framework for simplifying theQoS-aware WSN application development using QoSassurance algorithms.

In the rest of the paper, we will focus on the ap-proaches and techniques for implementing the aboveidentified middleware components.

3 Middleware System Services

3.1 Code Management

In the context of this paper, a WSN applicationconsists of pieces of code that executes on the sensornodes. Code management provides services for codedeployment, i.e., allocation and migration of code tosensor nodes. Code allocation determines a set of sen-

sor nodes, on which the execution will be activated.Code migration transfers the code on a sensor node toanother node[36]. It not only helps conveniently re-taskthe network for network reprogramming (code updat-ing), but also enables the data computation elementsof an application to be re-located. Code can migrateto the nodes close to the area where relatively largeamounts of data are collected, enabling potentially highenergy saving, or migrate with the mobile phenomena.For example, the code of an application for fire alarmcan be migrated from node to node along the path offire spread.

Generally speaking, implementation of code alloca-tion involves with checking conditions using compar-isons. In SINA[37] code allocation is implemented in asensor execution environment (SEE), which comparesSQTL script parameters with the attributes of sensornodes and executes the script only if there is a match.In Cougar[26], code allocation is implemented by aquery optimizer that determines the energy-efficientquery routes[36]. Code allocation services implementedby a query optimizer have good expressivity but bringnetwork load, while the SEE approach has limited ex-pressivity but good scalability. Another promising ap-proach, as used in MiLAN[38], is to apply application-level QoS to the control of the code allocation in con-figuration adaptation. The approach enables the adap-tation of the application operations on the basis of

the current application requirements, which can be ad-justed depending on the output of the application itself.In this way the code allocation is adaptive to the chang-ing conditions. However, the technique used in MiLANrequires a centralized control.

Code migration can be implemented at not onlythe middleware layer but also in the underlying em-bedded operating systems, as in BerthaOS[39] andMagnetOS[40]. However, because WSN OS does notsupport code interpretation, code migration imple-mented at the OS level is error prone and subject tomalicious attacks[36].

At the middleware level, most techniques for taskmigration rely on the use of mobile code, movingthe code to the data origins to process the datalocally[36]. Current implementations include code mi-gration through mobile code (e.g., TCL script inSensorware[41], SQTL scripts in SINA[37]) and mobileJava object (e.g., TinyLime[42]). An example of mo-bile code is mobile agent, which is an execution threadencapsulating the code as well as the state and data.Mobile agent makes migration decisions autonomously.The key of this approach is to make the application asmodular as possible to facilitate their injection and dis-


6/22


tribution through the network. However, the nature ofmobile agent code does not allow hardware heterogene-ity. So, this approach is implemented on top of a VMfor platform independency.

There is a trade-off between the complexity of theinterpreter running on the nodes and the complexityof mobile code. Code migration services implementedby mobile code with TCL and SQTL have the advan-tages of small size and high dynamicity, but suffer fromthe complexity in specification and high communica-tion cost. Implementations based on mobile agent andmobile Java objects have good scalability but high re-source consumption. Code migration is very resourcedissipative and should be used only when necessary.

To get more insights of the code management ser-vices, we take Agilla[29] as an example of the imple-mentation techniques. Agilla is a mobile agent basedWSN middleware. The idea behind Agilla is to initiallydeploy a network without any application installed.Agents that implement the application behavior canlater be injected, effectively reprogramming the net-work. Agilla marks the first time that multiple mobileagents and tuple spaces are used in a unified frameworkfor WSNs.

Fig.4. Agilla system model.

The Agilla system model is shown in Fig.4. Eachsensor node supports multiple agents, and maintains atuple space and a neighbor list. The tuple space is lo-cal and is shared by the agents residing on the node.Special instructions are given to allow the agents toremotely access another nodes tuple space. The neigh-bor list contains the addresses of all the one-hop nodes.Agents can migrate carrying their code and state, butnot their own tuple spaces.

Fig.5 shows the middleware architecture of Agilla.The tuple space manger implements the tuple spaceoperations (e.g., out, inp and rdp) and reactions, andmanages the contents of the local tuple space and re-action registry. The agent manager maintains eachagents context. It is responsible for allocating memory

to an agent when it arrives and de-allocating it whenthe agent leaves or dies. The context manager deter-mines the nodes location as well as that of its neigh-bors. Instruction manager and Agilla engine provideruntime support. Instruction Manager is responsiblefor dynamic memory allocation, retrieving the next in-struction to execute, and packing up the agents codeinto the minimal number of messages. The Agilla en-gine controls the concurrent execution of all the agentson a sensor node.

Fig.5. Agilla middleware architecture.

Fig.6 shows the agent architecture. An agent con-sists of a stack, a heap, and various registers. The heapis a random-access storage area that allows an agent tostore variables. The registers contain the agents ID,program counter (PC), and the condition code. Theagent ID is unique to each agent and is maintainedacross migration operations. A cloned agent is assigneda new ID. The PC contains the address of the next in-struction, and is used by the code manager for fetchingthe next instruction. When a reaction fires, the reac-tion manager changes the PC to point it to the firstinstruction of the reactions code. To allow an agent

to resume execution from where it was when the reac-tion fired, the original PC is stored on the stack. Thecondition code records the execution status.

Fig.6. Agilla mobile agent architecture.


7/22


With regards to code allocation, Agilla uses a reac-tion approach. Reactions are added to the tuple spaces,allowing an agent to tell Agilla that it is interested intuples which match a particular template. The tuplespace manager remembers the reactions registered byeach agent by storing them within the reaction registry.Whenever a tuple is inserted, the registry is checked tosee whether the new tuple matches a reactions tem-plate. If so, the tuple space manager notifies the agentmanager, which updates the agents program counterto execute the reactions code.

Code migration is implemented by moving or cloningan agent from one node to another. The tuple spacemanager packages up all the reactions registered by anagent so they can be transferred along with the agent.When an agent moves, it carries its state and code, and

resumes executing on the new node. When it clones,it copies its state and code to another node and re-sumes executing on both the old and new nodes. Themulti-hop migration is handled by the middleware andis transparent to the user.

3.2 Data Management

As mentioned before, WSN applications are datacentric. Here, data refers mainly to the sensed data.Sometimes it also refers to the network infrastructureinformation interested by the applications. Data man-

agement in WSN middleware provides services to appli-cations for data acquisition, data processing, and datastorage. The approaches to implementing the datamanagement services depend much on the applicationdata model.

3.2.1 Data Acquisition

Data acquisition is an essential service for WSN ap-plications, responsible for delivering the relevant andaccurate data required by the application.

For the event-based data model, data acquisition

support is focused on the event definition, event regis-ter/cancel, event detection and event delivery. The ap-plication specifies the interest in certain state changesof the data. Upon detecting such an event, the mid-dleware will help send event notification to interestedapplications. TinyDB[25], DSware[43], Mires[44], andImpala[22] all support event-based data acquisition.DSware also supports compound event detection.

A typical approach to implementing event-baseddata acquisition is the Pub/Sub paradigm, which hastwo advantages in supporting event-based data acqui-sition. First, it supports asynchronous communication.Second, it facilitates message exchanging between the

sensor nodes and the sink node. The basic entities ofPub/Sub system are event subscriber and event pub-lisher (some times event broker also). From the mid-dlewares point of view, the event subscriber is the sinknode and the event publishers are the sensor nodes.

Fig.7. Mires architecture.

Fig.8. Mires Pub/Sub component.

As an example of the Pub/Sub approach, let us have

a look of Mires. Figs. 7 and 8 show Mires archi-tecture and its Pub/Sub component structure, respec-tively. Mire includes a core component, namely thePub/Sub service, and some additional services. Thecommunication between the sensor nodes consists ofthree phases. Initially, the sensor nodes in the networkadvertise their available topics (e.g., temperature andhumidity) collected from the local sensors. Next, theadvertised messages are routed to the sink node usinga multi-hop routing algorithm. A user application con-nected to the sink node is able to select (i.e., subscribe)the desired advertised topics to be monitored. Finally,the subscribed messages are broadcasted down to the


8/22


network nodes. After receiving the subscribed topics,the sensor nodes are able to publish their collected datato the network. The Pub/Sub service maintains thetopic list and the subscribing applications so as to mar-shal the right topic to the related application. In Mires,only the messages referring to the subscribed topics aresent, hence reducing the number of transmissions andenergy consumption.

For query-based data model, data acquisition sup-port is focused on the query processing model andmethods. Middleware for query-based data modelusually uses a declarative interface, with globallevel abstraction and database programming model.Example systems are TinyDB[25], Cougar[26], andSensorWare[41]. They leverage the techniques used inthe traditional database system to implement data ac-

quisition services, e.g., applying distributed query[45,46]

or CACQ (continuously adaptive continuous queriesover streams)[47,48].

TinyDB is a good example to illustrate the query-based approach. TinyDB is a query-processing systemthat extracts information from the data collected by theWSN using the underlying operating system TinyOS.TinyDB maintains a virtual database table, called SEN-SORS, whose columns contain information such as sen-sor type, sensor node identifier, and remaining batterypower. The programmer can view the values of theSENSORS, and add new rows to it. Consider the fol-

lowing example, a user wants to be reported when theaverage temperature is above 80F in any room on thethird floor of a building monitored by sensors. The userinputs the following database query along with the rateat which the sensors are to collect the data:

SELECT AVG (temp) FROM sensors

(select rows from Sensors)

WHERE floor = 3(at the 3rd floor)

GROUP BY room

(rows are grouped by room number)AVG (temp) > 80F

(only groups with average temperature > 80F)

SAMPLE PERIOD 20 seconds

(perform every 20 secondsrate of collection)

TinyDB uses a controlled-flooding approach to dis-seminate the queries throughout the network. The sys-tem maintains a routing tree (spanning tree) rootedat the end point (usually the users physical location).Then, in a decentralized approach, every sensor nodehas its own query processor that processes and aggre-gates the sensor data and maintains the routing infor-mation. In every period, the parent node closer to theroot agrees with its children in a time interval for lis-tening to data from them.

3.2.2 Data Processing

Generally speaking, there are three different ap-proaches to supporting data processing in WSNs. Incentralized processing, all the data are collected andthen sent to a central node for processing. In nodelevel, distributed processing raw data collected in thesensor nodes are pre-processed to obtain partial results,which are then collected by the sink node for furtherprocessing to get the final result. In network level, dis-tributed processing final results are obtained throughboth node-level distributed processing and informationexchange between the sensor nodes, and between thesensor nodes and the sink node. In the extreme case,where every sensor node is involved with data process-ing and routing, and is aware of the final decision, it

becomes completely distributed processing.

Given that the communication cost is much higherthan the computation cost at a sensor node, WSNmiddleware should support in-network distributeddata processing service, mostly through data fu-sion/aggregation. Although in-network data process-ing services are also supported at a lower level by somefirmware in terms of signal conditioning, and data fu-sion and data aggregation can also be supported at theMAC and routing layers, middleware support has thefollowing distinctive features. 1) It is more independentof the underlying network protocols, so different strate-

gies can be applied according to different data accu-racy requirements from different applications or differ-ent network conditions. 2) It facilitates high level dataanalysis such as feature-based fusion and decision-basedfusion.

For event-based data model, data aggrega-tion/fusion can be implemented in separate services.An example is the aggregation service in Mires[44]. InMires, data aggregation is implemented in separatemodules for functions such as AVG and SUM. The ag-gregation is executed by an Aggregate Use modulethat carries out an activity of de-multiplexing, passing

requests for the correct aggregation module in accor-dance to its identifier. This way, the flexibility to addnew aggregation functions is guaranteed, just requir-ing the creation of a module for the new function andadding the association between the function and anidentifier to a configuration file.

In addition, for event-based data model, detectingthe event boundary and determining the event area andits center should also be considered in WSN middle-ware.

For query-based data model, data aggrega-tion/fusion services can be implemented by using the


9/22


pipelining techniques[46], as used in TinyDB and Sen-sorWare.

Another data processing service is data calibrationfor ensuring the synchronization between the sensornodes. Some applications, e.g., seismographic or build-ing health monitoring, require precise time synchroniza-tion among the readings on different sensor nodes. Howto achieve time synchronization is an important func-tion of the middleware. More details on implementationtechniques of time synchronization in WSN, e.g., hard-ware implementation, software implementation can befound in [55].

3.2.3 Data Storage

There are three approaches to implementing data

storage support in WSNs[49,50]. External storage stores

the data in the base station out of the WSN. Localstorage stores the data where it is generated, reducingcommunication but increasing the inquiry cost. Datacentric storage provides a tradeoff between the previ-ous two approaches. Data-centric storage is the mostpopular approach implemented in existing WSN mid-dleware.

Let us look at Data Service Middleware(DSWare)[43] as an example to show the data stor-age service implementation in WSN-middleware. Asshown in Fig.9, DSWare is a specialized layer that

implements various data services and, in doing so,provides a database like abstraction to WSN applica-tions. Fig.10 shows the DSWare framework. The eventdetection component is responsible for providing thedata acquisition service. The group management com-ponent provides the support for group-based decisionand is responsible for data aggregation. The schedul-ing component schedules the services to all DSWarecomponents with two scheduling options: energy-awarescheduling and real-time scheduling. Here, we focus onthe data storage and caching components.

Fig.9. DSWare framework.

Fig.10. DSWare system model.

The Data Storage component in DSWare stores dataaccording to the semantics associated with the data. Ithas a data look-up operation and provides fault tol-erance should there be node failures. It also has op-erations for storing correlated data in geographicallyadjacent regions. This has two advantages: enablingdata aggregation and making it possible for the systemto perform in-network processing.

To facilitate data look-up, DSWare maps data tophysical storage using two levels of hash functions. Atthe first level, the hash function maps a key, which is

a unique identifier assigned to each data type, to a log-ical storage node in the overlay network. As a resultof this operation, the storage nodes form a hierarchy atthis level. The second level involves the mapping of sin-gle logical node to multiple physical nodes such that abase station performing a query operation has the datafetched from one of the physical locations. There is abig risk in mapping a given data type to a single nodeas this data could be lost as a result of node failure.Furthermore, mapping data to a single node in the sen-sor network causes bursts of traffic to the node whichmay lead to collision and higher rate power consump-

tion. DSWare uses replication to store data in multiplephysical sensor nodes that can be mapped onto a singlelogical node. Load balancing is achieved since queriescan be directed to any one of the physical nodes andthe lifetime of individual nodes is prolonged since powerconsumption is substantially reduced. With replicationof data amongst multiple nodes there come consistencyissues. DSWare adopts weak consistency to avoidpeak time traffic since only the newest data amongstnodes is bound to lack consistency. This new data ispropagated to other nodes and the size of inconsistentdata is bounded so that replication occurs when theworkload in individual nodes is low.


10/22


Data caching in DSWare provides multiple copiesof data that are most requested. DSWare spreads thecached data over the network to achieve high avail-ability and faster query execution. A feedback con-trol scheme is used for dynamically deciding whetheror not copies should reside in frequently queried nodes.The scheme uses various inputs, including proportion ofperiodic queries and average response time, from datasource to guide the nodes in making decisions aboutwhether or not a copy should be kept. This componentalso monitors the usage of the copies to decide whetherto increase or reduce the number of copies, or movethem to a new location.

In conclusion, 1) data management is an importanttopic in WSNs. One of the distinguished features thatmiddleware offers in data management is the appropri-

ate abstraction of data structure and operation. With-out this abstraction, the developer has to manage theheterogeneous data and low level operation in the ap-plication. Various exiting data management algorithmscan be implemented as reusable and alternative middle-ware services with certain of parameters. The middle-ware system can even automatically adjust the serviceparameters according to its current status. Applica-tion specific data management algorithms can be writ-ten based on those common data services. This alsofacilitates the development process. 2) Most existingWSN middleware provides some kinds of data manage-

ment services. However, high level in-network analysisservices related to the WSN application domain, e.g.,data mining, are not implemented yet, to which moreattention should be paid.

3.3 Resource and Information Discovery

Resources in a WSN usually refer to the sensor nodehardware resource, e.g., energy, memory, A/D device,and communication module. The resource discoveryservice returns the data type that a discovered nodecan provide, the modes in which it can operate, and

the transmission power level or residual energy level ofa sensor node. On the other hand, the information dis-covery service returns the information about the net-work topology, the network protocols, and the neigh-bors and the locations of the discovered nodes. Theservice can also be used for discovering new nodes andfinding out when nodes become inaccessible as a resultof either mobility or loss of battery power. However,many of the above mentioned service features are notbeing available in existing WSN middleware yet.

Compared to the resource discovery in traditionalnetworks[51,52] which is involved with identifying andlocating (relocating) the services and resources in the

system, resource and information discovery services inWSN are more difficult to implement due to the lackof unique node ID and the lack of generic service spec-ification, and because the services need to be providedin a power-aware way. Some existing WSN middlewaresystems adopt service discovery protocols from tradi-tional computer network solutions, e.g., SLP[53] andBluetooth SDP[54]. MiLAN is an example. Other sys-tems, e.g., TinyLime, use tuple space to implement theresource discovery service. However, these implementa-tions need unique ID of the resource, but many WSNsare content-based without unique ID for sensor nodes.

Although many localization algorithms have beendeveloped for different kinds of systems, for exam-ple, Ultrasound, RF, and ultra-wideband, RSSI tech-niques are used for accurate localization via carefully

placed beacons. Few existing WSN middleware has in-tegrated location discovery service. To our opinion, thisis mainly because the implementation of this kind ofservice depends very much on hardware and the un-derlying environment. For large scale use of WSN forpervasive computing, standard and adaptive locationdiscovery services should be provided.

3.4 Resource Management

Resource and information discovery services de-scribed in the previous section have two main functions:

1) providing the underlying network information to ap-plications that are required to be reflective or adaptive(e.g., context-aware); 2) providing the underlying net-work information for the purpose of supporting adap-tive resource management services. Resource manage-ment in WSN middleware is mainly for providing com-mon and reusable services of supporting the applica-tions that have the requirements for self-organization.Resource management services are usually used for re-source configuration at setup time and resource adap-tation at runtime, and they are essential to ensure theQoS of WSN which we will discuss in details later on.

Resource management at the OS layer is platform-dependent, so changes at this level might affect differentresource requirements of the applications running in asensor node. On the other hand, application-level re-source management imposes an extra burden on the ap-plication, and adaptation mechanisms developed at thislevel cannot be reused. In contrast, resource manage-ment at the middleware layer has more flexibility. Mostexisting WSN middleware provide services includingcluster service[56,57], schedule service, and data routingservice. These services are supported by finer granularservices such as power level management, transmissionlevel management, etc. These fine granular services


11/22


should be supported and constrained by the underly-ing OS, the firmware, and the hardware. Otherwise, itis impossible for the middleware to provide the corre-sponding services.

The cluster service refers to the cluster membermaintenance for layered WSN. For cluster service,many middleware systems, including EnviroTrack[30],MiLAN[38], DSWare[43], AutoSec[58], and SINA[37] ad-dressed the implementation issues according to dif-ferent objectives. For examples, EnviroTrack[30] pro-vided the cluster member re-allocation service that re-defines the clusters after deployment; the MiLAN[38]

and AutoSec[58] provided automatically cluster orga-nization service according to the QoS information ob-tained from network infrastructure and WSN applica-tion. SINA[37] and DSWare[43] also provided automat-ically cluster organization service, but the objectiveswere to achieve appropriate clusters so as to facilitatethe data aggregation process. Except for the aboveexamples, the work reported in [57] provides a func-tion for generic cluster management of sensor nodes.The function arises either in terms of non-functionalrequirements (e.g., security, reliability) or according todynamic system conditions. (e.g., power level, connec-tivity).

The schedule service refers to the node wakeup/sleepscheduling. It is used for reducing the energy consump-tion by allowing the sensor nodes to be put to sleepand to be waken up according to specific policy. Forexample, when not being allocated tasks to a sensornode can sleep in order to save energy. Implementationof this service may make use of the services, such assleep scheduling protocols in the MAC layer and CPUvoltage scaling[1] in the physical layer.

The data routing service can be implemented in sev-eral different ways. Some middleware such as Mate[20]

do not provide any specific routing management ser-vice, but provide architecture which allows the imple-mentation of arbitrary routing protocols. For systems

that provide routing management services, three mainapproaches can be identified. The first approach is im-plementing a new higher level routing protocol at themiddleware level. An example is MagnetOS[40] thatimplements a multi-hop routing protocol in a middle-ware component. The second is maintaining an overlay,and supporting routing mechanism, as well as routingreconfiguration on top of this overlay. For example,Mires[44] makes use of a Pub-Sub mechanism to sup-port the routing management. Owing to the looselycoupled interactions between the nodes in the Pub-Sub paradigm, it is very flexible to provide new kindof data routing implementation. The third approach

is implementing a mechanism that allows for switchingbetween different routing protocols, as what is done inImpala[22], or providing a mechanism that allows forthe adaptation of different routing protocols, as whatis done in MilAN[38]. As an example, Fig.11 shows thedata routing management of MilAN. The routing man-agement of MiLAN is intended to sit on top of mul-tiple physical networks. It acts as a layer that allowsnetwork-specific plug-ins to convert MiLAN commandsto protocol-specific ones that are passed through theusual network protocol stack. Therefore, MiLAN cancontinuously adapt to the specific features of whichevernetwork is being used in the communication.

Fig.11. MiLAN network protocol management.

In conclusion, most existing WSN middlewareadopts localized resource management. Policy-basedmanagement has been shown to be a good approach tosupporting the design of self-adaptive resource manage-ment. Currently, resource management services in ex-isting WSN middleware are tightly coupled with appli-cations and generic resource management services needto be developed.

3.5 WSN Integration

For broader applications, WSN needs to be inte-grated into other exiting network infrastructures, suchas the Internet, Gird, and database-based systems. Be-cause a WSN is a close network, it is not easy toimplement the integration service at the lower layers(e.g., OS or MAC layer), and thus middleware shouldprovide this service[5963].

For WSN middleware, integration is related to bothtask coordination as well as data sharing, and can beimplemented at the application level or data level. Ap-plication level integration is more related to task co-ordination, where the applications are running in both


12/22


the WSNs and the leverage system. Data level integra-tion, on the other hand, is more related to data sharing,where only the data provided by the WSNs are used inthe leverage system.

Proxy server is a common mechanism for inte-gration implementation. The client can access non-standardized services in a wireless sensor network byinquiring a proxy server which translates the stan-dardized protocol to the proprietary protocol, and viceversa. For integrating WSNs into existing legacy mid-dleware, authors of [65] described an edge server mid-dleware which performs application-specific process-ing at the boundary between the WSN and the legacymiddleware. For integrating WSNs into a Gird mid-dleware infrastructure, several early systems have beenreported[6063] on sensor-grid computing.

The service-oriented approach[28,64] to implementingWSN integration is based on standard open architec-ture technologies such as Web services[66]. It provides acommon information and communication format to fa-cilitate the integration. In this approach, the sink nodeis modeled as web service provider that exposes the ser-vices provided by the network using a standard serviceinterface. The WSDL language and SOAP protocol[66]

are used for describing the services and formatting mes-sages used by the underlying communication protocol.This approach does not combine the proposal with anyother particular underlying data dissemination proto-cols. Thus, the WSN can be used as a system to supplydata for different applications and users.

On the basis of the SOA approach, some researchersproposed the concept of Sensor-Web[6769]. The Sen-sor Web aims at making various types of web-residentsensors, instruments, image devices, and repositoriesof sensor data, discoverable, accessible, and control-lable via the World Wide Web. A lot of efforts havebeen made in order to overcome the obstacles associ-ated with the connecting and sharing of these hetero-geneous sensor resources. The Sensor Web Enablement(SWE) standard has been defined by the OpenGIS Con-sortium (OGC), which is composed of a set of specifi-cations, including SensorML, Observation & Measure-ment, Sensor Collection Service, Sensor Planning Ser-vice and Web Notification Service. OGC has also pro-posed a reusable, scalable, extensible, and interopera-ble service-oriented sensor Web architecture, which con-forms to the SWE standard, integrates Sensor Web withGrid Computing, and provides middleware support forSensor Webs.

In comparison, the proxy server approach is more ap-plication dependent and less scalable because adding orremoving a proxy server will impact the network struc-

ture. The service-oriented approach is more flexible andscalable, but needs more energy consumption. Most ofthe integration services are now still in very prelimi-nary stage. WSN middleware for this kind of servicesare resting on the architecture concept level.

4 WSN Runtime Support

As mentioned in Section 2, because the underlyingWSN platform, mostly the embedded OS does not al-ways provide enough support for implementing the mid-dleware services, WSN middleware needs to developruntime support. Runtime support extends the func-tions provided by the embedded OS for processing,communication, and storage management in order toprovide a well-defined execution environment for the ex-

ecution of application and system programs. The basicfunctions of runtime support include inter-process com-munication (IPC), memory control, and power controlin terms of voltage scaling and component activationand inactivation. These functions are used by higherlevel middleware services such as multi-thread process-ing, smart task scheduling, synchronization of memoryaccessing and the spread signal spectrum management.Runtime support in WSN middleware is always embod-ied as some kinds of virtual machines over the under-lying platform. It can be implemented as a platformspecific kernel on top of the embedded OS, but with

platform independent primitives for the generic WSNmiddleware services.

Fig.12. Architecture of Mate.

Let us look at an example, Mate[20], which is a mid-dleware built on top of TinyOS. Fig.12 illustrates itsarchitecture. Mate takes the role of a traditional OSkernel. Instead of system calls, it provides a set ofprimitives for programming. As shown in the figure,Mate has a byte code interpreter that runs on TinyOSwhich adopts a component-based model to build sen-sor network applications in an event-driven operating


13/22


environment. The core of the Mate architecture isa simple FIFO scheduler. The scheduler maintains aqueue of run-able contexts, and interleaves their execu-tion. The scheduler executes a context by fetching itsnext byte code from the capsule store, and dispatchesit to the corresponding operation component. TheMate concurrency model is based on statically namedresources, such as shared variables. Operations spec-ify the shared resources that they use. The analysisthat determines a handlers complete resource usageis language-specific. Mate forwards the programs us-ing the Trickle algorithm which uses broadcast-basedsuppressions to quickly propagate new data but mini-mizes the overheads when the nodes share data. Justas with explicit forwarding, once a user installs a sin-gle copy of a program in the network, Mate installs

it on every mote. Mate proposes a spectrum of re-programmability, from simply adjusting parameter touploading complete program updates. The support canbe used for developing more complex code managementservices, which will be discussed later on.

Another example is Magnet[40], a runtime based onMagnetOS, which is a power-aware, adaptive operat-ing system specifically designed for sensor and ad hocnetworks. With its support for a single system image,MagnetOS overcomes the heterogeneity of distributed,ad hoc sensor networks by exporting the illusion of theJava VM on a top of distributed sensor networks. Mag-

net has both static and dynamic components. Thestatic components are responsible for rewriting appli-cations in the form of object modules. The runtimecomponents (dynamic components) on each node mon-itor the objects creation, invocation, and migration.

Task cooperation is an important component of run-time support, which includes the means for communi-cation between distributed tasks. Task cooperation isuseful when multiple tasks reside on the nodes in theWSN and need to interact with each other. In existingsystems, e.g., TinyTime[42] and Agilla[29], implementa-tion of task coordination mainly uses the tuple space

approach. The concept of tuple space was proposedoriginally in Linda. Tuples are collections of passivedata values. A tuple space is a pool of shared informa-tion, where tuples are inserted, removed, or read. Dataare global and persistent in the tuple space and remainuntil being explicitly removed. In WSN middleware, tu-ple spaces are used for inter-agent communication andcontext discovery. In the tuple space, a task does notneed to know its peer task and tasks do not need toexist simultaneously, because they do not need to com-municate directly.

Let us look at the Agilla example again for task co-

ordination support. The tuple space ensures that theagents run autonomously by allowing them to commu-nicate in a decoupled fashion. For example, supposethere are a fire detection agent and a habitat monitoringagent residing on the same node when fire is detected.The fire detection agent inserts a fire tuple into the localtuple space to indicate the presence of fire and activatesa tracking agent before dying. The habitat monitoringagent reacts to this tuple, and voluntarily kills itselfto free additional resources. The fire detection agentdoes not need to know who receives the fire tuple. Thesending and the reception operations can occur respec-tively at different time, and reception can occur evenwhen the sender is no longer present. This spatial andtemporal decoupling ensures each agent operates au-tonomously. In Agilla, agents also need to coordinate

with the agents residing on remote nodes. Agilla allowsagents to coordinate across nodes by introducing spe-cial remote tuple space operations. They are synony-mous with local operations, except that they take anadditional location parameter that specifies on whichnode to perform the operation. Note that Agilla doesnot support tuple spaces that span across nodes. Eachnode maintains a distinct and separate tuple space. Thededicated remote tuple space instructions rely on uni-cast communication with the specific node hosting thetuple space.

5 WSN QoS Support

QoS support is important for applications withrequirements on performance, both functional andnon-functional. These requirements include fault-tolerance[70,71], reliability[72,73,77], security[7476], andreal-time[7780]. It is also very important for context-aware applications. Under different contexts, applica-tions can adopt different QoS policies. As mentionedin Section 2, QoS support in WSN middleware is stillan open issue for research. First of all, the QoS met-rics are not well defined in the context of WSN ap-

plications. For expressing QoS of WSN network per-formance, parameters such as packet delay, jitter andloss, throughput, and latency are defined. For express-ing QoS of WSN application performance, new param-eters are defined, including data accuracy, aggregationdelay, aggregation degree, coverage, and precision[34].The literature [34] surveyed both of above parameters,and proposed that in WSN middleware level, collectiveQoS metrics should be considered. Because WSNs arealways densely deployed, single sensor accuracy or timedelay between two respective sensors may not be mean-ingful. Collective behavior and effect of a set of logicallyrelated sensors become very important. However, nei-


14/22


ther did [34] nor other existing work provides a cleardefinition of collective QoS metrics and the way of howto implement them in WSN middleware.

Implementation of QoS support in WSN middlewaredepends on the middleware services we have describedbefore, mainly the resource discovery service and the re-source management service. Provision of QoS in WSNmiddleware, on the other hand, also affects other ser-vices, such as data acquisition in the data managementservice.

WSN middleware may provide a QoS support im-plementation framework with the fundamental QoS as-surance algorithms to simplify the development process.For example, in [70] a framework is proposed with fault-tolerant algorithms. But a typical implementation ap-

proach of QoS support in WSN middleware is to trans-late and control the QoS between the application andthe networks. That is, if the QoS requirements from anapplication are not feasible to be satisfied in the net-work the middleware may negotiate a new quality ofservice with both the application and the network.

Fig.13. QoS support in MiLAN.

Take MiLAN, for example, let us look at how ex-isting systems implement QoS support. As shown inFig.13, MiLAN assumes that application performancecan be described by the QoS expressed in different vari-ables of interest to the application. The QoS variablesdepend on the fact that sensors provide data to theapplication. Each sensor has a certain QoS in charac-terizing each of the applications variables. In order todetermine how to best serve the application, MiLANneeds to know the variables of interest to the applica-tion, the required QoS for each variable, and the level ofQoS that the data from each sensor or set of sensors canprovide for each variable. Note that all of these maychange according to the applications current state.

During the initialization of the application, the QoSinformation is conveyed from the application to Mi-lAN via State-based Variable Requirements Graph andSensor QoS Graph. The State-based Variable Require-ments Graph specifies to MiLAN the applications min-

imum acceptable QoS for each variable based on thecurrent state of the application. For a given applica-tion, the QoS for each variable can be satisfied usingthe data from one or more sensors. Given the informa-tion from the two kinds of graphs as well as the currentapplication state, MiLAN can determine which sets ofsensors satisfy all of the application QoS requirementsfor each variable. These sets of sensors define the appli-cation feasible set FA where each element in FA is a setof sensors that provides QoS greater than or equal tothe application-specified minimum acceptable QoS foreach specified variable. MiLAN also determines whichsets of sensor nodes can be supported by the networkusing Sensor QoS Graph. The subsets of the nodes thatcan be supported by the network define a network fea-sible set FN. MiLAN combines these two constraints to

obtain an overall set of feasible set F = FA FN.QoS support in WSN-middleware is still in a very

preliminary stage. Although work has been reported,there is a lack of implementation and simulation results.

6 Taxonomy of WSN Middleware Features

Current works on developing middleware for WSNshave focused on different aspects and for different pur-poses. In this section, we highlight the characteristicsof WSN middleware and propose taxonomy of the de-sirable features. We first classify the features of WSN

middleware by using feature trees, and then on the basisof the classification provide an overview of the exitingworks. The use of a feature tree facilitates structur-ing the middleware features and describing the rela-tionships between them.

The feature tree is derived by analyzing the sys-tem model and the implementation approaches of WSNmiddleware functions discussed in the previous sections.In Fig.14, the solid dots represent the necessary fea-tures, while the hollow dots represent optional or alter-native features. Features can be decomposed into subfeatures. The relationship between sub features can

be either the inclusive relationship, denoted by solidbranch cross, or the alternative relationship, denotedby the hollow branch cross.

As seen in the root tree (see Fig.14(a)), the featuresare from both the WSN middleware and the underly-ing network. The features from the middleware includethe services provided by and system architecture of thetarget middleware. The features from the WSN consistof two parts. The first part contains the features de-scribing the characteristics of the applications that thetarget middleware can support. The second part con-tains the features that describe the underlying WSNplatform support of the target middleware.


15/22


Fig.14. Feature trees of WSN middleware. (a) Root feature tree of WSN middleware. (b) Feature tree of middleware services. (c)

Feature tree of middleware architecture. (d) Feature tree of WSN.


16/22


The middleware feature sub-tree (see Fig.14(a)) it-self has two sub-trees: middleware service features (seeFig.14(b)) and architecture features (see Fig.14(c)).Middleware service features are composed of functionalfeatures, which are related to the middleware services,and none-functional features, which are related to theQoS support. The architecture features are composedof the programming abstraction features and the im-plementation features. We have discussed the program-ming abstraction features in Subsection 2.2.

Implementation-related features have two main per-spectives: the feature of coordination among the pro-cesses and the context features. In the branch rep-resenting the process coordination, the procedure-oriented method is not very applicable to the WSN Mid-

dleware due to its poor scalability[81]. Object-orientedmethod is scalable, but it is based on the object con-text whose weight is too heavy for the WSN context.Message-oriented and tuple space oriented methods canscale easily and support the event-driven paradigm[82].Thus, they are often used in the WSN middleware.

In the branch that represents the context features,hardware transparent features are those that hide thehardware implementation details from users. The fea-tures supporting heterogeneous hardware transparencyhide the differences of various hardware platforms.These kinds of features are rarely supported because ofthe diversity of the WSN hardware and the tight appli-cation dependent characteristics. Remote transparencymeans hiding the location and other network attribute

Table 1. Overview of Existing Projects and Proposals

(a)

Features Programming Abstraction Features Middleware Service Features

Proposal Interface Abstraction Programming Functional Un-Functional

Type Level Paradigm

Sensor Ware Declarative Local Database CodeManagement None

MagnetOS Imperative Global Virtual machine CodeManagement None

(java language) ResourceManagement

Mate Imperative Local Virtual machine CodeManagement Security

(motle, byte code) ResourceManagement

MiLAN None None None ResourceManagement None

ResourceDiscovery

SINA Declarative Global Database DataManagement None

(cells data format SQTL)

TinyDB Declarative Global Database DataManagement None

(ACQP language) Graphic UI ResourceManagement

Cougar Declarative (XML data Global Graphic UI DataManagement None

format, SQL-like language)

Impala None None Mobile agent CodeManagement Security

ResourceManagement

StorageSupporting

Agilla Imperative Local Mobile agent CodeManagement None

(compile-like)

FACTS Declarative (facts, Global Rule based CodeManagemet None

rules, functions, XML like) DataManagemetAutoSec None None None ServiceDiscovery None

ResourceManagement

DSWare Declarative Global None DataManagement Real-time

ResourceManagement Reliability

StorageSupporting

A Service Approach Declarative Global None DataManagement None

(XML,SOAP) Integration

Resource discovery

Mire Imperative Local Graphic UI DataManagement None

Enviro Track Imperative object-based Global None DataManagement None

(context object and ) ResourceDiscovery

tracking objects ResourceManagement


17/22


Table 1. Overview of Existing Projects and Proposals

(b)

Features Internal Implementation Features Supporting Application Features WSN FeaturesProposal Process Context Application Application Network Node

Communication Transparent Reflective Dynamic Dada Collection Level Level

Sensor Ware Asynchronous Homo None Mobile All None Linux

Tuple-Oriented Phenomena IPAQ Based

MagnetOS Asynchronous Homo/ None All All Ad-Hoc On-Demand

Hetero Routing Build on PC

Mate Synchronous Homo None All All Content-Based TinyOS-

Asynchronous Routing Based;

MiLAN Synchronous Hetero Proactive All Event-Driven Switch Between None

Asynchronous Different Protocols

SINA ASynchronous Remote None Static Enquire Cluster-Based None

Homo

TinyDB Asynchronous H omo None Static/Mobile Enquire/Event Spanning-Tree- TinyOS

Sensor Driven Based Routing Mote

Cougar Asynchronous Remote None Static Enquire Directed Diffusion None

Homo Routing

Cluster-Based

Impala Asynchronous Homo Adaptive Mobile Sensor Event-Driven Switch Between iPAQ/PC

(designed for Different Protocols Linux

ZebraNet)

Agilla Asynchronous Homo None All Any Multi-Protocol Tiny OS,

(tuple based) Routing MICA2,

FACTS Asynchronous Homo None All Event-Driven None None

Tuple-Oriented

AutoSec Asynchronous Homo Proactive All No None Tiny OSBroker-Based

DSWare Asynchronous Homo None All Event-Based Cluster-Based None

Pub-Sub-Based

A Service Asynchronous Homo Reflective All Event-Driven Directed None

Approach (Pub-Sub) Remote Proactive Diffusion

Mire Asynchronous Homo None All Event-Driven Cluster-Based TinyOS

(Pub-Sub)

Enviro Track Asynchronous Homo None Mobile- Continues/ Group-Based TinyOS

Synchronous Phenomena Event-Driven Content-Based

Routing

details from the user. Remote transparency does not

fit WSN systems which need the information to sup-port the applications and manage the resources.

For context features, in order to achieve resourcemanagement adaptation, developers must introduceopen resource configuration and reconfiguration. Thisrequires the context to be reflective[83]. Computationalreflection refers to the ability to reason about (beingaware of) and alter (being adaptive to) its own behav-ior. Both proactive and reactive middleware sys-tems belong to the category of adaptive middleware.Compared to reactive middleware systems, which re-act only by themselves when changes occur within the

network, proactive middleware systems enable appli-

cations (or middleware) to actively participate in the

process of configuring the network where the middle-ware operates.

The branch representing the WSN network features(see Fig.14(d)) includes the features of WSN appli-cations such as the application dynamic features andthe application data collection features (see the rightbranch of Fig.14(d)) as explained in [84]. Applicationdata collection feature defines the data acquiring ap-proach. By observer initiated approach, the data ac-quiring process is initiated by the data query command.By event-driven approach, data will be sent to the sinknode whenever a defined event occurs. By continuous

approach, data is sent to the sink node during every de-


18/22


Table 2. Summary of Existing WSN Middleware Production

Proposal Test Environment Simulation and Testing Tools Published Evaluation Results

Sensor Ware Prototyp e SensorSim Framework Size, Execution Delays, Energy ConsumptionMagnetOS JVM Custom Simulator Internal Algorithm Comparison in Simulator

Mate Prototype TOSSIM Byte Code Overhead, Installation Costs, Code Infection

Performance

MiLAN None None None

SINA Simulation GloMosim SINA Networking Overhead, Application Performance

TinyDB Simulation Custom Environment Query Routing Performance in Simulation, Sample Accuracy

Prototype and Sampling Frequency in Prototypes

Cougar None None None

Impala Simulation ZnetSim System Implementation and Overhead, Impala Event

Processing Time, Software Transmission Volume

Agilla Prototype Mica 2 Reliability of Remote Tuple Space and Agent Migration

Operations, Overhead of Agillas Instructions, Case StudyFACTS None None None

AutoSec Simulation Custom Environment Information Collection Overhead, Overall Performance

Efficiency

DSWare Simulation GloMoSim Performance in Reduction of Communication, Impact of Node

Density, Performance in Reaction Time

Mire None None Case Study

Enviro Track Prototype Mica 2 Communication Performance Data, Effect of Sensory Radius

on Maximum Trackable Speed

Service Oriented None None WSDL Documents for Describing, the WSN Services

Middleware and the SOAP Messages Format and Content

fined period. The application dynamic features define

the mobility characteristic of WSN application. Mobil-ity can be divided into three classes, namely, mobile tar-get, mobile sensors and mobile sink. Location discoveryservice of WSN middleware is especially important formobile sensor model. WSN infrastructure features (seethe left branch of Fig.14(d)) also have important im-pact on the WSN middleware. For example, if TinyOSis used, then synchronization process coordination canbe easily implemented because of the inherent supportfrom the TinyOSs active message mechanism.

An overview of the exiting work can be found in Ta-ble 1, which compares the existing WSN middleware

systems and the proposals by applying the feature tree.We also provide Table 2, which summarizes the exitingWSN middleware by classifying them into Test-beds,simulation and testing tools, and evaluation results.

7 Challenges and Directions

Before concluding this paper, in this section, we dis-cuss the challenges, research issues, and future direc-tions in the area of WSN middleware.

We classify the challenges in designing and imple-menting WSN-middleware into three main types. The

first type of the challenges comes from the conflict

between the contexts of distributed computing andthe embedded sensor devices. Distributed comput-ing should support scalability, reliability, dependability,and heterogeneity, but this demands the careful the de-sign under the context of resource limited devices anddynamic network topology.

The second type of challenges comes from the trade-offs between the degree of application specificity andmiddleware generality. It is important to integrate ap-plication knowledge into the services provided by themiddleware because it can significantly improve the re-source and energy efficiency of the operations. How-ever, since middleware is designed to support and op-timize a broad range of applications, tradeoffs need tobe explored between the degree of application-specificrequirements and the generality of the middleware. Apractical policy is to embed the unique features of anapplication into the application code or specification,which can be interpreted by the middleware at runtime.

The third type of challenges comes from the newcontext of QoS. Because of the limited resources, itis very likely that the performance requirements of allthe running applications cannot be simultaneously sat-isfied. Therefore, it is necessary for the middleware to


19/22


smartly trade the QoS of various applications againsteach other.

Existing work uses different approaches to provide

different WSN-middleware services. For example, thedatabase-based approach is more appropriate for datamanagement services, and mobile agent is more appro-priate for code management services. In fact, the mo-bile agent approach can also be used in data manage-ment services especially in distributed in-network dataprocessing services. So, how to choose or integrate dif-ferent approaches, and how to make their advantagestogether deserves consideration.

With regards to the system architecture, most ofthe current middleware have not considered how to in-tegrate the components into generic middleware archi-

tecture to help developers match different requirements.Because many features need to be considered in the de-sign of WSN middleware, re-factoring WSN middlewarewith aspects[85] is helpful. Services should be reusable,and a generic framework with customizable component-based architecture is desirable. Component-based ar-chitecture has good support for dynamic configuration,and it can make use of the component interface defi-nition to provide slandered service interface. Compo-nents need not always exist, and they can be initializedwhen needed, so as to save the system resource. Therelationship between components and services shouldbe carefully considered. Moreover, design patterns arewidely used in traditional middleware, but until now,there is very little study on design patterns for WSNmiddleware[86]. Also, Domain specific design of WSNmiddleware functions deserves more attention.

Furthermore, evaluation metrics, as well as testingand simulation tools for WSN-middleware are needed.

Finally, WSN middleware can be seen as a kindof lower layer pervasive computing middleware. Un-til now, all the exiting work on WSN middleware hasfocused on the sensor networks. In the future, morekinds of sensor nodes, RFID, and camera sensors will

put new challenges to this research field. Also, with thematurity of new kinds of sensor networks, such as de-lay tolerant sensor networks, sensor and actuator net-works, and mobile sensor networks, we will face newresearch issues in developing WSN-middleware, in or-der to deal with the more complex heterogeneity prob-lems. So, we should consider more integration of WSN-middleware and higher level pervasive computing mid-dleware. WSN middleware focuses on information gath-ering from the physical world and pervasive computingmiddleware focus on the use of the information, andthe appropriate division of functions and cooperationbetween these two kinds of middleware are very impor-

tant for supporting efficient pervasive computing appli-cations.

8 Conclusion

In this paper, we have presented a review of the stateof arts of middleware for wireless sensor networks. Wedescribed a reference model for WSN middleware ar-chitecture as a basis for our discussion. We discussedand evaluated the programming abstractions and mid-dleware services of the model in detail. Using a featuretree-based taxonomy, we classified the features of WSNmiddleware and compared existing projects and propos-als. We also discussed the challenges as well as futureresearch directions in developing WSN middleware.

The main objective of this paper is to provide a

comprehensive understanding of the current issues inthis area for better future academic research and in-dustrial practice of WSN-middleware. WSN is a newand rapidly evolving field, and advances and new ca-pabilities are constantly introduced into the design ofWSN middleware. This paper is presenting what es-sentially constitutes a snap shot of the state of theart around the time of its writing, as is unavoidable thecase of any survey of a thriving research field. We do,however, believe that the core information and princi-ples presented will remain relevant and useful to thereader.

References

[1] Akyildiz IF, Su W, Sankarasubramaniam Y, Cayirci E. A sur-vey on sensor networks. IEEE Communications Magazine,2002, 40(8): 102114.

[2] Cecilia Mascolo, Stephen Hailes. Survey of middleware fornetworked embedded systems. Technical Report for Pro ject:Reconfigurable Ubiquitous Networked Embedded Systems,University College London, 2005.

[3] Java Soft. Java Remote Invocation specification. Revi-sion 1.5, JDK1.2 Edition, Oct. 1998, http://java.sun.com/j2se/1.4.2/docs/guide/rmi/.

[4] OMG. The common object request broker: Architectureand specification, Rev. 2.2, 1998, http://en.wikipedia.org/wiki/CORBA.

[5] Licia Capra, Wolfgang Emmerich, Cecilia Mascolo. Middle-ware for mobile computing. Technical Report, Department ofComputer Science, University College London, 2005.

[6] Murphy A L, Picco G P, Roman G C. Lime: A middlewarefor physical and logical mobility. In Proc. the 21st Int. Conf.on Distributed Computing Systems, Orland, USA, May 2001,pp.524533.

[7] Kay Roomer, Oliver Kasten, Friedemann Mattern. Middle-ware challenges for wireless sensor networks. Mobile Comput-ing and Communications Review, 2002, 6(1): 1217.

[8] Matthew Wolenetz, Rajnish Kumar, Junsuk Shin. Umak-ishore Ramachandran. Middleware guidelines for future sen-sor networks. Technical Report 30332-0280, College of Com-


20/22


puting, Georgia Institute of Technology, Atlanta, Georgia,2004.

[9] Bartolome Rubio, Manuel Diaz, Jose M. Troya. Program-ming approaches and challenges for wireless sensor networks.

In Proc. the 2nd International Conf. Systems and NetworksCommunications (ICSNC07), Cap Esterel, French Riviera,France, August 2531, 2007, p.36.

[10] Jiang Q, Manivannan D. Routing protocols for sensor net-works. In Proc. the 1st IEEE Consumer Comm. and Net-working Conf. (CCNC 04), Las Vegas, NV, USA, IEEE Press,2004, pp.9398.

[11] Chong C, Kumar S P. Sensor networks: Evolution, opportuni-ties, and challenges. In Proc. the IEEE, August 2003, 91(8):12471256.

[12] Sadjadi S M. A survey of adaptive middleware. Technical Re-port, Software Engineering and Network Systems Laboratory,Department of Computer Science and Engineering, MichiganState University, 2005.

[13] Wassim Masri, Zoubir Mammeri. Middleware for wireless sen-

sor networks: A comparative analysis. In Proc. the 2007 IFIPInternational Conference on Network and Parallel Comput-ing, Dalian, China, Sept. 1821, 2007, pp.349356.

[14] Karen Henricksen, Ricky Robinson. A survey of middlewarefor sensor networks: State-of-the-art and future directions. InProc. the Int. Workshop on Middleware for Sensor NetworksTable of Contents, Melbourne, Australia, 2006, pp.6065.

[15] Salem Hadim, Nader Mohamed. Middleware for wireless sen-sor networks: A survey. In Proc. the 1st Int. Conf. Comm.System Software and Middleware (Comsware06), New Delhi,India, Jan. 812, 2006.

[16] Hill J, Szewczyk R, Woo A, Hollar S, Culler D, Pister K. Sys-tem architecture directions for networked sensors. In Proc.the 9th Int. Conf. Architectural Support for ProgrammingLanguages and Operating Systems (ASPLOS-IX), New York,NY, USA, ACM Press, 2000, pp.93104.

[17] Kay Rome. Programming paradigms and middleware for sen-sor networks. Technical Report, Institute for Pervasive Com-puting, ETH Zurich, 2002.

[18] Nuno Costa, Antonio Pereira, Carlos Serodio. Virtual ma-chines applied to WSNs: The state-of-the-art and classifi-cation. In Proc. the 2nd International Conference on Sys-tems and Networks Communications (ICSNC 07), Cap Es-terel, French, Riviera, France, August 2531, 2007.

[19] Kang K, Cohen S, Hess J, Nowak W, Peterson S. Feature-oriented domain analysis (FODA) feasibility study. TechnicalReport, CMU/SEI-90-TR-21, Pittsburgh, Software Engineer-ing Institute, Carnegie Mellon University, PA, 1990.

[20] Levis P, Culler D. Mate: A tiny virtual machine for sensor net-works. In Proc. the 10th Int. Conf. Architectural Support forProgramming Languages and Operating Systems (ASPLOS-X), San Jose, USA, ACM Press, 2002, pp.8595.

[21] Levis P, Gay D, Culler D. Bridging the Gap: Programmingsensor networks with application specific virtual machines. InProc. the 6th Symp. Operating Systems Design and Imple-mentation(OSDI 04), San Francisco, USA, 2004, pp.273288.

[22] Liu T, Martonosi M. Impala: A middleware system formanaging autonomic, parallel sensor systems. In Proc.PPoPP03, San Diego, California, USA, June 2003, pp.107118.

[23] Welsh M, Mainland G. Programming sensor networks usingabstract regions. In Proc. the 1st Usenix/ACM Symp. Net-worked Systems Design and Implementation (NSDI 04), SanFrancisco, CA, March, 2004, pp.2942.

[24] Gummadi R et al. Macro-programming wireless sensor net-works using kairos. In Proc. the Int. Conf. Distributed

Computing in Sensor Systems (DCOSS 05), Marina del Rey,USA, LNCS 3560, Springer, 2005, pp.126140.

[25] Madden S R, Franklin M J, Hellerstein J M. TinyDB: Anacquisitioned query processing system for sensor networks.

ACM Trans. Database Systems, 2005, 30(1): 122173.[26] Bonnet P, Gehrke J, Seshadri P. Towards sensor database sys-tems. In Proc. the 2nd Int. Conf. Mobile Data Management(MDM 01), Hong Kong, China, 2001, pp.314810.

[27] Kirsten Terfloth, Georg Wittenburg, Jochen Schiller. FACTS A rule-based middleware architecture. In Proc. theIEEE/ACM International Conference on Information Pro-cessing in Sensor Networks (IPSN), Los Angeles, USA, 2006.

[28] Fla Via, Paulo F Pires. A Service Approach for ArchitectingApplication Independent Wireless Sensor Networks. ClusterComputing, Netherlands: Springer Science Business Media,Inc, 8, 2005 C, 2005, pp.211221.

[29] Fok C, Roman G, Lu C. Mobile agent middleware for sensornetworks: An application case study. In Proc. the 4th Int.Conf. Information Processing in Sensor Networks (IPSN05), UCLA, Los Angeles, California, USA. Apr. 2527, 2005,

pp.382387.[30] Abdelzaher T, Blum B, Cao Q, Evans D, George J, George S,

He T, Luo L, Son S, Stoleru R, Stankovic J, Wood A. Envi-roTrack: Towards an environmental computing paradigm fordistributed sensor networks. In Proc. the 24th Int. Conf.Distributed Computing Systems (ICDCS 04), Tokyo, Japan,March 2326, 2004, pp.582589.

[31] Krishna Chintalapudi, Jeongyeup Paek, Omprakash Gnawali,Tat S Fu, Karthik Dantu, John Caffrey, Ramesh Govindan,Erik Johnson, Sami Masri. Structural damage detection andlocalization using NETSHM. In Proc. the 5th Int. Confer-ence on Information Processing in Sensor Networks (IPSN06), Nashville, TN, USA, April 1921, 2006, pp.475482.

[32] Musiani D, Lin K, Simunic Rosing T. Active sensing platformfor wireless structural health monitoring. In Proc. the 5th In-

ternational Conference on Information Processing in SensorNetworks (IPSN 07), Cambridge, Massachusetts, April 2527,2007.

[33] TinyOS communities. TinyOS specification, http://www.tinyos.net.

[34] Chen D, Varshney P K. QoS support in wireless sensor net-works: A survey. In Proc. the Int. Conf. Wireless Networks(ICWN 04), Las Vegas, Nevada, USA, June 21, 2004.

[35] Mohsen Sharifi, Majid Alkaee Taleghan, Amirhosein Taherko-rdi. A middleware layer mechanism for QoS support in wire-less sensor networks. In Proc. the Int. Conf. Networking,Int. Conf. Systems, and Int. Conference on Mobile Commu-nications and Learning Technologies (ICNICONSMCL 06),Mexico, 2006, p.118.

[36] Mauri Kuorilehto, Marko Hannikainen, Timo D Hamalainen.

A survey of application distribution in wireless sensor net-works. EURASIP Journal on Wireless Communications andNetworking, 2005, 38(5): 774788.

[37] Srisathapornphat C, Jaikaeo C, Shen C. Sensor informationnetworking architecture. In Proc. the Int. Workshop Paral-lel, IEEE CS Press, 2000, pp.2330.

[38] Heinzelman W B et al. Middleware to support sensor networkapplications. IEEE Network, 2004, 18(1): 614.

[39] Lifton J, Seetharam D, Broxton M, Paradiso J. Pushpin.Computing system overview: A platform for distributed, em-bedded, ubiquitous sensor networks. In Proc. the 1s Int.Conference on Pervasive Computing (Pervasive02), Zurich,Switzerland, August 2002, pp.139151.

[40] Barr R et al. On the need for system-level support for ad hocand sensor networks. Operating Systems Review, 2002, 36(2):15.


21/22


[41] Athanassios Boulis, Chih-Chieh Han, Mani B Srivastava. De-sign and implementation of a framework for efficient and pro-grammable sensor networks. In Proc. the First InternationalConference on Mobile Systems, Applications, and Services

(MobiSys 03), SAN Francisco, CA, US