Remotely Deployed Virtual Sensors

TR-UTEDGE-2007-010

Sanem KabadayiChristine Julien

© Copyright 2007The University of Texas at Austin

Remotely Deployed Virtual SensorsSanem Kabadayı and Christine Julien

The Center for Excellence in Distributed Global EnvironmentsThe Department of Electrical and Computer Engineering

The University of Texas at AustinEmail: {s.kabadayi, c.julien}@mail.utexas.edu

Abstract—In this paper, we focus on supporting remote het-erogeneous monitoring, in which applications that run on mobileclient devices connect to the sensors of a multihop sensor network.For emerging pervasive computing environments, the ability toremotely retask sensor networks for different applications will beindispensable. This requires combining the basic physical sensordata available in the network to provide tailored application-leveldata. In our approach, the necessary data types and aggregationfunctions are encapsulated in a message and sent to a node thatbecomes the virtual sensor coordinator. This node modifies itsbehavior based on the received message, obtains the necessarydata from the virtual sensor’s participants, and performs therequired aggregation before sending the result back to the client.This paper reports on our initial work with remotely deployedvirtual sensors and results of our implementation.

I. INTRODUCTION

Pervasive computing environments use sensor networks,which entail a multitude of ubiquitous sensing devices. Thesedevices have limited computational and communication ca-pabilities and generally provide highly specialized function-ality. In this paper, we focus on supporting applications inwhich client devices (e.g., laptops or PDAs) that users carrythrough the environment interact directly with such multihopsensor networks. While such structure is common in manyapplications, we motivate our approach using applicationsfrom the construction domain, which provides a unique andheterogeneous mix of devices.

As developers construct applications for these environments,they may desire to have information that is not available usingthe basic physical sensors in the environment. We define avirtual sensor as a software sensor that provides an indirectmeasurement of an abstract condition (that, by itself, is notphysically measurable) by combining sensed data from a groupof heterogeneous physical sensors [1].

Fig. 1 depicts physical sensors aggregated into a virtualsensor that can run (a) locally (the virtual sensor runs on theclient) or (b) remotely (the virtual sensor runs in the network).The physical sensors that provide the base types for the virtualsensor are illustrated using circles, and the different shadingsindicate their potentially heterogeneous nature. The sensorsinside the dashed circle contribute to the virtual sensor, andthey may be at varying distances from the client device.

Supporting the case shown in Fig. 1(a) is straightforwardusing today’s sensor network capabilities; each of the physicaldata types can be independently collected from the networkand then aggregated on the client device in a higher-level

Virtual Sensor

(a) Physical sensors aggregatedinto a virtual sensor which runslocally

Virtual Sensor

(b) Physical sensors aggregatedinto a virtual sensor which runsremotely

Fig. 1. Two different types of virtual sensor deployments

language (e.g., Java) [2]. In this paper, we consider the morecomplicated situation depicted in Fig. 1(b) in which the virtualsensor is dispatched into the network to execute on resource-constrained sensing devices. In this case, the application’sdefinition of a virtual sensor in a high-level language mustbe translated into a form understandable by the underlyingresource-constrained sensor network. This potentially limitsthe expressiveness of the virtual sensors that can be specified,but it also has the potential to drastically reduce the overheadof heterogeneous aggregation in sensor networks because itreduces the number of messages that must be sent.

While we do not assume any hierarchy in the physicalnetwork, the virtual sensors can be hierarchical: a virtualsensor can use other virtual sensors in the same way it usesphysical sensors. We view physical sensor data types andvirtual sensor data types as both being merely data types frominformation sources in the network. If a sensor, either physicalor virtual, can be discovered in the network, it can be used toextract information and therefore to build a virtual sensor.

The novel contributions of this work are the ability to createremote virtual sensors and the ability to create hierarchicalvirtual sensor specifications. We define a virtual sensor modelthat abstracts data from heterogeneous physical sensors byapplying user-defined functions and realize this model ina middleware implementation. The virtual sensors enableadaptive and efficient in-network processing that dynamicallyresponds to an application’s needs.

Section II provides a complete problem definition. Sec-tion III describes our virtual sensor model, while Section IVdetails its design and implementation. In Section V, we

2

Position sensor

Tension sensorMaximum load moment

Safe Working Load?

(a)

BasePosition

DangerCircle

BoomPosition

Safe to walk?

(b)

Concrete

Temperature sensor

Temperature sensor

Temperature sensor

Temperature sensor

Cured?

(c)

Fig. 2. Construction site domain examples

discuss the performance characteristics of the virtual sensorimplementation, drawing on three example applications fromthe construction site domain. Section VI examines relatedwork and Section VII concludes.

II. MOTIVATION AND PROBLEM DEFINITION

The tiny sensing devices that support pervasive computingenvironments have many constraints. Limited energy is a ma-jor concern, and it is therefore essential to reduce applications’communication overhead. The amount of communication eachsensor must perform can be reduced through the use of in-network aggregation, so that not all data has to be relayedback to a requesting node; instead, the necessary result canbe calculated en route through node cooperation. Existingsolutions generally provide only homogeneous aggregation.However, emerging user-level applications will leverage capa-bilities from RFIDs, smart cell phones, sensors from differentvendors, etc. that provide vastly varying data types. Hetero-geneous data aggregation is important in combining this datainto a single abstract measurement.

It will often be most efficient in terms of communicationto perform such aggregation remotely, in the network, asopposed to collecting all of the available data and processingit offline. This task is significantly more complicated thanthis simple statement implies; remotely deploying complexaggregation requires being able to quickly load new func-tionality on remote, resource-constrained sensors. In addition,sensor networks in support of pervasive computing must bereusable. Current efforts create application-specific solutions,but the future will see multipurpose networks deployed tosupport numerous and changing applications. The cost ofphysically visiting each sensor to reprogram it is prohibitive,and therefore the ability to remotely reprogram sensors totailor them to particular applications will be essential. Someexisting approaches attempt to perform the remote code de-ployment [3], [4], [5], but they have limitations with respectto how applications can tune the distribution of the new code,what the code can do, and in which situations mobile code canbe used. We will revisit these existing systems in Section VI.

As sensor networks become widespread in their supportof a variety of applications, the utility of an abstractionthat addresses these challenges can be demonstrated through

many examples. We draw examples from the intelligent con-struction site, where potentially mobile sensors embedded inequipment and structures can support safety and managementapplications [6]. We introduce three examples and revisit themthroughout the remainder of the paper.

Crane safe load sensor. On an intelligent constructionsite, users may desire the cranes to have safe load indicatorsthat determine if a crane is exceeding its capacity. A safeload indicator would rely on measurements from physicalsensors that monitor boom angle, load, telescoping length,two-block conditions, wind speed, etc. [7]. Using fewer datatypes for ease of presentation, Fig. 2(a) depicts the connectionto an application-defined safe-load sensor (represented by thedashed ellipse) on a tower crane that uses data from threephysical sensors (represented by dots). The safe-load sensoraggregates the information from these sources into a higher-level reading that represents the effective load on the crane andcompares this against the crane’s known safe working load.

Crane danger circle sensor. A danger circle represents thearea near a crane where it is unsafe to walk. It is centered at thebase of the crane (which may move) and has a radius definedby the position of the boom (which is even more likely tomove). Fig. 2(b) shows a software sensor that calculates sucha “danger circle” using two different physical sensors. As theboom moves along the crane arm, the size of the danger circleshould expand and contract accordingly.

Aggregate concrete cure sensor. A construction site super-visor coordinating a team of workers spread throughout thesite may want to have an aggregate view of the concrete cureconditions over a concrete slab in the site. Fig. 2(c) shows anaggregate concrete cure sensor that would allow the supervisorto be alerted when the concrete is ready for use. While the firsttwo examples provide heterogeneous aggregation, this thirdapplication demonstrates homogeneous aggregation.

In summary, these application-motivated challenges leadus to create a light-weight, parameterizable middleware thatruns on every node in the network. We provide the domainexpert with a Java application programming interface and aset of operations that can be combined to specify complicatedvirtual sensor behavior. Instead of sending new code when thedeveloper wants to inject a new virtual sensor, a message is

3

sent that contains the parameters for specializing a genericpiece of code already present within the middleware. Thisshould significantly reduce the communication and computa-tional costs associated with loading new functionality but mayalso decrease the flexibility of virtual sensor definitions. Weevaluate these tradeoffs in later sections.

III. VIRTUAL SENSORS MODEL

In this section, we introduce the virtual sensors model.After giving an overview of the model, we will detail theessentials of virtual sensor creation, which include specifyingthe input data types and the resulting abstract data type. Withthe data types defined, the sensors that can provide these typesneed to be discovered; since we do not want to flood theentire network with messages for sensor discovery, we showhow traditional scoping abstractions can be applied to limitthe reach of discovery messages. We then use these buildingblocks to completely formalize the virtual sensor definitionand describe how virtual sensors are subsequently used byapplications.

A. Model Overview

In our model, several sensors required to supply the desiredapplication-level data to the client application are encapsulatedin a virtual sensor. A virtual sensor’s declarative specificationoffers the ability to specify any desired function and leavesthe discovery of physical data sources to an underlying com-munication layer. It also provides a layer of abstraction for theapplication developer in comparison to directly programmingin the low-level language that the sensing devices use.

The physical sensors are the components of the modelthat provide the basic data types required to compute avirtual sensor’s abstract measurement. Creating a virtual sensorrequires defining a group of sensors that have a defined localityrelationship (e.g., they belong to a local region, where “local”is defined by some property of the network or environment).The resulting virtual sensor has an interface that, from theapplication or user’s perspective, is similar to that of any othersensor (e.g., the physical sensors used to construct it).

B. Creating and Deploying a Virtual Sensor

To create the virtual sensor, our model requires a declara-tive specification that describes the desired sensor’s behaviorwithout requiring the application developer to specify theunderlying details of how the sensor network should supportthat behavior. Most importantly, the virtual sensor specificationhides the explicit data sources from the application and theuser, making them appear as one data source.

We assume applications and sensors share a naming schemefor data types (e.g., they share a knowledge of how to accessa “location” or “temperature” data type). This implies sometranslation machinery deployed in the sensor network; thiswill be discussed in detail in Section IV. The available datatypes are determined by the types of sensors (both physicaland virtual) deployed in a network. A programmer creating

a new virtual sensor must then specify four components tocompletely specify the virtual sensor:• Input data types: the types required to compute the

abstract measurement. These can be provided by physicalsensors or by other virtual sensors that have alreadybeen constructed and deployed. Each input type alsoincludes the number of distinct sensors of this type thatare required. This number could be one, two, all, etc. Thisallows us to differentiate between requests for “all of theconcrete heat sensors” and “one concrete heat sensor.”

• Aggregator: a generic function defined to operate over the(possibly heterogeneous) input data types to calculate thedesired measurement. When the virtual sensor is deployedon a powerful client device, as in Fig. 1(a), high-levelcode (e.g., written in Java) can be directly executed toevaluate the aggregator. In this paper, however, we lookat aggregators that can be dispatched to the resource-constrained sensor network for evaluation.

• Resulting data type: the abstract type that results fromevaluating the aggregator over the input data types.

• Aggregation frequency: the frequency with which thisaggregation should be made. This determines how con-sistent the aggregated value is with actual conditions (i.e.,more frequently updated aggregations reflect the environ-ment more accurately but generate more communicationoverhead). This is similar to the sample frequency ofa physical sensor; at each interval, the virtual sensor“samples” each sensor it uses and aggregates the results.

By providing these virtual sensor specifications, an appli-cation delegates physical sensor discovery to the frameworkthat supports the virtual sensor. Therefore, if the data sourcessupporting the virtual sensor change over time, the virtualsensor can adapt, but the application need not notice. Wenext explore in more detail how data types are modeled in thevirtual sensor framework, how a regional abstraction supportsthe acquisition of data to support the virtual sensor, and howdata types are discovered in a distributed fashion.

1) Modeling Data Types Defining a Virtual Sensor: In ourmodel, a data type may at times be provided by a physicalsensor and at other times by a virtual sensor (e.g., locationprovided by GPS (physical sensor) or by triangulation (virtualsensor)). From the application’s perspective, this is a singledata type. This is mediated through a repository of data typesthat, for lack of a better term, we refer to as the “data typeontology.” The structure and function of this repository aredescribed in more detail later, but, at the model level, it allowsthe architecture to be structured as shown in Fig. 3.

The figure shows two points of interaction with the virtualsensors. The first is through the virtual sensor developer, adomain expert who can create new virtual sensors and insertthem into the virtual sensor code repository. This domain ex-pert possesses the knowledge necessary to create the domain-specific aggregator. For example, an expert in the constructiondomain knows the equations for computing the safe workingload of the crane. Once this virtual sensor is created and madeavailable through the virtual sensor repository, its type can be

4

VS Code

Repository

developer

(domain

expert)

VS definitions

(Section 4)

data type

ontology VS deployment

(Section 4)

application/user

virtual

sensor

Fig. 3. Virtual Sensor Architecture

listed in the data type ontology. When an application or userwants to connect to a data type, whether it be a physical typeavailable directly from one or more sensors in the network or avirtual sensor data type available through a piece of softwaredefined in the virtual sensor repository, the type is listed inthe data type ontology. The two double arrow lines indicatethe discovery process that ensues to find the data type in thenetwork, and, if it is not already available, to cause a virtualsensor to be deployed if possible.

This discovery process is not the focus of this paper; manycommunication mechanisms exist to support this, and thevirtual sensors architecture does not commit to a particular un-derlying communication mechanism. We do, however, brieflydiscuss this issue here and from an implementation perspectivein the next section.

2) Defining the Region of a Virtual Sensor: Restrictingthe physical devices that contribute to the resolution of thevirtual sensor queries requires that a coalition of relatednodes support cooperative query resolution. Protocols forestablishing relative local neighborhoods have been previouslyexplored for sensor networks [8], [9], [10], [11]. Instead ofbuilding in a dedicated neighborhood formation algorithm, thevirtual sensors architecture can incorporate any one of theseapproaches that allows a node (the virtual sensor “coordinator”in our case) to form a local neighborhood around itself. Forthe remainder of this paper, we assume the particular physicaldevices contributing to the virtual sensor are known a priori;our implementation uses an approach based on on-demanddistributed evaluation of proximity functions to determine thevirtual sensor membership on the fly [9].

3) Formalizing Virtual Sensors: Abstractly, a virtual sensoris defined in terms of the physical devices that contribute toits construction. Assuming the physical devices available inthe neighborhood described above can be represented as theset S, we can formalize the constraints on the virtual sensordefinition as:

Given the set of hosts S in the virtual sensor’sneighborhood, the required physical data types,D1, D2, . . . , Dn, the aggregator, A, and the re-

sulting data type, Dres, the virtual sensor can beformalized as:Dres = A(D1, D2, . . . , Dn), where:

〈∀Di : 1 ≤ i ≤ n :: 〈∃V : |V | = Di.count ∧〈∀s ∈ V : s ∈ S ∧ Di.type B s〉〉〉1,2

In the above definition, the set V is the subset of S thatdefines which physical devices contribute to the virtual sensor.V may not be exactly equivalent to S in the case that extranodes are required to provide communication connectionsamong the nodes in V . If the construct in the last line ofthe definition evaluates to false, it is not possible to constructthe specified virtual sensor. Recall from above that the inputdata types (D1, D2, . . . , Dn) are defined by the type of datathey request and the number of independent readings of thattype that are required. We assume the former is expressed asDi.type and the latter is expressed as Di.count. For example,the virtual sensor shown in Fig. 2(b) requires two data typesand one sensor of each type: a single crane base position anda single crane boom position. A virtual sensor that generatesthe average temperature of a curing pad of concrete requirestemperature values from n temperature sensors. In this case,only one D is provided, and its count value reflects the numberof sensors to be polled. As we described previously, the countvalue included in the declaration of the virtual sensor can bea number (e.g., one as in the case of the crane sensors) orall, indicating that all matching sensors in the virtual sensor’sneighborhood should be polled.

C. Using a Virtual Sensor

Domain experts can create virtual sensors at any time. Thesevirtual sensor definitions are then placed in the repositoryshown in Fig. 3 until an application requires the data type thevirtual sensor provides. The virtual sensor’s definition includesan aggregation frequency, but that does not mean that thevirtual sensor sends updates according to that frequency once ithas been defined. Physical sensors are capable of taking read-ings but usually do not do so until some application instructsthem to. Similarly, virtual sensors do not send responses backuntil they are actually queried or used by an application.

IV. IMPLEMENTATION

In this section, we describe the parameterized middlewareimplementation of the virtual sensors abstraction. The userinterface that runs on the client device is written in Java.The middleware that runs on the sensors is written forTinyOS [12] in nesC [13] and programmed onto CrossbowMICA2 motes [14]. Our implementation code is availableat [15]. Virtual sensor definitions are encapsulated in TinyOS

1In the three part notation: 〈op quantified variables : range ::expression , the variables from quantified variables take on all possiblevalues permitted by range. Each instantiation of the variables is substitutedin expression , producing a multiset of values to which op is applied, yieldingthe value of the expression. If no instantiation of the variables satisfies range,then the value of the three-part expression is the identity element for op, e.g.,true if op is ∀.

2The “Di.type B s” construct denotes the fact that “sensor s can providethe data type specified in Di.type.”

5

Application Programming Interface

Virtual Sensor Specification

Unicast (communication)Query domain protocol (discovery)

Physical Sensors

Query Domain Specification

Virtual Sensor

Specifications

API

Data processing

Communication

Network

Fig. 4. Simplified object diagram for the virtual sensor middleware

messages and distributed to sensor nodes. These messages aredescribed in more detail later in this section; we first describehow the developer perceives and interacts with the virtualsensors abstraction.

A. Application Programming Interface

Fig. 4 depicts the middleware’s object diagram from thedeveloper’s perspective. The application developer uses thisAPI to specify virtual sensors, and the middleware then han-dles the necessary sensor network communication on behalfof the application. The virtual sensor constructed as a resultof these specifications uses proximity functions [9] for sensordiscovery. These query domains allow the application devel-oper to specify required relationships among all participantsin the virtual sensor (e.g., all physical sensors contributingto a virtual sensor must be within a given distance of eachother). Once these groups are created, the infrastructure usesa combination of groupcast and unicast communication tomaintain the virtual sensors and to aggregate and retrieve data.

The VirtualSensor object shown in Fig. 4 is maintainedat the client device and keeps a list of live queries. Thisallows a single virtual sensor to support queries from multipleapplications in the same way that a single physical sensorcan provide data for multiple applications. A virtual sensoris deployed only when there are active queries, and theinformation from the virtual sensor is accessed on-demand.

Fig. 5 shows the distributed virtual sensor architecture.The application perceives a single interface to access to bothphysical and virtual sensors. The developer’s high-level code(written in Java) interfaces with the sensors using a data typeontology that includes built-in general-purpose data types (e.g.,temperature, location, angle, etc.) and provides a straight-forward mechanism for inserting additional types. When theapplication needs to query the network for a data type that isnot directly provided by the physical sensors, the developerconstructs and deploys a virtual sensor using his knowledgeof the available data types (as expressed in the ontology). Theapplication subsequently queries this virtual sensor directly, inthe same manner that it queries other physical sensors.

When defining new virtual sensors, the developer needs tospecify the low-level data types and the relationships requiredto compute the desired abstract measurement. This gives thedeveloper the maximum amount of flexibility in specifyingnew data types and how they should be formed while hiding

Java application

sensor interface

To physical sensor

Data types

Availablevirtual sensors

Ontology

To virtual sensor

Fig. 5. Virtual sensor architecture

REQFREQPERSISTENT

2 BYTES 1 BYTE 1 BYTE 2 BYTES

DATA

23 BYTES

CMDSOURCE

REQFREQPERSISTENT

2 BYTES 1 BYTE 1 BYTE 2 BYTES

DATA

20 BYTES

DATATYPE

1 BYTE 2 BYTES

MEASUREMENTCMDSOURCE

TASKMSG

DATAMSG

Fig. 6. Packet formats for the TaskMsg and DataMsg messages

the underlying implementation details from the end user,lending a powerful virtual sensor implementation.

B. Virtual Sensor Tasking

Domain experts define virtual sensors using a high-levelprogramming language. Our middleware translates these defi-nitions into a specific format that is placed in TinyOS messagesand distributed within the sensor network. Specifically, tocreate a virtual sensor and to obtain data from it, we usetwo different packet formats, as shown in Fig. 6. The firstof these, the task message, contains a field that describesthe operations the virtual sensor should perform. Since RPN(Reverse Polish notation, also known as postfix notation) [16]provides a compact representation that is machine-readable,we define the following grammar based on RPN for the datafield of the virtual sensor task messages:

E → E E bin op | datatype all set op | datatype # set op |

datatype datatype bin op | datatype # bin op |

datatype un op |

where:

bin op = {+,−, ∗,÷, POW, <, . . .}set op = {MIN, MAX, SUM, AVG, . . .}un op = {SQRT, COS, SIN, . . .}

and datatype refers to single instances of sensor typesavailable in the network, datatype all indicates a desire toapply a set operation to all available readings of the indicatedtype, and # refers to an integer number (between 0 and 10).

This grammar defines unary operators (e.g., the square root),binary operators (e.g., addition), and set operators (e.g., mini-mum). As defined in the grammar above, data types associatedwith an expression are interpreted differently depending on thetype of operator. For example, a task message containing thedata [Temperature all AVG] instructs the created virtual sensor

6

Task message received

VS Coordinator

?

1. Parse the taskField 2. Extract the data in each buffer and perform the computation 3. Send result back to client device

No

Ignore messageNo

Yes

Yes

VS timer expired?

1. Parse data type/operator field extracting the data types required (and save the operation to be performed in taskField )2. Set up buffers for each data type that is required for the computation (including VS coordinator itself if applicable).3. Save the data field and if the requested data type is ALL, save its operation indexed by data type.3. Send DataMsg (with data field set to the data types requested) requesting data from sensors contributing the data types4. Wait for all the data to come back5. When data comes back, do parsing 6. Extract the data

1. Extract required data types from message2. Set up buffers 3. Save the data field in taskField (and if requested data type is ALL save its operation indexed by data type)4. Send DataMsg requesting data from physical sensors

Yes

TaskMsg received

(while the end of the task field is not reached)Using a stack,- If the next symbol is an operand (a number or a datatype), put it on top of the stack (number itself, or the measurement for the data type pulled from the buffer.- If the next symbol is an operator, remove the top two numbers from the stack, perform the operation, and place the result on top of the stack.Then, do opp:Remove the topmost element from the stack and set rightOperand equal to itIf binary operation:Remove the topmost element from the stack and set leftOperand equal to itPerform the operation and push the result back onto the stack

Parse the task field

Fig. 7. Task Msg received

to collect all of the available temperature readings and averagethem, while [Temperature 5 AVG] instructs the created virtualsensor to collect five temperature readings and average them.

Numbers, data types, and operators make up the alphabetof this grammar, and we map each one to a reserved numberto enable its transmission in a data message:• 0-10: Numbers• 11: “All” (reserved to support additional functionality)• 12-31: Operators (set operators and binary operators)• 32-143: Data types (with the ability to specify the number

of distinct sensors that should provide a value)• 144-255: Data types “all” (this requires all sensors within

the proximity that can provide this data type to respond)

C. Virtual Sensor Operation

The middleware running on the virtual sensor coordinatoris tasked to provide an abstract measurement through thenecessary calculations that are stated in a task message. Tosupport the task, the virtual sensor coordinator sets up buffersfor each data type required for the computation and sends datamessages to the contributing physical sensors, asking for theirdata. When the data comes back from all the physical sensors,the virtual sensor coordinator performs the operations in theorder stated in the task message (and if the query is continuous,this happens at every periodic virtual sensor query interval).

Figs. 7 and 8 show the message processing flowcharts forthe task messages and the data messages, respectively.

Since the goal is to collect data and process it in the networkas it arrives, and since we use an RPN-based grammar for thetask field, we use a stack to perform the calculations whileparsing the task message (shown Fig. 7). Until the end of thetask field is not reached, the task field is parsed and all theoperations are performed in order:

Data message received

VS Coordinator

?

No

Yes

If physical sensor:1. Parse data type field checking if this node can provide the requested data type2. If YES (can provide), send data back to VS coordinator If VS coordinator:1. If single data type, put received measurement into the buffer for this data type2. If ALL data type, update the value in the buffer for this data type using this currently received measurement until all the data from all the physical sensors received

DataMsg received

Update the value in the buffer for this data type using this measurement

No

Yes

Put received measurement into buffer for this data type

Yes

Can provide data

type?

No Ignore message

Yes

Data type ALL?

Send data toVS coordinator

Fig. 8. Data Msg received

• If the next symbol is an operand (a number or a datatype), we place it (the number itself or the measurementfor the data type pulled from the buffer for that data type)on top of the stack.

• If the next symbol is an operator, we remove the topelements from the stack, perform the operation, and placethe result on top of the stack.

The stack reduces the amount of data the virtual sensorcoordinator must store. It also allows a “running” operationthat is computed on the fly and does not need to store historicaldata. To summarize, the task message and the way it is parsedallows any combination of binary and unary operations as wellas comparison operations on any type of data to transformit to an abstract data type, giving the application developerflexibility and the ability to retask sensor nodes.

V. EVALUATION

We evaluate four characteristics of the remote virtual sensor:the abstraction’s expressive power, the complexity of appli-cations created for the middleware, the complexity of themiddleware itself, and the communication overhead requiredto support the abstraction.

A. Expressive Power

The expressive nature of the virtual sensor allows appli-cations to request arbitrary functionality, making it flexibleand useful in interacting with intermittently connected sensornodes. An application can create a virtual sensor directlytailored to its needs. The application can also dynamicallychange the virtual sensor by sending a new virtual sensor taskmessage.

We demonstrate the virtual sensor abstraction’s expressivepower using the three application examples introduced inSection II: a) a crane’s safe working load; b) a crane’sdanger circle; and c) a curing concrete pad. We have deployedeach application on four MICA2 motes running the virtualsensor middleware. Upon receiving a TaskMsg from outside

7

Application Virtual Sensor DefinitionSafe Working Load (ActualLoad ∗ BoomLength) < MaximumLoadMoment

ActualLoad BoomLength ∗ MaximumLoadMoment <24 25 0E 26 16 0 ...0

Danger Circlep

(BasePositionX− BasePositionY)2 + (BoomPositionX− BoomPositionY)2

BasePositionX BasePositionY − 2 POW BoomPositionX BoomPositionY − 2 POW + SQRT20 22 0D 02 10 21 23 0D 02 10 0C 11 0 ...0

Curing Concrete Pad AVG(CureRate, ALL)CureRateAll AVG90 15 0 ...0

Fig. 9. Example Virtual Sensor Definition Messages. For each example, we give the abstract virtual sensor definition first written in standard form, then inRPN. Finally, we give the definition written in the hexadecimal form. in which it is actually transmitted in our prototype. The latter depends on the (static)list of types available for our application domain and on the static mapping of operators to values as shown in Section IV-B.

the network, one of the nodes becomes the virtual sensorcoordinator, gathers the required data from the other nodes,adds its own data (if applicable), performs the calculation,and sends the aggregate result back to the client device. Fig. 9shows the data field of the TinyOS message for each virtualsensor. For each virtual sensor, it takes an average of 1.031seconds to perform the calculation on the MICA2 mote, butthis includes the one second it takes for the virtual sensor toacquire all the data from the other motes contributing to thevirtual sensor.

B. Reduction of Application Complexity

Without the virtual sensors middleware, an applicationdeveloper must construct the entire behavior by hand. Thisincludes querying each physical node and locally aggregatingthe returned data values.

The more straightforward way of coding afforded by thevirtual sensor simplifies the programmer’s task. Instead ofbeing concerned with low-level communication details, theprogrammer delegates complex coding to the middleware. Thedeveloper relies on the programming interface described in theprevious section to provide the aggregation behavior which canbe optimally placed in the sensor network. In addition, the po-tential ability of the middleware to dynamically determine thebest location in the network for the remotely deployed virtualsensor can significantly reduce the communication overhead.For example, instead of retrieving the sensor measurementsfrom each node, then applying a threshold to each retrievedvalue locally, filtering can be performed at the remote virtualsensor, limiting the data that must be sent back. In a localvirtual sensor deployment with four motes, each mote wouldhave to send a message back to the client device, resulting ina total of 4 messages, but in a remote deployment, only onemessage has to be sent all the way back to the client device(i.e., the result from the virtual sensor coordinator).

C. Middleware Complexity

We have quantified the overhead introduced by our middle-ware in terms of the memory footprint. The MICA2 platformhas 128KB of program memory (ROM) and 4KB of primarymemory (RAM). The virtual sensor code (written in nesC)for the crane danger circle application yields the followingmemory footprint for TinyOS and MICA2 motes:

• local deployment: occupies 15,872 bytes in ROM and 544bytes in RAM.

• remote deployment: occupies 17,234 bytes in ROM and1,303 bytes in RAM.

In comparison to computing virtual sensor measurementslocally, remotely deploying the virtual sensor does increase thememory footprint due to the need to have a generic middlewaredeployed that can accept tailored virtual sensor definitions. Themiddleware empowers remote nodes in the network to performcomplicated operations without having to send as much databack to a client node.

In terms of message size, the virtual sensors middleware fitsall virtual sensor definitions into 29 byte TinyOS messages.More complex virtual sensor definitions than those givenas examples here may become lengthy, requiring more thanone 29 byte message to distribute the virtual sensor taskinginformation; support for this multiple message format is savedfor future work.

D. Reduction in Communication Overhead

The amount of communication in a sensor network di-rectly relates directly to the nodes’ energy expenditure andconsequently to network lifetime. The key aspect of thecommunication overhead is the amount of data (in bytes) thatmust be sent. Without the virtual sensor, each data value fromthe remote physical sensors must be sent back to the clientdevice for processing.

Let a virtual sensor, V , require data from n distinct physicalsensors, P1, P2, ..., Pn. Let us assume that Pn is the physicalsensor that is closest to the client device from the set {P1,P2, ..., Pn} and choose that as the virtual sensor coordinator.Assuming that Pn is hn hops away from the client device,and that {P1, P2, ..., Pn−1} are h1, h2, ..., hn−1 hops away,respectively, from the virtual sensor coordinator (see Fig. 1,in Section I for a simple example, where n = 4, h4 = 2, andh1 = h2 = h3 = 1):• A local deployment of such a virtual sensor would take

h1+h2+...+hn−1 transmissions for all the other physicalsensors to send their data to node n. Then, for this node toforward all of these data values and its own value wouldrequire an additional n×hn transmissions, resulting in atotal of nhn +

∑n−1i=1 hi transmissions.

8

0

500

1000

1500

2000

2500

3000

3500

4000

4500

40 60 80 100 120 140 160 180 200

Ove

rhea

d [b

ytes

]

Number of nodes

Graph of Querying Overhead vs. Number of Nodes

Traditional QueryingVirtual Sensor

(a)

0

500

1000

1500

2000

2500

3000

3500

4000

0 2 4 6 8 10

Ove

rhea

d [b

ytes

]

Number of nodes in virtual sensor

Graph of Querying Overhead vs. Size of Virtual Sensor

Traditional QueryingVirtual Sensor

(b)

Fig. 10. Reduction in communication overhead when using a virtual sensor

• In the case of a remote deployment, it would takeh1+h2+...+hn−1 transmissions for all the other physicalsensors to send their data to virtual sensor coordinator.Since the virtual sensor coordinator aggregates all thisdata before sending it to the client device, it would takeonly hn transmissions thereafter to relay this data tothe client node, resulting in a total of hn +

∑n−1i=1 hi

transmissions.Given the above, remotely deployed virtual sensors can

reduce communication overhead significantly, especially as thenumber of physical sensors contributing to a virtual sensorincreases or as the number of hops between a client deviceand the virtual sensor coordinator increases.

Figs. 10(a) and (b) show the measured communicationoverhead as a function of the number of nodes in the networkand of the number of nodes participating in the virtual sensor(i.e., the size of virtual sensor), respectively. Using a virtualsensor in a network of increasing size reduces the overheadcompared to a traditional querying approach. As the virtualsensor size increases, the difference in the amount of overheadbetween the approach using a virtual sensor and the traditionalquerying approach increases significantly.

VI. RELATED WORK

As the main goal of this work is to provide in-networkaggregation and sensor tasking in support of pervasive com-puting, we will overview a combination of related work thathave addressed in-network aggregation, virtual sensors, andover-the-air network reprogramming.

A. In-Network Aggregation Techniques

Several recent research efforts have focused on in-networkdata aggregation techniques. Projects targeted directly forsensor networks have often explored representing the sen-sor network as a database. Two demonstrative examples areTinyDB [17] and Cougar [18]. Generally, these approachesenable applications with data requests that flow out from acentral point and create routing trees to funnel replies back to

this root but do not allow this access point to be dynamicallydefined or to vary over time in response to a user’s movement.

VM? [19] provides a virtual machine approach directed athandling device heterogeneity. VM? assumes situations wherethe application and its needs can be known in advance sothat the VM deployed can be optimized with respect to theapplication and device. TinyGALS [20] allows programmersto represent applications in terms of relatively high-levelcomponents which are subsequently synthesized into the low-level, lightweight, efficient programs that are deployed onthe nodes. While such approaches are highly beneficial whenthe application is known and the networks are relativelyapplication-specific, they do not map well when the nodesmust be able to service a variety of unpredictable applications.

B. Virtual Sensor

While the concept of a virtual sensor is not novel, ourmodel and its middleware implementation vary significantlyfrom previous approaches.

Virtual nodes [21] are specified using logical neighbor-hoods [8]. This approach only uses functions like average andthreshold detection to trigger an event, and it is not possibleto define groups to contribute to a virtual sensor based onphysical properties. VirtuS [22] describes a similar concept butonly offers temporal and spatial aggregation of heterogeneoustypes or the transformation of a single type into another.The Global Sensor Network (GSN) [23] supports a similarabstraction in which the user can declaratively specify XML-based deployment descriptors. SQL queries over local andremote sensor data sources can merge sensor network data.However, GSN assumes that the sensor network uses oneor more dedicated computers which perform expensive datamining operations before returning results.

Semantic Streams [24] provides a service concept thatallows the user to issue queries over semantic values andto extract semantic information from raw sensor data. Theuser does not have to specify the data or operations thatshould be used. However, the approach focuses on fixed sensor

9

infrastructures such as those in homes and office buildings,where most of the sensors are powered and wired, or at mostone hop away from a base station.

C. Network Reprogramming (Over-the-Air Programming)

Mate [5] is a virtual machine designed for sensor networksthat divides event-based applications into capsules that areflooded across the network. Mate assumes that only oneapplication runs in the sensor network, so all the sensor nodesexecute the same code. Deluge [25] reprograms the wholesensor network by flashing the instruction memory of eachmote and supports multihop reprogramming. However, it takesa long time to transfer the new image (which is the same forall sensors). Also, sending a large image to every mote in awireless sensor network is limited by the sensor hardware andthe multihop nature of connections. Like Mate, Deluge doesnot allow multiple applications to be installed on nodes.

Agilla [4] is an agent-based sensor network middleware thatallows applications to inject agents that migrate intelligentlyto carry out the applications’ tasks. SensorWare [3] injectsmobile executable scripts. Unlike Mate and Deluge, it allowsmultiple applications to be running on the same node. How-ever, SensorWare requires platforms with 1 MB of programmemory and 128 KB of RAM, and the scripts support onlyweak mobility in the network.

VII. CONCLUSION AND FUTURE WORK

In this paper, we have introduced the remote deployment ofvirtual sensors model through middleware parameterization.We have shown through our evaluation that it is feasible touse a parameterized middleware that can accept tailored virtualsensor definitions to create new aggregation functionality in asensor network on-demand. In combination with a neighbor-hood definition scheme such as [9], the virtual sensor providesa powerful abstraction that not only has the potential to reducethe complexity of programming pervasive computing networksbut can also increase the efficiency with which such networkscan respond to applications’ demands. Furthermore, the virtualsensor abstraction is not application-specific.

Future work will incorporate a remote virtual sensor deploy-ment using mobile code directly instead of parameterizing aresident middleware. We expect that, in difference applicationsituations, different approaches may perform differently, andwe hope to discover when each option is optimal. Another areafor future work is to design the ability for a remotely deployedvirtual sensor to intelligently follow its creator’s device as itmoves through the sensor network. On a construction site,a supervisor may deploy a virtual sensor to monitor themovement of the nearest crane. As the supervisor movesthrough the site, this will require the remotely deployed virtualsensor to remain aware of the user or application’s relativelocation and to adjust its location accordingly.

REFERENCES

[1] S. Kabadayı, A. Pridgen, and C. Julien, “Virtual sensors: Abstractingdata from physical sensors,” in Proc. of the 2006 Int’l. Symp. on Worldof Wireless, Mobile and Multimedia Networks, 2006.

[2] S. Kabadayı, C. Julien, W. O’Brien, and D. Stovall, “Virtual sensors:A demonstration,” in 26th Int’l Conf. on Computer Communications:Demonstrations Track, 2007.

[3] A. Boulis, C.-C. Han, and M. Srivastava, “Design and implementation ofa framework for efficient and programmable sensor networks,” in Proc.of the 2nd Int’l. Conf. on Mobile Sys., Apps., and Services, 2003, pp.187–200.

[4] C.-L. Fok, G.-C. Roman, and C. Lu, “Rapid development and flexibledeployment of adaptive wireless sensor network applications,” in Proc.of Int’l. Conf. on Dist. Comput. Sys., 2005, pp. 653–662.

[5] P. Levis and D. Culler, “Mate: A tiny virtual machine for sensornetworks,” in Proc. of ASPLOS X, 2002.

[6] J. Hammer, I. Hassan, C. Julien, S. Kabadayı, W. O’Brien, and J. Tru-jillo, “Dynamic decision support in direct-access sensor networks: Ademonstration,” in Proc. of the 3rd Int’l. Conf. on Mobile Ad-hoc andSensor Sys., 2006.

[7] L. Neitzel, S. Seixas, and K. Ren, “A review of crane safety inthe construction industry,” Applied Occupational and EnvironmentalHygiene, vol. 16, no. 12, pp. 1106–1117, 2001.

[8] L. Mottola and G. Picco, “Programming wireless sensor networks withlogical neighborhoods,” in Proc. of InterSense, 2006.

[9] V. Rajamani, S. Kabadayı, and C. Julien, “Query domains: Groupingheterogeneous sensors based on proximity,” in Technical Report TR-UTEDGE-2007-008, 2007.

[10] M. Welsh and G. Mainland, “Programming sensor networks usingabstract regions,” in Proc. of the 1st USENIX/ACM Symp. on NetworkedSys. Design and Implementation, 2004.

[11] K. Whitehouse, C. Sharp, E. Brewer, and D. Culler, “Hood: A neigh-borhood abstraction for sensor networks,” in Proc. of MobiSys, 2004,pp. 99–110.

[12] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister,“System architecture directions for networked sensors,” in Proc. of the9th Int’l. Conf. on Architectural Support for Prog. Languages andOperating Systems, 2000, pp. 93–104.

[13] D. Gay, P. Levis, R. vonBehren, M. Welsh, E. Brewer, and D. Culler,“The nesC language: A holistic approach to networked embeddedsystems,” in Proc. of the ACM SIGPLAN Conf. on Prog. LanguageDesign and Implementation, 2003, pp. 1–11.

[14] “Crossbow Technologies, Inc.” http://www.xbow.com, 2005.[15] “Remotely Deployed Virtual Sensors Implementation Code,” http://mpc.

ece.utexas.edu/remotevirtualsensors/index.html, 2007.[16] “RPN Calculator,” http://home.att.net/∼srschmitt/script reverse polish.

html, 2007.[17] S. Madden, M. Franklin, J. Hellerstein, and W. Hong, “TinyDB: An

acquisitional query processing system for sensor networks,” ACM Trans.on Database Systems, vol. 30, no. 1, pp. 122–173, 2005.

[18] Y. Yao and J. Gehrke, “The cougar approach to in-network queryprocessing in sensor networks,” ACM SIGMOD Record, vol. 31, no. 3,pp. 9–18, 2002.

[19] J. Kosh and R. Pandey, “VM?: Synthesizing scalable runtime environ-ments for sensor networks,” in Proc. of SenSys, 2005.

[20] E. Cheong, J. Liebman, J. Liu, and F. Zhao, “TinyGALS: A program-ming model for event-driven embedded systems,” in Proc. of the 2003ACM Symp. on Applied Computing, 2003, pp. 698–704.

[21] P. Ciciriello, L. Mottola, and G. P. Picco, “Building virtual sensors andactuators over logical neighborhoods,” in Proc. of the 1st ACM Int’l.Wkshp. on Middleware for Sensor Networks, 2006.

[22] P. Corsini, P. Masci, and A. Vecchio, “VirtuS: A configurable layer forpost-deployment adaptation of sensor networks,” in Proc. of the Int’lConf. on Wireless and Mobile Comm., 2006, pp. 8–13.

[23] K. Aberer, M. Hauswirth, and A. Salehi, “Middleware support forthe “internet of things”,” in GI/ITG KuVS Fachgesprach “DrahtloseSensornetze” (Expert Talk on Wireless Sensor Networks), UniversitatStuttgart, 2004.

[24] K. Whitehouse, F. Zhao, and J. Liu, “Semantic streams: A framework forcomposable semantic interpretation of sensor data,” in Proc. of EWSN,2006, pp. 5–20.

[25] J. W. Hui and D. Culler, “The dynamic behavior of a data disseminationprotocol for network programming at scale,” in Proc. of the 2nd Int’l.Conf. on Embedded Networked Sensor Systems, 2004, pp. 81–94.