TinyLIME: Bridging Mobile and Sensor Networks through Middleware

TinyL IME: Bridging Mobile and Sensor Networks through Middleware

Carlo Curino, Matteo Giani, Marco Giorgetta, Alessandro GiustiDip. di Elettronica e Informazione

Politecnico di Milano, Italy

Amy L. MurphyDept. of Informatics

University of Lugano, [email protected]

Gian Pietro PiccoDip. di Elettronica e Informazione

Politecnico di Milano, [email protected]

Abstract

In the rapidly developing field of sensor networks, bridg-ing the gap between the applications and the hardwarepresents a major challenge. Although middleware is one so-lution, it must be specialized to the qualities of sensor net-works, especially energy consumption. The work presentedhere provides two contributions: a new operational settingfor sensor networks and a middleware for easing softwaredevelopment in this setting. The operational setting we tar-get removes the usual assumption of a central collectionpoint for sensor data. Instead the sensors are sparsely dis-tributed in an environment, not necessarily able to commu-nicate among themselves, and a set of clients move throughspace accessing the data of sensors nearby, yielding a sys-tem which naturally provides context relevant informationto client applications. We further assume the clients arewirelessly networked and share locally accessed data. Thisscenario is relevant, for example, when relief workers ac-cess the information in their zone and share this informa-tion with other workers. Our second contribution, the mid-dleware itself, is an extension ofL IME, our earlier work onmiddleware for mobile ad hoc networks. The model makessensor data available through a tuple space interface, pro-viding the illusion of shared memory between applicationsand sensors. This paper presents both the model and theimplementation of our middleware incorporated with theCrossbow Mote sensor platform.

1. Introduction

Wireless sensor networks have emerged as a novel andrapidly evolving field, with staggering enhancements in per-formance, miniaturization, and capabilities. However, weobserve that the features provided by the computing and

communication hardware still await to be matched by anappropriate software layer enabling programmers to easilyand efficiently seize the new opportunities.

At the same time, we observe that much of the work inthe area assumes statically deployed sensors organized in anetwork from which data is collected and analyzed at a cen-tral location. For many applications, e.g., habitat monitor-ing [16], this is a natural setting. However, in many othersthis seems to be overly constraining. First of all, it may beimpractical or even impossible to choose where to place thecollection point, for example in disaster recovery or militarysettings. Moreover, in the centralized scenario sensors con-tribute to the computation independently of their location.In other words, there is no notion ofproximity supporting,say, reading only the average temperature sensed around atechnician while he walks through a plant. Finally, the tra-ditional centralized scenario poses technical challenges re-lated to the problem of routing the sensed information fromsensors at the fringe of the system back to the collector host,by mediating the conflicting issues of multi-hop routing andpower saving.

In this paper, we provide a contribution to both issues, byproposing a new operational setting for sensor network ap-plications, as well as a middleware supporting their devel-opment. Our reference operational setting replaces central-ized data collection with a set of mobile monitors intercon-nected through ad hoc, wireless links, and able to receivesensed data only from the sensors they are directly con-nected to. This way, sensors effectively provide each mo-bile monitor withcontext-sensitivedata.

To support this novel operational setting, we extend andadapt a model and middleware called LIME [13, 15], orig-inally designed for mobile ad hoc networks (MANETs).Changes to the model are required to match the operationalsetting described so far. Extension of the middleware isneeded to cope with the requirements related with power

consumption and with the sheer need of installing the mid-dleware components on devices with very limited computa-tional resources. The result of this effort, called TinyLIME,has been implemented entirely of top of the original LIME

and deployed using Crossbow motes [2] as the target plat-form.

The paper is organized as follows. Section 2 containsbackground information about LIME and the mote sensors.Section 3 illustrates the operational setting we propose andtarget. Section 4 presents the TinyLIME model, while Sec-tion 5 describes the architecture of the corresponding mid-dleware developed for motes. Additional implementationdetails and evaluation are provided in Section 6. Section 7places our work in the context of related efforts. Finally,Section 8 ends the paper with brief concluding remarks.

2. Background

In this section we provide the reader with the necessarybackground about LIME, which TinyLIME builds upon, andon the Crossbow Mote sensor platform, which serves as thetarget deployment technology for our implementation.

2.1. L IME

TinyL IME is a data-sharing middleware based on LIME,which in turn adapts and extends towards mobility the tuplespace model made popular by Linda.

Linda and Tuple Spaces.Linda [6] is a shared memorymodel where the data is represented by elementary datastructures calledtuplesand the memory is a multiset of tu-ples called atuple space. Each tuple is a sequence of typedfields, such as〈“foo”, 9, 27.5〉 and coordination among pro-cesses occurs through the writing and reading of tuples.Conceptually all processes have a handle to the tuple spaceand can add tuples by performing anout(t) operation andremove tuples by executingin(p) which specifies a pattern,p for the desired data. The pattern itself is a tuple whosefields contain eitheractualsor formals. Actuals are values;the fields of the previous tuple are all actuals, while the lasttwo fields of 〈“foo”, ?integer, ?float〉 are formals. Formalsact like “wild cards”, and are matched against actuals whenselecting a tuple from the tuple space. For instance, the tem-plate above matches the tuple defined earlier. If multiple tu-ples match a template, the one returned byin is selectednon-deterministically. Tuples can also be read from the tu-ple space using the non-destructiverd(p) operation.

Both in andrd are blocking, i.e., if no matching tuple isavailable in the tuple space the process performing the op-eration is suspended until a matching tuple appears. A typi-cal extension to this synchronous model is the provision of apair of asynchronous primitivesinp andrdp, which returnnull if no matching tuple exists in the tuple space. Some

variants of Linda (e.g., [17]) also provide thebulk opera-tionsing andrdg, which can be used to retrieve all match-ing tuples at once.

Processes interact by inserting tuples into the tuple spacewith theout operation and issuingrd andin operations toread and remove data from the space. A typical exampleis a producer/consumer, where the produceroutstuples de-scribing jobs, and the consumerins job tuples based on pat-terns related to their capabilities. If needed, the results ofthe job execution can beouttedby the consumers and col-lected by any process with thein operation.

L IME: Linda in a Mobile Environment.Communication inLinda is decoupled intime andspace, i.e., senders and re-ceivers do not need to be available at the same time, andmutual knowledge of their identity or location is not neces-sary for data exchange. This decoupling makes the modelideal for the mobile ad hoc environment where the partiesinvolved in communication change dynamically due to theirmovement through space. At the same time, however, theglobal nature of the tuple space cannot be maintained insuch an environment, i.e., there is no single location to placethe tuple space so that all mobile components can access itat all times.

To support mobility, the LIME [13, 15] model breaks upthe Linda tuple space into multiple tuple spaces each per-manently attached to a mobile component, and defines rulesfor the sharing of their content when components are ableto communicate. In a sense, the static global tuple spaceof Linda is reshaped by LIME into one that is dynamicallychanging according to connectivity. For example, considera group of professors carrying PDAs, and imagine each ofthem inserting a business card tuple into their local tuplespace, referred to in LIME as theInterface Tuple Space(ITS). When all professors are in the same room (or, ac-cording to LIME rules, within transitive communication),L IME ’s transient sharing of tuple spaces provides a viewwhere it is as if all business card tuples were in the same tu-ple space, and accessible to all professors. However, whenone professor leaves the room her business card is no longeraccessible to the others, but it remains accessible to her.As shown in Figure 1, the LIME model encompasses mo-bile software agents and physical mobile hosts. Agents arepermanently assigned an ITS, which is brought along dur-ing migration, and reside on the mobile hosts. Co-locatedagents are considered connected. The union of all the tuplespaces, based on connectivity, yields a dynamically chang-ing federated tuple space. Hereafter, for the purpose of thiswork we always consider the agents as stationary.

Access to the federated tuple space remains very simi-lar to Linda, with each agent issuing Linda operations onits own ITS. The semantics of the operations, however, is asif they were executed over a single tuple space containingthe tuples of all connected components. In the previous ex-

Interface Tuple SpaceHost-Level Tuple Space

Federated Tuple Space

migrate

Mobile AgentsMobile Host

Figure 1. In L IME connected mobile hosts tran-siently share the tuple spaces of the agents exe-cuting on them.

ample, a professor could issue ard operation and retrieve,non-deterministically, the business card of one of the pro-fessors in the room.

Besides transient sharing, LIME adds two new notionsto Linda: tuple locations and reactions. Although tuples areaccessible to all connected agents, they only exist at a sin-gle point in the system, i.e., with one of the agents. Whena tuple is output by an agent it remains in the correspond-ing ITS, and the tuple location reflects this. LIME also al-lows for tuples to be shipped to another agent by extendingtheout operation to include a destination. The notion of lo-cation is also used to restrict the scope of therd andin op-erations, effectively issuing the operation only over the por-tion of the federated tuple space owned by a given agent orresiding on a given host. For example, a professor can readthe business card of another by specifying the host identi-fier of her colleague as part of therd query.

Reactions allow an agent to register a code fragment—a listener—to be executed whenever a tuple matching aparticular pattern is found anywhere in the federated tuplespace. This is particularly useful in the highly dynamic mo-bile environment where the set of connected componentschanges frequently. Continuing the example above, now aprofessor (say, Dr. Doe) registers a reaction for businesscard tuples and associates a listener for displaying the cardcontents. When the reaction is registered, it fires immedi-ately for each professor, since the business cards are alreadyin the tuple space, and trigger the display of each card con-tent on Dr. Doe’s screen. Similarly, if a new professor walksin the room with a card in her tuple space, the reactionwould immediately cause its display on Dr. Doe’s screen.Like queries, reactions can also be restricted in scope to aparticular host or agent. Nevertheless, the ability to moni-tor changes across the whole system by installing reactionson the federated tuple space has been shown to be one ofthe most useful features of LIME.

Additional information, including API documentationand source code, is available at [1].

2.2. Crossbow Mote Sensor Platform

From this point forward our discussion focuses on theCrossbow Mote sensor platform [2], which we chose as theimplementation target. It is worth noting, however, that theTinyL IME model is equally applicable to any platform. Inthe Crossbow platform, a sensor board can be plugged ontoeach mote to support several environment readings includ-ing light, acceleration, humidity, magnetic field, sound, etc.The MICA2 motes in our testbed run on two AA batteries,whose lifetime is dependent on the use of the communica-tion and computation resources. The communication rangevaries greatly based on the environmental conditions, withan average indoor range observed during our experimentsof 6-7 m. The motes run an open source operating systemcalled TinyOS [7] and have 5Mbit of flash memory, with1Mbit reserved for program memory and 4Mbit availablefor user data. A laptop is converted to a base station able tocommunicate with the motes by connecting a special basestation circuit board to the serial port of the laptop.

3. Operational Setting

Most middleware designed specifically for sensor net-works operate in a setting where the sensors are fixed in theenvironment and report their values to a centralized point.As we discuss in Section 7, much work has gone into mak-ing these operations power efficient. However, this central-ized model may not be the ideal model for all applications.Consider an application that requires information from sen-sors in close proximity to the user. In this case, both the lo-cation of the user and the location of the sensors must beknown, the data must be requested by the sensors deter-mined as proximate, then the data must be shipped to thecentral collection point. This has a number of drawbacks.First, it may not be reasonable to expect to know the lo-cation of all sensors. Second, the collection of informationputs a communication burden on the sensors between theproximate sensors and the collection point to forward thedata. Third, it requires that all sensors be transitively con-nected to the base station—something that may not be feasi-ble in all environments due to physical barriers or economicrestrictions limiting the number of sensors in a given area.

Considering these issues, we propose an alterna-tive, novel operational scenario; one that naturally providescontextual information, does not require multi-hop com-munication among sensors, and places reasonable com-putation and communication demands on the motes. Thescenario, depicted in Figure 2, assumes that motes are dis-tributed sparsely throughout a region, and need not be ableto communicate with one another. The monitoring applica-tion is deployed on a set of mobile hosts, interconnectedthrough ad hoc wireless links—e.g., 802.11 in our ex-

Figure 2. Operational scenario showing one hopcommunication between base stations (laptops)and motes and multi-hop communication amongbase stations and clients (PDAs). Client agentscan also be co-located with the base stations (e.g.,running on the laptops).

periments. Some hosts are only clients, without directaccess to sensors, such as the PDA in the figure. The oth-ers are equipped with a sensor base station, which howeverenables access only to sensors within one hop, there-fore naturally providing a contextual view of the sensorsub-system.

This scenario is not just an academic exercise, rather it isrelevant in several real-world situations. Imagine, for exam-ple, a disaster recovery scenario with mobile managers andworkers, where sensors have been deployed randomly (e.g.,thrown from the air). The computer of each worker is alsoa base station that enables them to perform their tasks byaccessing the proximate sensor information. Instead, man-agers are connected only as clients, and gather global- orworker-specific data to direct the recovery operations, with-out the need either to have a single data collection pointor to know exactly where sensors are placed. In a sense,the scenario we propose merges the flexibility of MANETswith the new capabilities of sensor networks, by keepingthe complexity of routing and disseminating the sensed in-formation on the former, and exploiting the latter as muchas possible only for sensing environmental properties.

4. The TinyL IME Model

TinyL IME was conceived to support the development ofapplications in the operational setting just described. It ex-tends LIME by providing features and middleware compo-nents specialized for sensor networks. In this section we in-

troduce the underlying model, while in the next we describethe middleware architecture.

As in LIME, the core abstraction of TinyLIME is that ofa transiently shared tuple space, which in our case stores tu-ples containing the sensed data. However, TinyLIME alsointroduces a new component in addition to agents andhosts—the motes. In the physical world defined by our set-ting, motes are scattered around. They communicate withbase stationsonly when the latter move within range. Deal-ing with this scenario by considering a mote just like an-other host would lead to a complicated model with aninefficient implementation. Instead, in TinyLIME a sim-pler abstraction is provided. A mote is not visible throughTinyL IME unless it is connected to some base station. Whenthis is the case, the mote is represented in the model muchlike any otheragentresiding on the base station host (andtherefore “connected” to it), with its ITS containing the setof data provided by its sensors. Looking at Figure 1, it is asif on each host there were an additional agent for each motecurrently in range of that host. Clearly, things are quite dif-ferent in practice: the mote is not physically on the base sta-tion, and there is no ITS physically deployed on the mote.As usual, it is the middleware that takes care of creating thisabstraction to simplify the programmer’s task. The supportfor the abstraction is described in the next section.

Once this leap is made, the rest comes naturally. For in-stance, operations on the federated space now span not onlyconnected hosts and agents, but also the motes within rangeof some host—similarly for operations restricted to a givenhost. Also, the mote identifier can be used much like anagent identifier to restrict the scope of a query or reactionto a specific mote. To make a concrete example, considerthe scenario of Figure 2. When an agent on the laptop basestation on the right issues ard for light data, restricted inscope to its own host, a light reading from one of the twoconnected motes will be returned. If, instead, an agent run-ning on the PDA client issues the samerd query but withunrestricted scope, a light reading from any of the five sen-sors connected to the two base stations will be returned non-deterministically. It should be noted, however, that althoughTinyL IME agents use the basic LIME operations to accesssensor data, this data is read-only, i.e., only reactions,rd,rdp, andrdg are available. Indeed, sensors measure andreport properties of the environment that cannot be changedor removed by the clients, but only inspected.

Reactions work as in LIME, modulo the changes above,and are extremely useful in this environment. Imagine asituation where a single base station agent registers a re-action to display temperature values. As the base stationmoves across the region, the temperature from each motethat comes into range will be displayed—with no extra ef-fort for the programmer. TinyLIME reactions also provideadditional expressive power. First, it can be specified how

frequentlythe data received through a reaction should berefreshed. The notion of data freshness is a property of asensor in the context of an application, and it reflects thefact that sensors measure environmental properties, and ev-ery reading has a time threshold beyond which it is con-sidered no longer useful—orfresh. In our example, this isvery useful when the base station remains in a single loca-tion for an extended period of time. Second, TinyLIME reac-tions also accept acondition, e.g., to specify reaction onlyto temperatures between 20 and 30 degrees. This is moti-vated by the need to limit communication by the motes, en-abling data sending only if it is useful for the application.Both these features, together with details such as the for-mat of sensor data tuples, are described in the next section.

5. The TinyL IME Middleware Architecture

As previously stated, the TinyLIME model has been de-signed and implemented for the Crossbow Mote platform,exploiting the functionalities of TinyOS. On standard hosts,TinyL IME is implemented as a layer on top of LIME withoutrequiring any modification to it1, therefore reasserting theversatility of the LIME model and middleware. In this sec-tion we describe the architecture of TinyLIME, whose maincomponents are shown in Figure 3. Our discussion startsfrom the perspective of the client, and moves progressivelytowards the components deployed on the sensors.

5.1. Client Components

A client interacts with the sensors through theMoteLimeTupleSpace class, which extendsLimeTupleSpace in the LIME API. However, asmentioned in Section 4, only the read and reaction op-erations are available: the others throw an exception.Figure 4 shows the code of a TinyLIME client agent,where the first line of therun method contains the cre-ation of the MoteLimeTupleSpace , and the secondmakes it shared, as per the LIME API.

To query the motes, a client must know the format ofthe tuples containing sensor data. In LIME, and in gen-eral in tuple space models, this decision is normally left tothe application. However, in TinyLIME this format is prede-fined to access the sensors available on the motes, althoughit can be easily adapted to suit different sensor platforms.A tuple (or template) containing a sensor reading con-sists of four fields:〈SensorType, Integer, Integer, Date〉.The first field indicates the type of sensor to be queried.In our mote-specific implementation, valid values areACCELX, ACCELY, HUMIDITY, LIGHT, MAGNOMETER,

1 For full disclosure, only a few methods changed their access level fromprivate to protected.

MICROPHONE, RADIOSTRENGTH, TEMPERATURE,and VOLTAGE. The second field contains the actual sen-sor reading2. The third field is theepochnumber of themote that provided the reading, and indicates approxi-mately how long that mote has been alive, as discussedlater in this section. The last field is a timestamp set whenthe data is collected at the base station, thus allowing corre-lation of values gathered at the same host without requiringsynchronized clocks on the motes.

Based on this format, a client can create aMoteLimeTemplate for use in any of the allowedoperations. The available constructors optionally allow set-ting a freshness value and an operation scope. The lat-ter can span the federated tuple space, the agents ormotes on a host, a single agent, or a single mote. TheMoteLimeTemplate created in Figure 4 for a light read-ing specifies neither. Therefore, therd using it will re-turn as soon as a light reading with the default freshnessis found in the federated tuple space. Reactions are spec-ified as in LIME, with a template and a listener. Thetemplate, however, may contain an additional field re-quiring a matching other than the typical value equalityprovided by LIME and Linda-based models. In the cur-rent implementation, inequality (e.g., voltage differentfrom 2.1V) and matching over a value range (e.g., tempera-ture between 20 and 30 degrees) are available3.

MoteLimeTupleSpace also provides operationsdedicated to controlling sensors. For example, the PDA inFigure 2 can invokesetBuzzer() to cause all motesconnected to the two base stations to buzz for a short pe-riod of time. Also, setDutyCycle changes the awakeperiod of the motes,setRadioPower changes the sig-nal strength, andsetSensingTimeout changes themaximum time waited for a mote to answer before declar-ing it unreachable. Like other operations, these methodscan also be restricted in scope.

5.2. Interaction Between Client and Base Station

MoteLimeTupleSpace , MoteLimeTuple , andMoteLimeTemplate are the only classes needed bya client application. Hereafter, we look at the inter-nals of TinyLIME, describing how it uses LIME and inter-faces with motes.

The first component we examine in detail is theMoteLimeTupleSpace itself. Although it presents tothe client the illusion of a single tuple space containing sen-

2 In TinyOS all sensor readings are represented as integers. Conversionfunctions exist to convert them to more meaningful measurements.

3 This is only a temporary solution to enable experimentation. A newversion of the tuple space engine underlying LIME [14] will providethese features as part of the template specification, therefore allowingfor a more elegant and uniform solution.

ClientAgent

LimeTupleSpace"motes"

MoteAgent

LimeTupleSpace"config"

mote request and

config

Limifiedmote data

current data

historical data

Lime <--> motetranslation

guaranteestuple

freshness

removeold tuples

Configuring

MoteLimeTemplate

MoteLimeTupleSpace

LimeTupleSpace"motes"

LimeTupleSpace"config"

TOSMoteAccess

asynchronousrequest/response

LimeTupleSpace

Sharing

MoteLimeTuple

Client Host

Base Station Host

Reachable Motes

Figure 3. Main architectural components on the base station and client hosts. Although shown separate here,the two can be co-located.

public class SimpleClientAgent extends StationaryAgent {public void run() {

LimeTupleSpace lts = new MotesLimeTupleSpace();lts.setShared(true);ITuple tup = new Tuple()

.addActual(new SensorType(SensorType.LIGHT))

.addFormal(Integer.class)

.addFormal(Integer.class)

.addFormal(Date.class);MoteLimeTemplate tmpl = new MoteLimeTemplate(tup);MoteLimeTuple t = (MoteLimeTuple)lts.rd(tmpl);System.out.println("Tuple returned: " + t.toString());

}}

Figure 4. A sample Tiny L IME client that reads a light sensor value and prints it to the screen. This is the realcode: only exception blocks are not shown for readability.

sor data, internally it exploits two LIME tuple spaces,one holding data from the sensors and one for commu-nicating requests from the client. By using two names,respectivelymotesand config, the content of the two tu-ple spaces is shared separately by LIME. These same twotuple spaces are also instantiated at all base stations, there-fore sharing occurs across all clients and base stations,based on connectivity.

The motestuple space provides access to sensor data.One would expect that, if the mote is connected, its sen-sor data should be in the tuple space. Instead, sensordata is retrieved only on demand, saving motes the com-munication of values that no application needs. There-fore, when a client issues a request, the internal processingof MoteLimeTupleSpace first queries themotes tu-ple space for a match. If no match is found, the operationproceeds by informing the base stations to query for the re-quired data. This is accomplished by placing aquery tupleinto the config tuple space, and simultaneously register-ing a reaction on themotes tuple space. (These tuplesand reactions are clearly system-defined.) The query tu-ple causes the firing of a reaction on the base station, whichin turn retrieves the data from the sensor and posts it inthemotestuple space, where it causes the firing of the pre-viously registered reaction, and delivers the data to theclient. The data remains in themotestuple space, possi-bly fulfilling subsequent queries, until it is no longerfresh.The freshness requirement is maintained by simply delet-ing the stale tuples upon expiration of a timer. Theconfigtuple space is also used for implementing the mote con-figuration requests described in the previous section (e.g.,setRadioPower ) using a similar scheme based on re-quest tuples and reactions.

In TinyL IME, all base stations run an instance ofMoteAgent , which installs the system reactions neces-sary to the processing we described, manages the operationrequests, and maintains the freshness of the sensor data. Be-cause some applications may find it useful to access notonly the current value of a sensor but also its recent val-ues, theMoteAgent also maintains historical informationin the motestuple space, albeit with a different tuple pat-tern.

5.3. Base Station to Mote Interaction

To this point we have described how data is retrievedby the client once it is available, however we have notdiscussed in detail how it is retrieved from the motes. InTinyL IME, this is handled by a combination of three com-ponents: theMoteAgent that receives client requests, theTOSMoteAccess component that asynchronously inter-acts withMoteAgent to handle request, replies, and allcommunication with the motes, and finally the compo-

nents residing on the motes themselves.MoteAgent andTOSMoteAccess are highly decoupled, thus enabling thereuse of the latter in applications other than TinyLIME toprovide a straightforward interface to access motes from abase station.

The main job of theTOSMoteAccess component is totranslate high-level requests issued by TinyLIME into pack-ets understandable by the motes. Four kinds of requests areaccepted: read, reaction, stop operation, and set parameter.Requests which last an extended period of time, i.e. readsand reactions, accept a listener parameter. The listener iscalled when the operation is complete, e.g. data is receivedor the timeout expires. Once a request is received by theTOSMoteAccess component, it is translated into commu-nication with the motes.

Communication.In principle, communication between thebase station to and from motes is just message passing.However this is not as straightforward in sensor networksas in traditional ones. To see why, one must understand afundamental property of motes, namely that to conserve en-ergy they sleep most of the time, waking up on a regular ba-sis to receive and process information. Because motes can-not receive packets while sleeping, the base station must re-peatedly send a single packet as shown in Figure 5. The fre-quency at which to repeat the packet and the length of timeto repeat it are determined by two parameters: the nomi-nal awake time and the epoch period. Thenominal awaketimeis the amount of time that a mote promises to be awakeduring each epoch period. Theepoch periodis the basic cy-cle time of a mote. Multiplying the current epoch numberby the epoch length estimates the time a mote has been ac-tive. To avoid duplicate delivery of packets, each contains asequence number that the motes use to filter incoming mes-sages. This design intentionally puts the burden of commu-nication on the base station rather than on the motes, forc-ing the former to repeat a message many times to ensure itsdelivery. This is not an issue if, as we assume, the base sta-tion has a larger energy reserve and is more easily recharge-able than the motes.

Operation Processing.With this understanding of commu-nication with motes, we return to theTOSMoteAccesscomponent. Sending a read or parameter set request to amote is accomplished by this component simply sending themessage and waiting for the reply. The processing inside themotes will be discussed shortly, however it should be notedthat because the base station does not enter a sleep mode,messages sent by the motes are only transmitted once. Ifno mote replies within an epoch period, the request is re-transmitted. Even if no mote within range can provide thedata, the base station may move into range of a new moteat any time. Therefore ard request should be retransmittedas long as the client is still waiting for a tuple. The probeand group operations,rdp andrdg, must be handled dif-

time

Mot

e1Ba

seSt

atio

nM

ote2

awake sleeping awake sleeping

awake sleeping awake sleeping

awake

mote cycle time

1

Figure 5. Communication with motes that sleep for a majority of the time. To ensure all motes in one-hop rangereceive the packet, each packet is broadcast by the base station at a frequency determined by the awake timefor the duration of an epoch.

ferently because the agent should receive anull reply if nomote can service the request. Therefore, after a timeout pe-riod theTOSMoteAccess component stops repeating therequest and returnsnull if no motes responded or, in thecase ofrdg, the set of sensor values collected before thetimeout.

Next we consider reaction requests. One option is to senda reaction installation message to the motes, indicating thatsensor values should be sent every epoch until they are nolonger needed. This would require the motes to maintaininformation about all requests, including the conditions thatmust be met (e.g., required value ranges). At least two prob-lems arise with this solution. Consider the case where aclient/base station pair moves through a region with a re-action installed for temperature sensors. Here the base sta-tion must repeatedly send the request to install the reactionon all motes and, moreover, the motes that are no longerin contact need to detect disconnection and stop transmit-ting temperature values. This can be difficult and energyconsuming to the motes. These problems led us to a basestation driven solution, where theTOSMoteAccess com-ponent continuously sends reaction requests to the motes.Reaction requests differ from normal read requests becausethey contain the condition to be met by data, allowing themotes to avoid transmitting sensor values that are uselessfor the application. Motes are expected to reply once perepoch, even if their sensor value has not changed, there-fore the packet filter mechanism on the motes is designedto accept packets with the same reaction request identifieronce per epoch. In this solution, the motes remain stateless;when the base station moves out of range no processing isneeded on the motes to cancel the operation. When a clientmoves out of range of the base station, the client’s reac-tions must be disabled, but such disconnection is easily de-

tected using LIME mechanisms inside theMoteAgent andtheTOSMoteAccess is informed to stop requesting sen-sor values on behalf of the disconnected client. By choosingthis solution, we require that the base stations both maintainmore state and send more messages to repeatedly request in-formation. However, this is reasonable given that the basestation is likely to have both a larger on-board energy sup-ply and more memory than the motes.

5.4. On-Mote Components

The only remaining component is that deployed on themotes themselves. Given the choices made up to this point,the motes component is designed as a reactive system, re-sponding to incoming messages and of course managingits epoch and awake periods. Figure 6 shows the ar-chitecture of software deployed on motes as a set ofinterconnected TinyOS components. TheTimers mod-ule controls the epoch and awake periods. TheFilteredCommunication module receives all incoming pack-ets, eliminating duplicates based on packet identifiers.The Sensors Subsystem invokes the appropri-ate TinyOS components to take sensor readings, includingpowering sensors on and off before and after use. If ad-ditional sensors are added to the system, this componentmust be modified. TheTuning module handles the set-ting of mote parameters such as transmission power.Finally, the Core module links all these components to-gether, triggering events and calling parameters.

To understand the functionality of the sensor compo-nent, consider the processing of an incoming reaction re-quest. Assuming the incoming packet is not a duplicate,theFiltered Communication module passes it to theCore , where the sensor type and condition are extracted

Core

Photo Temp Volt GPS

Sensors Subsystem

Genericcomm

Main

∑Stats

Tuning Timers

FilteredComm

Figure 6. Architecture of components installedon motes. Shaded components have been devel-oped for Tiny L IME, while the others are providedby TinyOS.

from the packet. TheCore then communicates with theSensor Subsystem requesting a reading for the spec-ified sensor, e.g., light. When the reading has been taken, anevent is raised on theCore , the value is checked against theconditions contained in the packet and, if the value meetsthe condition, a packet containing the sensed value is as-sembled and passed to theGeneric Communicationmodule to be sent back to the base station.

5.5. An Example

To summarize how the components fit together, we walkthrough a simple example where a client reads a sensorlight value, as shown in Figure 7. The client first createsthe desired template, and invokes therdp function on aninstance ofMoteLimeTupleSpace . Inside it, therdpis converted to a query which is posted to themotestuplespace to see if a fresh light value already exists. If a valueis returned, it is passed back to the client immediately. Oth-erwise, a configuration tuple is output toconfig, indicatingthat a sensed light value is needed, and at the same time a re-action is installed onmotesfor the required sensor data. TheMoteAgent , which is registered to react to every configu-ration tuple, receives the agent’s request, passes it along tothe TOSMoteAccess component, which in turn sends aread request to the motes. When the value is returned, it isplaced into themotestuple space, triggering the earlier in-stalled reaction to fire, which finally delivers the tuple withthe sensed value back to the client.

Component Language LOC

MoteLimeTupleSpace Java 446MoteAgent Java 361TOSMoteAccess Java 470On-Mote Components nesC 550

Table 1. Uncommented lines of source code forall major Tiny L IME components.

6. Implementation Details

TinyL IME is available for download athttp://lime.sf.net/tinyLime.html . Table 1 shows the break-down of source code lines across components.

Evaluation. To get a feel for response times, we ran someindicative test cases with an epoch time of8s and an awaketime of 2s. These values, especially the epoch time, heav-ily influence the numbers below, and should be tuned ac-cording to the application needs.

Our test cases involved only the blockingrd operation.Results would have been the same for therdp since in ourtest a mote is always in range to provide the requested value.Therdg instead would produce different but rather uninter-esting results, because its performance is not dependent onthe motes but on the parameter of theTOSMoteAccesscomponent that determines how long to wait to collect allreplies. All tests were run with the TinyLIME client co-located with the base station in order to eliminate the net-work delays on the non-mote network.

Our first test involved a single mote and two requests.For the firstrd request, response times varied from0.35sto 5.8s, with an average over 11 runs of3.2s. In a twelfthrun, the response time was observed at12.1s, clearly an un-expected value since it is longer than the epoch time. Thiscan be explained by the lossy nature of mote communica-tion. Likely, the request packet was corrupted and the motedid not receive the request until the second epoch. Immedi-ately following the firstrd request, a second request was is-sued. In this case, the previously sensed value was still con-sidered fresh, so no communication with the motes was re-quired. This time, response times varied from0.0049s to0.20s, depending on CPU load. With low CPU usage, theaverage was approximately0.008s.

Our second set of tests involved three motes. In this case,the firstrd request response times varied from0.29s to 2.3swith an average of1.2s. This reduction in time over the sin-gle mote scenario is expected since the awake time of themotes is likely to be scattered, increasing the chance that atleast one of the motes is awake shortly after the query is is-sued. We also repeated the test with a second, immediaterdshowing the same results as before. Again, this is expected

ClientAgent MoteLimeTupleSpace LimeTupleSpace"motes"

MoteAgent

rdp[cur,dest,MoteID](SensorType,Int,Int,Timestamp) rdp[cur,dest,MoteID]

(SensorType,Int,Int,Timestamp)

null

LimeTupleSpace"config"

Reaction firing

MoteAccess

doRead(mote,sensor)

MoteInteraction

addData(values)out(mote data)

addWeakReaction(...)

Reaction firing: mote data

out(config)

mote data

base station lime node

client lime node

Figure 7. Sequence diagram showing the processing of a rdp.

since no mote communication is involved as the fresh valueis simply observed in the tuple space.

Tests with reactions confirm the previous results, assum-ing the readings match the specified conditions. Again, thisis expected since reaction are implemented like queries—they are simply repeated for more than one epoch.

Wakeup scattering.As observed during the tests, the re-sponse time for a request is quite variable and dependent onwhen it is issued with respect to when the motes wake upand receive the request packet. With multiple motes the av-erage response time was shorter, albeit still quite variable.This is because the awake times of the motes are not coor-dinated in any fashion; motes wake up at random times inthe epoch period and these times are not evenly distributed.The left side of Figure 8 shows the consequence of this phe-nomenon. If the first transmission of the request is atA, thenthe response will be immediate. However, if the first trans-mission is atB, no mote is awake to reply, and the requestwill not be answered until the second transmission duringthe next mote epoch. Interestingly, even if the first transmis-sion is atA and TinyOS provides provisions such as carrier

sense and collision avoidance for multiple motes transmit-ting at the same time, multiple motes can still saturate thechannel and affect performance. Again the left half of Fig-ure 8 shows this possibility with four motes, whose wakeuptimes are not exactly aligned, but nonetheless may respondall at the same time when a request is made.

To avoid these situations, we propose a wakeup scatter-ing algorithm that more uniformly distributes the points atwhich the motes wake up during the epoch, resulting in awakeup distribution similar to the right side of the figure.Although a centralized solution may be able to optimize alarge, multi-hop network, our solution is distributed, and en-ables local decisions with relatively little overhead. In short,our solution proceeds in rounds. At the beginning of the firstround, the process is initiated by a special packet sent byone of the motes or an external agent. Immediately after re-ceiving this packet, each mote randomly places its wakeuptime in the next one-epoch-long period of time (the calibra-tion period). When this time arrives, it sends ascatter notifypacket. During the entire epoch, each mote records the ar-rival times of the notify packets of the others. Only two suchpackets are of interests, the one received immediately be-

BA BA

Figure 8. Left: with non-ideal wakeup times, all motes compete for bandwidth to reply to the query and theremay be a delay if the first transmission is at time B. After scatter wakeup times, fewer motes compete and withhigher probability some mote is awake to receive the transmission.

fore the transmission of the mote’s own scatter notify, andthe one received immediately after. At the end of the epoch,the mote finds the midpoint between these two transmis-sions, and moves its own wakeup time closer to, but not ex-actly to, this point. How far to move the wakeup time is a pa-rameter we determined through experimentation. The pro-cess of detecting the scatter notify packets and moving thewakeup time can be repeated any number of times, itera-tively refining distribution.

This solution has been implemented directly in nesC andsimulated in tossim, a TinyOS simulator. It yielded the ex-pected results, namely distributing the wakeup times moreevenly throughout the epoch. We are still evaluating sev-eral aspects of this approach including choosing how far tomove the wakeup time each epoch, evaluating how manyrounds are needed on average to stabilize the wakeup time,and how the algorithm is affected by the fact that the initial-ization packet will not reach all motes at the same time.

7. Related Work

The idea of providing middleware for sensor networkshas been growing in popularity, providing application pro-grammers with a variety of useful abstractions easing thedevelopment process. EnviroTrack [3], a middleware forenvironmental tracking applications, supports event-drivenprogramming by identifying an event at a given location,collecting the data from proximate sensors, and reportingthe readings and event to the user. TinyLIME supports a sim-ilar notion through reactions, although it does not performthe in-network aggregation of EnviroTrack.

An alternative model is data-oriented and thus closer toTinyL IME. In Directed Diffusion [8], applications specify“interest queries” for the necessary data attributes, and thenodes collaborate to set up routes for this information tofollow back to the application. It is explicitly multi-hop innature, unlike TinyLIME that focuses on local, contextualinteractions with sensors. Other systems provide databaseinteraction with sensors. TinyDB [12] provides an SQL-

like interface with optimization for placement of parts ofthe query (e.g., joins, selects) to minimize power consump-tion. Cougar [4] and SINA [18] also provide a distributeddatabase query interface towards a sensor network withan emphasis on power management either by distributingqueries or clustering low-level information in the network.Although TinyLIME also provides a simplified databasemodel, the Linda tuple space, it has no notion of collect-ing information at a single point. Instead multiple clientscan be distributed, and the system can dynamically recon-figure, something not inherent in the other systems. More-over, since TinyLIME protocols are simpler and do not re-quire a tree structure, its communication delays tend to besmaller.

Other data-oriented approaches, such as DSWare [11],address the redundancy of data collected by geographicallyproximate sensors. By aggregating the data of several sen-sors and reporting it as a single value, some amount of sen-sor failure can be tolerated. QUASAR [10] addresses qual-ity concerns, allowing applications to express Quality awareQueries (QaQ). For example, QaQs can express quality re-quirements as either set-based (e.g., find at least 90% of thesensors with temperature greater than 50oC) or value-based(e.g., estimate the average temperature within 1oC). Nei-ther of these optimizations is incorporated into TinyLIME,although we plan to explore how aggregation and qualityconcerns can be addressed in the system.

Tuple spaces have also been considered previously foruse in sensor networks. Claustrophobia [5] replicates a sin-gle tuple space among multiple motes, providing a vari-ety of efficiency-reliability tradeoffs for populating the tu-ple space with sensor data as well as retrieving that data.However, it is based on a different operational setting thanthe one we chose in this paper. ContextShadow [9] exploitsmultiple tuple spaces, each holding only local informationthus providing contextual information. The application isrequired to explicitly connect with the tuple space of in-terest to retrieve information. TinyLIME, being focused onthe combination of MANET and sensor networks, exploits

physical locality to restrict interactions without applicationintervention.

8. Conclusions

In this paper we proposed a novel operational settingfor wireless sensor networks, and a middleware supportingthe development of corresponding applications. The opera-tional setting, in contrast with mainstream approaches, doesnot assume a centralized data collector. Data is coopera-tively collected by mobile monitors interconnected througha MANET, which can access only those sensors that aredirectly available to them. This configuration brings moreflexibility, simplifies the communication infrastructure, andnaturally provides for context-awareness through proxim-ity of sensors to the monitors. The middleware, TinyLIME,is an extension of the LIME middleware originally designedfor MANETs. While communication between the mobilemonitors is entirely handled through LIME, a new layer isbuilt entirely on top of it to interact efficiently with the spe-cialized components deployed on the sensors.

An instantiation of the middleware has been imple-mented for the Crossbow mote platform, and is availablefor download athttp://lime.sf.net/tinyLime.html .

References

[1] Lime. http://lime.sourceforge.net .

[2] Crossbow Technology Inc. http://www.xbow.com ,2005.

[3] T. Abdelzaher, B. Blum, D. Evans, J. George, S. George,L. Gu, T. He, C. Huang, P. Nagaraddi, S. Son, P. Sorokin,J. Stankovic, and A. Wood. EnviroTrack: Towards an en-vironmental computing paradigm for distributed sensor net-works. InProc. of the 24th Int. Conf. on Distributed Com-puting Systems (ICDCS), 2004.

[4] P. Bonnet, J. Gehrke, and P. Seshadri. Querying the physicalworld. IEEE Personal Communication, 7(5):10–15, October2000.

[5] V. Bychkovskiy and T. Stathopoulos. Claustrophobia: Tinytuple spaces for embedded sensors. Course Project, UCLACS233, http://lecs.cs.ucla.edu/˜thanos/cs233/cs233_vlad_thanos_report.ps , 2002.

[6] D. Gelernter. Generative communication in Linda.ACMComputing Surveys, 7(1):80–112, January 1985.

[7] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, andK. Pister. System architecture directions for network sen-sors. InProc. of the 9th Int. Conf. on Architectural Sup-port for Programming Languages and Operating Systems(ASPLOS), pages 93–104, Cambridge, MA, USA, Novem-ber 2000.

[8] C. Intanagonwiwat, R. Govindan, and D. Estrin. DirectedDiffusion: A scalable and robust communication paradigm

for sensor networks. InProc. of the 6th Int. Conf. on Mo-bile Computing and Networks (MobiCom), 2000.

[9] M. Jonsson. Supporting context awareness with the contextshadow infrastructure. InWorkshop on Affordable WirelessServices and Infrastructure, June 2003.

[10] I. Lazaridis, Q. Han, X. Yu, S. Mehrotra, N. Venkatasubra-manian, D. Kalashnikov, and W. Yang. QUASAR: Quality-aware sensing architecture.SIGMOD Record, 33(1):26–31,March 2004.

[11] S. Li, S. Son, and J. Stankovic. Event detection services us-ing data service middleware in distributed sensor networks.In Proc. of the 2nd Int. Workshop on Information Process-ing in Sensor Networks, April 2003.

[12] S. R. Madden, M. J. Franklin, J. M. Hellerstein, andW. Hong. The design of an acquisitional query processor forsensor networks. InProc. of the ACM SIGMOD Int. Conf.on Management of Data, 2003.

[13] A. L. Murphy, G. P. Picco, and G.-C. Roman. LIME: A mid-dleware for physical and logical mobility. In F. Golshani,P. Dasgupta, and W. Zhao, editors,Proc. of the 21st Int. Conf.on Distributed Computing Systems (ICDCS), pages 524–533,May 2001.

[14] G. P. Picco, D. Balzarotti, and P. Costa. LIGHTS: Alightweight, customizable tuple space supporting context-aware applications. InProc. of the 20th ACM Symposiumon Applied Computing (SAC), Santa Fe, New Mexico, USA,March 2005.

[15] G. P. Picco, A. L. Murphy, and G.-C. Roman. LIME: Lindameets mobility. In D. Garlan, editor,Proc. of the 21st Int.Conf. on Software Engineering (ICSE), pages 368–377, May1999.

[16] J. Polastre, R. Szewcyk, A. Mainwaring, D. Culler, andJ. Anderson. Analysis of wireless sensor networks for habi-tat monitoring. In Raghavendra, Sivalingam, and Znati,editors,Wireless Sensor Networks, pages 399–423. KluwerAcademic Pub, 2004.

[17] A. Rowstron. WCL: A coordination language for geographi-cally distributed agents.World Wide Web Journal, 1(3):167–179, 1998.

[18] C.-C. Shen, C. Srisathapornphat, and C. Jaikaeo. Sensor in-formation networking architecture and applications.IEEEPersonal Communication, 8(4):52–59, August 2001.