asurveyofapplicationdistribution …...wireless sensor networks (wsns) are deployed to an area of...

EURASIP Journal on Wireless Communications and Networking 2005:5, 774–788c© 2005 Mauri Kuorilehto et al.

A Survey of Application DistributioninWireless Sensor Networks

Mauri KuorilehtoInstitute of Digital and Computer Systems, Tampere University of Technology, P.O. Box 553, 33101 Tampere, FinlandEmail: [email protected]

Marko HannikainenInstitute of Digital and Computer Systems, Tampere University of Technology, P.O. Box 553, 33101 Tampere, FinlandEmail: [email protected]

Timo D. HamalainenInstitute of Digital and Computer Systems, Tampere University of Technology, P.O. Box 553, 33101 Tampere, FinlandEmail: [email protected]

Received 14 June 2004; Revised 23 March 2005

Wireless sensor networks (WSNs) are deployed to an area of interest to sense phenomena, process sensed data, and take actionsaccordingly. Due to the limited WSN node resources, distributed processing is required for completing application tasks. Propos-als implementing distribution services for WSNs are evolving on different levels of generality. In this paper, these solutions arereviewed in order to determine the current status. According to the review, existing distribution technologies for computer net-works are not applicable for WSNs. Operating systems (OSs) and middleware architectures for WSNs implement separate servicesfor distribution within the existing constraints but an approach providing a complete distributed environment for applications isabsent. In order to implement an efficient and adaptive environment, a middleware should be tightly integrated in the underlyingOS. We recommend a framework in which a middleware distributes the application processing to a WSN so that the applicationlifetime is maximized. OS implements services for application tasks and information gathering as well as control interfaces for themiddleware.

Keywords and phrases: ad hoc networking, distribution, service discovery, task allocation, wireless sensor networks.

1. INTRODUCTION

Wireless sensor networks (WSNs) have gained much atten-tion in both public and research communities because theyare expected to bring the interaction between humans, envi-ronment, and machines to a new paradigm. Despite being afascinating topic with a number of visions of a more intelli-gent world, there still exists a huge gap in the realizations ofWSNs. In this paper, we define WSNs as networks consist-ing of independent, collaborating nodes that can sense, pro-cess, and exchange data as well as act upon the data content.Compared to traditional communication networks, there isno preexisting physical infrastructure that restricts topology.

WSNs are typically ad hoc networks [1] but there are ma-jor conceptual differences. First, WSNs are data-centric with

This is an open access article distributed under the Creative CommonsAttribution License, which permits unrestricted use, distribution, andreproduction in any medium, provided the original work is properly cited.

an objective to deliver time sensitive data to different destina-tions. Second, a deployed WSN is application-oriented andperforms a specific task. Third, messages should not be sentto individual nodes but to geographical locations or regionsdefined by data content [2].

In WSNs quantitative requirements in terms of latencyand accuracy are strict due to the tight relation to the en-vironment. In general, the capabilities of an individual sen-sor node are limited, but the feasibility of WSN lies on thejoint effort of the nodes. Thus, WSNs are distributed sys-tems and need distribution algorithms. Another motivationfor distribution is the resource sharing. Further, to obtain re-sults, WSN applications typically require collaborative pro-cessing of the nodes sensing different phenomena in diverseareas [2].

The main focus of WSN research, as well as wirelessad-hoc network research in general, has been on differentprotocol layers, reviewed in [2, 3, 4, 5, 6, 7, 8] and on en-ergy efficiency [9, 10]. Recently, issues concerning security,

mailto:[email protected]



A Survey of Application Distribution in WSNs 775

context-sensitivity, and self-organization have gained moreattention [11]. Surveys concerning application layer issuesand prototype implementations are fairly limited [4, 12,13]. Furthermore, proposals implementing distribution areemerging as the complexity of applications increases. Theseare covered in [2] but the discussion of proposals supportingapplication distribution is limited to few solutions for distri-bution control.

In this paper, we focus on four essential distribution as-pects in WSNs, namely, service discovery, task allocation, re-mote task communication, and taskmigration. The service dis-covery comprises of identifying and locating services and re-sources required by a client. In homogeneous WSNs, the ser-vice discovery is not important but when node platforms andthe composition of tasks are heterogeneous, the service dis-covery is essential. The task allocation specifies a set of sensornodes, on which the execution of an application task is acti-vated. The remote task communication covers the means forcommunication between distributed tasks through a wirelesscommunication link. The task migration means the methodsfor transferring a task executable from a sensor node to an-other. The algorithms defining the target nodes for migrationare included in the task allocation.

Algorithms that are tightly bound to an application arenot discussed. The presented distribution aspects are selecteddue to their generality for different types of WSNs and appli-cations. We omit, for example, data fusion and data aggrega-tion that are beneficial only for applications that gather datato a centralized storage.

In this paper we review the application distribution forWSNs focusing on distribution implemented in systems soft-ware. By systems software we mean software componentsproviding application-independent services and managingnode resources. The proposed solutions vary according totools provided, requirements placed on the underlying plat-forms, and targeted applications and environments. How-ever, the current proposals lack an integrated solution pro-viding a distributed operating environment for WSN appli-cations. This approach would lead to a more efficient usageof resources.

This paper is organized in two main parts as follows. Thefirst part describes the basics of objectives, challenges, andsystems software solutions of WSNs. In addition, a summaryof WSN application proposals is presented in order to definerequirements. The second part starting in Section 3 containsthe survey of distribution proposals followed by their analysisin Section 4. Finally, conclusions are given in Section 5.

2. OVERVIEWOFWSNs

In order to give an overview of WSN applications, we reviewsome examples and their characteristics. These are listed inTable 1. The selection is mainly based on prototype imple-mentations and thus all the scopes of WSNs might not berepresented.

The first column in Table 1 lists the applications and thesecond classifies them according to the main task. The thirdcolumn presents the requirements set by the application. The

networking requirements in terms of data amount and fre-quency are defined in the fourth column, while the last col-umn gives the scale and density of the application.

Most of the applications gather, evaluate, or aggregatedata from different types of sensors. Major differences arein networking requirements and complexity. Unfortunately,accurate values or limits to these properties are not often re-ported, which complicates a fair comparison.

The nature of applications listed in Table 1 varies, but atleast four main tasks can be identified [28]. Monitoring isused to continually track a parameter value in a given lo-cation, and event detection recognizes occurrences of events.Object classification attempts to identify an object or its typeand object tracking traces movements of an object.

For the presented applications, the “worst-case” WSNwould comprise of an extensive number of nodes with vary-ing density and a network topology that constantly changesdue to the errors in communication, mobility of nodes, andinactive nodes [3]. To complete complex tasks in the sce-nario, the application requires distributed processing withinthe network.

In our view, WSN application quality of service (QoS) isconstructed from network lifetime, network load, accuracyof data, and fault tolerance. Network load in this case com-prises of the required data latency, throughput, and reliabil-ity. WSN protocols and their functions are adapted accordingto the QoS requirements. Currently, security is a QoS issuethat is often omitted in WSNs. The natural reason is that se-curity requires too much resources [2].

For the rest of the paper we define an environmental mon-itoring application that is used for the analysis of the pro-posed solutions. For clarification, we refer to the applicationas EnvMonitor. The main task of the application is the con-stant gathering of location-dependent information within adefined area. In addition to the passive monitoring involvedin the environmental monitoring applications in Table 1, En-vMonitor consists of active monitoring tasks reacting to con-dition changes in WSN. The passive monitoring data aregathered to a central storage and aggregated during the rout-ing. Active in-network monitoring tasks execute signal pro-cessing algorithms locally in order to determine thresholdvalues for temperature and humidity. When a threshold isreached, a set of predefined actions modifying the applica-tion QoS and the communication topology taken. The mod-ifications alter the requirements for data composition, accu-racy, and latency. The priority of active monitoring tasks pre-cedes passive monitoring.

2.1. Systems software forWSNs

A general-purpose operating system (OS) is an example ofsystems software. Early WSNs have not included systemssoftware due to scarce resources and simplicity of applica-tions. However, complex applications require systems soft-ware because it eases the control of resources and increasesthe predictability of execution. The heterogeneity of plat-forms can be hidden under common interfaces provided bythe software. Still, the major disadvantages are heavy compu-tation and memory usage.

776 EURASIP Journal on Wireless Communications and Networking

Table 1: Examples of prototyped applications for WSNs.

Application Type Requirements Data amount and frequency Scale and density

Great Duck Island[14]

Environmentalmonitoring

Data archiving,Internet access, longlifetime

Minimal, every 5–10 min,2–4 h per day 32 nodes in 1 km2

PODS in Hawaii [15]Environmentalmonitoring

Digital images,energy-efficiency

Large data amounts,infrequently

30–50 nodes in 5hectares

CORIE (ColumbiaRiver) [16]

Environmentalmonitoring Base stations, lifetime

Moderate data amounts,infrequently

18 nodes inColumbia River

Peek value evaluation[17]

Environmentalmonitoring

Collaborativeprocessing, minimalnetwork traffic

Moderate data amounts,periodically

Case dependent

Flood detection [18]Environmentalmonitoring

Current conditionevaluation

50 bytes every 30 s200 nodes 50mapart

SSIM (artificialretina) [19] Health

Image identification,realtime, complexprocessing

Large data amounts,frequently every 200ms

100 sensors perretina

Human monitoring[20] Health

Quality of data,security, alerts

Moderate data amounts,depend on the human stresslevel

Several nodes perhuman

Mountain rescue [21] HealthCommunicationintensive

Large data amounts in highfrequency

One per rescuer inmountain area

WINS for military[22]

MilitaryTarget identification,realtime, security,quality of data

Large data amounts,infrequently

Several distantnodes

Object tracking [23] MilitaryCollaborativeprocessing, realtime,location-awareness

Large data amounts with highfrequency near an object

7 (prototype)nodes in proximity

Vehicle tracking [24] MilitaryIdentification andcoordination,realtime

Large data amounts every 8 snear an object

1024 nodes in40 km2

Intelligentinput/output [25] Home entertainment

Communicationintensive

Large data amounts with highfrequency

One node perinput device

WINS conditionmonitoring [22]

Machinery monitoringData aggregation,machinery lifetimeprojection

Depend on machinerycomplexity and its currentstatus

Few nodes permachinery

Smart kindergarten[26] Education

Video streaming,identification,location-awareness

Large data amounts invariable frequencies

Tens of sensors,indoor

Smart classrooms[27] Education

Context-sensing, dataexchange

Large data amounts inrandom frequency

Several nodes inclassroom

The systems software for WSNs implements single nodecontrol and network-level distribution control. The single nodecontrol software implements the low-level routines in a node,whereas the network-level distribution control manages ap-plication execution within several nodes.

Single node controlThe single node control operates on a physical node depictedin Figure 1. A processing unit consists of CPU, storage de-

vices, and an optional memory controller for accessing theinstruction memory of the main CPU. A sensing unit con-sists of sensors and an analog-to-digital converter (ADC). Atransceiver unit enables the communication with other sen-sor nodes. A power unit can be extended by a power genera-tor that harvests energy from environment. Other peripheraldevices, like actuators formoving the node and location find-ing systems, are attached to the node depending on the ap-plication requirements [3].


Processing unit

Code memory(∼ 128KB)

Memorycontroller

Data memory(∼ 4KB)

CPU(∼ 2MIPS)

Sensing unit

10-bitADC

Sensors

Actuators

Location findingsystem

Power unit

Power generatorTransceiver unit(< 256 kbps)

Figure 1: Reference hardware platform architecture of a sensornode.

The reference values in Figure 1 are the resources avail-able in MICA2mote [29]. The power consumption of a nodeis in order of mW when active and in order of µW when thenode is in sleep. The power unit is typically an AA battery orsimilar energy source.

The single node control is accomplished by OS or vir-tual machine (VM). In the reference platform, OS is executedon the main CPU and it uses the same instruction and datamemories as applications. Services implemented by OS in-clude scheduling of tasks, interprocess communication (IPC)between tasks, memory control, and possible power controlin terms of voltage scaling and component activation and in-activation. OS provides interfaces to access and control pe-ripherals. The interfaces are typically associated with layeredsoftware components with more sophisticated functionality,for example a network protocol stack.

Network-level distribution control

Distribution control relies on networking. Figure 2 depictsan example protocol stack for WSN in comparison to twowidely utilized stacks, the OSI model [1] and a distributedsystem in a wireless local area network (WLAN). In a WLANcomputer, the TCP/IP stack is used through a sockets ap-plication programming interface (API). The WLAN adapterthat contains the medium access control (MAC) protocoland the WLAN radio is accessed by a device driver.

There is no unified protocol stack for WSNs and mostof the proposed stacks are just collections of known pro-tocol functions. At the moment, the IEEE 1451.5 Wire-less Sensor Working Group [30] is standardizing the phys-ical layer for WSNs with an intention to adapt link layersfrom other wireless standards, for example, Bluetooth [31],IEEE 802.15.4 low-rate wireless personal area network (LR-WPAN) [32], or IEEE 802.11 WLAN [33]. Other types ofnetworks posing common characteristics withWSNs aremo-bile ad hoc networks (MANETs) [34] targeted to address mo-bility.

In WSNs, the essential protocol layers are the MAC pro-tocol on the data link layer and the routing protocol on thenetwork layer. TheMAC protocol creates a network topology

and shares the transmission medium among sensor nodes.The topology inWSNs is either flat, in which all sensor nodesare equal, or clustered, in which communication is controlledby cluster headnodes. The routing protocol allows commu-nication via multihop paths. A transport protocol that im-plements end-to-end flow control is rarely utilized in WSNs.The middleware layer is equivalent to the presentation layerin the OSI model [1].

For WSNs, the development of a distributed environ-ment requires the consideration of all four distribution as-pects. The control actions are taken according to the applica-tion QoS. The distribution aspects are typically implementedon the middleware layer on top of OS. Thus, the middle-ware component can reside in different types of platforms. Inaddition to OS routines, the middleware utilizes networkinginterface to implement communication between its own in-stances on different sensor nodes. Some distribution aspectscan also be implemented directly by OS.

3. SURVEY OF DISTRIBUTION PROPOSALS

Numerous technologies for the service discovery and remotetask communication are available for computer networks.The task migration is typically a transfer of a binary code im-age or a Java applet. In computer networks, the task alloca-tion is often not the main concern as resources are sufficient.Even though not directly applicable for WSNs, the computernetwork technologies define the basic paradigms and algo-rithms for the application distribution.

Other types of wireless ad hoc networks, like MANETsand Bluetooth, have common characteristics with WSNs.First, communication in these networks is very similar toWSNs. Second, the resource constraints must be considered,even though the limits are looser than in WSNs. For thisreason we include technologies proposed for MANETs andBluetooth in our assessment of WSN proposals.

A distinct categorization of proposed solutions forWSNscannot be made since a proposal typically present a morecomplete architecture addressing several distribution as-pects. Therefore, we categorize the proposals according totheir system architecture to OSs, VMs, middlewares, andstand-alone protocols.

3.1. Architectural paradigms

Figure 3 presents three architectural paradigms for distribu-tion, which are client-server, mobile code, and tuple space.In computer networks, the client-server architecture is ap-plied for the service discovery and remote task communi-cation. It consists of one or multiple servers hosting a setof services and clients accessing these. A directory service ismaintained at the server in the service discovery. In the re-mote task communication, a client outsources a task process-ing to a server. Two alternatives are available, remote proce-dure calls (RPCs) and object-oriented remote method invo-cations (RMIs). As the internal data and state of objects areaccessed only through the object interface, RMI achieves bet-ter abstraction and fault tolerance. In addition, objects can becached and moved [35].


WSN OSI-model WLAN computer

WSN applicationApplication

layer Application program

MiddlewarePresentation

layer Distributing middleware

Sessionlayer Sockets API

WSN transportprotocol

Transportlayer TCP/UDP

Multi-hoprouting protocol

Networklayer IP

Error controlData linklayer

WLAN adapterdevice driver

WSNMAC protocol WLANMAC protocol

Transceiver unitPhysicallayer

WLAN radio

OS

OS

Figure 2: OSI model, WSN, and distributed system in WLAN protocol layers.

Client

Server

Request data

(a)

Client

Mobile code

(b)

Client

Tuple insertTuple read

Tuple removeRequest dataTuple distribution

(c)

Figure 3: Three architectural paradigms for distribution: (a) client-server, (b) mobile code, and (c) tuple space.

Differences in programming languages and platformsmust be hidden in the remote task communication. Stub pro-cedures are generated for this from interface definitions. Astub procedure at the client marshals a procedure call to anexternal data presentation, which is then unmarshalled backto a primitive form at the server [35].

In the mobile code paradigm, instead of moving datafrom a client to a server for processing, the code is moved tothe data origins, and data are then processed locally. A mo-bile agent is an object that in addition to the code carries itsstate and data. Furthermore, mobile agents make migrationdecisions autonomously. They are typically implemented ontop of VMs for platform independency [36].

The concept of tuple space was proposed originally inLinda [46] for the remote task communication, but it is ap-plicable also for the service discovery. Tuples are collectionsof passive data values. A tuple space is a pool of shared in-formation, where tuples are inserted, removed, or read. Dataare global and persistent in the tuple space and remain un-til explicitly removed. In the tuple space, a task does not

need to know its peer task, tasks do not need to exist si-multaneously, and they do not need to communicate di-rectly.

3.2. Computer networks

Service location protocol (SLP) [47], Jini [48], universal plugand play (UPnP) [49], and secure service discovery service(SDS) [50] implement a client-server architecture servicediscovery in computer networks. The tuple space is utilizedin JavaSpaces [51] on top of Jini and in TSpaces [52]. For theremote task communication, Sun RPC [53] and distributedcomputing environment (DCE) [54] are well-known RPCtechnologies. The best-known object-oriented technologiesare common object request broker architecture (CORBA)[55], Java RMI [56], and Microsoft’s distributed commonobject model (DCOM) [57]. The mobility of terminals isaddressed in Mobile DCE [58], Mobile CORBA [59], andRover Toolkit [60]. Schedulers for computer clusters imple-ment task allocation within a cluster by allocating tasks to themost applicable resources [61].


Table 2: Implemented distribution aspects in single node proposals.

Proposal Targetnetwork

Resource requirements(CPU/code memory/data memory)

Service discovery Task allocationRemote taskcommuni-cation

Taskmigration

OS-based architectures

EYES OS [37] WSN 1MHz / 60KB / 2KB Resource requests Not supported RPC Not supported

BTnodes [38] WSN 8MHz/ 128KB/ 64KB Tuple space Not supported Callbacks Smoblets

TinyOS [39] WSN 8MHz/ 128KB/ 4KB Not supported Not supported Active messages Not supported

BerthaOS [40] WSN 22MHz/ 32KB/ 2,25 KB Not supported Not supported BBS Binary code

MOS [25] WSN 8MHz/ > 64KB/ > 1KB Not supported Not supported Not supported Binary codedownload

QNX [41] LAN 33MHz/ 100KB/ N/A Network manager SMP scheduler Message passing Not supported

OSE [42] LAN N/A/ 100KB/ N/A Hunting service Not supported Phantom process Not supported

VM-based architectures

Sensorware [17] WSN N/A/ 1MB/ 128KB Not supportedScript populationspecification

Not supportedTCL scriptmigration

MagnetOS [43] WSN N/A / N/A / N/A Not supportedAutomatic objectplacement

DVM [44]Mobile Javaobjects

Mate [45] WSN 8MHz/ 128KB/KB Not supported Not supported Not supportedCode capsuleupdate

Distribution technologies designed for computer net-works are typically both computation and communicationintensive and cannot be implemented on sensor nodes. Theyare based on the client-server architecture and use detailedspecifications for services and interfaces. These technologiesdo not consider the possible mobility or unavailability of sen-sor nodes. While mobility is addressed in Mobile DCE, Mo-bile CORBA, or Rover toolkit, these still rely on the client-server architecture from DCE and CORBA.

3.3. Distribution proposals forWSNs

From systems software proposals for WSNs, OSs and VMsimplement the single node control and middleware archi-tectures implement the network-level distribution control.These can be supported by stand-alone protocols that ad-dress only a single distribution aspect. We contribute theWSN proposals according to distribution aspects they imple-ment.

OS-based architecturesThe distribution aspects implemented in OSs are listed inTable 2. In addition, the second column defines the type ofa network OS is targeted for, while the third one gives OSresource requirements. In WSNs, OSs implement a very lim-ited set of services and they are fairly primitive in their na-ture. As shown in Table 2, the remote task communication isaddressed typically by providing a simple method for RPC.The service discovery is rarely implemented in OS but on ahigher system services layer that is associated to OS. Tasksmigrate as binary code, because OSs do not support code in-terpreting.

The service discovery is implemented in EYES OS [37]on a distributed services layer above the OS by utilizing re-source requests to neighbor nodes. Also Bluetooth smartnodes (BTnodes) [38] implement distribution in system ser-vices above a lightweight OS. BTnodes use the tuple space toimplement the service discovery. The task allocation is notimplemented in any of the proposals.

A client-server type RPC is applied to the remote taskcommunication in TinyOS [39], BerthaOS (for Pushpinnodes) [40], and in EYES OS. In the component-basedTinyOS, the handler name of the remote component and re-quired parameters are encapsulated in a TinyOS active mes-sage. BerthaOS uses bulletin board system (BBS) for IPC andnodes can post messages also to BBS of a neighbor node. InEYES OS, the basic RPC between neighbor nodes is applied.BTnodes use the tuple space also for information sharing andfor sending notifications to callbacks routines.

The taskmigration as binary code is possible in BetrhaOSand in MultimodAI NeTworks of In-situ Sensors (MANTIS)OS (MOS) [25]. BerthaOS allows the in-network initiation oftransfers and checks the code integrity using a simple check-sum, but neither it nor MOS considers the vulnerability ofthe system to malicious code. In BTnodes, precompiled Javaclasses, smoblets, are able to migrate but they must be exe-cuted on more powerful platforms.

Embedded OSs and RealTime OSs (RTOS), like QNX[41] and OSE [42], support service discovery and remotetask communication in OS services. In QNX, the networkof computers is abstracted to a single homogenous set of re-sources. QNX uses message passing to implement IPC andhides remote locations in process and resource managers.


The local managers interact with a network manager thathandles name resolution. OSE uses stub procedures, referredto as phantom processes, for the remote task communica-tion. A phantom process uses a link handler to communi-cate with the peer phantom process on the remote node. Theremote node is discovered by a hunting system service thatbroadcasts service requests to the network.

From these proposals, QNX and OSE offer a distributedenvironment for applications, but they require more efficientsensor node platforms. Their resource requirements shownin Table 2 do not contain all the components required forthe implementation of the distributed environment. The re-source requirements set by other OSs are in the same order ofmagnitude. All the proposed OS architectures implement thesingle node control over the application tasks of EnvMonitor.The most applicable environment for EnvMonitor is availablein BTnodes, where the tuple space implements service dis-covery and callbacks and smoblets support in-network dis-tributed processing.


Compared to OSs, VMs offer hardware platform indepen-dency and substitute the lack of hardware protection by theprotection implemented in code interpreters. The distribu-tion aspects, target network, and required resources of VMarchitectures are categorized in Table 2. As shown, themobilecode is a common approach to distribution, whereas servicediscovery is not supported.

The task allocation is supported by Sensorware [17] andMagnetOS [43]. The population of tool command language(TCL) scripts in Sensorware is specified in the scripts them-selves. MagnetOS utilizes automatic object placements algo-rithms that adaptively attempt to minimize communicationby moving Java objects nearer to the data source. The remotetask communication is addressed only in MagnetOS that re-lies on distributed VM (DVM) [44]. DVM abstracts networkof computers to a single Java VM (JVM).

As depicted in Table 2, the mobile code is a TCL scriptin Sensorware, a custom bytecode capsule in Mate [45], anda Java object in MagnetOS. The size of the TCL scripts andespecially the Mate code capsules is small compared to thesize of Java objects. In Mate that operates on top of TinyOSa new code capsule is sent in TinyOS active messages to allnodes.

From the proposed solutions, Sensorware and Magne-tOS implement task migration and task allocation, whereasin Mate only the latest code version is updated to all nodes.Implementation of MagnetOS on sensor nodes is not pos-sible, Sensorware sets considerable requirements for under-lying platforms, and Mate is implemented to very resourceconstrained nodes.

Like OSs, these proposals implement the single node con-trol for EnvMonitor. From these proposals, Sensorware is themost suitable for EnvMonitor due to its migration, alloca-tion, and task coprocessing capabilities. However, the con-trol for these actionsmust be implemented by the applicationscripts.

Middleware architectures

Middleware architectures implement a higher abstractionlevel environment for applications. Generally, three differ-ent approaches in WSN middlewares can be identified. First,a middleware coordinates the task allocation based on theapplication QoS. Second, WSN is abstracted to a databasethat supports query processing. Third, a middleware controlsapplication processing in the network based on the currentcontext of surrounding environment. The context dependson the location, nearby people, hosts, and devices, and thechanges in these over time [62]. The target network and dis-tribution aspects for proposals are listed in Table 3.

ApplicationQoS is applied for controlling the task alloca-tion in the configuration adaptation of the middleware link-ing applications and networks (MiLAN) [20], in the resourcemanagement of the cluster-based middleware architecturefor WSNs [63], and in QoSProxies of the QoS-aware middle-ware for ubiquitous and heterogeneous environments [64].The cluster-based middleware and MiLAN adapt also thenetwork topology. The QoSProxy selects an application con-figuration matching available resources and makes resourcesreservations to guarantee the specified QoS for that configu-ration. Both MiLAN and QoS-aware middleware adopt ser-vice discovery protocols from computer network solutions.QoS-aware middleware requires a more powerful platformthan the other two.

A database approach is taken in sensor information andnetworking architecture (SINA) [24], in TinyDB [65] on topof TinyOS, and in Cougar [66]. In SINA, database queriesare injected to network as sensor querying and tasking lan-guage (SQTL) [71] scripts. These scripts migrate from nodeto node depending on their parameters. The task allocationin SINA is implemented by a sensor execution environment(SEE), which compares SQTL script parameters to node at-tributes and executes script only if these match. In TinyDBand Cougar, the task allocation is implemented by a queryoptimizer that determines energy-efficient query routes. Thequery plans generated by the query optimizer are parsed inthe nodes and then executed accordingly. TinyDB supportsalso event-based queries that are initiated in-network on theoccurrence of an event.

Application adaptation based on the current contextis performed by Linda in a mobile environment (LIME)[67], mobile agent runtime environment (MARE) [21], andreconfigurable context-sensitive middleware (RCSM) [27].Service discovery is implemented by the tuple space in LIMEand MARE. RCSM uses a custom RKS [68] protocol that re-duces communication by advertising services only if they canbe activated in the current context and potential clients arein the vicinity. LIME implements task allocation by reactionsadded to tuples. The MARE control manages nearby mobileagents and allocates tasks to the agents. RCSM ADaptive ob-ject containers (ADC) activate tasks in an appropriate con-text.

The tuple space in LIME and MARE is used also for theremote task communication. LIME supports also location-dependent recipient identification. RCSM utilizes RCSM


Table 3: Implemented distribution aspects in middleware and stand-alone protocol proposals.

Proposal Target network Service discovery Task allocationRemote taskcommunication

Task migration


MiLAN [20] WSNSLP, BluetoothSDP

Configurationadaptation

Not supported Not supported

Cluster-basedmiddleware [63]

WSN Not supportedResourcemanagement


QoS-awaremiddleware [64] MANET SLP/Jini/SDS QoSProxy Not supported Not supported

SINA [24] WSN Not supported Attribute matchingin SEE

Not supported SQTL scripts

TinyDB [69] WSN Not supportedQuery optimizer,event-based queries


Cougar [66] WSN Not supported Query optimizer Not supported Not supported

LIME [67] MANET Tuple space Context reaction Tuple space Mobile Java objects

MARE [21] MANET Tuple space MARE control Tuple space Mobile Java objects

RCSM [27] MANET RKS [68] Adaptive objectcontainers

R-ORB Not supported

Stand-alone protocols

GSD [69] MANET Service groups Not supported Not supported Not supported

Bluetooth SDP [31] Bluetooth Clients and servers Not supported Not supported Not supported

Task migration in [70] WSN Not supported Not supported Not supported Edit scripts

context-sensitive object request broker (R-ORB) that adaptsbasics fromCORBAORB. Both LIME andMARE utilize mo-bile agents implemented as Java objects for the task migra-tion.

Unlike OSs and VMs, most of the middleware architec-tures implement the network-level distribution control butdo not address the single node control. Middlewares rely-ing on the application QoS specification address mainly taskallocation, but leave other aspects to external components.The database abstraction is applicable to a certain type of ap-plications, like EnvMonitor, but the expressivity of the SQTLscripts in SINA, the event-based queries in TinyDB, and es-pecially the query processing capabilities in Cougar do notsupport complex in-network processing. As can be seen fromTable 3, context-aware proposals cover distribution aspectsextensively. They implement extensive environment for En-vMonitor but their resource requirements are too high forsensor nodes.


The environment provided by OSs, VMs, or middlewarearchitectures can be supported by stand-alone protocolsimplementing dedicated functions. We do not cover WSNMAC and routing protocols but focus on protocols that im-plement any of the four distribution aspects. The protocolsand their target networks are listed in Table 3.

The group-based service discovery protocol (GSD) forMANETs [69] and the Bluetooth service discovery protocol(SDP) [31] implement the service discovery. In GSD, termi-

nals advertise their services and nearby service groups withinthe distance of n hops. Service requests are forwarded to-wards the service provider based on group advertisements. ABluetooth terminal maintains information about its servicesin an SDP server. Searching and querying for existing servicesare performed by an SDP client that queries one server at atime.

An approach for minimizing the transferred binary codesize on the task migration is proposed in [70]. The proposaltransmits only the differences between the existing and thenew code. The algorithm is adopted from the diff commandof UNIX.

These protocols can be used as separate components forEnvMonitor, but none of them provides a complete environ-ment. GSD is communication intensive due to the multi-hopadvertisements. Bluetooth SDP does not support broadcastqueries, which restricts its applicability in large WSNs. Thetask migration proposed in [70] cannot be initiated in WSNsdue to the complexity of the algorithm and the lack of in-tegrity checking.

4. ANALYSIS OF PROPOSALS

A comprehensive comparison of the proposals is problematicdue to the diversity of platforms, applications, and imple-mentations. However, the requirements for each distributionaspect are similar, which makes their assessment possible. Inthe analysis, we concentrate on the proposals targeted forWSNs.


Table 4: System testing and validation environments for distribution proposals.

Proposal Test environmentSimulation andtesting tools

Prototypeplatform

Result accuracy Published results

OS-based architectures

TinyOS [39] Prototype TOSSIM [72] Motes AccurateComponent sizes, OS routinedelays, computation costs

BerthaOS [40] Prototype None Pushpin None Functionality mentioned

EYES OS [37] None None None None None

MOS [25] Prototype PC emulatorXMOS [25]

Nymph ModerateMemory and power consumption,test application performance results

BTnodes [38] Prototype NoneMicro-sizeBTnodes

ModerateComponent sizes, energyconsumption


Sensorware [17] Prototype SensorSim [73] Linux IPAQ AccurateFramework size, execution delays,energy consumption

MagnetOS [43]Windows/LinuxJVM

Custom packet-level simulator

PC NoneInternal algorithm comparisonin simulator

Mate [45] Prototype TOSSIM [72] TinyOS mote AccurateBytecode overhead, installationcosts, code infection performance


MiLAN [20] None None None None None

Cluster-basedmiddleware in [63]

Algorithmsimulation

Customsimulator

None NoneHeuristic resource allocation,algorithm performance

Qos-awaremiddleware in [64] None None None None None

SINA [24] Simulations GloMoSim [74] None PoorSINA networking overhead,application performance

TinyDB [65]Simulations,prototype

Custom en-vironment

TinyOS mote AccurateQuery routing performance insimulations, sample accuracy andsampling frequency in prototypes

Cougar [66] None None None None None

LIME [67] JVM None PC Poor Approximations about Java code size

MARE [21] JVM None PDA Poor Service discovery performance

RCSM [27] Prototype NonePDA with customhardware

RCSM poor,RKS accurate

RCSMmemory consumption,RKS size, communication,energy consumption


GSD [69] Simulations GloMoSim [74] None PoorInfluence of internal parameterson service discoverability

Task migrationin [70]

PC NoneTested in EYESnodes

AccurateAlgorithm performance,influence of internal parameters

4.1. Testing and validation ofWSN proposals

Discussed WSN architectures vary in their complexity andrequirements. In order to provide a scope for the assessmentof proposals, their testing and validation environments arepresented in Table 4. The test environment is presented in thesecond column. The simulation and testing tools and proto-type platforms identify the proposal validation tools and testplatform. The published results and their accuracies are listedin the last two columns.

Generally, prototypes exist for the single node architec-tures and their results are accurate including informationrequired for comparison. Instead, on the middleware layer,proposals are evaluated by simulations or not at all. Thesimulation results are inaccurate as they compare only theinternal algorithms and do not give any information fora general comparison. Of course, exceptions exist in bothcases.

Even though some of the presented results in Table 4 areaccurate and their scope is adequate, the direct comparison


Table 5: Characteristics of technologies implementing service discovery.

Technology Communication Scalability Fault tolerance Requirements Benefits (pros) Problems (cons)

Resourcerequests

Requeststo neighbors

Restrictedto neighbors

Broadcastedto all neighbors

Resourcedeclaration

One-hopcommunication

Scalability

Tuple space Tuple operations Balancing betweenmemory and scale

Redundantinformation

Memory pool ineach node

Source and targetindependency

Communication/memory load

Networkmanager

Name resolution re-quests to manager

Local manager area,but extensible

Possibly redundantnetwork managers

Resource managers,register to manager

Scalability due tonaming

Name resolution,communicationload

Huntingservice

Broadcast hunt ser-vice requests

Not restricted Lost services can berehunted

Remote serviceidentification

Lightweight afterinitiation

First hunt latencyand communica-tion load

BluetoothSDP

Peer-to-peer link Only nearby nodesone at a time

Service informationonly in the host

Bluetooth protocolstack

Querying foravailable services

Scalability, nobroadcast

RKSAdvertises for po-tential clients

Only to nearby clients Advertisementswhen context andclients applicable

Context definitionsfor services

Advertisements Scalability

GSD servicegroups

Service and groupadvertisements

n-hop diameter, butgroups span wider

Redundantinformation

Service registration Request routingbased on groupadvertisements

Communicationload (both ad-vertisements andrequests used)

of distribution performance is not possible. The prototypeplatforms vary in their efficiency, the simulators in their ac-curacy, and the test applications in their requirements andfunctionality. As the area is evolving rapidly, generally ac-cepted benchmarks would ease the comparison of the pro-posals. However, the definition of general-enough bench-marks for WSNs is difficult due to their application-specificnature.

4.2. Comparison of technologies

We classify the technologies for each distribution aspect sep-arately. The classification dimensions for a technology arecommunication mechanism, scalability to large WSNs, faulttolerance, and requirements that must be met before the tech-nology can be used. For each technology, we also assess itspros and cons in general. These dimensions offer tools forthe evaluation of the robustness and applicability of a tech-nology for different kinds of WSNs and applications.

Service discovery

The classification of the service discovery technologies in theproposals according to the defined dimensions is presentedin Table 5. From the presented solutions, all but the tuplespace and GSD rely on client-server architecture. Still, thenetwork manager is the only centralized server. In general,two problems can be identified from the proposals. They ei-ther have a restricted scalability or require intensive commu-nication.

The client-server technologies that are limited to nearbynodes do not scale to large WSNs. GSD and the tuple spaceboth scale to large networks but they require more commu-nication for locating a service. However, in both technolo-gies the communication load can be decreased by increasingthe number of hops, to which the service information is dis-tributed. This increases the communication during the ini-

tiation but reduces it during the discovery, with the cost ofincreased memory consumption.

Task allocationThe technologies that implement a mechanism for the taskallocation and the characteristics of each technology arelisted in Table 6. As peer-to-peer communication is notneeded in all the technologies, the communication mecha-nism is replaced by a more general outlining of the taken ap-proach. As shown in Table 6, the variance of technologies isgreater than in the service discovery. Asmost of the technolo-gies are middleware layer implementations, the main reasonfor the variance is the three different approaches taken at thatlayer.

Themost promising approach is the task allocation basedon application QoS. It does not restrict the implementa-tion of tasks nor rely on the surrounding context. Instead,it enables the adaptation of application operations depend-ing on the current application requirements. The applicationrequirements can be adjusted depending on the output ofthe application itself, which makes the technologies adaptiveto changing conditions. Generally, application-QoS-basedtechnologies require a central control for the task allocation,but a distributed control lacks similar adaptability.

Remote task communicationFrom the remote task communication technologies classifiedin Table 7, most utilize traditional RPC or RMI that are tai-lored for resource constrained environments. The tuple spaceand callbacks, which also utilize tuple space, are the only ex-ceptions.

In general, the technologies either are restricted in theirscalability or burdenmemory and communication resources.The problem in RPC and RMI technologies is the require-ment for a client to know the server. In the tuple space andcallbacks this is not required. In the callbacks, the message


Table 6: Characteristics of technologies implementing task allocation.

Technology Approach Scalability Fault tolerance Requirements Benefits (pros) Problems (cons)

SMPscheduler

Scheduling of tasksto free resources

Not restricted Redundant High-speed bus,shared memory

Efficiency andtransparency

Inapplicablerequirements

Script popu-lationspecification

Specification in mi-grating scripts

Not restricted Multiple copiesin network

Control in appli-cation scripts

No controlrequired

Expressivity ofspecification

Automaticobjectplacement

Activating andmov-ing objects near tosource

Not restricted Multiple agentsavailable

Object placementalgorithms

Reduced datacommunication

Complexity

Configurationadaptation

Mapping tasks toavailable resources

Not restricted Changes activenodes adaptively

Feasibility analy-sis,state updates

Application QoSconsideration

Controlcommunication

Resourcemanagement

Heuristic algorithmbalancing load [75]

Restricted toa cluster

Continuousallocation

Control messages Network lifetimemaximizing

Algorithmcomplexity

QoSProxy

Component andservice adaptationfor resources andapplication QoS

Network-wide insmall networks

Adaptation accord-ing to conditions

Application QoSspecification

QoS adaptationdynamically toavailable resources

Server required,complexity andcommunication

Attributematching inSEE

Matching script at-tributes to node pa-rameters locally

Not restricted Multiple copiesin network

Accurate attributespecifications

Local late binding Restrictedexpressivity

Queryoptimizer

Optimizing queryrouting to network

Optimization ingateway node

Redundancyin queries

Disseminatedquery plans

Only requiredset of nodesactivated

Networking loadof query plans

Event-basedqueries

Initiate query on oc-currence of event

Not restricted Possibly severalevent detectors

Event identifica-tioncapability

In-networkreaction

Loading of eventsource node

Contextreaction

Reactions on tuplesand executed onmatching context

Reaction restrictedto a location

Redundancy in tu-ple space

Locationidentifying

Task executed onlywhen its context isapplicable

Scalability

MAREcontrol

Nearby agents forman executionenvironment

Restricted to nearbyagents

Possibleredundancy

Agent managerscontrolling agents

Agent cooperationin complex tasks

Scalability

Adaptiveobjectcontainers

ADC activates tasksin correct context

Not restricted Possibleredundancy

Context interfacespecifications

Only applicabletasks activated

Complex contextspecifications

is sent to a registered callback function whenever the valueof a tuple changes. The tuple space does not support suchinterests on tuples. Like in the service discovery, the com-munication and memory load of the tuple space are ad-justable.

Taskmigration

The technologies for the task migration are summarized inTable 8. Most of the technologies rely on the mobile agentsdue to their fault tolerance and smaller physical size. Threetechnologies rely on binary code in order to lessen the com-putation load caused by the agent interpreting.

In order to use binary code in the task migration, thepossible errors during transfers and malicious attacks mustbe managed. The edit script generation algorithm is toocomplex to be executed in nodes, thus making it inappli-cable for dynamic WSNs. From the VM approaches, theTCL and SQTL scripts and Mate bytecode capsules are morelightweight than Java objects because of the complexity andmemory requirements of JVM.

4.3. Suitability assessment

Generally, the OS and VM proposals support the remotetask communication and the task migration but leave thetask allocation and the service discovery to an applicationor other external components. On the contrary, middlewareapproaches concentrate on implementing the task allocation,leaving other aspects for the tuple spaces or some legacy pro-tocols. MARE and LIME are the only proposals that cover alldistribution aspects. However, the utilization of JVM and thedistributed tuple space requires resources that are not gener-ally available in current WSN platforms.

We assess the applicability of the proposals for En-vMonitor. For a fair comparison, we separately comparethe approaches for node platforms with enough resources,and then for platforms with limited resources defined inFigure 1. The main aspect considered in the assessment is thecompleteness of the operating environment provided for theapplication. In a complete environment, the application doesnot need to consider its distributed nature but the distribu-tion is handled by the systems software. Further, the adap-


Table 7: Characteristics of technologies implementing remote task communication.

Technology Communicationimplementation Scalability Fault tolerance Requirements Benefits (pros) Problems (cons)

Activemessages

Remote handler,data encapsulation

Not restricted N/A Awareness ofremote handler

Mapping toTinyOS eventmodel

Handler name inASCII

BBS Message posting toneighbor BBS

Restricted to neigh-bor nodes

Message posted toall neighbors

Neighbor postingenabled by sender

One-hopcommunication

Scalability,memory load

EYES OS RPC N/A Restricted toneighbors

N/A N/A One-hopcommunication

Scalability

Callbacks Callback registeredto a tuple

Restricted to nodessharing tuple space

Callback registeredonly in one node

Shared tuple spacebetween nodes

Callback fired onlyon an event

Fault tolerance

Messagepassing

Custom networking(QNet) operations

Not restricted Possibility forredundantmessages

Name resolution Mapping to localIPC

Network namingoverhead

Phantomprocess

Messages sent bylink handler

Not restricted Possible securechannels

Created channel forcommunication

Mapping to localIPC

Required hand-shaking,communicationload

DVM Invocationredirection

Not restricted N/A Compile time scriptmodification

Seamless IPC be-tween objects

Communicationand processingload

Tuple space Tuple operations Not restricted Redundant Shared tuple spacebetween nodes

Distributed inspace and time

Communication/memory load

R-ORB Message-orientedcommunication

Requires nearbyrecipient

Activated when linkavailable

Context sensing Activated only inapplicable context

Scalability

Table 8: Characteristics of technologies implementing task migration.

Technology Communication Scalability Fault tolerance Requirements Benefits (pros) Problems (cons)

Binary code Binary code afternegotiation

Only to one neigh-bor at a time

Simplechecksum

Initiated by the binarycode itself

Runtime initiation Scalability, bit er-rors, binary size

Binary codedownload

Binary code fromworkstation

No in-networkinitiation

No protection User initiatesdownloads

Possibility to updateOS components

Errors, binary size,user interaction

Smoblets Java applet modules Execution only inlaptops/PDAs

Java interpreterprotection

Efficient platforms Complex processingoutsourcing

Executed only inefficient nodes

TCL scriptmigration

TCL scripts The scale specifiedin scripts

TCL interpreterprotection

Injected to networkby a user

Dynamic migration,small size of scripts

Complex popula-tion specifications

Mobile Javaobjects

Objects on topof JVM

Not restricted Interpreterprotection

Event initiatingmobilization

Scalability Communicationand processingload

Code capsuleupdates

Small capsules in oneactive message

Script populatedto all nodes innetwork

Mate interpreterprotection


Small size of scripts No controlledmigration

SQTL scripts Custom query scripts The scale specifiedin scripts

SEE interpreterprotection


Small size of scripts Communicationcost in broadcast

Edit scripts Scripts containingchanges to old code

No in-networkinitiation

Erroneous/missingscripts requestedfrom neighbors

Generation of editscripts in workstation

Small size of scripts Complexity, no in-network operation

tivity of the proposals to changing conditions and the taskallocation for extending network lifetime are emphasized.

For resource rich environments, MARE is the most suit-able environment. The sensing and aggregation tasks in Env-Monitor can be allocated by theMARE control, and the activemonitoring tasks can be implemented as mobile agents thatare activated on demand.

For typical WSN platforms, MARE is not applicabledue to its resource requirements. On the other hand, BTn-odes fit to the restricted resources. The callbacks can beused to implement active monitoring tasks in EnvMoni-tor. The only aspect that is not supported by BTnodes isthe task allocation so that the load is balanced betweennodes.


4.4. Recommendations

From the systems software proposals for WSNs, OS and VMtechnologies implement the single node control and separatesolutions for application distribution. The middleware pro-posals are applicable to the network-level distribution con-trol. However, we argue that in WSNs, OS and middlewarelayers must be integrated to provide sufficient services withinthe constraints set by applications and platform resources.

In this kind of an approach, OS and middleware are in-side the same framework so that information about OS in-ternals and network topology is applicable to the middle-ware layer. Thus, this approach minimizes extra computa-tion required for interfacing OS routines and communica-tion due to the control signaling. Further, the middlewarelayer is aware of the influences of its actions at both the singlenode and network level. This awareness can be beneficial inthe network-level power management and in the balancingof node loading.

For a sufficient environment for EnvMonitor, OS mustimplement a preemptive scheduling of tasks, a memory andpower management, and a local IPC. The memory controlshould support static and dynamicmemory andmaintain in-formation about available memory. We recommend the us-age of a message-passing IPC because it is easily extendedto the remote task communication. This kind of a general-purpose OS can be implemented on limited resources asshown in [25].

In addition to the local services, OS informs the middle-ware about the node energy and storage consumption, net-work role, associations, and nearby nodes and routes. An in-ternal interface for the middleware to control tasks, powerstates, and network is implemented in OS. When all distri-bution aspects are implemented on the middleware layer, thecomponents are able to utilize the information from eachother more efficiently.

For service discovery we recommend the tuple space,since the pure client-server architecture is too static forWSNs. The resource and communication load of the tuplespace can be diminished by selectively distributing tuple stor-ing to nodes that use the tuple data and by dividing tuples totwo-level hierarchies similar to GSD. The nodes that need atuple for their operation can be identified with the supportof task allocation. By sending only service group tuples to thedistant nodes, less memory is needed but requests for tuplescan still be routed accurately.

For the task allocation, the current application-QoS-based middleware proposals implement sufficient technolo-gies. However, simpler algorithms that require less controlcommunication should be used, even with the cost of accu-racy.

For the remote task communication we recommend asimple approach that marshals the local message passing IPCto network packets. The remote nodes are identified by theservice discovery. To make the delivery of a packet reliable,acknowledgements must be used. This is more lightweightthan the tuple space, and the fault tolerance does not dependon the available recipients.

From our perspective, the task migration is required onlyin very dynamic applications, like object tracking. Theseapplications require a VM-based environment. In OSs, thecommunication cost of the large binary transfers is extensive.Thus, the taskmigration should only be used when extremelynecessary. The transfers must be protected with checksumsand digital signatures, even though these are resource con-suming.

We recommend also the usage of virtual clusters. A vir-tual cluster may follow the physical topology or it can be aset of adjacent nodes that have elected a single control en-tity. By storing detailed tuple information and performingtask allocation within the boundaries of a virtual cluster, thecommunication and memory load can be diminished.

5. CONCLUSIONS

Our survey of WSN applications and their distributionshows that, despite many proposals, no common bench-marks nor detailed, large-scaled experiments have been pub-lished. The research seems to focus either on node imple-mentations or theoretical work on distinct aspects, such asrouting algorithms, without a realistic relation to physicalplatforms.

The systems software proposals are still evolving. Cur-rently, they implement technologies and algorithms for ap-plication distribution but lack an approach combining a dis-tributing middleware layer to OS providing a single nodecontrol. This kind of an approach is needed in order to im-plement a distributed operating environment, which sup-ports application QoS and extends network lifetime, for re-source scarce sensor nodes.

REFERENCES

[1] W. Stallings, Data & Computer Communications, Prentice-Hall, Englewood Cliffs, NJ, USA, 6th edition, 2001.

[2] J. A. Stankovic, T. E. Abdelzaher, C. Lu, L. Sha, and J. C. Hou,“Real-time communication and coordination in embeddedsensor networks,” Proc. IEEE, vol. 91, no. 7, pp. 1002–1022,2003.

[3] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci,“A survey on sensor networks,” IEEE Commun. Mag., vol. 40,no. 8, pp. 102–114, 2002.

[4] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci,“Wireless sensor networks: a survey,” Computer Networks,vol. 38, no. 4, pp. 393–422, 2002.

[5] K. Akkaya and M. Younis, “A survey on routing protocols forwireless sensor networks,” Elsevier Ad Hoc Network Journal,vol. 3, no. 3, pp. 325–349, 2005.

[6] H. Karl and A. Willig, “A short survey of wireless sen-sor networks,” Tech. Rep. TKN-03-018, Technical Univer-sity Berlin, Berlin, Germany, 2003, available: http://www.tkn.tu-berlin.de/publications.

[7] D. Chen and P. K. Varshney, “QoS support in wireless sensornetworks: a survey,” in Proc. International Conference onWire-less Networks (ICWN ’04), pp. 227–233, Las Vegas, Nev, USA,June 2004.

[8] S. Tilak, N. B. Abu-Ghazaleh, and W. B. Heinzelman, “Ataxonomy of wireless micro-sensor network models,” ACMSIGMOBILE Mobile Computing and Communications Review,vol. 6, no. 2, pp. 28–36, 2002.

http://www.tkn.tu-berlin.de/publications

http://www.tkn.tu-berlin.de/publications


[9] V. Raghunathan, C. Schurgers, S. Park, and M. B. Srivastava,“Energy-aware wireless microsensor networks,” IEEE SignalProcessing Mag., vol. 19, no. 2, pp. 40–50, 2002.

[10] A. J. Goldsmith and S. B. Wicker, “Design challenges forenergy-constrained ad hoc wireless networks,” IEEE WirelessCommunications, vol. 9, no. 4, pp. 8–27, 2002.

[11] D. Remondo and I. G. Niemegeers, “Ad hoc networking infuture wireless communications,”Computer Communications,vol. 26, no. 1, pp. 36–40, 2003.

[12] N. Xu, “A survey of sensor network applications,” available:http://enl.usc.edu/∼ningxu/papers/survey.pdf.

[13] C.-Y. Chong and S. P. Kumar, “Sensor networks: evolution,opportunities, and challenges,” Proc. IEEE, vol. 91, no. 8, pp.1247–1256, 2003.

[14] A. Mainwaring, J. Polastre, R. Szewczyk, D. Culler, and J. An-derson, “Wireless sensor networks for habitat monitoring,”in Proc. International Workshop on Wireless Sensor Networksand Applications (WSNA ’02), pp. 88–97, Atlanta, Ga, USA,September 2002.

[15] PODS, A Remote Ecological Micro-sensor Network Projectwebsite, http://www.pods.hawaii.edu.

[16] CORIE website, http://www.ccalmr.ogi.edu/CORIE.[17] A. Boulis, C.-C. Han, and M. B. Srivastava, “Design and im-

plementation of a framework for efficient and programmablesensor networks,” in Proc. 1st International Conference on Mo-bile Systems, Applications, and Services (MobiSys ’03), SanFrancisco, Calif, USA, May 2003.

[18] P. Bonnet, J. Gehrke, and P. Seshadri, “Querying the physicalworld,” IEEE Pers. Commun., vol. 7, no. 5, pp. 10–15, 2000.

[19] L. Schwiebert, S. K. S. Gupta, and J. Weinmann, “Researchchallenges in wireless networks of biomedical sensors,” inProc. 7th ACM International Conference on Mobile Comput-ing and Networking (MobiCom ’01), pp. 151–165, Rome, Italy,July 2001.

[20] W. B. Heinzelman, A. L. Murphy, H. S. Carvalho, and M. A.Perillo, “Middleware to support sensor network applications,”IEEE Network, vol. 18, no. 1, pp. 6–14, 2004.

[21] M. Storey, G. S. Blair, and A. Friday, “MARE: resource discov-ery and configuration in Ad hoc networks,” J. Mobile Networksand Applications, vol. 7, no. 5, pp. 377–387, 2002.

[22] H. O.Marcy, J. R. Agre, C. Chien, L. P. Clare, N. Romanov, andA. Twarowski, “Wireless sensor networks for area monitoringand integrated vehicle health management applications,” inProc. AIAA Guidance, Navigation, and Control Conference andExhibit, Portland, Ore, USA, 1999, Collection of Technical Pa-pers. Vol. 1 (A99-36576 09-63).

[23] K. Romer , “Tracking real-world phenomena with smartdust,” in Proc. 1st European Workshop on Wireless Sensor Net-works (EWSN ’04), pp. 28–43, Berlin, Germany, January 2004.

[24] C.-C. Shen, C. Srisathapornphat, and C. Jaikaeo, “Sensor in-formation networking architecture and applications,” IEEEPers. Commun., vol. 8, no. 4, pp. 52–59, 2001.

[25] H. Abrach, S. Bhatti, J. Carlson, et al., “MANTIS: system sup-port for MultimodAl NeTworks of In-situ Sensors,” in Proc.2nd ACM International Workshop on Wireless Sensor Networksand Applications (WSNA ’03), pp. 50–59, San Diego, Calif,USA, September 2003.

[26] M. B. Srivastava, R. R. Muntz, and M. Potkonjak, “Smartkindergarten: sensor-based wireless networks for smart de-velopmental problem-solving enviroments,” in Proc. 7th ACMInternational Conference on Mobile Computing and Network-ing (MobiCom ’01), pp. 132–138, Rome, Italy, July 2001.

[27] S. S. Yau, F. Karim, Y. Wang, B. Wang, and S. K. S. Gupta, “Re-configurable context-sensitive middleware for pervasive com-puting,” IEEE Pervasive Computing, vol. 1, no. 3, pp. 33–40,2002.

[28] NIST Wireless Ad hoc Networks Project website, http://www.antd.nist.gov/wahn ssn.shtml.

[29] MICA2 data sheet, available: http://www.xbow.com.[30] IEEE P1451.5 Wireless Sensor Working Group website,

http://grouper.ieee.org/groups/1451/5.[31] Bluetooth Special Interest Group, “Bluetooth specification,

version 1.1,” February 2001.[32] Wireless Medium Control (MAC) and Physical Layer (PHY)

Specifications for Low Rate Wireless Personal Area Networks(LR-WPAN), IEEE Standard 802.15.4, 2003.

[33] Wireless LAN Medium Control (MAC) and Physical Layer(PHY) Specifications, IEEE Standard 802.11, 1999.

[34] IETF Mobile Ad-hoc Networks Working Group website,http://www.ietf.org/html.charters/manet-charter.html.

[35] G. Coulouris, J. Dollimore, and T. Kindberg, Distributed Sys-tems: Concepts and Design, Addison-Wesley, Boston, Mass,USA, 3rd edition, 2001.

[36] A. Fuggetta, G. P. Picco, and G. Vigna, “Understanding codemobility,” IEEE Trans. Software Eng., vol. 24, no. 5, pp. 342–361, 1998.

[37] P. J. M. Havinga, “System architecture specification,”EYES Project Deliverable 1.1, available: http://www.eyes.eu.org/dissem.htm.

[38] J. Beutel, O. Kasten, F. Mattern, K. Roemer, F. Siegemund, andL. Thiele, “Prototyping wireless sensor networks with BTn-odes,” in Proc. 1st European Workshop on Wireless Sensor Net-works (EWSN ’04), pp. 323–338, Berlin, Germany, January2004.

[39] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pis-ter, “System architecture directions for networked sensors,” inProc. 9th ACM International Conference on Architectural Sup-port for Programming Languages and Operating Systems (AS-PLOS ’00), pp. 94–103, Cambridge, Mass, USA, November2000.

[40] J. Lifton, D. Seetharam, M. Broxton, and J. Paradiso, “Push-pin computing system overview: a platform for distributed,embedded, ubiquitous sensor networks,” in Proc. 1st Interna-tional Conference on Pervasive Computing (Pervasive ’02), pp.139–151, Zurich, Switzerland, August 2002.

[41] QNX website, http://www.qnx.com.[42] OSE website, http://www.ose.com.[43] R. Barr, J. C. Bicket, D. S. Dantas, et al., “On the need

for system-level support for ad hoc and sensor networks,”ACMSIGOPSNewsletter on Operating Systems Review, vol. 36,no. 2, pp. 1–5, 2002.

[44] E. G. Sirer, R. Grimm, A. J. Gregory, and B. N. Bershad, “De-sign and implementation of a distributed virtual machinefor networked computers,” in Proc. 17th ACM Symposium onOperating Systems Principles (SOSP ’99), pp. 202–216, KiawahIsland, SC, USA, December 1999.

[45] P. Levis and D. Culler, “Mate: a tiny virtual machine for sen-sor networks,” in Proc. 10th ACM International Conference onArchitectural Support for Programming Languages and Oper-ating Systems (ASPLOS ’02), pp. 85–95, San Jose, Calif, USA,October 2002.

[46] D. Gelernter, “Generative communication in linda,” ACMTrans. Programming Languages and Systems, vol. 7, no. 1, pp.80–112, 1985.

[47] E. Guttman, C. Perkins, J. Veizades, and M. Day, “Service lo-cation protocol, version 2,” IETF, RFC 2608, June 1999.

[48] Jini Architecture Specification, version 2.0, Sun Microsystems,June 2003, available: http://www.sun.com/software/jini/specs.

[49] UPnP Device Architecture, Microsoft Corporation, June 2000,available: http://www.upnp.org/resources/documents.asp.

[50] S. E. Czerwinski, B. Y. Zhao, T. D. Hodes, A. D. Joseph, andR. H. Katz, “An architecture for a secure service discovery

http://enl.usc.edu/~ningxu/papers/survey.pdf

http://www.pods.hawaii.edu

http://www.ccalmr.ogi.edu/CORIE

http://www.antd.nist.gov/wahn_ssn.shtml

http://www.antd.nist.gov/wahn_ssn.shtml

http://www.xbow.com

http://grouper.ieee.org/groups/1451/5

http://www.ietf.org/html.charters/manet-charter.html

http://www.eyes.eu.org/dissem.htm

http://www.eyes.eu.org/dissem.htm

http://www.qnx.com

http://www.ose.com

http://www.sun.com/software/jini/specs

http://www.upnp.org/resources/documents.asp


service,” in Proc. 5th International Conference on Mobile Com-puting and Networking (MobiCom ’99), pp. 24–35, Seattle,Wash, USA, August 1999.

[51] JavaSpaces Service Specification, version 2.0, Sun Microsys-tems, June 2003, available: http://www.sun.com/software/jini/specs.

[52] T. J. Lehman, A. Cozzi, Y. Xiong, et al., “Hitting the dis-tributed computing sweet spot with TSpaces,” Computer Net-works, vol. 35, no. 4, pp. 457–472, 2001.

[53] R. Srinivasan, “RPC: remote procedure call protocol specifi-cation version 2,” IETF, RFC 1831, August 1995.

[54] The Open Group Portal to World of DCE, website, http://www.opengroup.org/dce.

[55] Object Management Group website, http://www.omg.org.[56] Java RMI specification, Sun Microsystems, 1997–2003, avail-

able: http://java.sun.com/products/jdk/rmi/reference/docs.[57] M. Horstmann and M. Kirtland, “DCOM architec-

ture,” Microsoft Corporation, July 1997, available: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/dcom.asp.

[58] A. Schill and S. Kummel, “Design and implementation ofa support platform for distributed mobile computing,” Dis-tributed Systems Engineering, vol. 2, no. 3, pp. 128–141, 1995.

[59] S. Adwankar, “Mobile CORBA,” in Proc. 3rd InternationalSymposium on Distributed Objects and Applications (DOA’01), pp. 52–63, Rome, Italy, September 2001.

[60] A. D. Joseph, J. A. Tauber, and M. F. Kaashoek, “Mobile com-puting with the rover toolkit,” IEEE Trans. Comput., vol. 46,no. 3, pp. 337–352, 1997.

[61] Supercluster.org website, http://www.supercluster.org.[62] B. Schilit, N. Adams, and R.Want, “Context-aware computing

applications,” in Proc. Workshop onMobile Computing Systemsand Applications (WMCSA ’94), pp. 85–90, Santa Cruz, Calif,USA, December 1994.

[63] Y. Yu, B. Krishnamachari, and V. K. Prasanna, “Issues in de-signing middleware for wireless sensor networks,” IEEE Net-work, vol. 18, no. 1, pp. 15–21, 2004.

[64] K. Nahrstedt, X. Dongyan, D. Wichadakul, and L. Baochun,“QoS-aware middleware for ubiquitous and heterogeneousenvironments,” IEEE Commun. Mag., vol. 39, no. 11, pp. 140–148, 2001.

[65] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong,“The design of an acquisitional query processor for sensornetworks,” in Proc. 22nd ACM SIGMOD International Con-ference on Management of Data (SIGMOD ’03), pp. 491–502,San Diego, Calif, USA, June 2003.

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

[67] A. L. Murphy, G. P. Picco, and G.-C. Roman, “LIME: amiddleware for physical and logical mobility,” in Proc. 21stInternational Conference on Distributed Computing Systems(ICDCS ’01), pp. 524–533, Phoenix, Ariz, USA, April 2001.

[68] S. S. Yau and F. Karim, “An energy-efficient object discov-ery protocol for context-sensitive middleware for ubiquitouscomputing,” IEEE Trans. Parallel Distrib. Syst., vol. 14, no. 11,pp. 1074–1085, 2003.

[69] D. Chakraborty, A. Joshi, Y. Yesha, and T. Finin, “GSD: anovel group-based service discovery protocol for MANETS,”in Proc. 4th International Workshop on Mobile and WirelessCommunications Network (MWCN ’02), pp. 140–144, Stock-holm, Sweden, September 2002.

[70] N. Reijers and K. Langendoen, “Efficient code distributionin wireless sensor networks,” in Proc. 2nd ACM International

Workshop on Wireless Sensor Networks and Applications, pp.60–67, San Diego, Calif, USA, September 2003.

[71] C. Jaikaeo, C. Srisathapornphat, and C.-C. Shen, “Query-ing and tasking in sensor networks,” in Proc. 14th Interna-tional Symposium on Aerospace/Defense Sensing, Simulation,and Control, vol. 4037 of Proc. SPIE’s, pp. 184–197, Orlando,Fla, USA, April 2000.

[72] P. Levis, N. Lee, M. Welsh, and D. Culler, “TOSSIM: accu-rate and scalable simulation of entire TinyOS applications,”in Proc. 1st ACM Conference on Embedded Networked SensorSystems (SenSys ’03), pp. 126–137, Los Angeles, Calif, USA,November 2003.

[73] S. Park, A. Savvides, and M. B. Srivastava, “Simulating net-works of wireless sensors,” in Proc. Winter Simulation Confer-ence (WSC ’01), pp. 1330–1338, Arlington, Va, USA, Decem-ber 2001.

[74] X. Zeng, R. Bagrodia, and M. Gerla, “GloMoSim: a library forparallel simulation of large-scale wireless networks,” in Proc.12th Workshop on Parallel and Distributed Simulations (PADS’98), pp. 154–161, Banff, Alberta, Canada, May 1998.

[75] Y. Yu and V. K. Prasanna, “Energy-balanced task allocationfor collaborative processing in networked embedded systems,”in Proc. ACM SIGPLAN Conference on Languages, Compilers,and Tools for Embedded Systems (LCTES ’03), pp. 265–274, SanDiego, Calif, USA, June 2003.

Mauri Kuorilehto received the M.S. de-gree in 2001 from Tampere University ofTechnology (TUT), Finland. He is currentlypursuing his Ph.D. degree and acting asa Research Scientist in the DACI ResearchGroup, the Institute of Digital and Com-puter Systems at TUT. His research inter-ests include wireless sensor and ad hoc net-works concentrating on distributed pro-cessing, operating systems, and networksimulation.

Marko Hannikainen received the M.S. de-gree in 1998 and the Ph.D. degree in 2002both from Tampere University of Technol-ogy (TUT). Currently he acts as a SeniorResearch Scientist in the Institute of Dig-ital and Computer Systems at TUT, anda Project Manager in the DACI ResearchGroup. His research interests include wire-less local and personal area networking,wireless sensor and ad hoc networks, andnovel web services.

Timo D. Hamalainen received the M.S. de-gree in 1993 and the Ph.D. degree in 1997both from Tampere University of Technol-ogy (TUT). He acted as a Senior ResearchScientist and Project Manager at TUT dur-ing 1997–2001. He was nominated to beFull Professor at TUT, Institute of Dig-ital and Computer Systems in 2001. Heheads the DACI Research Group that fo-cuses on three main lines: wireless localarea networking and wireless sensor networks, high-performanceDSP/HW-based video encoding, and interconnection networkswith design flow tools for heterogeneous SoC platforms.



http://www.opengroup.org/dce

http://www.opengroup.org/dce

http://www.omg.org

http://java.sun.com/products/jdk/rmi/reference/docs

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/dcom.asp



http://www.supercluster.org

asurveyofapplicationdistribution …...wireless sensor networks (wsns) are deployed to an area of...

Documents