Virtual machine. This system is flexible and contains virtual machines (VMs), interpreters, and mobile agents. It lets developers write applications in separate, small modules. The system injects and distributes the modules through the network using tailored algorithms, such as overall energy consumption and resource use are minimized. The VM then interprets the modules. This approach, however, suffers from the overhead that the instructions introduce.
Mate WSN middleware is among those that use a VM approach as an abstraction layer to implement its operation and tackle the challenges we've mentioned. 12,13 The project focuses on the need for new programming paradigms to overcome constraints such as limited bandwidth and network activities' large energy draw. Mate proposes a spectrum of reprogrammability, from adjusting simple parameters to uploading complete program updates using a VM. Sending a single bit of data can consume the same energy as executing thousands of instructions to produce that bit of data. The VM can use and support a content-specific routing and reprogramming model.
Mate is a byte code interpreter that runs on TinyOS. 14,15 TinyOS is the de facto operating system for sensor networks that run on motes (small devices with a small CPU and limited storage resources). Written using the NesC language, 16 TinyOS adopts a component-based model to build sensor network applications in an event-driven operating environment. TinyOS binds components statistically and then compiles them to a binary image that's programmed into a sensor node's flash memory. In TinyOS, communication between nodes is based on the active messages paradigm. According to this paradigm, each message contains the ID of a handle to be invoked on the target node and a data payload to pass as an argument.
Mate uses codes broken into capsules of 24 byte-long instructions. This benefits large programs, which are made up of multiple capsules and, thus, easily injected into the network. Mate's key components are the VM, the network, the logger, the hardware, and the boot/scheduler. Using a synchronous model that begins execution in response to an event such as a packet transmission or a time out, Mate avoids message buffering and large storage. The synchronous model makes application-level programming simpler and far less prone to bugs than dealing with asynchronous event notifications. Another Mate functionality is infection or network updates achieved by adding a version number to the capsule. So, comparison takes place at the neighbors, followed by installation of the new version. This process cascades with hop-to-hop communication.
Magnet is also in the middleware category that uses a VM. 17 MagnetOS is a power-aware, adaptive operating system specially designed for sensor and ad hoc networks. It constitutes a layer defined as Single System Image, which provides a higher abstraction for the heterogeneity of ad hoc networks' distributed nature. The abstraction lets the whole network appear as a single, unified Java VM. Following the JVM pattern, the system comprises dynamic and static components. The static component is responsible for rewriting regular java applications in the form of objects or modules, which explains MagnetOS's object-oriented nature. Then the component injects them into the network with special instructions to keep the semantics. At this point, a dynamic runtime component on each node monitors the object's creation, invocation, and migration, providing different services for applications.
For performance purposes, MagnetOS runtime provides flexibility for programmers to explicitly adjust object placement and migration. This lets them reduce network communication by moving objects closer to data sources, for instance. MagnetOS provides a robust, power-aware algorithm using object migration of the same application to nodes that are topologically closer together. This mechanism reduces application energy consumption and increases longevity.
Modular programming (mobile agents). The key to this approach is that applications are as modular as possible to facilitate their injection and distribution through the network using mobile code. Transmitting small modules consumes considerably less energy than a whole application. For example, Impala18 provides mechanisms for network updates that are efficient enough to support dynamic applications. Its autonomic behavior increases its fault tolerance and network self-organization. However, the nature of its code instruction doesn't allow hardware heterogeneity, which makes it unsuitable for devices with limited resources.
The insight for Impala stems from the observation that sensor networks are long running and autonomous. Impala was specially designed as part of the wildlife-watch project ZebraNet. It proposes an asynchronous, event-based middleware layer that uses program modules (mobile agents) compiled into binary instructions then injected into the network. The approach ensures application adaptation and can automatically discern needed parameter settings or software uses. Programmers can plug in new protocols at anytime and switch between protocols at will.
The middleware itself is separated into two layers. The upper layer contains all of the ZebraNet applications and protocols. These applications use various strategies to achieve the common task of gathering environment information and routing it to a base station. The lower layer contains three middleware agents: event filter, adapter, and updater. The event filter controls different operations and initiates processing chains: timer, packet, send, done data, and device events. Armed with the Application Finite State Machine (AFSM), the adapter agent handles application adaptation on the basis of different scenarios, such as energy efficiency and other attributes the applications determine. The updater agent is in charge of achieving effective software updates with resource constraints by taking into account trade-offs such as high node mobility, constrained bandwidth, wide range of updates, propagation protocol, and code memory management.
Impala adopts a module-based system with a version number. Each application as a whole also has a version number. Before exchanging software updates, nodes exchange an index of application modules. They then request only the changed modules for transmission, which saves network bandwidth. The system compiles program modules into binary instructions before injecting them into the network. Impala won't link a module to the main program for installation until it receives the whole update.
Database. This approach views the whole network as a virtual database system. It provides an easy-to-use interface that lets the user issue queries to the sensor network to extract the data of interest. However, the approach provides only approximate results, and it lacks the support of real-time applications that need the detection of spatio-temporal relationships between events.
Cougar introduces a new dimension in middleware research by adopting a database approach in which sensor data are considered a virtual relational database. 19 Cougar ( http://www.cs.cornell.edu/database/cougar) implements WSN management operations in the form of queries, using an SQL-like language. The system defines a sensor database system comprising sensor database and sensor queries. The sensor database, in its turn, contains stored data and sensor data. Cougar represents stored data as relations that include the set of sensors that participate in the sensor database and the sensors' or physical environment's characteristics. Signal-processing functions generate the sensor data, which is represented as time series to facilitate sensor query formulation. Cougar then uses abstract data types with virtual relations to model the signal processing functions. Because object-relational databases support ADT, Cougar represents these signal-processing functions as sequences. An ADT represents all sensors of the same type in the physical world. With algebra operators, the system formulates the sensor queries as SQL-like language with little modifications. To maintain a persistent view of long running queries, Cougar supports such queries using incremental results.
TinyDB is a query-processing system for extracting information from a network of sensor devices using TinyOS as an operating system. 20 As we mentioned, other solutions using TinyOS generally force the user to write embedded C code (NesC) to extract sensor data. However, TinyDB relieves the user from this complexity by providing an easy, SQL-like interface for extracting the data of interest from sensor nodes with limited power and hardware resources.
The queries use simple data manipulation to indicate the type of readings, such as light and temperature, as well as the subset nodes of interest. For that purpose, TinyDB maintains a virtual database table (called SENSORS), where columns contain information such as sensor type, sensor node identifier, and remaining battery power. We can view reading out the sensors at a node as adding a row to SENSORS. Consider the following example: A user wants to report when the average temperature is above 80° F in any room on the third floor of a building sensors that are monitoring. The user inputs the following database query along with the rate at which the sensors are to collect data:
TinyDB uses a controlled-flooding approach to send the queries throughout the network. The system maintains a routing tree (spanning tree) rooted at the end point (usually the user's physical location). Then, in a decentralized approach, every sensor node has its own query processor that processes and aggregates sensor data and maintains all routing information. The parent node closer to the root agrees with its children on a time interval for listening for data from them. The whole process repeats for every period and query.
SINA (System Information Networking Architecture) models the network as massively distributed objects. 21 SINA is cluster-based middleware, and its kernel is based on a spreadsheet database for querying and monitoring. Each logical datasheet comprises cells, and each cell represents a sensor node attribute (in the form of a single value, such as power level and location, or multiple values, such as temperature changes history). Each cell is unique, and each sensor node maintains the whole datasheet. The sensor network as whole is a collection of datasheets. The spreadsheet approach is the abstraction that allows information management to meet application changes and needs. SINA, then, incorporates two robust mechanisms: hierarchical clustering allowing scalability and energy savings, and an attribute-based naming scheme based on an associative broadcast to manage the spreadsheets. The cells are initiated in a node by requests from other nodes. The nodes make requests in a SQL-like statement. The nodes maintain the cells through four possible approaches: on-demand content retrieval, content coaching, periodic content update, and triggered content update.
DsWare (Data Service Middleware) is a database-like abstraction approach tailored to sensor networks on the basis of event detection. 22 DsWare provides more flexibility by supporting group-based decision-making and reliable data-centric storage. It improves real-time execution performance and aggregated results' reliability and reduces network communication (overhead). DsWare provides applications with services supported by its architecture modules such as data storage, data caching, group management, event detection, data subscription, and scheduling. Like Cougar, DsWare uses an SQL-like language for registering and canceling events.
Application driven. This approach introduces a new dimension in middleware design by supplementing an architecture that reaches the network protocol stack. This will let programmers fine-tune the network on the basis of application requirements—that is, applications will dictate network operations management, providing a QoS advantage. However, the tight coupling with applications might result in specialized, not general purpose, middleware.
Milan's (Middleware Linking Applications and Networks) masterpiece is its focus on high-level concerns by providing an interface that's mainly characterized by applications that actively affect the entire network. 8 Milan lets sensor network applications specify their quality needs and adjusts the network characteristics to increase application lifetime while still meeting those needs. To accomplish that, it receives
• the individual applications' QoS requirements over time and a way to meet these QoS requirements using different sensor combinations,
• the different applications' relative importance to the overall system and the user, and
• the network's available sensors and resources, such as energy and channel bandwidth.
With specialized graphs incorporating state-based changes in application needs, Milan can determine the adequate combination ( F A) of sensors satisfying an application's QoS requirements. Then, with its architecture that extends into the network protocols stack and an abstraction layer that lets network-specific plug-ins convert commands to protocol-specific commands, Milan can configure and manage the network. Depending on the application feasible set ( F A), the network plug-ins determine which sets of sensor nodes ( F N) best meet the requirement, as well as other information such as each node's role. Finally, Milan combines the two constraints to get an overall set of feasible combinations: F = F A ∩ F N .
Message-oriented middleware. Mainly a communication model in a distributed-sensor network, message-oriented middleware uses the publish-subscribe mechanism to facilitate message exchange between nodes and the sink nodes. The strength of this paradigm lies in that it supports asynchronous communication very naturally, allowing a loose coupling between the sender and the receiver. This approach is quite suitable in pervasive environments such as wireless sensor networks, where most applications are based on events.
Mires proposes an adaptation of a message-oriented middleware for traditional fixed distributed systems. 23 Mires provides an asynchronous communication model that's suitable for WSN applications, which are event driven in most cases, and has more advantages over the traditional request-reply model. Mires is built on TinyOS using NesC. It adopts a component-based programming model using active messages to implement its publish-subscribe-based communication infrastructure.
Mires' architecture includes a core component (a publish-subscribe service), a routing component, and some additional services, such as data aggregation. The publish-subscribe service coordinates the communication between middleware services. Communication occurs in three phases. First, the nodes in the network advertise their sensed data (topic) through the publish service. Next, Mires routes the advertised messages to the sink, using the multi-hop routing algorithm. Finally, the user application subscribes to topics of interest using only a suitable GUI. The publish-subscribe service also maintains the topics list and the subscribed application to marshal the right topic to the related application. Mires sends only messages referring to subscribed topics, hence reducing the number of transmissions and energy consumption. It includes a data aggregation service that lets the user specify how data will be aggregated and the association between topics of interest and aggregates.
Other approaches. Other middleware research efforts also provide programming support in the sensor network community. However, most of them fall into one of the approaches we've mentioned, and they use similar mechanisms. These efforts include AutoSec, Agilla, Garnet, and SOS.
AutoSec (Automatic Service Composition) is an application-driven middleware framework that focuses on providing support for dynamic service brokering. 24 In a distributed system, this focus allows better resource use. Distributed applications have QoS requirements that programmers can translate into the underlying system-level resources. AutoSec has an architecture that goes deep in the network. It performs resource management and organization in a sensor network by providing the required QoS for applications on per-sensor basis. It does this by choosing a combination of information-collection and resource-provisioning policies from a given set on the basis of user and system needs.
Agilla is Based on Mate and extends that approach by providing mechanisms for better injection of a mobile code into the sensor network to deploy user application. 25 Mobile agents can intelligently move or clone themselves into desired locations based on network changes. This method is more suitable than the flooding mechanisms Mate uses for the same purpose.
Garnet is a middleware framework that focuses on managing data streams as an abstraction within a sensor network. 26 Garnet offers a collection of system services such as receivers, filtering and dispatching services, resource manager, and orphanage.
SOS is considered an operating system specifically designed for motes sensor networks class. 27 However, we judged useful to include it here because it provides some middleware services. Moreover, its kernel includes a sensor API, which makes developing sensor network applications on top of it easy. It's actually a suitable operating system to develop more middleware services for WSN applications. SOS's motivation stems from the need for a general purpose operating system that allows dynamic configurability. This lets programmers dynamically change software modules in sensor nodes after they have deployed and initialized the network.
SOS offers incremental software updates, addition of new software modules, and removal of unnecessary or unused modules. These functions should be done with minimal energy and resources consumption, which is critical in sensor nodes. TinyOS adopts a single system image that's statistically linked at compile time, where there is no kernel mode and user mode. In contrast, SOS adopts a more general-purpose approach by having its architecture composed of a common kernel and dynamic application modules that can be loaded and unloaded at runtime.
Global behavior (macroprogramming). This subclass introduces a new and completely different view on how to program sensor networks. Macroprogramming involves programming the sensor network as a whole, rather than writing low-level software to drive individual nodes. The WSN global behavior is programmed at a high-level specification, enabling automatically generated nodal behaviors. This relieves application developers from dealing with low-level concerns at each network node.
Kairos focuses on providing the necessary notions and concepts to design, develop, and implement a macroprogramming model on WSN. 28 Kairos allows developers to express a single centralized program (global behavior) into subprograms that can execute on local nodes (nodal behavior). It includes compile time and runtime subsystems, leaving only a small set of programming primitives for the programmer while making transparent the low-level concerns such as the distributed code generation, remote data access and management, and internode program flow coordination. Kairos extends to a programming language by providing three main abstractions:
• a node abstraction for manipulating nodes and lists of nodes,
• a list of one-hop neighbors for tracking the current list of the node's radio neighbors, and
• a remote data-access mechanism to read from variables at named nodes.
Kairos addresses node synchronization in either a loose synchronization or a tight synchronization. Programmers choose the method on the basis of trade-offs between efficiency and overhead.
Local behavior. In most sensor network applications, the focus is more on the nature of the sensed data, which generally involves a group of sensor nodes in a specified region. In region or Hood style, the interest is on a specific location in a sensor network—for example, applications are more likely to ask for a location where the temperature exceeds a certain value, rather than for an individual sensor reading. In data-centric sensor networks, nodes are addressed according to the data produced—for example, detect a target having a shape of "tank" in military applications.
Abstract regions29 stem from the observation that most sensor network applications involve the cooperation of a group of nodes over which local computation, data aggregation, and communication occur. For example, in the military, tracking a mobile target involves aggregating all sensor readings from nodes near the object to generate accurate information on the characteristics of that target. Based on this observation, abstract regions are a suite of general-purpose communication primitives for WSN that provide addressing, in-network data aggregation, 8 and data sharing and reduction in the network's local regions. This serves an efficient method for energy and bandwidth savings by trading increased local computation for reduced radio communication, which is expensive in terms of energy. For example, consider a sensor network application for determining the boundaries of a region of interest in a network. The best approach is having nearby nodes cooperate and compute the boundaries locally, then communicate the results to the base station. This yields considerable energy savings and less communication overhead than having the base station collect data centrally on each sensor.
Abstract regions support operations such as neighbor discovery, in which sensor nodes discover each other's enumeration operator to return the set of nodes participating in the region; and data sharing between the nodes in the region and a reduction operator, whose role is to reduce the amount of data shared in a region by performing operations such as sum, max, or min on the sensors data. Due to the wide range of sensor network applications, Matt Welsh and Geoff Mainland propose various abstract regions implementations: radio and geographic neighborhood, approximate planar mesh, and spanning tree. 28 Each of these implementations is suitable for a subset of sensor networks applications. They have proven successful on University of California, Berkeley, motes running on TinyOS.
EnviroTrack (data-centric)30 is well suited for embedded tracking applications. EnviroTrack adopts a data-centric programming paradigm called attributed-based naming through context labels, where the routing and addressing are based on the requested data's content rather than the target sensor node's identity. As with most of the projects, it's also built on top of TinyOS using compiled NesC programs. Its contribution stems from its convenient, robust interface for application developers geared toward tracking the physical environment. Programmers apply the attributed-based naming by associating user-defined entities (context labels) to real physical targets. With this network-abstraction layer, the programmer declares the environmental characteristics, which define the context label of the object to be tracked. Based on this declaration, all sensor nodes that sense the same declared characteristics (object) are aggregated to track that physical target, such as a car or a fire.
With powerful network-management mechanisms such as lightweight group management and group leader election, EnviroTrack supports the dynamic behavior of the tracked targets, such as mobility. Thus, the system detects and reports any moving target's presence, which is very useful for environmental watch and military applications. EviroTrack is one middleware service among a whole set of other middleware services carried out at the University of Virginia under a major initiative in the sensor network community called VigilNet, 31 an integrated sensor network system for surveillance missions.
Other research. Additional research efforts fit in either category. Recent projects adopting a macroprogramming model include
• Regiment: a demand-driven functional language that takes a sensor network as a whole, 32
• Abstract Task Graph: a data-driven programming model incorporating novel extensions for distributed sense-and-respond applications, 33 and
• Semantic Streams: a mark-up and declarative query language based on the use of semantic services accessed directly by query specifications. 34
Projects adopting a local-nodal-behavior programming model include
• Hood: similar to abstract regions, Hood shows that a neighborhood abstraction of sensor nodes can convey local behaviors adequately. 35 and
• Generic role assignment: programmers assign individual sensor nodes user-defined roles in an application-specific manner. 36 (Due to article length constraints, we left out the implementation details of these projects).
Salem Hadim is a PhD student at the Stevens Institute of Technology. His research interests include middleware, software systems, multimedia networking, autonomic computing and enabling technologies, and wireless ad hoc sensor networks. He received an MS degree in computer engineering from the Stevens Institute of Technology. Contact him at the Dept. of Electrical and Computer Eng., Stevens Institute of Technology, Hoboken, NJ 07030; email@example.com.
Nader Mohamed is an assistant professor of electrical and computer engineering at Stevens Institute of Technology. His research interests include middleware, sensor networks, software systems, cluster and Grid computing, and systems integration. He published more than 30 articles in journals and conferences in these areas. He received a Ph.D. in computer science from the University of Nebraska-Lincoln. Contact him at the Dept. of Electrical and Computer Eng., Stevens Institute of Technology, Hoboken, NJ 07030; firstname.lastname@example.org.