wireless sensor networks - semantic scholar · pdf file · 2017-11-01wireless...

Wireless Sensor Networks

Fourth European conference, EWSN 2007Delft, The Netherlands, 29-31 January 2007

Adjunct poster/demo proceedings

Koen Langendoen and Thiemo Voigt (Eds.)

PDS

Parallel and Distributed Systems Report Series

report number PDS-2007-001

ISSN 1387-2109

Published and produced by:Parallel and Distributed Systems SectionFaculty of Electrical Engineering, Mathematics and Computer ScienceDelft University of TechnologyMekelweg 42628 CD DelftThe Netherlands

Information about the Parallel and Distributed Systems Report Series:[email protected]

Information about the Parallel and Distributed Systems Section:http://www.pds.ewi.tudelft.nl/

Preface

This technical report contains the adjunct poster/demo proceedings of EWSN 2007, the fourth Europeanconference on Wireless Sensor Networks, which took place at TU Delft from January 29 to 31, 2007.Its objective was to provide a forum where researchers with different experience and background, fromhardware to applications, would present and discuss the latest developments in the exciting field of wirelesssensor networks.

The poster and demo abstracts contained in this report provide a nice cross section of the Europeanactivities and state-of-affairs in wireless sensor networks, both from a theoretical and practical perspective.The discussions with their presenters made for an enjoyable reception at the conference.

January 2007 Koen Langendoen and Thiemo VoigtProgram Chairs

Table of Contents

Poster Abstracts

Residual Energy Measurement based on Bloom Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Y. Li and W. Cai

Collaborative Data Processing for Forest Fire Fighting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3E. M. Garcıa, A. Bermudez, R. Casado, and F. J. Quiles

A Utility Based Sensing and Communication Protocol for Sensor Networks . . . . . . . . . . . . . . . . . . . 5P. Padhy, R. K. Dash, K. Martinez, and N. R. Jennings

A low power reliable sensor network for glacier deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7K. Martinez, A. Elsaify, G. Zou, P. Padhy, and J. K. Hart

BusNet - A Sensor Network Built Over a Public Transport System . . . . . . . . . . . . . . . . . . . . . . . . . . 9K. De Zoysa and C. Keppitiyagama

Towards component reuse in MAC protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11T. Parker, M. Bezemer, and K. Langendoen

A Wireless Magneto-resistive Sensor Network for Real-Time Vehicle Detection . . . . . . . . . . . . . . . . 13A. Bemporad, F. Gentile, A. Mecocci, F. Molendi, and F. Rossi

A Global Resource Management Model (GRMM) for Wireless Sensor/Actuator Network . . . . . . . . 15S. F. Pileggi, C. E. Palau, and M. Esteve

Proposal of a Secure Routing Algorithm for Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . 17E. de Mattos Kalinowski, L. Nacamura Jr., and R. Demo Souza

Simulation Framework for Power Aware Wireless Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19J. Glaser and D. Weber

Modular Architecture for Heterogeneous Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21B. Latre, E. De Poorter, I. Moerman, and P. Demeester

Self-Configuration Middleware for Sensor Localization in a Realistic Business Context . . . . . . . . . . 23N. Matthys, S. Michiels, B. Elen, W. Joosen, and P. Verbaeten

Meeting the Evolving Reliability Requirements for WSN Applications . . . . . . . . . . . . . . . . . . . . . . . 25F. K. Shaikh, A. Khelil, and N. Suri

Radio Design for Ultra Low-Power and Ultra-Wideband Wireless Sensor Nodes . . . . . . . . . . . . . . . 27T. Fu, G. Dolmans, O. Rousseaux, L. Huang, B. Gyselinckx, J. Ryckaert,S. D’Amico, and A. Baschirotto

Rime: A Lightweight Layered Communication Stack for Sensor Networks . . . . . . . . . . . . . . . . . . . . 29A. Dunkels

A Co-Simulation Framework for Performance Comparison of Wireless Sensor Networks . . . . . . . . . 31A. Klein

A Multihop Path Wakeup Mechanism For Dual-Radio Sensor Networks . . . . . . . . . . . . . . . . . . . . . . 33T. Stathopoulos, M. Lukac, D. McIntire, J. Heidemann, D. Estrin, and W. J. Kaiser

Influence of Energy Models on Sensor Network Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35B. Emmert

Castalia: the Difference of Accurate Simulation in WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37D. Pediaditakis, S. H. Mohajerani, and A. Boulis

An OO Approach to Sensor Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39T. Riedel, A. Arnold, and C. Decker

MSPsim an Extensible Simulator for MSP430-equipped Sensor Boards . . . . . . . . . . . . . . . . . . . . . . 41J. Eriksson, A. Dunkels, N. Finne, F. Osterlind, and T. Voigt

IntellBuilding: A Wireless Sensor Network for Intelligent Buildings . . . . . . . . . . . . . . . . . . . . . . . . . 43T. Olivares, P. J. Tirado, F. Royo, J. C. Castillo, and L. Orozco-Barbosa

Demo Abstracts

Passive Inspection of Deployed Sensor Networks with SNIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45M. Ringwald, M. Cortesi, K. Romer, and A. Vitaletti

Development and Test with the Deployment-Support Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47J. Beutel, M. Dyer, M. Yucel, and L. Thiele

Bytecode and Virtual Machine for Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49R. Mueller, M. Duller, G. Alonso, and D. Kossmann

RETOS-based Distributed Acoustic Source Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51J. Yoo, Y. You, H. Kim, S. Choi, and H. Cha

SensorScope: An Urban Environmental Monitoring Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53G. Barrenetxea, M. Bystranowski, O. Couach, H. Dubois-Ferriere, S. Dufey, M. Krichane,J. Mezzo, S. Mortier, M. Parlange, G. Schaefer, J. Selker, T. Varidel, and M. Vetterli

Cross-level Simulation in COOJA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55F. Osterlind, A. Dunkels, J. Eriksson, N. Finne, and T. Voigt

GSN: Quick and Simple Sensor Network Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57A. Salehi and K. Aberer

Spatial sensing to support interaction across devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59R. Gostner and H. Gellersen

TinyOS on Mindstorms NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61R. Pedersen

Poster Abstract: Residual Energy Measurementbased on Bloom Filter

Yongjun Li and Wandong CaiSchool of Computer Science

Northwestern Polytechnical UniversityXi'an 710072, China

Email: [email protected]

Abstract�It is important to have continuously updated in-formation about sensor network resources after it is deployedin an unpredictable environment. Such macroscopic informationof resources in large sensor networks can provide users earlywarning of system failure, aid in incremental deployment ofsensors. However, due to limited energy and resources, it isimpractical to collect the such detailed information from eachindividual sensor node. In this paper, we present brie�y a residualenergy measurement algorithm that approximately depicts thenodes distribution whose residual energy level belows a givenvalue within a sensor network. In the future work, we willevaluate its performance and its scalability using simulation.

I. INTRODUCTIONWireless sensor networks have been attracting increasing

research interest in recent years. A sensor network usuallyconsists of a large collection of small wireless, unattendedsensors which are deployed randomly in the monitored en-vironment. As described in [1], due to their unattended andtheir complexity, it is critical that the users can continuouslymonitor the sensor network health, i.e. explicit knowledge ofthe overall state of the sensor network after deployment. Suchmacroscopic view of resources or activities in large sensornetworks can provide users early warning of system failure,aid in incremental deployment of sensors.The monitoring system should introduce minimal impact

on network lifetime, scale with network size, yet preserve the�delity of the overall picture. We propose a residual energymeasurement algorithm to construct the residual energy viewof sensor networks by applying Bloom �lter (detail aboutBloom �lter can be found in [2]). Rather than fuse localmeasurements piecewise on their way towards a collectingpoint, this approach collects sensor identi�cation informationfrom each individual sensor node whose residual energy levelsatis�es the user's interest. After the collection is �nished, wecan obtain the distribution of the sensors whose residual energylevel belows the user's expected quantity. This algorithm willnot loss the detailed information at each individual node andcan reduce the communication overhead signi�cantly.

II. RELATED WORKThere is a little research that has attempted continuous

monitoring of large-scale distributed sensor networks. JerryZhao et al [2] proposed sensor network topography to con-struct abstracted scans of sensor network health by applying

localized algorithms in sensor network for energy-ef�cient in-network aggregation of local representations of scans. Ratherthan collect detailed state information from each individualsensor node and then process centrally, this technique buildsa composite san by combining local scans piecewise ontheir way towards the sink node. Simulations show that theirapproach has good scalability and energy-ef�ciency character-istics, compared to continuously extracting the residual energylevel individually from each node. Meng Xiaoqiao et al [3]proposed an ef�cient data-collection scheme that can be usedfor event monitoring or network-wide diagnosis. Their schemerelies on the well-known representation of data-contour maps,which trade off accuracy with the amount of samples. Theyused three novel algorithms to build contour maps: distributedspatial and temporal data suppression, contour reconstructionat the sink via interpolation and smoothing, and an ef�cientmechanism to convey routing information over multiple hops.By reducing the number of transmissions, this scheme canimprove network lifetime.

III. SYSTEM MODELAs described in [2][3], we consider a network of �xed

sensor nodes that are deployed in a two- or three-dimensionalspace. A set of monitoring nodes, de�ned as sinks, areresponsible for collecting data reports form sensor nodes. Wedo not assume any speci�c routing or MAC protocol in sensornetwork. Without loss of generality, we also assume each nodehas a unique global ID and knows its location by localizationsystem such as GPS.Assume each sensor node is powered by batteries with nor-

malized capacity of 100% and most sensors expect sinks havelimited energy and resources. The inter-node communicationconsumes more energy that computation. Assume the residualenergy level can be measured by interface similar to APM orACPI.

IV. RESIDUAL ENERGY MEASUREMENTSpeci�cally, we design a residual energy measurement algo-

rithm that approximately depicts the nodes distribution whoseresidual energy level belows a given value within a sensornetwork. Assume each node measures the residual energylevel periodically. Before the nodes are deployed into the realenvironment, the deployer creates a number of hash functions

PDS-2007-001 1 EWSN 2007 adjunct proceedings

used by Bloom �lter and implements these hash functionswithin every node.A user may express a special INTEREST message (e.g.

whose residual energy level belows 30%.) for a residual energymeasurement. This message propagates throughout the sensornetwork by �ooding. Once a node receives this message andits residual energy level satis�es this INTEREST message, itwill overhear the shared medium and waits the report fromits neighboring nodes. If a node does not receives the reportfrom its neighboring nodes until a speci�ed period of timehas elapsed, the node allocates a bit array to be used as aBloom �lter. The bit array is initialized to zero. After a nodereceives or creates the report, the node uses the created hashfunction to hash its node ID into some bit of the bit array.These corresponding bits are set to one. The node then sendsthis report along the path to the sink node. Eventually, whenthe sink receives the report, the sink can apply the sameset of hash function to each node ID. If all the bits in theindices of the hash values are one, the sink infers that theresidual energy level of this node very likely satis�ed the user'sINTEREST. Using this approach on each node, we can obtainthe distribution of sensors whose residual energy level verylikely belows the user's given value.The energy report can be queried periodically by the sink

from all the sensors in the network or it can be triggeredwhen energy levels fall below certain thresholds such as 20%or 30% above Emin (the minimium energy that keep sensoralive) [3]. This report can be identi�ed by its own ID. Oncea node receives this message and its residual energy level fallbelow the given threholds, it hash its ID into the report. Eachnode that receives this report will forward this report alongthe path to the sink node. Eventually, when the sink receivesthis report, the sink can apply the same approach as describedabove to obtain the information of sensors whose residualenergy level fall below the given threholds. This informationallows dynamic recon�guration of the network fro optimalperformance.This algorithm can be extanded to scan the residual energy

level overall the sensor network. To some extent, we add theresidual energy level quantity into the report. When a nodereceives the user's INTEREST message, it will overhear theshared medium. If the received report has similar residualenergy level with it, it will hash its ID into the report.Otherwise, it just forward this report along the path to thesink node. If it receives two or more reports and these havesame or similar residual energy level, it will aggregate thesereports into one report which contains a bit array that describesall the nodes, and the residual energy level at those nodes. Wecan use operator OR at the bit array to aggregate the bit array(i.e. Xi = Xi

1 _ Xi2 ). Once the sink �nishes the collection,

we can determine the residual energy level of each node.As the above description, we have the following algorithm

for the residual energy level measurement overall the sensornetwork. Suppose the the residual energy level of the reportr is Er, the ID of sensor node i is Ii, and its residual energylevel is Ei.

1) The user �oods the residual energy level message intothe sensor network.

2) All the sensor nodes received this message measure itsresidual energy level and overhear the shared medium.

3) For each node within the sensor networka) If the node i receives report from its neighboringnodes within the speci�ed period of time theni) If receives more than two reports and thesereport have similar residual energy level thenA) Aggregates these report into one report.

ii) If Ei is simailar with Er thenA) The node i hashes Ii into the report r.

b) If the node i does not receive one report from itsneighboring nodes within the speci�ed period oftime theni) The node i creates one report.ii) Allocates a bit array to be used as a Bloom�lter, and initializes all the bits to zero.

iii) Er = Ei:iv) The node i hashes its ID Ii into the report.

c) Forwards this report along the path to the sinknode.

4) Once the sink node receives all the report. its uses thethe same hash functions to hash Ii into some bits. if thecorresponding bits of report r is one then the residualenergy level of node i is Er.

5) Use the method as described in step 6 on each nodewithin the sensor network and then we can determinethe residual energy level of each node.

We can use the similiar algorithm to obtain the distributionof sensors whose residual energy level very likely belows theuser's given value.

V. FUTURE WORK

We will evalute the performance of our algorithm usingsimualtion. It is known well enough that Bloom �lter bringserrors because of false positive (a node whose residual energydoes not below a given value is inferred to below this givenvalue). How to choose the parameters of the Bloom �lter suchas the size of bit array and the number of hash functions. Theseparameters can make us to eliminate all false positive errorswith high probability. On the other hand, we will compare ouralgorithm with the eScan. Can our scheme provide signi�cantenergy savings while not lossing the detailed information?We will also extend this algorithm to monitor others networkcharacteristics such as link loss.

REFERENCES[1] J.Zhao, R.Govindan, D.Estrin. Sensor Network Tomography: Monitoring

Wireless Sensor Networks. Computer Communication Review. 32(1)(2002) 64-64

[2] B.Bloom. Space/time trade-offs in hash coding with allowable errors.Communication of ACM. 13(7) (1970) 422-426.

[3] Meng Xiaoqiao, Nandagopal Thyaga, Li Li, Lu Songwu. Contour maps:Monitoring and diagnosis in sensor networks. Computer Networks, 50(15)(2006) 2820-2838


Abstract—In this work, we propose a distributed system to

provide to the firefighters with critical information in real time, in order to increment their safety and efficacy. The main element of the system is a wireless sensor network deployed over the field. Sensors obtain environmental information and collaborate among them to determine the current behavior of the fire fronts. Firefighters receive this information in a handheld device wire-lessly connected to the sensor network.

Index Terms—Environmental monitoring, localization algo-rithms, collaborative information processing, mobile devices, MicaZ, TinyOS.

I. INTRODUCTION he people involved in the extinction of forest fires is fre-quently exposed to many hazardous conditions due to the

lack of critical information, such as field topography, fire evo-lution, and location of human and material resources and safe-ty zones.

In the literature we can find several works which propose using a wireless sensor network (WSN) in forest fire fighting. In some cases, the only purpose of the network consists in acquiring environmental data. Then, these data are gathered and displayed in a base station, stored in a database, and/or sent to a remote location [1, 2]. Fig. 1 represents conceptually this behavior. Other cases, the WSN itself contains some intel-ligence to process the data obtained before sending them to the base station. Usually, the objective is to delimitate the fire perimeter [4].

Until our knowledge, previous works assume the existence of a central server that gathers the fire behavior and, occasion-ally, redistributes it to the firefighters by means of a different communication technology (GSM/GPRS, WiFi,…).

In this work we present EIDOS (EquIpment Destined for Orientation and Security). Its main contribution is that the network incorporates the fire model, which is built from the

The authors are with the Computing Systems Department, Research Insti-

tute of Informatics at Albacete, University of Castilla-La Mancha, 02071 Albacete, Spain. E-mail: {evamaria.garcia, aurelio.bermudez, rafael.casado, francisco.quiles}@uclm.es.

This work was partly supported by the following projects: CSD2006-46 and TIN2006-15516-C04-02 (Ministerio de Educación y Ciencia), PBC05-007-1 (Junta de Comunidades de Castilla-La Mancha), and PCTC0622 (Uni-versidad de Castilla-La Mancha).

geographical information of the area (topography, combusti-ble,…) and the data sensed by network nodes (temperature, humidity, wind direction and speed,…). Moreover, this model is directly sent to the firefighters, who carry handheld devices running a lightweight browser application. Fig. 2 shows this behavior.

The rest of this document is organized as follows. Section II presents the elements making up the EIDOS system, and the way they interact. After that, Section III outlines the method-ology that we plan to apply to develop this proposal.

II. SYSTEM DESCRIPTION Fig. 3 shows the architecture of EIDOS system. The main

component of the system is a network composed of thousands of sensor nodes, deployed in the field by means of an UAV (Unmanned Aerial Vehicle). Each sensor is an electronic de-vice with wireless communication capability, encapsulated into a fireproof packaging.

Other key element in the system is the handheld device that the firefighters carry. It incorporates a lightweight GIS (Geo-graphical Information System) engine to display the data proc-

Poster Abstract: Collaborative Data Processing for Forest Fire Fighting

E. M. García, A. Bermúdez, R. Casado, and F. J. Quiles

T

Fig. 1. Traditional proposals. The WSN captures physical data. This infor-mation is the input for a fire model at a local (or remote) server.

Fig. 2. EIDOS protocol stack. The WSN incorporates the fire model, proc-esses physical data and delivers the result to the mobile devices carried by the firefighters.


essed by the sensor nodes –as firefighter locations and fire behavior– over a map of the terrain. Additionally, the hand-held device allows the firefighter to interact with the com-mand, by sending reports and receiving instructions.

Besides the above elements, the system could optionally in-clude a base station. It could be a laptop located in the com-mand vehicle, wirelessly connected to the sensor network. This server can graphically show the data collected from the sensors, and run a more complex fire simulation [6], in order to predict the future behavior of the forest fire. All this infor-mation may be used by the command to decide the best strat-egy against the fire.

The position of each element in the system (sensor nodes and firefighters) must be known at any given time. With this aim, some of the sensor nodes –and possibly the UAV– are equipped with a GPS receiver. Then, the rest of nodes can calculate their exact position, by means of some ranging-based localization algorithm. A very simple approach is the Bound-ing Box algorithm [8].

Sensor nodes monitor their environment, by periodically measuring physical magnitudes, such as temperature and hu-midity. This information is shared with the rest of nodes in the network. Before transmit them, data can be filtered and/or compressed. In this way, the amount of necessary packets can be reduced –and consequently the energy consumption. Other techniques to extend network lifetime can be applied, as for example leaving to a sleep state some sensors when they are too close to others.

Finally, a collaborative algorithm processes all this physical information, in order to determine the current location and direction of the fire fronts. To do that, we plan to consider a widely accepted fire model, as [5]. The result of this distrib-uted algorithm is sent to the firefighters’ handheld devices and the base station.

III. METHODOLOGY First, we plan to implement, analyze, and tune our propos-

als in a simulation environment. Then, we will develop a more realistic prototype, by using standard network devices. Fi-

nally, the prototype will evolve to a real system, in which all the hardware components will be designed specifically for the forest fire environment.

To simulate the wireless sensor network we are going to use TOSSIM [7], due to its ability to simulate TinyOS applica-tions. TinyOS is a popular open source operating system for sensor nodes, developed by the University of California at Berkeley. The advantage of using TOSSIM is that, once the TinyOS code has been debugged, it can be directly down-loaded to the sensor memory. We plan to adapt this tool to our scenario, by developing a customized GUI (Graphical User Interface), which will allow us to dynamically interact with the simulation.

Apart from the network simulator, we are going to make use of a specialized fire simulator [6], with the purpose of testing the behavior of our collaborative processing algorithm. In particular, TOSSIM will provide the location of the simu-lated sensors to the fire simulator, and the fire simulator will periodically give to TOSSIM the physical parameters (tem-perature and humidity) corresponding to each location. In this way, we will be capable of comparing the outputs of both si-mulators.

In the experimental deployment, we plan to use the Cross-bow MicaZ mote [3]. It is a Zigbee compatible model, incor-porating an Atmel Atmega128 microcontroller and a Chipcon CC2420 radio. As handheld device, we plan to use a standard PDA (personal digital assistant), equipped with Microsoft Windows Mobile or similar, and running a friendly Flash in-terface. Both the PDA and the base station will be integrated in the network by means of Zigbee adapters.

For the final system, we have to take into account that commodity-of-the-self sensors have not been designed for this extreme environment. So, final sensors must be designed and made to support high temperatures. They also need a fireproof and drop-resistant packaging.

REFERENCES [1] D. M. Doolin and N. Sitar, “Wireless sensors for wildfire monitoring,”

SPIE Symposium on Smart Structures & Materials/NDE 2005, San Di-ego, California, March 2005.

[2] Y. Li, Z. Wang, and Y. Song, “Wireless sensors network design for wildfire monitoring,” 6th IEEE World Congress on Intelligent Control and Automation, June 2006.

[3] Crossbow Technology, Inc., www.xbow.com. [4] C.-L. Fok, G.-C. Roman, and C. Lu. “Mobile Agent Middleware for

Sensor Networks: An Application Case Study,” 4th International Con-ference on Information Processing in Sensor Networks (IPSN'05), Los Angeles, California, April 2005.

[5] G. Pruessner and H. J. Jensen, “A new, efficient algorithm for the Forest Fire Model,” Physical Review E 70 066707, 2004.

[6] SEM (Systems for Environmental Management) corporation, www.fire.org.

[7] TinyOS, www.tinyos.net. [8] K. Whitehouse and D. Culler, “A Robustness Analysis of Multihop

Ranging-based Localization Approximations,” 5th International Confer-ence on Information Processing in Sensor Networks, Nashville, TN, April 2006.

Fig. 3. EIDOS system architecture.


Poster Abstract: A Utility Based Sensing andCommunication Protocol for Sensor Networks

Paritosh Padhy, Rajdeep K. Dash, Kirk Martinez, Nicholas R.JenningsSchool of Electronics and Computer Science

University of SouthamptonSouthampton, SO17 1BJ, United Kingdom{pp04r, rkd, km, nrj}@ecs.soton.ac.uk

I. I NTRODUCTION

Multi-sensor networks are being deployed in a wide varietyof application areas and, in particular, they have recentlybeenadvocated for a number of environmental monitoring appli-cations [2]. Moreover, there is an increasing interest in con-trolling these networks using multi-agent system techniques[1]. In this vein, we consider a particular sensor network,GLACSWEB [2], that we have deployed in the Brikdalsbreenglacier in Norway, and examine how it can be modelled as a(cooperative) multi-agent system. In this case, the two maintasks performed by the nodes (agents) are gathering data fromthe environment and communicating it towards a central sinknode (i.e. an agent that harvests data from all other agents). Ingeneral, the agents work towards the predefined system goalof maximising data collection (hence the cooperative natureof the system). However, they are invariably constrained intheir available power directly influencing the life-span oftheagents and, hence, that of the system as a whole. Given this, wefocus on developing a communication and a sensing protocolfor this network. Nevertheless, the solution we develop isalso more broadly applicable to networks that have any formof limited power supply. In more detail, the purpose ofthe GLACSWEB multi-sensor network is to monitor sub-glacial behaviour in order to understand climatic change. Thesystem’s communication protocol is infrastructure based andmore energy savings can be made by adopting a multi-hopapproach. Currently, the sensing in GLACSWEB is carried outat a constant rate which does not adapt to actual variationsin the environment. This decoupling results in unnecessarysampling because, given the same energy expenditure, theinformation gained by sensing a slowly varying environmentis less than what could be gained in a more dynamic situation.Against this background, the paper [3] develops a Utility-based Sensing and Communication protocol (called USAC).The focus of our work is on cooperative agents (since all nodesare owned by one stakeholder, the University of Southampton)and differs from existing research by combining both sensingand communication via a utility function. In doing so, weadvance the state of the art by developing a new adaptivesampling mechanism and devising a new cheapest cost routingprotocol that incorporates the opportunity cost of the energyspent relaying the data (i.e. the value that a node could have

gained by using the energy in sensing instead of relaying).

II. SENSING PROTOCOL

We develop a novel mechanism for adaptive sampling. Inthis, each agent adjusts its sampling rate depending on therate of change of the environment and a valuation function(based on a sound information theoretic foundation) that theagents use for assigning a value to the data they observe. Anoptimal sampling rate can only be derived if the agent hasknowledge about the future data. However, this requirementiscontradictory since in the case that the agent knows the futuredata, it does not need to sense the environment. As a result,an agent can only find an optimal sampling rate based on itsforecast of the future data. Then, upon observing previouslyforecasted data, the agent gains information by reducing itsuncertainty about this data to zero. Here the representation weuse for the uncertainty of the data is the confidence intervalofa predicted data point. Specifically, the x% confidence intervalof a data point is a range of values centred around the mean ofthe forecast within which x% of the data is guaranteed to fall.For example, a 100% confidence interval is the range of valuesthe data can only ever take, whereas a 10% confidence intervalimplies that only 10% of the forecasted data is guaranteed tofall in this interval. From this, it can be seen that a lowerconfidence interval is more useful since its range is smaller.Therefore, a good forecast is one that minimises the confidenceinterval. The forecasting method we use here is based ona limited window linear regression model. This is becauseit provides a good forecasting model for data that can becharacterised as piecewise-linear functions of time with addedGaussian noise (which is the case for data collected in theGLACSWEB environment). Given this, we then calculate thevalue of a data point as

V (data(ts)) =| ci(ts−1) − ci(ts) | (1)

whereci(ts−1) is the confidence interval before the data wassampled at timets and ci(ts) is the confidence interval attime ts calculated usingdata(ts). The core concept behind theadaptive sampling protocol is reflected in the reasoning that ifat timets the observed data falls outside the confidence inter-val, then the agent should set its sampling rate to maximum(fmax). This is because if the data falls outside the intervalthen the agent believes that there has been a unpredictable


change in the environment. Hence it starts sampling at themost frequent rate in order to better incorporate this phasechange in its forecasting model. However, if data falls withinthe confidence interval, it implies that the agent already hasa good regression model. Hence, it can gradually reduce itssampling until a lower boundfmin is reached.

III. C OMMUNICATION PROTOCOL

We devise a new routing protocol that finds the cheapestcost route from an agent to the centre. Here, the cost of a linkfrom one agent to another is derived using the opportunitycost of the energy spent relaying the data (i.e. the value that arelay could have gained by using the energy in sensing insteadof relaying).The network is modelled as a multi-agent system consistingof a number of agents,I = {1, . . . , n}, that each haveKdifferent discrete power levels,{pt1i , . . . , ptKi }, (with ptk+1

i >

ptki ) at which they can transmit. At each level, there is a setof neighboursni(ptki ) ⊆ I to which agenti can transmit data.Due to the nature of radio transmission,ni(ptki ) ⊆ ni(ptk+1

i ).Thus, the direct communication of data from any agenti

to another agentj, where j ∈ ni(ptki ) consumes a certainamount of energyEt

ji which is given by:

Etji (data) = ptk∗i × t

ji (data)

where ptk∗i is the lowest power level at whichj ∈ ni(ptki )and t

ji (data) is the amount of time a data packet takes to

transmit. Now, in this scenario the size of each sensed datapacket and the bandwidth available to each agent is the same,so t

ji (data) is constant for all agents and sensed data packets.

Therefore, by slight abuse of notation, we shall hereafter referto Et

ji (data) asEt

ji .

The cost of communication of an agenti to another agentj is then the opportunity cost of that decision. Now, thereare two particular scenarios to consider when communicatingdata. If, on one hand, an agent is originating the data, then itscost of communication is given by:

cji (originate) =

Etji

Etji + Esense

i

× vsensei (tn) (2)

whereEsensei is the energy spent byi in sensing new data and

vsensei (tn) is the value of the new data. On the other hand, if

an agent is relaying data, then its cost of transmission is givenby:

cji (relay) =

Etji + Ereceive

i

Etji + Esense

i

× vsensei (tn) (3)

whereEreceivei is the energy spent by the agent receiving the

data which it then relays.Now, since it is not possible to assignvsense

i (tn) beforeactually carrying out the observation, we need to estimateit. Due to the nature of the data (where sudden changes arepossible) we estimatevsense

i (tn) using a moving average withwindow sizew. Thus at timetn the estimated value of thedata is given by:

visense(tn) =

1

min(n, w)

n−1∑

i=max(n−w,0)

vsensei (ti)

We choose such a forecasting method since it evens out thechanges in value that random noise can introduce, whilst at thesame time updating the value of the data fairly quickly as timeprogresses. However, it should be noted that this forecastingmethod (or for that matter any forecasting method) cannotguarantee to correctly predict the value of the data all thetime. Also, the moving average only starts once the numberof samples collected by the sensor> w. Up to that point, theestimated value is just an average.

Having calculated the cost of communication, the decisionprocess of the node involves only transmitting that data who’svalue is worth more than the cost of communication. If the datais valued less than the cost of communication, it is deemedunimportant and disposed.

IV. EMPIRICAL EVALUATION

We empirically evaluated the USAC protocol against thecurrent GLACSWEB protocol by examining the impact onefficiency of the network topology, the size of the network, andthe degree of dynamism of the environment. In so doing, wedemonstrated that the efficiency (value of the data gained overthe energy consumed) gain of our new protocol, over the cur-rently implemented method over a 6 month period, are 470%,250% and 300% respectively. The protocol also demonstratedrobustness in the face of node failure and openness (nodescould leave and enter the network) of the system.

V. CONCLUSION

The protocol we have developed in this paper allows nodesto act in a decentralised (based on the nature of their localenvironment) manner, while self-organising to form a networkwhose performance is high in terms of minimising energy con-sumption and maximising the value of data gained. It makesuse of the localisation ability of individual agents to determinethe cheapest cost path to the sink and incorporates the valueofthe observed data to calculate the cheapest path. We have alsoshown that our protocol is superior to the currently deployedGLACSWEB protocol, even when the distribution of agentsaround the sink and the nature of observed environment isvaried.

REFERENCES

[1] V. Lesser, C. Ortiz and M. Tambe, editors.Distributed sensor networks:a multiagent perspective. Kluwer Publishing, 2003.

[2] K. Martinez, J.K. Hart and R. Ong.Environmental sensor networks.Computer, 37(8):5056, 2004.

[3] P. Padhy, R.K. Dash, K. Martinez and N.R. Jennings.A utility-basedsensing and communication model for a glacial sensor network. In Proc.5th Int. Conf. on Autonomous Agents and Multi-Agent Systems (AAMAS06), 2006.


Poster Abstract: A low power reliable sensor network for glacier deployments Kirk Martinez1, Ahmed Elsaify1, Gang Zou1, Paritosh Padhy1, Jane K. Hart2

1Electronics and Computer Science, {km,ae,gz,pp04r]@ecs.soton.ac.uk 2School of Geography, [email protected]

University of Southampton, UK.

I. INTRODUCTION The Glacsweb project [1] has provided an extreme

environment in which to design sensor networks. Sensor nodes (probes) have been deployed inside and underneath a glacier in Norway. An ARM-based Linux system is based on top of the glacier and acts as the base station, controlling the system, taking weather station and differential GPS readings. The earliest deployments involved tackling physical problems such as size, waterproofing, radio losses and reliability. The previous systems used a simple star network and proved capable of producing continuous data for over a year. Although the hardware and software was extremely tuned to a lossy and non-real time environment many lessons were learnt about the design of such a system. Although the star-network was predictable and easy to debug it meant that probes moving too far from the base station were lost. An ad-hoc network which allowed inter-probe communications was clearly needed and it was felt that like the rest of the system, this should also be designed from the ground up to meet the requirements of the environment. This was typically characterised by periods of extremely high radio loss when there was melt water in the glacier (spring to autumn) and periods with zero packet loss in the winter for example. The system can deliver data at a later date if there were communication problems, which is a useful requirement.

The data is used by glaciologists [2] to study sub-glacial dynamics as well as glacier response to climate change. Tilt and orientation of the probes helps the study of how rocks move under the glacier. Case stress is used to indicate compression and external conductivity showed how wet the material was.

II. PROBE DESIGN The new probe design (shown in figures 1 and 2) is based

on the PIC18 microcontroller. This has more features to improve functionality, performance and reduce size. Its 128Kbyte flash memory replaces the external EEPROM in the old design. The microcontroller was run at 40MHz so it could do all jobs including driving the transceiver. An accurate (±2ppm) external RTC is used for synchronisation at wake up and during network activity. The probe runs in 5 different modes: sleep (1 µA), sensor reading (60mA), RF transmitting (102mA), RF receiving (30mA) and idle (21mA). During sleep mode all circuits are powered off apart from the RTC which is in sleep mode. When the system wakes up only the power circuit, power switches, RTC and PIC are powered in idle mode. Three AA-size Lithium batteries provide sufficient power (7.2AH) for many years. The single PCB has the same dimensions as the three AA batteries, to reduce size. The radio PCB contained the transceiver module, matching circuit and antenna.

Fig. 1. Probe hardware

Fig 2. Schematic of the probe hardware.


III. RADIO AND COMMUNICATION: Previous experience showed that higher radio frequencies

typically used in sensor networks (433-900 MHz) suffer more attenuation in ice. To increase range, the RF frequency was switched from 433MHz to 173MHz. A 100mW transceiver module from Radiometrix (BiM1) was chosen. A custom antenna was tuned on the glacier and field tests confirmed the range improvements. RSSI is captured for every packet received by any probe during network configuration to generate data for probe localization which is currently under development.

IV. NETWORKING Wireless sensor networks benefit from communication

protocols that reduce power consumption by avoiding collisions, idle listening and overhearing. Time Division Multiple Access (TDMA) protocols avoid collisions by allotting time slots for communication [3, 4]. TDMA provides deterministic guarantees about message communication and hence, it is useful for reliable sensor networks. For these reasons a TDMA protocol was chosen and customized for Glacsweb. The protocol was inspired by Randomized and deterministic TDMA protocols such as [5, 6]. The protocol combines TDMA with an optimised directional flooding technique to broadcast messages. This combination overcomes problems with message overload and collisions.

The protocols are more power efficient since nodes can enter inactive states until their allocated time slots. The protocol is dynamic and time slots are reassigned to improve performance. The physical layer of the network was designed around the transceiver. A custom packet is used over a 5kbit/s data link which is Manchester encoded. The payload is up to 64 bytes (102.4ms) in order to allow a complete data group to fit into one packet while being small enough to reduce errors. TDMA time slots were 130ms long to allow for preamble and safety margins. The number of time slots can be reconfigured at network setup and is normally set to 35, allowing up to 31 nodes to be added easily. The base station is directly linked to 4 wired probes, and uses them to communicate to the rest of the network. The first 4 TDMA slots were allocated to these 4 top nodes.

An accurate time synchronisation algorithm was used at start up and each time a command message is received. At wake up the protocol assumes there is no time synchronisation. The base station sets itself to a “best” time found in the top nodes and broadcasts it to the rest of the network with every message sent. Probes use the millisecond timer in the packet when the diffusion was initiated and the time that the diffusion took to reach that node.

Network discovery uses a flooding algorithm to ensure full network coverage during discovery. The first message sent by the base station is “direct echo” to discover nodes which can communicate with top nodes. The second message “spread echo” is sent to discover all the nodes that can not talk directly to the top nodes and require multi hoping. Each node receiving this will rebroadcast it N times (a message parameter). This flooding technique ensures the second message is sent to the entire network. The third

discovery message “spread echo reply” asks all the nodes in the entire network to send their lists of received ID and RSSI. The base station then chooses a network configuration based on RSSI which lets nodes route for their “nearest” child-nodes.

The next Network Setup phase uses optimised directional flooding by reconfiguring slot assignments and routes as well as assigning reply frames for uplinks. This new directional flooding configuration is then used for all downlink and uplink messages. These Network explore and setup phases are not executed every time the system wakes up or asks for data, it only runs when required due to an increase in lost nodes or the need to refresh and optimise the network.

To start data acquisition the base station sends “SendData” and in response each node sends its data. To avoid energy and time consuming acknowledgements, packet failures are detected by the base station tracking the data sent by each probe. After the data gathering period it can request missing packets from any nodes it needs to. The nodes go to sleep when the sleep command is sent or a timeout occurs.

V. CONCLUSION When designing sensor networks for real deployments, it

is important to consider the energy constrains, host environment, communication reliability and user needs. The design of this system has evolved through iterations of deployments in the field, taking into account all these factors. Reducing the radio frequency and tuning the antenna, improves reliability. Using a TDMA protocol with time synchronisation insures collision free communication and reduces idle listening and overhearing. When the TDMA is combined with an optimised ad-hoc flooding algorithm for messages and data diffusion, the network power efficiency increased and the risk of data loss due to weak communications and probe movement was reduced.

ACKNOWLEDGMENT The Glacsweb project is funded by the EPSRC UK. We

also thank the following for their excellent contributions: Alistair Riddoch, Kathryn Rose, Mark Long and Ken Frampton.

REFERENCES [1] K. Martinez, J. K. Hart and R. Ong. “Environmental Sensor

Networks”, IEEE Computer, Vol 37, No. 8, pp. 50-56. 2004. [2] J. K. Hart, K. Martinez, R. Ong, A. Riddoch, K. C. Rose, and P.

Padhy, “An autonomous multi-sensor subglacial probe: Design and preliminary results from Briksdalsbreen, Norway”. Journal of Glaciology, Vol. 52, No. 178, pp. 389–397, 2006.

[3] S. S. Kulkarni, U. Arumugam. “Collision-free communication in sensor networks”. In Proceedings of Self-Stabilizing Systems, 6th International Symposium, Springer LNCS 2704, pp. 17-31., 2003.

[4] S. S. Kulkarni, U. Arumugam: TDMA Service for Sensor Networks”. ICDCS Workshops 2004: 604-609.

[5] W. B. Heinzelman, A. P. Chandrakasan, and H. Balakrishnan. “An application-specific protocol architecture for wireless microsensor networks”, IEEE Transactions on Wireless Communications, vol. 1, No. 4, pp.660–670, October 2002.

[6] K. Arisha, M.Youssef, and M.Younis. Energy-aware TDMA-based MAC for sensor networks. In Proceedings of the IEEE Workshop on Integrated Management of Power Aware Communications, Computing and Networking (IMPACCT), May 2002.


http://eprints.ecs.soton.ac.uk/9997/

http://eprints.ecs.soton.ac.uk/9997/

http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/a/Arumugam:Umamaheswaran.html

Poster Abstract:BusNet – A Sensor Network Built Over a Public

Transport SystemKasun De Zoysa and Chamath Keppitiyagama

University of Colombo School of ComputingColombo 07, Sri Lanka

[email protected], [email protected]

Abstract— BusNet is a sensor network to be built on a publictransport system to monitor environmental pollution. BusNetuses only a few sensors mounted on public transport busesto gather data on air pollution levels in a large geographicalarea in contrast to a large number of sensors required in aconventional sensor network deployed for such a purpose. Thepublic transport network also acts as the communication networkin BusNet. Because only a few sensors are needed for the BusNetit is less costly to build and easy to manage. Even though wepresent BusNet with respect to one particular application theidea is generic enough to be used in other systems in which alarge number of sensors can be replaced by a few moving sensorsmounted on public transport vehicles.

I. MOTIVATION

There are certain monitoring systems that require a largenumber of sensors spread over a large terrain to gather data.Environmental monitoring systems are examples of such asystem. Citing a study by Arora et al. [1], Tanenbaum etal. [2] note that the range of the thermal, humidity, infrared,and magnetic sensors are less than their radio ranges. Theimplication of this is that these systems require a large numberof sensor nodes to collect data and to maintain the connectivityin order to transfer the data to collection centers. However,it would be quite expensive to build a system with a largenumber of sensors when each sensor is expensive. Also it isnot easy to maintain and manage a system consisting of alarge number of sensors. The regular replacement of batteriesand replacement of faulty sensors are costly and labor inten-sive tasks. In addition, protecting a large number of sensorsscattered throughout a large terrain is also a daunting taskwhich makes such a sensor network a cumbersome solutionfor environmental monitoring.

We consider systems that monitor environmental pollutionas systems that fits into the above description. Air pollutionchanges considerably in different areas of a city and even frombuilding to building. Data gathered from a single point are notrepresentative of air pollution levels in different parts of thecity and therefore a large number of data gathering pointsspread over the city is needed. While for a small city it maybe feasible to deploy such a system it would be prohibitivelyexpensive to deploy a system over a larger geographical areasuch as a large city or a country.

We observe that most countries have a public transportsystem that spans the country. Buses and train networkshave central points (such as regional bus/train stations) fromwhich regional transport networks span out. There are bus andtrain routes inter-connecting these regional stations as wellas central hubs in capital cities. This forms a large publictransport network. We propose to use several sensors mountedon the vehicles of the public transport system as a replacementfor a network consisting of large number of sensors. Thesevehicle mounted moving sensors would be able to gatherdata that covers a large geographical area. When the busesarrive at bus stations, which also function as data collectioncenters, gathered data are transferred over a wireless link to thecollection point. Data gathered in regional collection points aretransferred to buses traveling between the regional centers andthe main collection center. In this scenario the public transportsystem functions as a data delivery network as well as the datacollection network. Therefore, it is quite different from vehicleassisted data delivery networks [3], where vehicles form anad hoc network to deliver data. In our proposal data travel invehicles and also vehicles facilitate data gathering by hostingsensors. We assume that the gathered data are not required inreal time in this particular application.

We name this network BusNet and we have commencedbuilding a prototype to be deployed using the public transportsystem in Sri Lanka.

II. THE DESIGN OF THE BUSNET

The BusNet has three main components as shown in Fig-ure 1; Sensor Units, Sub Stations, and a Main Station.

The sensor unit consists of a Crossbow1 MICAz mote,and several sensor boards including a GPS sensor board. Thesensor boards other than the GPS sensor board depend on thetype of data to be gathered; in our prototype we plan to use atemperature sensor and a carbon monoxide sensor. This sensorunit will be mounted on top of a bus and it gets power fromthe battery of the bus. Other than getting power from the bus’sbattery we do not expect any cooperation from the bus driveror the bus operators. The sensors gather environmental data (inthe prototype just the temperature and the carbon monoxide

1http://www.xbow.com


Fig. 1. BusNet System Architecture

level) along the bus route. The collected data will be storedtogether with the GPS coordinates of the collection points. Inthe current prototype these data points will be stored in thememory of the sensor mote. However, we expect to connecta storage devise, such as a flash drive, to the sensor unit infuture.

The sub stations are the collection nodes located at theregional bus stations. Regional bus routes span out from thesub stations. Buses going out and coming towards the substations collect the temperature and carbon monoxide levelsat regular intervals and store them together with the GPScoordinates. Once they reach the sub station they transmitthe data over a wireless network to the sub station. The substation route these collected data to the main station over thebus network. It uses buses going to other regional bus stationsto send the data to the main station, and before reaching themain station the collected data may have to go through severalsub stations, which act as routers.

Since we do not expect the cooperation of the buses otherthan carrying the sensor units on them, we cannot assume thatbuses will wait in the station until the completion of the datatransfer. To handle this we are developing a protocol whichprioritize the data transfer. The collected data are prioritizedbased on the GPS coordinates. For example, the sensor unitinitially transfers the data collected at 1 Km intervals andnext transfers data collected at 500 m interval and so on. Itprioritizes the data based on the spatial coordinates so thatdata collected over a large area is transferred first and onlycovers the points in between if the time permits. In additionto this, when there is more than one bus transferring data, thestation must make sure that it collects data from all the busesin a round robin fashion to ensure that it collects data fromall the routes fairly.

The proposed data transfer protocol does not stop to retrans-mit lost packets; that is, if a packet is lost its retransmissionis delayed and retransmission starts only after the first attempttransmission of all the packets. Therefore, retransmission takesplace only if the bus stays long enough to retransmit. Priorityis given to the first attempt packets to ensure transmission ofdata to cover a large terrain as much as possible.

The main station is similar to the sub stations but it has adirect connection to the data processing center and it does nothave to route data to other stations.

Since the sensors eventually come to a sub station or themain station, maintenance work such as battery replacementand the replacement/repairing of faulty sensors can be doneat these stations. In addition we only have to handle far fewernumber of sensors. Also, buses will be parked in secured areaswhen they are not in operation and this reduces the possibletheft and damages to the sensors.

III. SOME ISSUES

The measurements taken by a moving sensor will not beas accurate as a measurement taken by a stationary sensor.Some sensors require several seconds to get an accuratemeasurement. In this case the exact location where the mea-surement was taken cannot be pin pointed. We propose tofind the correlation between the moving measurements andthe stationary measurements and to extrapolate the collectedmeasurements to increase the accuracy. We assume that sucha correlation exists and as a part of this work we will alsoexperiment on this.

IV. POSSIBLE USES

Even though the proposed prototype is developed for anenvironment monitoring system, the idea is generic enough touse for other systems in which large number of sensors canbe replaced by few moving sensors. We are also developinga public transport network based system to monitor the roadsurface conditions; this work is also carried out in parallel tothe BusNet. We believe that the idea of using vehicles to movedata, which can provide very high bandwidth at the expenseof latency, can be used for many other novel applications.

ACKNOWLEDGMENT

This project is funded by the Swedish Program for Informa-tion and Communication Technology in Developing Regions(SPIDER). We appreciate the contributions by Leif Axelsson(Volvo), Henrik Riomar (Ericsson), and Martin Gustavsson(Ericsson).

REFERENCES

[1] A. Arora, R. Ramnath, E. Ertin, P. Sinha, and S. B. et al., “ExScal: Ele-ments of an Extreme Scale Wireless Sensor Network,” in 11th IEEE Intl.Conf. on Embedded and Real-Time Computing Systems and Applications(RTCSA), 2005, pp. 102–108.

[2] A. S. Tanenbaum, C. Gamage, and B. Crispo, “Taking sensor networksfrom the lab to the jungle,” Computer, vol. 39, no. 8, pp. 98–100, 2006.

[3] J. Zhao and G. Cao, “VADD: Vehicle-assisted data delivery in vehicularad hoc networks,” Network and Security Research Center, Departmentof Computer Science and Engineering, Pennsylvania State University,University Park, PA, USA, Tech. Rep. NAS-TR-0020-2005, July 2005.


Poster Abstract: Towards component reuse in MACprotocols

Tom Parker* Maarten Bezemer Koen [email protected], [email protected], [email protected]

Faculty of Electrical Engineering, Mathematics, and Computer ScienceDelft University of Technology, The Netherlands

* Supported by the Dutch Organisation for Applied ScientificResearch (TNO)

Abstract— Most current WSN MAC protocol implementationshave multiple tasks to perform - deciding on correct timing, send-ing of packets, sending of acknowledgements, etc. However, asmuch of this is common to all MAC protocols, there is duplicationof functionality, which leads to larger MAC protocol code size andtherefore increasing numbers of bugs. Additionally, extensions tothe basic functionality must be separately implemented in eachMAC protocol. In this paper, we show a different way to designa MAC protocol, focusing on the core MAC role of timing. Weprovide data on an implementation of these principles workingwith different categories of MAC protocol (including CSMA andTDMA-type protocols).

I. I NTRODUCTION

Current Medium Access Control (MAC) protocol designfor Wireless Sensor Networks (WSNs) covers a wide varietyof different tasks. A MAC protocol is responsible not onlyfor deciding when to send packets, but also what to send.For example, generating the standard Unicast sequence ofRTS/CTS/DATA/ACK messages is usually the responsibilityof the MAC protocol after the application has provided a datapacket to be sent. The MAC must maintain an internal statemachine monitoring which one of these packets it last sentor received, enabling it to determine what packet should besent/received next.

Unfortunately, the decision about whether a MAC’s imple-mentation of Unicast uses RTS/CTS messages (which are seenby some designers as overhead, and by others as requiredfor reliability) tends to be a somewhat haphazard affair.Often, whether they are required should be an applicationlevel decision, and so some MAC protocols that implementRTS/CTS allow this functionality to be switched off and on atrun time. However, this is another example of a feature thatmay or may not be in a given MAC protocol depending onthe whims of its designer.

Given that we have a set of functionality that should becommon to all MAC protocols, but certain implementations door do not have particular features implemented, we lose out onthe advantage of common functionality: the idea that we canideally use any given MAC protocol as a drop-in replacement.Additionally, because the duplication of effort results inbothincreased bug count due to multiple implementations of thesame ideas (e.g. Unicast), and a system that is hard to extend,we conclude that the current design brief for MAC protocolshas a number of significant problems, and so should berethought.

In this poster we will set out an improved design brieffor MAC protocols, and show how these principles can be

implemented efficiently with data from implementations ofseveral different protocols.

II. RETHINKING MAC PROTOCOLS

We wish to redesign the process for creating a MACprotocol such that the common functionality that does notnecessarily need to be in a MAC protocol itself can beseparated out. The first step to achieving this is to determinewhat is common functionality, and what are MAC-specificrequirements.

A. Existing concepts

Before we can start rethinking the design process for MACprotocols, we need to look at the current state of the art.Current WSN MAC protocols are usually grouped in twodifferent groups: TDMA protocols (LMAC [1], TRAMA [2],etc) and CSMA-based protocols (S-MAC [3], T-MAC [4], B-MAC [5], etc). These two approaches are usually regarded asbeing very different, and even within each approach we areshown many different protocols that all do things in drasticallydifferent ways. However, despite all the apparent differences,all of these protocols have one thing in common - they aredesigned to manage the available time in the radio mediumin order to fulfill certain metrics while sending/receivingmessages (latency, energy usage, etc).

Specifically, they all do this by managing when a partic-ular node can send messages - TDMA protocols do this byseparating the available time into slots and allowing nodesonly to send in their slot; CSMA protocols do this by makingnodes perform carrier sense before sending (and in the caseof protocols like S-MAC, also by waiting until the beginningof the next “frame”). In total, a MAC protocol must do twothings: given that an application wishes to send a packet,determine what time this node will be able to send and send thepacket at that point; and transmit appropriate control packetsso that the application layer will be able to send packets inthe future.

B. Role separation

We then looked at separating the large existing MACprotocols into three parts: below the MAC, above the MACand aλMAC layer. This set of layers we refer to collectivelyas the MAC stack, and together they should do everything atraditional monolithic MAC layer would do on its own.

Our first task was looking at the modules required “below”the λMAC layer. Working from the conclusions of Section II-A, we know that MAC protocols need to send/receive packets,and to decide when to send/receive. The first can be achieved


with a “dumb” packet layer (no queueing, minimal latency,switches radio on/off only when told to); the second requiresmedium activity detection (as part of the “dumb” packet layer)and/or a time synchronisation layer. Time synchronisationcanalso be used to generate “frames” (periodic timers, as used byall TDMA protocols and S/T-MAC), but it would need to bedesigned such that it will not interfere with protocols thatdonot require time synchronisation (e.g. B-MAC [5]).

The biggest question re-

Fig. 1. λMAC protocol stack

garding how much we canpull out of a standard MAClayer was deciding what aλMAC layer actually reallyneeds to do. Or in otherwords, knowing what a com-plete MAC stack needs to do,what makes one MAC pro-tocol different from another?Our conclusion was simple:time management. One of thestandard opinions about therole of WSN MACs is power

management, and time management can be considered anextension of this - one of the time management roles isdeciding when to switch the radio on/off, but the other isdeciding when to start sending a packet sequence. However,once a node has started a packet sequence (e.g. all of Unicastafter the RTS message), the code becomes remarkably genericand MAC-portable, yet is currently still embedded within theMAC. What if we could extract that - let the MAC decidewhen to initiate packet sequences, but then hand off to ageneric module to perform the actual sequence itself? Thisnew transmission layer module could then be reused in otherMAC protocols.

C. Design conclusions

Given our new formulation of a MAC protocol stack, weredefine the required modules and connections as follows (seeFigure 1 for an overview of how these interact):

• Packet layer - responsible for the actual sending/receivingof a packet, radio state changes (Rx/Tx/sleep) and forproviding carrier sense functions (for CSMA-basedλMACprotocols). The sending/receiving radio state here is “dumb”- it does things right now, with no options for delay or smartdecisions considered.

• Global Time layer - responsible for storage and genera-tion of global time information to provide cross-networkevent synchronisation. This is not required by allλMAClayers, but given that global time information is useful toa large quantity of WSN MAC layers (due to the energysavings that can be made if nodes are able to agree whentransmit/receive periods should be), that the informationis potentially useful to other layers, and doing accuratetiming information above the MAC layer is difficult, weimplemented the Global Time layer here as a generalservice to the entire application stack.

• λMAC - responsible for time management. Allocates timeblocks in response to requests from the Transmission layer,at times that are considered to be “good”. Talks to theGlobal Time layer in order to send its own control packets,as well as for carrier sense checking in order to determineif the radio medium is free for sending (for CSMA-basedλMAC layers), and decides when to switch the radio onand off. Passes packet send requests/receive events from/tothe Transmission layer to/from the Global Time layer,possibly altering said packets along the way. Given theroles now allocated to other layers, theλMAC layer willbe considerably smaller than a traditional MAC layer.

• Transmission layer - contains the Unicast, Broadcast andother application-level primitives of this nature. Requeststime blocks from theλMAC layer as required, and thensends packets during the allocated time.

III. I MPLEMENTATION AND CONCLUSIONS

We then proceeded to implement our improved MAC frame-work for TinyOS, and then created a series of MAC protocolsusing the framework in order to be able to test how useful ourframework was for building MAC protocols. We implementedT-MAC [4], L-MAC [1] and Crankshaft [6], as well as a“trivial” test MAC.

These new implementations have been tested both inTOSSIM and with our 26 node hardware testbed, as well asagainst existing implementations of the protocols (simulationsfor L-MAC and Crankshaft; an earlier TinyOS version for T-MAC). Results from these tests were promising - theλMACimplementations behaved in the same way as the existing im-plementations, reproducing faithfully the expected patterns ofthe protocols. The level of effort required for implementationwas also much less -λT-MAC was only 32% of the sizeof the original T-MAC implementation, and Crankshaft wasimplemented from scratch in only a month.

Given the lack of TinyOS MAC implementations comparedto the number of simulation-implemented MACs, we concludethat our effort in redesigning MAC protocols to provide thisnew framework will be of great help to other MAC protocoldesigners in the future.

REFERENCES

[1] L. van Hoesel and P. Havinga, “A lightweight medium accessprotocol(LMAC) for wireless sensor networks,” in1st Int. Workshop on NetworkedSensing Systems (INSS 2004), (Tokyo, Japan), June 2004.

[2] V. Rajendran, K. Obraczka, and J. Garcia-Luna-Aceves, “Energy-efficient,collision-free medium access control for wireless sensor networks,” in 1stACM Conf. on Embedded Networked Sensor Systems (SenSys 2003), (LosAngeles, CA), pp. 181–192, Nov. 2003.

[3] W. Ye, J. Heidemann, and D. Estrin, “Medium access controlwithcoordinated, adaptive sleeping for wireless sensor networks,” ACM/IEEETransactions on Networking, vol. 12, pp. 493–506, June 2004. A preprintof this paper was available as ISI-TR-2003-567.

[4] T. van Dam and K. Langendoen, “An adaptive energy-efficient macprotocol for wireless sensor networks,” in1st ACM Conf. on EmbeddedNetworked Sensor Systems (SenSys 2003), (Los Angeles, CA, USA), Nov.2003.

[5] J. Polastre and D. Culler, “B-MAC: An adaptive CSMA layerfor low-power operation,” Tech. Rep. cs294-f03/bmac, UC Berkeley, Dec. 2003.

[6] G. Halkes and K. Langendoen, “Crankshaft: An Energy-Efficient MAC-Protocol For Dense Wireless Sensor Networks,”EWSN 2007: Europeanconference on Wireless Sensor Networks, Jan. 2007.


Poster Abstract: A Wireless Magneto-resistiveSensor Network for Real-Time Vehicle Detection

A. Bemporad∗, F. Gentile, A. Mecocci, F. Molendi, F. RossiDepartment of Information Engineering, University of Siena, Siena, Italy.

http://www.dii.unisi.it/hybrid

Fig. 1. Two wireless sensor nodes deployed on the road

Abstract— This works describes a prototype wireless sensornetwork for vehicle detection developed at the University of Sienain collaboration with the Italian highways society AutostradeS.p.A. Each wireless sensor node is composed by an in-housedesigned electronic board driving a 2-axis Honeywell HMC1002magneto-resistive sensor interfaced to a Telos rev.b (MoteivCorporation) mote, and by a Matlab/Simulink interface forcollecting and processing sensor data in (soft) real-time.

I. MAGNETO-RESISTIVE WIRELESS SENSOR

Wireless magneto-resistive sensor networks are a cheap,easily deployable, and non-invasive alternative to inductiveloops and cameras for real-time count, speed measurement,and occupancy of vehicles on roads, and, indirectly, of trafficparameters like density and flows [1], [2].

In our setup each wireless node provides samples of twocomponents of the Earth magnetic field, perturbed by the vehi-cle, in a rather reliable way, thanks to a set-reset control circuiton the magneto-resistive sensor’s board. The board is physi-cally connected on the ADC expansion pins of the Telos mote(see Figure 2). Though specially tailored NesC componentsfor TinyOS, the mote samples the amplified analog signalfrom the sensor’s Wheatstone bridge at 64Hz and transmitsthe digital samples to the remote station located along theroad at a distance of about 10m. The sampling frequency ishigh enough to recognize vehicle magnetic “signatures” on awide spectrum of vehicle speeds (see Section 3). Two sensornodes are employed for robustified vehicle detection and speedmeasurements.

∗Corresponding author, [email protected].

Fig. 2. Magneto-resistive wireless sensor node

II. MAGNETIC SIGNATURE

Every vehicle leaves its own characteristic magnetic signa-ture when passing in the proximity of the sensor. For exampletwo different vehicles provide a different perturbation of theEarth’s magnetic field because their ferrous parts (engine,chassis and body) have different dimensions and are placedin a different way. The passage of the same vehicle canbe therefore identified by its signature. The shape of themagnetic signature is almost insensitive to vehicle speed,modulo deformations along the time axis due to non-uniformspeed (that is, the magnetic signature signal m(t) = m(s(t)),where s(t) is the vehicle position at time t). Figure 3 showsthe same signature identified at 30 and 80 km/h. In terms ofnumber of samples of the signature, at the given samplingfrequency 64 Hz around 50 samples are collected at 40 km/h,32 samples at 70 km/h. Different vehicle signatures wereobserved by changing the orientation of the sensor, a verypromising result pointing towards the possibility of reliablevehicle classification.

III. DETECTION ALGORITHM

Several detection algorithms running at the base station fornoise filtering (like integrals, autoconvolutions, FFT, etc.) weretested. A very efficient solution in terms of both numericalburden, accuracy of detection, and robustness, is an algorithmthat integrates the raw magnetic signal x(t) (y(t) or z(t))on a moving window of M (typically M = 32) samplesdepurated by the average of the samples, and then comparesthe resulting signal with a given threshold ±L, thereforeobtaining a {−1, 0, 1} signal ax(t) (ay(t) or az(t)). Thelogical “and” |ax(t)| ∧ |ay(t)| (or |ax(t)| ∧ |az(t)|) provides abinary signal b(t) that flags the passage of a vehicle.


Fig. 3. Magnetic signature of the same vehicle detected on x axis (alongthe motion direction) at the speed of 30 and 80 km/h.

Such a simple detection algorithm is described in moredetail below:

1. Initialization: mx(0) =

M−1∑

i=0

x(−i), my(0) =

M−1∑

i=0

y(−i);

2. At time t:a. collect last M samples x(t), x(t−1), . . . , x(t−M +1)

and y(t), y(t − 1), . . . , y(t − M + 1);b. mx(t) = (1−λ)mx(t− 1)+λx(t) (λ is a given fading

factor), my(t) = (1 − λ)my(t − 1) + λy(t);c. Ix(t) =

∑M−1i=0 (x(t − i) − mx(t)), Iy(t) =∑M−1

i=0 (y(t − i) − my(t));d. If Ix(t) > L then ax(t) = 1, else if Ix(t) < −L then

ax(t) = −1, else ax(t) = 0 (ay(t) is defined similarly);e. b(t) = |ax(t)| ∧ |ay(t)|.

Results of the algorithm on experimental signals are shownin Figure 5.

Fig. 4. Wireless sensor node embedded in road pavement

IV. IMPLEMENTATION AND EXPERIMENTS

On the base station data are collected by special methodsand conversion routines designed around a Matlab Java object.In addition, a Simulink S-function based on the Java object isused for real-time data processing and visualization.Several experiments have been carried out in collaborationwith the Italian highways society Autostrade S.p.A at their testsite in Florence, Italy. The wireless network was first placed onthe road surface and tested (as in Figure 1), then buried underthe pavement at about 10cm and covered by asphalt (Figure 4).In the latter case we experienced almost no loss in radiotransmission and only a very mild reduction of intensity ofthe sensed magnetic field, that does not jeopardize the correctfunctioning of the overall measurement and detection system.

Fig. 5. Data processing based on integrals on moving windows (x-axis):x(t) and Ix(t) (top), integral signal and thresholds (bottom)

When the nodes are placed aside rather than under the vehicle,the signal-to-noise ratio remains acceptable up to a distanceof about 70cm between vehicle and sensor.

On the base station we have implemented a Simulinkdiagram for soft real-time data processing and visualization.A Simulink block is devoted to listen to all the packets of thenetwork and to take out and convert the data of interest aboutthe magnetic field. Other blocks are used to implement thealgorithm described in Section III based on the integral of amobile window of 32 samples and they create a detection flagcomparing the processed signal with two specular thresholdsL and −L, where |L| = 150. Others blocks are used to countthe number of vehicles passing over the sensors using theinformation of the detection flag. The same Simulink diagramcan be also easily adapted to measure the speed of vehicles.

V. CONCLUSIONS

Our wireless magneto-resistive sensing system proved tobe a quite viable and reliable scheme for real-time vehicledetection on roads, such as at highway toll stations, and itcan replace the large and invasive inductive loops. Severalissues remain to be explored. Adaptive transmission schemesimproving on battery life by local processing data on the Telosnode should be investigated, as well as the possibility to movethe detection algorithm from the base station to the motes.To prevent the congestion of the network it may be usefulto synchronize the nodes or to use a different transmissionprotocol, like TDMA, instead of the CSMA. For using thiskind of wireless sensor network for vehicle classification, itis necessary to collect a large number of magnetic signaturesand create a database.

REFERENCES

[1] S.Y. Cheung, S. Coleri, B. Dundar, S. Ganesh, C.-W. Tan, and P. Varaiya.Traffic measurement and vehicle classification with a single magneticsensor. Technical report, Institute of Transportation Studies, Universityof California at Berkeley, 2004.

[2] Vehicle detection using amr sensors. http://www.magneticsensors.com, August 2005.


Abstract - Sensor networks represent a significant

improvement over traditional sensors. Very advanced

application can be designed on wireless sensor network if

network resources are optimally managed. This critical issue

advises to design a complex resource management plane (as a

framework) composed by ad-hoc protocols to communicate, to

reserve network resource, to optimize network resource.

Key words - Resource Optimization, Resource Reservation,

Wireless Communication, Wireless Sensor Network.

INTRODUCTION

ECENT advancement in wireless communications and

electronics has enabled the development of low-cost, low-

power, multifunctional sensor nodes that are small in size and

communicate in (relatively) short distance. These tiny sensor

nodes, which consist of sensing, data processing and

communicating components, leverage the idea of sensor

networks. Sensor networks represent a significant

improvement over traditional sensors. Sensor networks can be

used for various application areas (e.g., health, military,

home). For different application area there are different

technical issues that researchers are currently resolving. Resource Optimization is a central and critical issue for

Wireless Sensor/Actuator Network. Sensor hardware is rapidly

improving and, as consequence, requests and computation

level of applications that work on WSN are increasing too. If

interest applications are really characterized by high level, a

global and complex resource management plane is required;

Global Resource Management Model (GRMM) is the

proposed model.

GLOBAL RESOURCE MANAGEMENT MODEL

Figure 1 shows the proposed model. Different classes of

protocols and planes, organized on various logical

interdependent layers, are designed to support, in optimal way,

high level applications. Critical research issues are the

follows:

• Topology/Logic Organization

• Communication protocol

• Resource Reservation System

• Optimization Layer

Other important issue, directly related with the others, is the

management plane. Optionally a Security Layer can be

designed.

Figure 1: GRMM structure.

I. Topology/Logic Organization

Sensor/Actuator nodes are organized in logic areas and levels

(Figure 2). This logic organization can be supposed 2D or 3D.

Figure 2: Logic Organization.

Some topologic parameters, as for example the number of

areas and levels, the number of nodes in each sector, determine

some network characteristics .In general way, a great number

of nodes increases network scalability (and cost) decreasing

network performance.

II. Communication protocol

Communication protocol provides, basically, a routing plane

for the network. The interest characteristics are mainly

performance (minimum number of hops) and scalability; so,

independence of application field and application requests,

communication protocols must be able to guarantee different

communication planes. Typically, a wireless sensor network is

a relatively centralized system for the presence of Sink. This

means that communication protocols are related with

convergence and divergence of information both. A good

communication protocol, typically, guarantees an optimal

communication in convergence mode. Scalability is a critical

issue for the communication in divergence mode; so,

Poster Abstract: A Global Resource Management Model (GRMM)

for Wireless Sensor/Actuator Network

Salvatore F. Pileggi, Carlos E. Palau, Manuel Esteve

[email protected], {cpalau,mesteve}@dcom.upv.es

ETSIT. Universidad Politécnica de Valencia

Camino de Vera S/N, Valencia 46022 (SPAIN)

R


communication protocol is really integrated with Resource

Reservation Protocol to optimize the divergence of

information using particular structures (spanning tree, for

example). A good example of communication protocol that

guarantees performance and scalability and that can be

integrated with resource reservation protocol is LRA (Logic

Routing Algorithm) [1]. Using the configuration (and related

connectivity diagram) that guarantees best performance and

minimum scalability (Figure 4) showed in Figure 3, LRA

simulation returns an average number of hops next to 4 hops.

Figure 3: Logic Area Configuration and sensor Connectivity.

Figure 4: Load distribution.

III. Resource Reservation System and self re-

configuration

Resource Reservation can be considered as an important

research issue in a large number of context (wired, wireless)

and for a large number of applications (multimedia, for

example). Many applications can require some resources to

work (minimum resource request) or a number of resources to

guarantee a quality of service. Resource Reservation in

Wireless Sensor Network means integrating other protocol

layers to optimize their functions and provide interest

application of nodes that can have special “roles” (leader area

for example) or ad-hoc optimization structure (spanning tree

for example). Different applications can so share the same

WSN. The main characteristic of Resource Reservation Layer

(self re-configuration) determines a higher dynamism for

application.

IV. Optimization Layer

Resource Optimization is a central and critical issue for

Wireless Sensor/Actuator Network. Sensor hardware is rapidly

improving and, as consequence, requests and computation

level of applications that work on WSN are increasing too.

Resource Optimization layer has the main goal to optimize

network resource in function of application characteristics. A

power expense model by single sensor node point of view

(PEM) is designed; PEM is used to design PEC (Power

Expense Coefficient); PEC is a power expense model of a

single sensor/actuator node but by network point of view. PEC

is a “guide” to measure the “goodness” of network design in

function of interest application. Finally a real resource

reservation protocol, TROP (Timed Resource Optimization

Protocol), is designed. The main goal of TROP is to minimize

PEC. This layer is important by methodological point of view:

different mathematical node models can be designed

independence of hardware considered or general node

characteristics, as well as different guide coefficients and

finally different protocol/models for resource optimization.

Figure 5 shows the simulated results independence of

application characteristics (real time coefficient).

Standard vs Optimized Network

0

5

10

15

0 1 2 3 4 5 6 7 8 9 10

Real Time Coefficient

PE

C Standard

Optimized

Figure 5: Standard vs Optimized Network.

CONCLUSIONS AND FUTURE WORKS

A framework (GRMM) to support the development of high

level applications on WSN was designed; some mathematical

models that can support the designer in resource optimization

step were proposed too. Future works are mainly focused on

the development of applications over proposed framework;

interest application fields are related with:

• Reliable tourism

• Habitat monitoring

• Security and Alarm systems

REFERENCES

[1] Salvatore F. Pileggi, Carlos E. Palau, Manuel Esteve, “Grid Wireless

Sensor/Actuator Network Architecture”, International Conference on

Wireless and Mobile Communications, ICWMC’06, July 29-31, 2006,

Bucharest, Romania.

[2] B.Tavli, W.Heinzelman, Time reservation using adaptive control for

energy efficiency, IEEE Journal on Selected Areas of Communication

21 (10) (2003) 1506–1515.

[3] Salvatore F. Pileggi, “Resource Optimization in Wireless

Sensor/Actuator Network”, Technical Report, Polytechnic University of

Valencia, October 20th 2006.

[4] I. Akyildiz, W.Su, Y.Sankarasubramaniam, E.Cayirci, “A survey on

Sensor Network”, IEEE Communication Magazine, August 2002.


Poster Abstract: Proposal of a Secure RoutingAlgorithm for Wireless Sensor Networks

Eduardo de Mattos Kalinowski, Luiz Nacamura, Jr., Richard Demo SouzaGraduate School of Electrical Engineering and Industrial Informatics (CPGEI)

Federal University of Technology – Parana (UTFPR)Av. Sete de Setembro, 3165, 80230-901 Curitiba, PR, Brazil

[email protected], [email protected], [email protected]

Abstract— Sensor networks are networks usually composed ofsmall low-cost battery-powered devices and used for monitoring.These networks have no fixed infrastructure and no supportingequipment, so messages are sent from node to node, requiringthe use of routing algorithms to find routes. Several routingalgorithms have been proposed for sensor networks, but veryfew had security provisions. We present in this work a novelsecure routing algorithm for sensor networks. The algorithm isverified with a formal technique in order to show that it fulfillsthe proposed security requirements.

I. INTRODUCTION

Sensor networks are networks usually composed of smalllow-cost battery-powered devices and used for monitoring.Their uses are vast and varied, such as military, environmentalmonitoring, stock control, etc. It is expected that they willbecome more and more common in a near future [1]. Thesenetworks have no fixed infrastructure and no supporting equip-ment, so messages are sent from node to node, requiring theuse of routing algorithms to find routes between nodes. [2],[3].

II. SECURITY IN ROUTING ALGORITHMS

As in any network, security is essential. Since the air isthe transmission media, they are easier to attack because nophysical access to the network is necessary, one just needsto be close to the network. It is thus even more importantto make sensor networks secure. However, the equipmentused in sensor networks is limited in terms of processingpower and available memory [4], so the algorithms used toprovide security must be as efficient and small as possible,and this prevents the use of existing solutions and algorithmsemployed in other kinds of networks, even other kinds ofwireless networks.

Several routing algorithms have been proposed for sensornetworks [3], but only a few of them have security provisions.This is very unfortunate, because in real applications onecannot assume that all nodes will behave correctly. Andsince routing plays a fundamental role in sensor networks, anattacker can bring such a network down just by attacking therouting algorithm. Attacks can be made by forging messagesand/or changing legitimate messages in order to create false

routes and loops; or denial-of-service attacks that preventroutes from being successfully established.

Directed Diffusion [5] is one of those algorithms, a rela-tively simple algorithm that was not made with security inmind. Its principle is that the base stations (special nodesthat control the network and gather data, serving often alsoas an interface to control equipment or another network) sendmonitoring tasks that are disseminated to all other nodes ofthe network. The nodes record the path that this messagetook (storing the node from which the message was received).Later, when an event matching one of such tasks is observed,they send the gathered data to that stored node, which in turnforwards the data to the node from which which it receivedthe data, and the process continues until the message reachesthe base station.

III. A SECURE ROUTING ALGORITHM

Because of the need of secure routing algorithms for sensornetworks, we present a novel routing algorithm that is secure,that is, the network will remain operational even if one ormore nodes try to disrupt its functioning. This algorithm isbased on Directed Diffusion, but signatures are added to themessages sent by the nodes to make sure that messages arenot forged and are not changed while they travel the network.Some ideas in the algorithm were loosely based in the ARANalgorithm for mobile ad-hoc networks [6].

The signatures are created with Elliptic Curve Public-Key Cryptography [7]. While it had been initially thoughtthat public-key cryptography was not suitable for sensornetworks [8], several studies have shown that elliptic curvecryptography can be used in sensor networks [9]–[14]. Thiskind of cryptography is suitable for sensor networks becauseit requires smaller key sizes than those required for otherpublic-key cryptography systems, as shown in table I, whichreduces the processing time considerably and thus allowimplementation in reasonable time. It is expected that thealgorithms will run even faster in a near future, because ofadvances both in sensor network hardware and in the algorithmimplementations.

IV. FORMAL VERIFICATION

A serious problem with secure algorithms and protocols isthat they are generally only verified informally, which does not


TABLE IKEY SIZES (IN BITS) NECESSARY IN THE RSA AND ELLIPTIC CURVE

PUBLIC KEY CRYPTOGRAPHY ALGORITHMS TO ACHIEVE THE SAME LEVEL

OF SECURITY.

RSA Elliptic curve1024 1632048 2243072 2568192 384

15360 512

guarantee their security. It is not uncommon that later securityflaws are found in protocols previously considered safe. Toshow that the proposed algorithm is indeed secure, we use aformal verification technique developed by Acs, Buttyan andVajda [15], [16], that has been used to analyze some routingalgorithms for mobile ad-hoc networks and to find securityflaws in them [15], [16].

The technique consists of describing what are the securitygoals — what distinguishes a system that is “correct”, in thesense that it has not been successfully attacked and all itsrouting information is correct, from a system that has beenattacked. Naturally, the objective is to show that the algorithmalways leaves the system in a correct state, even if one or morenodes try to attack it.

Two system models are made: one describes what is ex-pected from the algorithm: it is an idealized version of itwithout limitations in what can be done. Basically, we expectthe algorithm to identify false route messages and discardthem, preventing the system from reaching an incorrect state.The other model describes the real algorithm implementation,with all its limitations. In the idealized version, an attackercannot succeed in disrupting the network. In the real version,it can if the algorithm is not secure and has some flaw.

We then show that, with the algorithm implemented asproposed, an attacker cannot inject false routing messagesin the network or alter them in any way without the nodesdiscovering that the message is false. This way, we canconclude that the algorithm is, in terms of security, equivalentto its idealized description, or, in other words, that it fulfillsthe proposed security requirements.

REFERENCES

[1] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayircy, “A surveyon sensor networks,” IEEE Communications Magazine, vol. 40, no. 8,pp. 102–114, Aug. 2002.

[2] Q. Jiang and D. Manivannan, “Routing protocols for sensor networks,”in First IEEE Consumer Communications and Networking Conference(CCNC 2004), Jan. 2004, pp. 93–98.

[3] J. N. Al-Karaki and A. E. Kamal, “Routing techniques in wireless sensornetworks: a survey,” IEEE Wireless Communications, vol. 11, no. 11, pp.6–28, Dec. 2004.

[4] M. A. N. Vieira, C. N. Coelho, Jr., D. C. da Silva, Junior, and J. M.da Mata, “Survey on wireless sensor network devices,” in IEEE Con-ference on Emerging Technologies and Factory Automation (ETFA’03),2003, pp. 537–544.

[5] C. Intanagonwiwat, R. Govindan, D. Estrin, J. Heidemann, and F. Silva,“Directed diffusion for wireless sensor networking,” IEEE/ACM Trans-actions on Networking, vol. 11, no. 1, pp. 2–16, Feb. 2003.

[6] K. Sanzgiri, B. Dahill, B. N. Levine, C. Shields, and E. M. Belding-Royer, “A Secure Routing Protocol for Ad Hoc Networks,” in 10th IEEEInternational Conference on Network Protocols (INCP’02), 2002, pp.78–87.

[7] V. S. Miller, “Use of elliptic curves in cryptography,” in Advancesin Cryptology (CRYPTO’85), ser. LNCS 218, H. C. Williams, Ed.Springer-Verlag, 1986, pp. 417–426.

[8] A. Perrig, R. Szewczyk, J. Tygar, V. Wen, and D. E. Culler, “SPINS:Security Protocols for Sensor Networks,” Wireless Networks, vol. 8,no. 5, pp. 521–534, Sept. 2002.

[9] J. Guajardo, R. Blumel, U. Krieger, and C. Paar, “Efficient Implementa-tion of Elliptic Curve Cryptosystems on the TI MSP430x33x Family ofMicrocontrollers,” in International Workshop on Practice and Theory inPublic Key Cryptography (PKC 2001). London, UK: Springer-Verlag,2001, pp. 365–382.

[10] N. Gura, A. Patel, A. Wander, H. Eberle, and S. C. Shantz, “ComparingElliptic Curve Cryptography and RSA on 8-bit CPUs,” in 6th Interna-tional Workshop on Cryptographic Hardware and Embedded Systems(CHES 2004). Springer-Verlag, 2004, pp. 119–132.

[11] T. Hasegawa, J. Nakajima, and M. Matsui, “A small and fast softwareimplementation of elliptic curve cryptosystems over GF(p) on a 16-bitmicrocomputer,” IEICE Trans. Fundamentals, vol. E82-A, no. 1, pp.98–106, Jan. 1999.

[12] Q. Huang, J. Cukier, H. Kobayashi, B. Liu, and J. Zhang, “Fastauthenticated key establishment protocols for self-organizing sensornetworks,” in 2nd ACM international conference on Wireless sensornetworks and applications (WSNA’03). New York, NY, USA: ACMPress, 2003, pp. 141–150.

[13] D. J. Malan, M. Welsh, and M. D. Smith, “A public-key infrastructurefor key distribution in TinyOS based on elliptic curve cryptography,”in 1st Annual IEEE Communications Society Sensor and Ad HocCommunications and Networks (SECON’04), 2004, pp. 71–80.

[14] A. S. Wander, N. Gura, H. Eberle, V. Gupta, and S. C. Shantz, “Energyanalysis of public-key cryptography for wireless sensor networks,”in 3rd IEEE International Conference on Pervasive Computing andCommunications (PerCom 2005), 2005, pp. 324–328.

[15] G. Acs, L. Buttyan, and I. Vajda, “Provably Secure On-demand SourceRouting in Mobile Ad Hoc Networks,” Report 2004/159, Mar. 2005.[Online]. Available: http://eprint.iacr.org/

[16] ——, “Provable security of on-demand distance vector routing inwireless ad hoc networks,” in Second European Workshop on Securityand Privacy in Ad Hoc and Sensor Networks (ESAS 2005), July 2005.


Poster Abstract:Simulation Framework for Power Aware Wireless

SensorsJohann Glaser and Daniel WeberInstitute of Computer TechnologyVienna University of Technology

Vienna, AustriaEmail: {glaser,weber}@ict.tuwien.ac.at

Abstract— The PAWiS (Power Aware Wireless Sensors) simu-lation framework facilitates design and simulation of wirelesssensor network models. The main focus is given to poweraware computing and therefore it can capture causes resultingin inefficiencies. The simulation framework covers all systemaspects comprising of all layers of the communication system,the targeted class of application itself, the power supply andenergy management, the central processing unit (CPU) and thesensor-actuator interface.

I. I NTRODUCTION

The PAWiS Simulation Framework assists in developmentand especially modelling, simulation and optimization ofWireless Sensor Networks (WSN) nodes and network proto-cols. The internal structure of nodes as well as communicationbetween them are simulated. The wide range of applicationsthat can be simulated begins with simple applications liketiny sensor nodes (e.g. the TinyMote [Roe04]), tire pressuremonitoring and car climate control to as complex systems ashome entertainment (e.g. Sindrion).

The internal structure of a node is built as avirtualprototype. This means that its function, the timing behaviorand power consumption as well as failures are simulated.With the true top down development methodology, the designstarts at a functional specification and implementation level.Guided by requirements, the design is refined via architecturalmodels down to models reflecting the actual implementation.On the other hand, physical constraints affect the functionaland architectural designs from bottom up.

II. WORK FLOW

The WSN node is split intofunctional blocks(physical,MAC, routing and application layer, CPU, serial interface,AD converters, timer and so on). Each of these blocks ismapped to modules in the simulation. For every functionalblock its module typeis defined which comprises its nameand the standardized interfaces. For each of the module typesseveral different implementations can be prepared.

Initially the node is composed from a module implementa-tion of a certain module type out of a module implementationslibrary. Then the modules are configured (e.g. clock frequency

of the CPU, resolution of the ADC) to meet the target platformrequirements. After that the model is simulated and the resultsare evaluated and potentially refined for further simulationiterations to improve the desired parameters and the system’sbehavior.

These cyclic improvements of the models are calledrefine-ment cyclesand are the main track to enhance the development[MGH05]. When these refinement cycles are completed, thefinal outcome comprises

• the functional description and• the architecture of the node, as well as• the implementation details at various levels and• the power specification of every module including its

components.

III. M ODEL OPTIMIZATION

Several strategies for the optimization of the wireless sensorsystem are available. First of all asystem level optimizationisperformed which includes node composition and modificationsof the entire system behavior (e.g. changing the network layoutor application pattern).

In parallel cross-layer optimizationis performed wheremore than one network layer is modified at a time. Probablyeach of these changes itself would degrade the node perfor-mance, but the interaction of them leads to an improvementin overall behavior of the node.

All optimization is performed by applying the followingstrategies.

• Exchange the actual moduleimplementationfor onemodule type, i.e. a different implementation from thelibrary, e.g. a dual-slope, aΣ∆ or an SAR ADC. Anotherexample is choosing different MAC protocols.

• Partitioning of modules and/or functions by dividing thetask between hardware and software, digital and analogor RF and baseband. For example a specific MAC pro-tocol could be implemented in software or as dedicatedhardware acceleration unit. A combination of both is alsopossible.

• The scaleof a module, e.g. the resolution of an ADC orthe register count of a CPU.


• Parameterizationof modules, e.g. the timing and thetransmission power of a radio transmitter.

IV. T HE SIMULATION FRAMEWORK

A. Structure

The PAWiS framework is based on the OMNeT++ [Var01]discrete event simulator and the C++ programming language.Figure 1 depicts the structure of the framework from theusers view. The model programmer mostly interacts withthe framework and C++. Additionally basic knowledge ofconcepts of OMNeT is required to comprehend the simulationprocess.

Model

PAWiS Framework

Air

C++OMNeT++

CPU PowerManagement

Misc Radio

Programmer

Executeable Simulator (optional with GUI)

Fig. 1. Structure of the PAWiS simulation framework.

The node composition as well as the network layout arespecified in configuration files. Completed models can becompiled (optionally with a GUI based on Tcl/Tk) to anexecutable simulator. With the optional GUI the workflowand communication of the model can be observed duringthe simulation. Additionally a log file with power and timingprofile is generated for post-simulation analysis.

B. Basic Concepts

a) Modularization: A wireless sensor node is typicallysplit up into various modules, e.g. a CPU, the network protocollayers (application, routing, MAC, physical), a timer and so on.Each of these modules is implemented as a C++ class derivedfrom a framework base class. Decomposition of a sensor nodedepends strongly on the design requirements. If the main focusof the design is set to network layers it is recommended toprovide a module for each layer in order to analyze multiplelayer combinations. On the other hand a focus on hardwareunits would result in modules representing hardware or anyapplicable combination.

b) State machines:Every module is executing its specifictasks which can be represented as finite state machines (FSM),each one implemented as a class method of the user’s moduleclass. Within one module several FSMs can be implementedand even run in parallel. The framework even allows to passparameters from and to such tasks.

c) Functional Interfaces:Control flow transitions be-tween two modules are implemented as so calledFunctionalInterfaces. These are similar to blocking subroutine calls butexceed module boundaries. Additionally modules can definea wait condition depending on other modules or conditions to

be satisfied. This is complemented by a mechanism to triggera parallel task.

d) Environment: All nodes are placed at 3D positionswithin an environment that manages the outer world of allnodes including their surroundings and the RF channel. Furtherimplementations will include various obstacles and dynamicobjects within the environment.

e) Air: The Air is a subcomponent of the environmentthat actually handles the RF channels, which are defined by thenode placement and the obstacles between them. The currentimplementation of the Air handles attenuation effects with freespace propagation and isotropic antennas with uniform antennagain. A radio module can be implemented by deriving froma framework class. Providing a few abstract methods enablesthe model to get the full support of the Air class. The entirecommunication including features like bit error rate (BER),timing and SNR aspects is then handled by the framework.

f) Power Simulation: Every module reports its powerconsumption during simulation. With the framework it ispossible to hierarchically combine power sources and adapttheir behavior to meet the target platform’s requirements.These power profiles are the main output of the simulationand are stored in a log file for further processing.

g) CPU: The submodules of a sensor node are usuallyeither implemented asfirmware (software), i.e. executed by aCPU, or asdedicated hardware. In order to model the powerand time consumption of software tasks the PAWiS frameworkprovides a CPU base class to be extended by the frameworkuser. All power simulation issues of the CPU are processedby the framework.

h) Interrupts: The aforementioned CPU features basicinterrupt handling methods for multipleinterrupt sources.These sources,interrupt vectorsand interrupt service routines(ISRs) can be freely configured (by overriding methods) bythe user. The timing, dispatching and execution of an ISR ishandled by the framework.

The proposed framework is available in a preliminaryversion and currently being evaluated with a model of a realsensor node [MMR06].

REFERENCES

[MGH05] Stefan Mahlknecht, Johann Glaser, and Thomas Herndl. PAWIS:Towards a Power Aware System Architecture for a SoC/SiP Wire-less Sensor and Actor Node Implementation. InProceedings of6th IFAC International Conference on Fieldbus Systems and theirApplications, pages 129 – 134, Puebla, Mexiko, 14.-15. November2005.

[MMR06] Stefan Mahlknecht, Sajjad Ahmad Madani, and Matthias Rtzer.Energy Aware Distance Vector Routing Scheme for Data CentricLow Power Wireless Sensor Networks. In4th InternationalIEEE Conference on Industrial Informatics INDIN’06, 16-18 August 2006.

[Roe04] Matthias Roetzer. Routing in energieautarken Funksensornetzw-erken, 2004.

[Var01] Andras Varga. The OMNeT++ discrete event simulation system. InEuropean Simulation Multiconference (ESM’2001), Prague, CzechRepublic, 2001.


Poster Abstract: Modular Architecture forHeterogeneous Sensor Networks

Benoıt Latre, Eli De Poorter, Ingrid Moerman and Piet DemeesterGhent University – IBBT vzw – IMEC vzw, Department of Information Technology (INTEC) – IBCN

Gaston Crommenlaan 8, bus 201, B-9050 Ghent, Belgium{benoit.latre, eli.depoorter, ingrid.moerman, piet.demeester}@intec.ugent.be

Abstract— Wireless sensor networks are becoming increasinglypopular for wireless monitoring and automation of buildingsand industrial processes. However, current network protocolsare typically custom built for a specific application. Hence, thedevelopment of sensor networks is a time consuming and cost-inefficient activity. Moreover, the lack of support for heteroge-neous networks and for advanced network functionality such asQoS and mobility prevents many developers to adopt wirelesssensor technology. Therefore, in this paper we propose a uni-versal, application independent architecture which is developedspecifically for heterogeneous sensor networks.

I. INTRODUCTION

The research in wireless sensor networks has known atremendous boost in the last few years. Wireless sensornetworks (WSNs) are becoming more and more widespread.Whereas sensor networks were originally used mainly formonitoring purposes, new applications such as process andasset monitoring, disaster intervention and wireless buildingautomation are rapidly emerging [1]. Considering these facts,it is clear that future sensor networks will impose more diverserequirements on the different sensors and not all of thesesensors will be capable to fulfill these requirements. Whereasthe first sensor networks consisted of a large number of homo-geneous nodes, additional computing power or functionalitywill be required in some nodes. Sensor networks are thusevolving into heterogeneous networks.

Even though many new applications for sensor networksare designed, there exist currently no protocol frameworkwhich is widely applicable. Current work mostly focuseson scalable and energy-efficient protocols. Each applicationthus requires a specific developed protocol stack. The ZigBeeAlliance [2] is defining application profiles for specific appli-cations. However, these profiles do not taken into account theheterogeneity of the network. Although this research is veryvaluable for the development of sensor networks, there is atpresent no optimized architecture in which these solutions canbe implemented. Thus, developing sensor networks currentlycomes at a great developments cost, impeding the growthof sensor networks and hindering the cooperation betweendifferent sensor networks

II. UNIVERSAL MODULAR FRAMEWORK

A. Motivation

The evolution of sensor networks as described above clearlyshows the need for an optimized generic, application inde-

pendent solution that accounts for the network heterogeneity.Furthermore, energy efficiency will remain one of the keydrivers in the research for optimizing wireless sensor networks.

Several authors have pointed out that cross-layer optimiza-tion is a very promising strategy in order to reduce the energyconsumption [3], [4]. Many networking aspects interact withmultiple layers, such as QoS, security, transmission power, etc.As such, the exchange of information between different layerscan enhance the performance of the wireless network.

We have defined an architecture where functionality isdivided in modules that interact with each other. This modulardesign has several key advantages:

• Duplication of functionality is prevented;• Due to the possibility of information exchange more

energy-efficient protocols are supported;• Heterogeneity is promoted: additional or more advanced

modules can be added to a node according to it’s capa-bilities;

• Through the replacement of modules, it is easy to adaptto changing network conditions and future developments.

The use of modular protocols is thus a very promising ap-proach for sensor networks.

B. Proposed framework

A schematic overview of the proposed framework is shownin figure 1. One can clearly see the modular layer structure thattakes care of the functionalities of the MAC and network layer.The middleware layer is designed to implement functionalitythat requires a strong interaction between application layerand network layer. An example is data-aggregation which,depending on the application, can be as simple as calculatingthe average of several data sets or realize complex dataprocessing. Next, the physical layer is also a separate layeras the properties of this layer largely depend on the design ofthe hardware. Finally, in order to allow for better optimization,a shared cross-layer database forms a generic interface for theexchange of cross-layer parameters.

As stated above, heterogeneity is one of the major charac-teristics of future sensor networks. In order to cope with thisheterogeneity, more and different modules can be added in thenodes depending on their capabilities. To avoid a myriad ofnodes that each support a different set of functionalities wepropose to use different classes of nodes by defining profiles.Based on their capabilities, we could e.g. define 3 types of


Cro

ss-la

yer

Middleware

Physical layer

Application Layer

Synchro-nization

Locali-zation

Data aggre-gation

Power manage-

ment

Neighbour discovery QoS Mobility

Medium Access Control Gateway

discovery

Advanced modules

Energy manage-

ment

Basic modules Optional modules

Network discovery

Basic routing

Network monitor-

ing

Advanced routing

Interest management

Basic transmission

control

Advanced transmission

control

Fig. 1. Proposed universal modular framework for sensor networks

nodes: lightweight nodes, advanced nodes and computingnodes. The lightweight nodes have very limited resources andwill only support the basic functionalities, hence only the basicmodules will be implemented. The advanced nodes are morepowerful. They will also implement the advanced functionalitywhich is needed for a scalable and energy efficient WSN. Thecomputing nodes are the most powerful and have a muchlarger battery capacity (e.g. connected to the power grid)and computing power. They will be equipped with optionalmodules that are not necessary for a proper operation of thenetwork, but they offer an added value for more advancedapplications, e.g. QoS or mobility support.

C. Example modules

We illustrate these principles with some example modules.• Each node will have a basic module taking care of

the basic transmission control. This module will handlethe segmentation, error correction and retransmission.More advanced nodes can also be equipped with anadvanced module which can buffer packets for batchtransmission. Finally, computing nodes can take care ofoptional transmission control functions, such as in-order-delivery and congestion control.

• Routing in lightweight nodes can be as simple as sendingall generated data packets to a nearby advanced orcomputing node. As advanced and computing nodes havefull-routing capabilities, they can create routes based oncriteria such as hop distance or remaining battery power.

• Some modules are only implemented in computing nodes,such as QoS and network monitoring. These servicescan be offered to the application even if only a smallsubsets of the nodes are computing nodes. For exam-ple, a computing node can provide QoS by examiningincoming packets, adjusting their priority to fulfill delay

requirements or duplicating them to a second route tofulfill reliability constraints.

D. Challenges when designing functional modulesDeveloping protocols in a modular way requires adjustments

on the approach of designing network protocols. Some chal-lenges when designing functional modules are the following:

• One has to determine the parameters to be exchanged inthe different modules. The performance increase should atleast compensate for the additional complexity introducedby the cross-modular interaction.

• There is a need to identify which parameters need to beoptimized at design-time and which at run-time.

• When designing modules, the interaction between dif-ferent modules should be thoroughly examined. For ex-ample, when choosing the next hop node, the decisionsof the routing module (shortest path) may interfere withdecisions of the energy management module (hop withmost remaining battery power). To avoid uncontrolledcompetition, a decision algorithm should be developed.

III. CONCLUSION AND FUTURE WORK

Current sensor networks have several key requirements thatcan not be supported using the traditional layered protocols.Support for energy-efficiency and heterogeneity has to beimplemented at an architectural level, not only in isolatedprotocols that do not take the layer interaction into account.Furthermore, in order to promote interoperability of protocolsand to reduce the cost of application development for sensornetworks, there is a strong need for an application independentsolution.

We proposed a universal applicable framework that, due toit’s modular design is exceptionally fitted to support energy-efficient protocols and heterogeneous networks.

Future work will focus on the design of modular protocolsand the possible methods for information exchange. Also, thefeasibility of the framework will be experimentally validatedin a hardware test bed.

ACKNOWLEDGMENT

This research is partly funded by the Belgian FederalScience Policy Office through the IAP V/11 contract, by theFund for Scientific Research - Flanders (F.W.O.-V., Belgium),by The Institute for the Promotion of Innovation through Sci-ence and Technology in Flanders (IWT-Vlaanderen) through aPhD.grant for B. Latre and Eli De Poorter and by the IBBT-WBA and IBBT-IM3 projects.

REFERENCES

[1] Akyildiz I., Kasimoglu, I.H., “Wireless Sensor and Actor Networks:Research Challenges.” Ad Hoc Network Journal (Elsevier), Vol. 2, No.4, pp. 351–367, October 2004

[2] ZigBee Alliance, http://www.zigbee.org[3] van Hoesel, L. Nieberg, T. J. W. Havinga, and P.J.M., “Prolonging the

lifetime of wireless sensor networks by cross-layer interaction,” WirelessCommunications, IEEE, vol. 11, Issue 6, pp. 78- 86, Dec. 2004.

[4] Melodia, T., Vuran, M. C., Pompili, D., “The State of the Art inCross-layer Design for Wireless Sensor Networks,”in Proceedings ofEuroNGI Workshops on Wireless and Mobility, Springer Lecture Noteson Computer Science, LNCS 388, Como, Italy, July 2005


Poster Abstract: Self-Configuration Middleware forSensor Localization in a Realistic Business Context

Nelson Matthys, Sam Michiels, Bart Elen, Wouter Joosen, Pierre VerbaetenIBBT-DistriNet Research Group, Department of Computer Science

K.U.Leuven, Celestijnenlaan 200A, B3001 Leuven, Belgium{nelson.matthys, sam.michiels}@cs.kuleuven.be

Abstract— Efficient and precise sensor localization must be de-ployed in a realistic business context, and must be automaticallydeployable at large scale. Moreover, localization techniques musthandle heterogeneous hardware, and they should be precise evenin the context of disturbing environment conditions. We presenta calibration mechanism that automatically configures sensornodes and that is able to handle heterogeneous sensor hardware.We apply autocalibration in the context of sensor localizationand we illustrate that our approach enables deploying a sensorlocalization service without cumbersome configuration of indi-vidual sensor nodes or quality loss. Our solution combines andoptimizes state-of-the-art distance measurement and localizationtechniques and integrates them in an end-to-end middlewareplatform, covering the sensor network, the application end pointsand the gateways in between.

I. I NTRODUCTION

Sensor localization is an important feature for various busi-ness applications of sensor networks. It requires an approachwhich is not only precise and efficient, but that also impliesminimal deployment cost. We define the deployment costas the investment to install and configure a sensor networkcapable to localize individual sensor nodes. A wide variety ofapplications like e.g. (1) a security monitoring application tolocalize sensor nodes attached to dangerous products insidea production hall, or (2) a surveillance application to locatefire fighters at a disaster scene, may benefit from such sensorlocalization mechanisms.

Configuring a sensor network to enable sensor localizationtypically involves two main actions: calibrating all sensornodes and upgrading a subset to anchor nodes (which havea known position in the network). When signal strengthis used for distance estimation between a pair of nodes,calibration determines the deviation of the signal strengthcharacteristics from reference sensor hardware, and applies theproper correction factor. This is necessary in order to com-bine measurements of individual sensor nodes with slightlydifferent hardware characteristics. After all nodes have beenconfigured, a sensor can be located by measuring its distanceto surrounding anchor nodes, and calculating its positiondata by applying techniques such as trilateration or n-hopmultilateration [4].

The minimization of the deployment costs for the previouslysketched applications is a non trivial task. They illustrate threeproblems that complicate sensor localization. First, a lot ofsensor applications involve an extensive amount of nodes.

This scale of deployment makes it impossible to manuallypre-configure each sensor node. Secondly, due to the naturalcontext of the applications, there will be mass produced sensornodes with slightly different hardware characteristics whichare moreover placed in different environmental conditions.This implies that the network installer should be aware of theimplementation details of the node and the physical conditionsof the environment. Finally, some applications like e.g. thelocalization of dangerous products require a considerableprecision of measurements and location determination.

Our solution to these three problems listed above is twofold.First, we need a precise and automated self-configuration ofeach sensor node, independent of hardware characteristics andof physical placement. Second, given the complexity of typicalbusiness applications, where heterogeneous user devices andback-end systems heavily rely on the data offered from oneor more sensor networks, we argue that there is definitely aneed for a middleware approach that offers support for thoseapplications. Since we argue that auto sensor configuration isan essential service in business applications, the middlewareplatform should incorporate and offer deployment support forit, as well as for other required sensor network services.

II. A UTO SENSORCONFIGURATION

Sensor configuration for localization purposes consists oftwo parts. There is the need for (1) calibration of the sensorhardware, and (2) configuration of the anchor nodes. Ourresearch currently focuses on an automatization of the firststep as some anchor-free localization schemes exist [5], [6]which do not require a configuration of the anchor nodes.

Since wireless radios differ from each other in both trans-mission strength and receiving sensitivity [2], they need tobe calibrated before they can be used to determinate internode distances with the help of RSSI. This calibration mustbe easy to perform and has to be scalable to hundreds or eventhousands of nodes. In traditional approaches, the nodes areplaced at known distances from reference nodes before beingcalibrated [1], [3]. This is impractical for large amounts ofsensor nodes, since it requires an accurate manual placementat the predefined distances. Our approach allows us to placethe sensor nodes at arbitrary distances from the referencenodes and to determine those distances automatically with anoptimized ranging method based on the TDoA of acousticsound that filters and corrects the distance measurements.


� � � � �

� � � � ��

� � � � � � � � � � � � � � � � � � �

� � � � �

��

� � � � ��

� � � � �

� � � � �

� � � � ��

� � �

� � � � �

��

� � � ��

� � � � � � � � �

� � � � � � �

� ��

ZigBee��

� � � � �

� � � � ��

� � ��

� � � ��

Sensor Network�

TCP/IP

Gateway Node

Calibration Reference Node

Sound Calibration

OS (TinyOS, SOS, ...)

OS (TinyOS, SOS, ...)

Sound Calibration

RSSILocalization

TemperatureSensing

MonitoringApplication

OS (Windows, Linux, ...) OS (Windows CE, Palm OS, ...)

Sensor Node

InstallerApplication

SecurityApplication

LocateLocateCalibrateLocate Temperature

Safety Officer Portable Installer PDA Safety Officer Mobile Phone

AircoApplication

Application Server

OS (Windows, Linux, ...)

SafetyApplication

Airco Control Locate Temp. DBMS...

OS (Symbian, Windows, Linux, ...)

AircoApplication

SafetyApplication

...

Fig. 1. The sensor network as a lightweight service platform on which a wide variety of applications can be installed, e.g. for automatic configuration,localization or airconditioning control. Application components are distributed over the sensor network, user devices and the gateway between the two entities.

The approach minimizes deployment costs by performingthe calibration process automatically, thereby preventing man-ual configuration. Due to the dynamic context of the sketchedapplications (with new nodes joining the network and othersbeing replaced), this approach also allows us to easily addadditional nodes to the sensor network and (re)calibrate themautomatically.

The results of our prototype implementation (on MICAzsensor nodes, with basic acoustic hardware) are very promis-ing. We have started from the current state-of-the-art indistance measurement via sound to determine the referencedistance for sensor calibration and we have optimized theapproach. First, our ranging method allows us to determinedistances up to eight meters on paved areas, with a maximalerror of 10 cm, between an individual node and a referencenode. Secondly, localization through automatically calibratednodes produces comparable results as in the literature withmanually configured nodes [4].

III. E ND-TO-END ARCHITECTURE

Deploying end-to-end sensor applications is highly complexgiven the very dynamic and heterogeneous environments inwhich they must operate. As illustrated in Figure 1, we meanwith end-to-end sensor applications, distributed applicationsover one or more wireless sensor networks, an enterprise back-end or user hosts, and a gateway between both entities. In thiscontext, we argue that sensor application developers must beoffered a generic middleware layer that can be customized toparticular sensor node types and to various applications. Thisimplies that we distribute and install the necessary componentson nodes, user hosts and the gateway based on the applicationpolicies and needs. The middleware must allow an easydeployment of those components on each device type and takecare of the interaction between corresponding components ondifferent entities.

In our prototype, each sensor node is provided with thenecessary components for self-configuration and localization,

while each user device is provided some middleware com-ponents that can interact with the corresponding componentsin the sensor network. The components at the user side oron the sensor nodes are generic enough to be reused fordifferent types of user or sensor applications such as a securitymonitoring or an inventory management application for mobileproducts.

IV. CONCLUSION AND FUTURE WORK

We have proposed a self-calibration mechanism for sensornodes that handles the complexity of realistic business ap-plications that use sensor networks. We have integrated thismechanism in an end-to-end middleware platform supportingthose applications. Sensor localization through self-calibratednodes significantly lowers the deployment costs and introducesno quality loss. There is however a need to further investigatethe optimization formula for distance determination in otherenvironmental conditions. In addition, our end-to-end architec-ture will be extended with other services, in order to furtherevaluate when and demonstrate how generic components canbe reused for different applications.

REFERENCES

[1] K. Whitehouse and D. Culler. Calibration as Parameter Estimation inSensor Networks. InProceedings of the 1st ACM international workshopon Wireless Sensor Networks and Applications (WSNA), pages 59–67,Atlanta, GA, USA, 2002.

[2] D. Lymberopoulos, Q. Lindsey and A. Savvides. An Empirical Charac-terization of Radio Signal Strength Variability in 3-D IEEE 802.15.4Networks Using Monopole Antennas. InProceedings of the ThirdEuropean Workshop on Wireless Sensor Networks (EWSN), pages 326–341, Zurich, Switzerland, 2006.

[3] J. Hightower, C. Vakili, G. Borriello and R. Want. Design andCalibration of the SpotON Ad-Hoc Location Sensing, August 2001.

[4] K. Langendoen and N. Reijers. Distributed localization in wirelesssensor networks: a quantitative comparison. InComputer Networks,43(4), pages 499–518, 2003.

[5] S. Capkun, M. Hamdi and J. Hubaux. GPS-Free Positioning in Mobilead-hoc Networks. InCluster Computing, 9(2), pages 157–167, 2002.

[6] A. Youssef and M. Younis, A. Agrawala. Accurate Anchor-Free NodeLocalization in Wireless Sensor Networks. InProceedings of the 24thInternational Performance Computing, and Communications Conference(IPCCC), pages 465–470, Phoenix, AZ, USA, 2005.


Poster Abstract: Meeting the Evolving ReliabilityRequirements for WSN Applications

Faisal Karim Shaikh, Abdelmajid Khelil and Neeraj SuriDepartment of Computer Science,

Technische Universitat Darmstadt, Germany{fkarim,khelil,suri}@informatik.tu-darmstadt.de

Abstract— Data transport (DT) is a core function for WirelessSensor Networks (WSNs) with different applications running onthe same WSN, and having varied requirements on the reliabilityof data delivery. Furthermore, application requirements mayevolve over time. Given that the DT reliability is a functionof the continuously changing network properties and protocolparameters, a framework for online adaptation of DT reliabilityis a major contribution to meet the evolving application require-ments for different network conditions. In this poster we sketcha novel approach that relies on the Reliability Block Diagramsto realize such a framework.

I. INTRODUCTION

Wireless Sensor Networks (WSNs) constitute a rapidlygrowing research area covering both a wide variety of de-vices and applications. Typical applications involve trackingor monitoring as (a) either statically as embedded sensorsor (b) dynamically as mobile (semi-) autonomous entities.Empirically the core function for a WSN is to collect data fromthe environment and transport it to a gateway node termed assink. The general data collection and dissemination processinvolves the flow of the raw data from source nodes towardsthe sink.

A WSN may be designed for different missions, i.e.,different applications can run on the same WSN. A WSNdeployed for fire detection in a forest can also be utilizedfor other tasks, such as measuring the humidity in forest.The application requires the fire to be detected and reportedwith high reliability whereas the delivery reliability requiredto measure the humidity may be relatively low. Clearly, thedifferent applications have different requirements on the reli-ability of Data Transport (DT). In addition, the requirementsof the same application may evolve in time, for exampleif the mission of the WSN changes. Considering the aboveexample, after the detection of fire and notifying the user,the (fire detection) application should stop reporting the fireand continue reporting the perimeter of the fire field. Asthe applications main task, reporting the fire detection, isaccomplished, the delivery reliability of the perimeter of thefire may be tolerable.

Furthermore, the WSN is obviously subject to a widerange of computing and communication level perturbations,changing the WSN properties over time which affects thereliability of DT. For example, the number of nodes in WSNare changing due to node crashes and new node deployments.The link quality may vary over time due to variable network

load or environmental conditions. To overcome the changingproperties of WSN, the DT protocols use different parame-ters such as retransmissions, number of nodes detecting thephenomenon etc.

The problem becomes of how to tune the DT protocol pa-rameters to adapt to both the evolving application requirementsand network properties. Most of existing effort for protocoladaptation focus on tolerating the changes in network proper-ties and not on application requirements [1]. In [2] a genericadaptation architecture is defined, which is unfortunately validonly for a specific class of applications, i.e., for code update.The above works show how adaptation is beneficial in dynamicand erratic WSNs and serve as a basis to introduce adaptivebehavior into these multifaceted systems.

We use Reliability Block Diagram (RBD) to analyticallyexpress the delivery reliability [3]. Section II presents brieflyhow reliability of DT is modeled using RBD. Using theseRBD’s sensor nodes are aware of inverse functions andcan adapt the DT parameters online to achieve the desiredreliability of application over time. Section III details theproposed online adaptation mechanism for evolving needs ofWSN applications.

II. MODELING THE RELIABILITY OF DATA TRANSPORT

We define DT in WSNs as a set of operations carried out onraw data from its generation till the phenomenon is reportedto the sink. The decomposition of the data transport intooperations simplifies the computation of the overall reliability.The reliability of data transport depends on the reliability ofeach operation. If one of the operation fails, then the overalldata transport fails. We model these operations by means ofRBD [3].

To understand the concept of online adaptation in Sec-tion III let us consider a representative DT protocol, ReliableMulti-Segment Transport (RMST) [4]. Operations for DT fromthe source to the sink in RMST are routing and MessageLoss Detection (MLD). MLD is used for retransmission ofmissing messages. For reliable delivery in RMST, a missingmessage is detected by Selective Negative Acknowledgmentmechanism and is retransmitted by the node. The failure ofone retransmission does not result in the failure of overalldata transport. This effect is shown as parallel RBD blocksfor RMST in Figure 1.


routing

routing1

routingr

MLD

MLD

r = number of retransmissions

MLD = message loss detection

Sink

Source

Fig. 1. Reliability Block Diagram for RMST

Using Figure 1, the reliability of RMST R is calculated asfollows:

R = 1− {(1−RR) ∗ (1− (RR ∗RMLD))r} (1)

where RR is the routing reliability, RMLD the reliability ofMLD and r is number of retransmissions. RR and RMLD

depend upon WSN properties, i.e., number of nodes, networkconditions etc. The DT protocol parameter r plays an impor-tant role in the reliability of the data transport.

III. ONLINE ADAPTATION FOR DT RELIABILITY

The reliability of a DT protocol is a function of (a) WSNproperties and (b) protocol parameters. Unlike the protocolparameters, WSN properties are difficult to control in time.In most of the application scenarios it is difficult to redeploythe new nodes, or to avoid crashing of nodes due to energydepletion. On the other hand protocol parameters can be tuned,provided the adaptation mechanisms are available. The RBDestablishes a relationship between WSN properties, protocolparameters and the reliability. Protocol designers can utilizethis relationship and implement simple decisions at deploy-ment.

Online adaptation of protocols can be easily achieved bytuning the protocol parameters according to current networkconditions. Assuming, at time to application requirementsfor delivery reliability Ro are available to DT protocol, e.g.,sink disseminates the application requirements to the nodes.Also the current network properties at to are available to DTprotocol, e.g., via routing layer, facilitating the DT protocolto computes the protocol parameters. As shown in Figure 2,considering RMST for instance, RRo and RMLDo reflect thecurrent network conditions. Wireless sensor nodes can keeptrack of network conditions either locally or sink can dissem-inate this information. Consequently, the protocol parameterro can be computed by using inverse function of Equation (1)as follows:

ro =log(1−Ro/1−RRo

)log(1− (RRo

∗RMLDo))(2)

If RR or RMLD varies over time, r will be tuned appropri-ately such that the required degree of reliability is maintained.

Application

Routing Layer

At time to

R= Ro

At time t

RR = RRo

At time t

RMLD = RMLDo

At time tor = ro

DT Protocol

log(1 /1 )

log(1 * )

o

o o

o R

o

R MLD

R Rr

R R

− −=

−

Fig. 2. Online adaptation for RMST

Similarly if the application varies its requirement for deliveryreliability, r will be tuned to attain the level required byapplication.

In the future, we plan to expand the framework focusingon different mechanisms for nodes to be aware of applicationrequirements using the requirement analysis presented in [5].Also we are focusing on developing efficient and scalablemechanisms to calculate the reliabilities of different operationsfor DT, e.g., RR and RMLD.

ACKNOWLEDGMENT

This research is supported in part by MUET, NoE ReSISTand DFG GRK 1362 (TUD GK)

REFERENCES

[1] T. He, B. M. Blum, J. A. Stankovic and T. Abdelzaher, AIDA: Adaptiveapplication-independent data aggregation in wireless sensor networks,Trans. on Embedded Computing Sys., 3(2):426–457, 2004.

[2] P. J. Marron, D. Minder, A. Lachenmann and K. Rothermel, TinyCubus:An Adaptive Cross-Layer Framework for Sensor Networks, it -Information Technology, 47(2):89–97, 2005.

[3] F. K. Shaikh, A. Khelil and N. Suri, On Modeling the Reliability ofData Transport in Wireless Sensor Networks, Euromicro Conference onParallel, Distributed and Network-based Processing (to appear),2007.

[4] F. Stann and J. Heidemann, RMST: Reliable Data Transport in SensorNetworks, International Workshop on Sensor Network Protocols andApplications, pages 102-112, 2003.

[5] D. Chen and P. K. Varshney, QoS Support in Wireless Sensor Networks:A Survey, International Conference on Wireless Networks, 2004.


Poster Abstract: Radio Design for Ultra Low-Power and Ultra-Wideband

Wireless Sensor Nodes Ting Fu, Guido Dolmans, Olivier Rousseaux, Li Huang, Bert Gyselinckx, Holst Centre / IMEC-NL, Eindhoven, the Netherlands, Julien Ryckaert, IMEC, Leuven, Belgium, Stefano D’Amico, Andrea Baschirotto, Università degli Studi di Lecce, Lecce, Italy

Abstract—An ultra low-power radio system based on ultra-

wideband (UWB) communications is presented in this paper. The 180nm CMOS UWB transmitter generates position-modulated pulses that comply with the FCC regulation mask. It operates between 3GHz and 5GHz and the signal bandwidth can be tuned from 500MHz up to 2GHz. The power consumption of it without VCO calibration is 50pJ/pulse. The receiver that is able to efficiently demodulate the UWB signal is also developed in 180 nm CMOS. The receiver has a higher power consumption than the transmitter: 28 mW at a pulse rate of 20 MHz, or 1.4 nJ/received pulse. In a second receiver design, a baseband VGA with 6 gain stages is employed and an offset compensation system is introduced.

Index Terms—Ultra low-power, ultra-wideband, wireless sensor nodes, CMOS transceiver

I. INTRODUCTION HE autonomy of today’s wireless sensor networks is seriously limited by their power consumption. Wireless

communication is typically a major power drain in these systems, consuming up to 70% of the total power budget. In order to allow micro power scavenging from waste energy, the radio in the autonomous sensor networks will have to operate at an average power of 20µW. However, low power ISM band radios such as today’s Bluetooth and Zigbee implementations cannot meet these stringent power requirements. In this power-constrained context, the emerging UWB air interface has been selected because it supports such a system partitioning that allows the use of an ultra-low-power, low-complexity transceiver.

In this paper the ultra low-power and UWB transceiver is presented. Section II presents the pulser of the transmitter. A first receiver design with demo setup and a second receiver layout are presented in section III. The conclusions are drawn in Section IV.

II. TRANSMITTER DESIGN Low data rate and low power applications typically require

the radio to operate in bursts. A higher data rate during the burst means a higher duty-cycling on the radio. The power consumption is minimized for a fixed average data rate. In

pulse-based UWB, the transmitter only needs to operate during the pulse transmission, producing a second duty cycle inside the burst. For example, if ten pulses are used to code one bit, our transmitter can achieve an average data rate of 10kbps with as little as 5μW average power consumption.

A. Pulser Architecture The architecture in Figure 1 is subdivided into 5 basic

functions. The PPM modulator enables the rest of the blocks at a variable time instant with respect to a clock instant. This enable signal activates two blocks. First the pulse shaping, creating an envelope for the pulse, which in this implementation is a triangle with a tunable duration. This signal also activates a circuit creating a ring activation signal, which is required to turn on and off the ring oscillator. The center frequency of the ring oscillator block is tunable. A ring oscillator is used here for its fast startup time and since phase noise is not an important requirement in our system. Both the oscillating signal and the triangular pulse are then feeding a mixer providing an up-conversion of the triangle shape to the center frequency defined by the oscillator. Finally an antenna adaptation block provides the interface with the antenna.

PPM Modulator

Ring Oscillator

Pulse Shaping

Ring activation

Antenna adaptation

Data

Fc

Tpos

Bw Pout

PPM Modulator

Ring Oscillator

Pulse Shaping

Ring activation

Antenna adaptation

Data

Fc

Tpos

Bw Pout

Figure 1: Architecture of Pulser UWB transmitter

B. Duty cycling and signal output The power saving scheme is outlined in Figure 2. Most

duty-cycling schemes cycles between the on- and off-state of the radio. The scheme of this paper performs duty cycling of active and idle states during the radio burst. This is called signal duty cycling, which enables enhanced power reduction.

T


Figure 2: Signal duty cycling of the pulse waveforms

The realized UWB pulser is shown in Figure 3. It offers a maximum of 2GHz signal bandwidth, useful for positioning applications, and a minimum of 500MHz, which could be required for channelized systems. We have proven the feasibility of this ultra-low power UWB transmitter in 0.18um CMOS technology at 3-5GHz. The transmitter is fully integrated and realizes smooth pulse shapes to facilitate the filtering of the transmit signal into the FCC mask or eventually to another specific signal mask for channelized systems.

Figure 3: Chip, RF board and demo of the UWB pulser

The measured time waveforms of overlapping pulses representing pulse-position modulations (PPM) for 528MHz (top) and 2GHz bandwidths (bottom) are shown in Figure 4.

Figure 4: Transmitted UWB pulser signals

III. RECEIVER DESIGN The carrier-based impulse response (CB-IR) approach has

been proposed as an alternative signal scheme for sufficient flexibility while keeping the system complexity as low as possible. The receiver architecture is a direct down-conversion architecture with an analog quadrature correlator, see Figure 5. A downconverted CB-IR signal has a bandwidth that still

spans a few hundreds of MHz. The digital processing of such signals usually requires a fast sampling in the ADC and a high frequency clock generator. Here, the complete pulse correlation is in the analog domain, sampling can be done at the pulse rate. Since the receiver features pulse position modulation (PPM), one sample is taken at each possible position.

ADC

ADC

TimingGenerator

Coarse DL Fine DL

ADC CAL

ADC CAL

Delay Line Block

Configuration data

Chip Controller

LNA

I

Q

LO

LPF

LPF

Freq

PC

FPGA

Clock Reset

Offset Q

Offset I

Out Q Out I

IN

System Clock

Clock/Reset Generator

ADC

ADC

TimingGenerator

Coarse DL Fine DL

ADC CAL

ADC CAL

Delay Line Block

Configuration data

Chip Controller

LNA

I

Q

LO

LPF

LPF

Freq

PC

FPGA

Clock Reset

Offset Q

Offset I

Out Q Out I

IN

System Clock

Clock/Reset Generator

Figure 5: Architecture of the quad analog correlation receiver

The total current consumption of the chip including the digital baseband is 16mA measured on a 1.8V supply at 20MHz clock rate. The chip photograph is shown in Figure 6.

3ns UWB Pulses over the air

Figure 6: First receiver chip

In our second receiver design, a new baseband VGA with programmable gain and offset compensation system is employed. It has 6 gain stages from 0dB to 15dB. A current-steering DAC has been used for the offset compensation on the integrator output nodes. The layout of second receiver is shown in Figure 7.

NEW VGA

Figure 7: Second receiver layout with new six gain-stage VGA and offset compensation circuits

IV. CONCLUSION An UWB transceiver has demonstrated the feasibility of

pulse UWB communication with low power consumption.

V. REFERENCES [1] J. Ryckaert et al. “A 16mA UWB 3-to-5GHz 20Mpulses/s quadrature analog correlation receiver in 0.18um CMOS”, ISSCC Digest of Technical Papers, pp 114-115, Feb. 2006. [2] J. Ryckaert et al. “Carrier-Based UWB Impulse Radio: Simplicity, Flexibility, and Pulser Implementation in 0.18-micron CMOS”, ICU, pp 432-437, Sept. 2005


Poster Abstract: Rime — A Lightweight LayeredCommunication Stack for Sensor Networks

Adam Dunkels, Swedish Institute of Computer [email protected]

Abstract— Early work in sensor networks found traditionallayered communication architectures too restrictive and proposedcross-layer optimizations. Recent work in data aggregation, how-ever, argues that the complexity of cross-layer optimizations maylead to fragile and unmanageable systems. This has inspiredus tocreate Rime, a layered communication stack for sensor networks,with much tinner layers than traditional architectures. Ri meis designed to simplify the implementation of communicationprotocols. A preliminary evaluation suggests that Rime maybeable to significantly reduce the implementation complexityofsensor network protocols with only a small increase in resourcerequirements, hinting that a layered stack may be a suitablecommunication abstraction even for sensor networks.

I. I NTRODUCTION

Early work in sensor networks found that traditional layeredcommunication architectures were too restrictive for sensornetworks [5]. Instead, radical cross-layer optimizationswereinvestigated, where e.g. high-level abstractions were imple-mented at a low level [8]. Recent work in data aggregation [6],however, argues that complex cross-layer optimizations fordata aggregation leads to fragile and unmanageable systems.Instead, a more traditional, layered, architecture is proposedand found to be nearly as efficient as cross-layer aggregationarchitecture. This move towards a more traditional architec-ture for data aggregation have inspired us to revisit layeredcommunication abstractions for sensor networks.

The contribution of this paper is Rime, a lightweight layeredcommunication stack for sensor networks. Rime is differentfrom traditional layered network architectures such as theInternet architecture in that the layers in Rime are unusuallythin. Rime draws heavily from communication abstractions fordistributed programming [7] where layers of simple abstrac-tions are combined to form powerful high-level abstractions.

The purpose of Rime is to simplify implementation ofsensor network protocols and facilitate code reuse. We haveimplemented Rime in Contiki [3] and a preliminary evaluationsuggests that Rime can significantly simplify protocol imple-mentation with only a small increase in resource requirements.The code footprint of Rime is less than two kilobytes and thedata memory requirements on the order of tens of bytes.

Rime is designed to be much simpler than existing pro-posals for modular communication abstractions for sensornetworks [4], [9]; Rime does not allow for a fully modularstructure where any module can be replaced, but enforces astrict layering structure where only the lowest layer and theapplication layer can be replaced.

Multi−hopSingle−hop

unicastSingle−hop

ribcbrucb

suc

uc

ruc ribc

sibc

ibc

abc

nfb

nf

Bulk transfer

Reliable transmission

Identified sender

Anonymous broadcast

Stubborn transmission

broadcast

Fig. 1. The current Rime stack. More protocols and layers maybe added.

II. R IME

Rime is organized in layers as shown in Figure 1. Thelayers are designed to be extremely simple, both in termsof interface and implementation. Each layer adds its ownheader to outgoing messages. Because Rime layers are simple,individual headers are very small; typically a few bytes each.

The thin layers in Rime enable code reuse within the stack.For example, reliable communication is not implemented ina single layer but divided into two layers, one that imple-ments acknowledgments and sequencing, and one that resendsmessages until the upper layer tells it to stop. We call thelatter layerstubborn. A stubborn layer is not only used byreliable protocols but also by protocols that send periodicmessages such as neighbor maintenance for routing protocolsand repeated transmission of messages in Rime’s networkflooding layer (nf). Figure 2 shows how a hop-by-hop reliabledata collection protocol implemented with Rime’s stubbornidentified best effort broadcast, sibc, and reliable unicast, ruc.

The lowest level primitive in Rime is anonymous best-effort broadcast, abc. The abc layer provides a 16-bit channelabstraction but no node addressing; it is added by upper layers.The identified sender best-effort broadcast, ibc, adds a senderidentity header field and the unicast abstraction, uc, adds areceiver header field.

An underlying MAC or link layer may chose to implementparts of the Rime stack, such as the abc, ibc, or uc layers, inhardware or firmware.

A. Shifting the Burden from Applications to the System Core

One of the basic ideas of Rime is to shift the burden, interms of memory footprint, from protocol implementations toRime. By making Rime part of Contiki’s system core, whichis always present in memory, loadable programs are madesmaller. Consequently, the energy consumption for programloading [2] is reduced.


sibc_received(node_id from) {neighbor_add_or_update(from, signal_strength());recalculate_hops_from_sink();

}

ruc_received(node_id from) {if(we_are_the_sink) {

print_to_serial(packet_data);} else if(we_have_a_route) {

ruc_send(neighbor_best(), packet_data);}

}

datacollection_process() {ruc_setup(DATA_CHANNEL);sibc_setup(NEIGHBOR_CHANNEL);sibc_send(hello_message);while(1) {

wait_until(sensor_event);ruc_send(neighbor_best(), sensor_data);

}}

Fig. 2. Hop-by-hop reliable data collection protocol implemented with Rime.

B. Buffer Management

To reduce memory footprint Rime uses a single buffer forboth incoming and outgoing packets similar to uIP [1]. Layersthat need to queue data, e.g. a stubborn protocol or a MAClayer, copy the data to dynamically allocated queue buffers.

III. PRELIMINARY EVALUATION

A. Memory Footprint

The code memory footprint of individual Rime modules issmall. The smallest module currently is ibc, identified senderbest-effort broadcast, with a footprint of only 100 bytes.Stubborn unicast and reliable unicast are the largest with acode footprint of 226 bytes. The current total footprint of Rimeis less than two kilobytes but will increase with more features.

Each Rime layer requires between two and four bytes ofRAM per connection. The stubborn layers currently need anextra 18 bytes of RAM because of the retransmission timer,which currently requires 16 bytes of state. Much of this is,however, due to the current timer implementation in Rime notbeing optimized for a low memory footprint.

B. Hop-by-hop Reliable Data Collection Routing Protocol

We evaluate Rime by reimplementing Treeroute, Contiki’shop-by-hop reliable data collection routing protocol, withRime. We compare the resulting lines of code and footprintwith the existing implementation. The results suggest thatRime can significantly reduce the complexity of protocolimplementations for sensor networks.

For this preliminary evaluation, the reimplementation doesnot fully conform to the existing implementation. The exist-ing implementation uses implicit acknowledgments while thereimplementation uses explicit acknowledgments because wehave not yet implemented implicit acknowledgments in Rime.

The results of the reimplementation are shown in Table I.Lines of code are measured without comments. Both imple-mentations are compiled with GCC 3.2.3 for the MSP430microcontroller. The code footprint for the reimplementedpro-tocol does not include the code footprint of the Rime modules.

TABLE I

EXISTING IMPLEMENTATION AND REIMPLEMENTATION OF CONTIKI ’ S

TREEROUTE DATA COLLECTION ROUTING PROTOCOL.

Existing With RimeLines of code 439 179Code footprint (bytes) 2064 772Memory footprint (bytes) 180 110Packet header size (bytes) 8 10

The memory footprint does, however, include the memoryfootprint of the Rime modules. The table shows a significantreduction in program size and a slight increase in header size.One of the extra header bytes for the reimplementation is dueto the use of explicit acknowledgments. The second extra byteis because the ruc layer uses an entire byte for a single-bit flag.We expect that a header packing mechanism that we plan toimplement will reduce the header size.

Although the reduction in code and memory footprint forthe reimplementation of the data collection protocol moduleis significant, the total code footprint for the data collectionprotocol and the Rime modules is slightly larger than that ofthe existing data collection implementation. In a system usingRime the footprint of the Rime modules is, however, amortizedover all protocols and applications using Rime. Therefore weexpect that, overall, Rime will reduce the total memory andcode footprint for systems using Rime.

IV. CONCLUSIONS

Our preliminary evaluation suggests that Rime may be ableto significantly reduce complexity of sensor network proto-col implementations, with only a small increase in resourcerequirements. If these results would continue to hold truefor a more thorough evaluation, this suggests that a layeredstack could be a suitable communication abstraction even forwireless sensor networks.

ACKNOWLEDGMENTS

This work was partly financed by VINNOVA and theEuropean Commission under contract IST-004536-RUNES.

REFERENCES

[1] A. Dunkels. Full TCP/IP for 8-bit architectures. InMobiSys’03, 2003.[2] A. Dunkels, N. Finne, J. Eriksson, and T. Voigt. Run-timedynamic linking

for reprogramming wireless sensor networks. InACM SenSys’06, 2006.[3] A. Dunkels, B. Gronvall, and T. Voigt. Contiki - a lightweight and flexible

operating system for tiny networked sensors. InIEEE Emnets-I, 2004.[4] C. Ee, R. Fonseca, S. Kim, D. Moon, A. Tavakoli, D. Culler,S. Shenker,

and I. Stoica. A modular network layer for sensornets. InProceedingsof OSDI, November 2006.

[5] D. Estrin, R. Govindan, J. Heidemann, and S. Kumar. Next centurychallenges: Scalable coordination in sensor networks. InProceedings ofACM/IEEE MobiCom, August 1999.

[6] O. Gnawali, K. Jang, J. Paek, M. Vieira, R. Govindan, B. Greenstein,A. Joki, D. Estrin, and E. Kohler. The tenet architecture fortiered sensornetworks. InACM SenSys ’06, November 2006.

[7] R. Guerraoui and L. Rodrigues.Introduction to Reliable DistributedProgramming. Springer, 2006.

[8] J. S. Heidemann, F. Silva, C. Intanagonwiwat, R. Govindan, D. Estrin, andD. Ganesan. Building efficient wireless sensor networks with low-levelnaming. InSymposium on Operating Systems Principles, 2001.

[9] J. Polastre, J. Hui, P. Levis, J. Zhao, D. Culler, S. Shenker, and I Stoica.A unifying link abstraction for wireless sensor networks. In SenSys, 2005.


Abstract—Available simulation frameworks for wireless

sensor networks can be divided into groups. The first groupconsists of tools that come with a huge library of protocols andmodules which allow the generation of simulations withoutmuch effort. The second group is represented by mathematictools that are optimized for complex calculations and resultevaluation. In this paper a co-simulation framework whichcombines the strength of both groups in order to achieve highperformance and reusability is introduced.

Index Terms—co-simulation, framework, sensor nodes,wireless

I. INTRODUCTION

N this paper we present a framework for performancecomparison of different wireless sensor mechanisms

which is currently under development. First of all, we haveto admit that there are already several simulation programsavailable [1] with a library to simulate wireless sensornetworks.The reason why we are going to implement a newframework lies in the fact that we want to improve flexibilityand performance. As shown in [2] co-simulation can be usedin many different cases to handle the complexity ofsimulations. In addition, co-simulation offers the possibilityto distribute calculations among different computers. As aresult complex scenarios can be simulated without the needof expensive workstations.

Commercial simulation tools have strengths andweaknesses. On the one hand analytical tools like MATLABoffer fast implementation of high level simulations with verygood performance. On the other hand programming acomplex network simulation including the entire ISO/OSIstack is very time consuming. Simulation tools like NS2 orOPNET offer a huge library of existing network protocols.Thus, they are favored if a detailed simulation of all layers isneeded. Furthermore, their library includes routing protocolsand detailed link layer modules. Therefore, they seem to bethe first choice when simulating wireless sensor networks.Nevertheless, these simulation tools have weak spots as well.

Instead of using a single simulation tool like [3] and [4] tosimulate wireless sensor networks, we want to takeadvantage of a powerful calculation tool as well. Thesolution to compensate the lacks of functionality in eachsimulation tool lies in co-simulation. We consider a co-

Alexander Klein is with the EADS Corporate Research Center,Ottobrunn, Germany. (e-mail: [email protected]).

simulation framework using MATLAB and OPNET via aHigh Level Architecture (HLA) interface as first choice tocombine the strength of both simulation tools.

The HLA interface allows us to exchange informationbetween MATLAB and OPNET while the simulation is inprogress. Signals, statistics and calculated values can beexchanged between both simulation tools without savingthem to a hard disk. Thus, performance is increased. Anotherapplication for co-simulation is represented by simulation ofthe environment. The signal sensed by the sensor nodes inthe OPNET simulation can be generated by a process run byMATLAB. Beside the advantages that result from co-simulation additional advantages have to be taken intoaccount. One goal of the co-simulation approach is to speedup the time needed to implement a simulation. Therefore, weare going to build a framework that encapsulates simulationrelevant mechanisms in reusable process modules. Thisallows us to compare different kinds of mechanisms in theirperformance without the need for reprogramming eachmodule. Moreover, we try to simulate each module in thesimulation tool that offers the best trade-off betweenperformance and programming effort.

II. WIRELESS SENSOR SIMULATION FRAMEWORK

As mentioned in the previous section the frameworkconsists of several simulation modules to increase thereusability of the programming code. Beside the advantageof reusability the framework allows the distribution of themodules on different computers. In this case the modulesimplemented in OPNET work as interfaces which exchangeinformation via the HLA interface. The calculation withinthe modules is done on other computers. Thus, lesscomputing power and memory is needed on the computerrunning the OPNET simulation software. For this reason it ispossible to simulate larger scenarios without reducing thesimulation performance in a significant way due to hard discaccess.

Figure 1 shows the node model of the frameworkimplemented in OPNET. Each module consists of a finitestate machine which describes the behavior of each process.C code is used to describe the functionality of the states andtransitions. The dashed lines in Fig. 1 represent statisticwires. The destination process is informed by the sourceprocess when a certain event has occurred. A rising edge ofa receiver signal e.g. signalizes a busy channel. The solidlines indicate data streams. They allow directcommunication between the modules. Nevertheless, modulesmay interact with each other without the presence of a data

Poster Abstract: A Co-Simulation Frameworkfor Performance Comparison of

Wireless Sensor NetworksAlexander Klein

I


stream. The environment module and the statistic modulemake use of the connectionless communication betweendifferent processes supported by the OPNET simulationtool.

Fig. 1. OPNET Node Model of the Framework

An enumeration of the modules and a brief descriptionof their functionalities are given in the following points:

1) The framework includes an energy module which issplit up into three smaller modules. A battery module isresponsible for indication of the energy exhaustion andcalculation of battery charge and discharge. An energyproducer module is implemented that calculatesproduced energy which may be gathered e.g. by solarcells. The energy module is completed by a powermodule that calculates the overall energy consumptionof the sensor node.

2) We are considering an environment moduleimplemented in MATLAB that is responsible forgenerating signals measured by the sensor nodes e.g.heat, humidity, or solar radiation. Furthermore, themodule may generate physical events that lead totemporary or permanent node failures.

3) The framework will include a mobility modelimplemented in MATLAB to support variable complextrajectories to compare the performance of wirelesssensor mechanisms under mobile conditions.

4) The traffic module offers the possibility to simulateapplication driven traffic flows as well as eventtriggered traffic.

5) In addition, we are going to implement an overheadmodule that evaluates the received traffic from higherlayers to measure the generated overhead of eachparticular layer.

6) Furthermore, a statistic process is implemented inOPNET that collects all values from the otherframework modules. In order to achieve highperformance, the collected values are forwarded toMATLAB via the HLA interface. The part implementedin MATLAB is responsible for evaluation andpresentation of the collected values e.g. routingtopology, traffic characteristic, overhead, sensedsignals, and energy consumption.

7) The routing module uses a pre-defined interface and isimplemented for the comparison of different routingprotocols and mechanisms. In addition, the metric of thelink costs can be adopted to simplify parameter studies.

8) The most important module is represented by the radiochannel module. It supports many features to speed upthe simulation. We implemented standard features suchas the definition of receiver groups. Thus, signalstrength and bit error calculation are only done by acertain number of sensor nodes for which thesecalculations make sense. The nodes within the receivergroup can be chosen according to a disk model or aconnectivity graph that may be calculated in advance ifthere is no mobility in the simulated scenario. Theconnectivity graph defines the receiver groups in moredetail. Therefore, it offers some advantage in scenarioswith high node density.

Beside these modules additional modules that simulate theTCP/IP layers can be added to the framework. It has to bekept in mind that a larger stack requires more calculations.Thus, the performance of the simulation decreases.

III. CONCLUSION

Co-simulation will become more and more important in thenear future of wireless sensor simulations because itimproves the performance of complex simulations withoutreducing the flexibility and the reusability of the programcode. Nevertheless, it is clear that a large library is needed inorder to take the full advantage of the framework. Futurework will include the extension of the existing library toallow the performance comparison of new wireless sensormechanisms.

REFERENCES

[1] E. Ekic, Y. Gu, and D. Bozdag, “Mobility-Based Communication inWireless Sensor Networks”, IEEE Communication Magazine, vol. 44,pp.56–79, July 2006.

[2] M. Anderson, D. Henriksson, A. Cervin, and K. Arzen, “Simulationof Wireless Network Control Systems”, Proc. 44 th IEEE Conf. onDecision and Control, University of Lund, Sweden, 2005.

[3] X. Li, “Multipath Routing and QoS Provisioning in Mobile Ad hocNetworks”, PhD thesis, University of London, Queen Mary, UnitedKingdom, 2006.

[4] E. Oyman, “Multiple Sink Location Problem and Energy Efficiencyin Large Scale Wireless Sensor Networks”, PhD thesis, UniversityBogazici, Istanbul, Turkey, 2004.


Poster Abstract: A Multihop Path WakeupMechanism For Dual-Radio Sensor Networks

Thanos Stathopoulos†

Martin Lukac†

Dustin McIntire♯

John Heidemann‡

Deborah Estrin†

William J. Kaiser♯

Center for Embedded Networked Sensing† UCLA, Department of Computer Science

♯ UCLA, Department of Electrical Engineering

‡ USC, Information Sciences Institute

{[email protected], [email protected], [email protected], [email protected], [email protected], [email protected]}

Abstract— Dual-radio, dual-processor nodes are an emergingclass of Wireless Sensor Network devices that provide both low-energy operation as well as substantially increased computationalperformance and communication bandwidth for applications.This paper describes a multihop path wakeup mechanism thatestablishes end-to-end paths in a network of dual-radio nodesusing the secondary radios as a control channel toselectively wakeup nodes along the desired path. Using testbed experiments, weshow that our proposed mechanism provides significant energysavings of more than60% compared to alternative approacheswith only slightly greater application latency.

I. I NTRODUCTION

Ever-increasing application demands in conjunction withadvances in low-power hardware design have resulted in anincreasing use of larger, more powerful sensor nodes [1], [2].To satisfy the seemingly conflicting application requirementsfor extended lifetime, large data transfer size and low latency,a new generation of 32-bit nodes as for example the LEAPnode [2] include an on-board low-power microcontroller (forconstantly vigilant operation) and asecond, low-bandwidthradio, in addition to the main 32-bit CPU and high-bandwidth802.11 radio. Such nodes can therefore operate in low-powermode for extended periods of time and switch to high-powerhigh-performance mode when needed.

In a multihop network of nodes that maintain their mainCPU and high-bandwidth radio in a low operating duty cycleso as to conserve energy, end-to-end paths do not always exist.A periodic wakeup algorithm can solve this problem when awell-established model for the observed phenomenon exists.When such a model does not exist and may not be learned asin seismic event detection, or whentimely notification of anevent is required, as in intrusion detection, a periodic algorithmcannot satisfy both low energy and low latency requirements.

In this paper, we propose a multihop path establishmentmechanism for dual-radio nodes. The mechanism uses thevigilant low-power radios to activate an end-to-end path inthe mostly-off high-bandwidth radios, for high volumes ofdata traffic. Prior work in multi-radio systems has exploredthe single-hop path wakeup scenario [3], while our focus is on

multihop path establishment, using the low-bandwidth radiosas a multihop control channel. In Section II we describe ourapproach as well as alternative approaches that we considered.We present and discuss our results in Section III.

II. T HE WAKE-PATH MECHANISM

In our proposed approach, calledwake-path the nodes’main processor and high-bandwidth radio are usually powereddown, while the microcontroller and low-power radio are keptalways on. When an important event occurs, only anecessarysubset of nodes are powered up, in order to form the end-to-end path and allow data to be transferred.

Specifically, a node wishing to communicate with anothernode over 802.11 uses its low-bandwidth radio to connect toa specific node, called thetopology controller and request anend-to-end path to a particular destination. The controller thendecides which nodes to wake up based on cached informationabout high-bandwidth routing paths (obtained during a timewhen the entire network was up) and sends the appropriaterequests to other nodes, again using the low-bandwidth radio.When nodes receive the wakeup request, they turn on theirCPU and high-bandwidth radio so that the end-to-end datatransfer can start.

Since our mechanism relies on the low-bandwidth networkfor establishing a path over 802.11, we assume that bothnetworks (low- and high-bandwidth) areconnected and notpartitioned. We note that this assumptiondoes not mean thatthe two network topologies match; in fact, our mechanismutilizes two independent routing protocols, one for each topol-ogy. In particular, in our implementation we used DSR [4] for802.11 routing and CentRoute [5], a centralized on-demandmote routing protocol as our low-bandwidth routing protocol.

The topology controller receives routing input from DSRin order to build up its cache of paths to all other nodes inthe network. When a path request arrives over CentRoute thecontroller consults its paths cache and selects the appropriatenodes for the wakeup based on the most recent valid 802.11path that existed before the nodes were put to sleep. It


0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 2 3 4 5 6Ene

rgy

Con

sum

ptio

n R

atio

(W

ake-

Pat

h / W

ake-

All)

Path length (number of nodes)

40 MBytes

4 MBytes

400 KBytes

Fig. 1. Energy consumption ratio ofwake-path versuswake-all as a functionof path length for 400KByte, 4MByte and 40MByte data transfers.

then dispatches wakeup control packets to those nodes overCentRoute and waits for those nodes to confirm that they haveturned on their main CPU.

In addition to ourWake-path mechanism, we also consid-eredwake-all as a point of comparison. Inwake-all, the nodeskeep their main processor and high-bandwidth radio powereddown butall nodes are powered up when an event occurs. Thissystem is a more general case of ourwake-path approach andis expected to have lower latency thanwake-path but higherenergy consumption.

III. R ESULTS AND DISCUSSION

In order to measure the energy consumption and latency ofour mechanism, we conducted experiments using our testbedof 11 Stargate nodes, each with a Mica-2 node attached.During our initial experiments, we discovered that even thoughthe 802.11b link topology was adequately connected, theCC1000 topology was partitioned. Therefore we used14 extrastandalone motes to augment the mote topology.

We ran our tests using the EmStar framework [6]. Ourmote-specific code used the EmTOS [7] emulation module ofEmStar. The sleep and wakeup process on the Stargate hard-ware was simulated by sending specific signals to the Stargate-specific communication stack from the emulated mote code.In all cases we placed our nodes in simulated suspend modeand then sent a “wakeup” command to a node, simulating asensor event. The node then attempted to communicate to aspecific destination, thus initiating the wakeup protocol.

Our first experiments involved measuring the energy con-sumption of ourwake-path mechanism. Our measurementsinvolved the number of nodes woken up, the duration of thewakeup process as well as the duration of the data transferand the total number of bytes transmitted and received. Thosevalues were then multiplied with the energy/power valuesfound in [2]. Figure 1 shows the energy consumption ratioof wake-path versuswake-all for three different data transfersizes. We note thatwake-path consistently outperformedwake-all, with the differences being more pronounced in smallerdata transfer sizes. In smaller data transfer sizes, the energy

5

10

15

20

25

30

35

40

1 2 3 4 5 6

Tim

e (s

ec)

Path length (number of nodes)

Wakeup time (wake-path)Wakeup time (wake-all)

DSR path establishment time (both mechanisms)

Fig. 2. Time required for the node wakeup process using the thewake-pathand wake-all mechanisms as well the DSR path establishment time for bothmechanisms as a function of path length.

consumption of the node wakeup process is the most dominantfactor; as a result,wake-path that only wakes up the requirednodes performs significantly better. As the data transfer sizegrows, the energy consumption of the data transfer processitself dominates, thereby reducing the advantage of wakingupa smaller number of nodes.

Our second experiments focused on measuring the timerequired for each mechanism to establish the end-to-end pathover 802.11. Figure 2 depicts the results of our experiments.When using thewake-path mechanism, the topology controllerneeds to contact the nodes as well as wait for replies fromthem, whilewake-all simply floods a message over the low-bandwidth network. Nevertheless, we note that the latencypenalty of the wakeup mechanism itself is fairly low (up to9seconds at the largest path length), especially compared totheDSR path establishment time.

ACKNOWLEDGEMENTS

This material is based upon work supported in part by theUS National Science Foundation (NSF) under Grants ANI-00331481 and by a Marie Curie Transfer of Knowledge (ToK-DEV) Grant ASPIRE within the 6th European CommunityFramework Program.

REFERENCES

[1] Intel, “Intel stargate, http://platformx.sourceforge.net,” 2002.[2] D. McIntire, K. H. Hing, B. Yip, A. Singh, W. Wu, and W. Kaiser, “The

low power energy aware processing (leap) system,” inIPSN SPOTS, April2006.

[3] Eugene Shih, Paramvir Bahl, and Michael J. Sinclair, “Wake on wireless:An event driven energy saving strategy for battery operateddevices,” inMobicom. 2002, ACM.

[4] David B Johnson and David A Maltz, “Dynamic source routingin adhoc wireless networks,” inMobile Computing. 1996.

[5] T. Stathopoulos, L. Girod, J. Heidemann, and D. Estrin, “Mote herdingfor tiered wireless sensor networks,” Tech. Rep. CENS-TR-59, 2005.

[6] L. Girod., J. Elson, A. Cerpa, T. Stathopoulos, N. Ramanathan, andD. Estrin, “Emstar: a software environment for developing anddeployingwireless sensor networks,” inUSENIX, 2004.

[7] L. Girod, T. Stathopoulos, N. Ramanathan, J. Elson, D. Estrin, E. Oster-weil, and T. Schoellhammer, “Tools for deployment and simulation ofheterogeneous sensor networks,” inSenSys, 2004.


Poster Abstract: Influence of Energy Models onSensor Network Analysis

Barbara EmmertUniversity of Wurzburg, Germany

[email protected]

Abstract— Algorithms and proposals for analyzing the energyconsumption of sensor nodes often assume that transmission costsscale with a power of the distance. While this assumption istheoretically correct, it does not reflect the capabilities of realsensor nodes. Moreover, the omni-directional nature of radiotransmissions which forces nodes to overhear the communicationof other nodes is ignored by this approach. We thereforepropose a novel and more realistic cost metric based on thecurrent consumptions of existing sensor nodes that also includesincreased energy consumption when processing unintendedlyreceived packets.

I. I NTRODUCTION

Energy is a critical topic in sensor networks: Usually, nodesare battery-supplied and once they are deployed, exchangingbatteries is mostly very challenging, sometimes even impos-sible. It is therefore a question of interest to determine for agiven implementation when and which node will run out ofenergy, to rate whether this specific deployment is reasonable.

Realistic simulations to predict the lifetimes of the sensornodes require a highly detailed model of the sensor nodes be-havior and the current consumptions in the different states[1].The most widely used energy model for less complex analyti-cal approaches focuses therefore on transmission costs [2]: thenecessary amount of energy for a transmission over a distanced is assumed to scale withdα, besides this, no static energydissipations are considered.

But, as shown in [1], the energy in terms of current drawneeded for transmissions isnot exponentially related to thetransmission distance. We therefore propose a more hardwareoriented energy consumption model for sensor networks, sim-ilar to the one for MANETs introduced in [3]. This frameworktakes the omni-directional nature of radio transmissions intoaccount, which leads to higher communication costs. We claimthat this approach is also reasonable for evaluating sensornetworks and therefore establish a novel cost metric for ratingsensor network lifetime which we present in this work.

II. M ODEL DESCRIPTION

A sensor network can be imagined as a graphG = (V,E),where theset of nodes V is the union of theset of sensornodes N and thesink node s. We consider a special classof sensor networks, where the sensor node transmit data tothe sink on a regular or random basis. Between any twonodes i, j ∈ V exists an edge or a communication link(i, j) ∈ E, if a transmission ofi reachesj. E is thus givenby the sensor nodes’ transmission power, reception sensitivity

and spatial distribution and indicates which sensor nodescould theoretically communicate. For now, we do not considerfactors like shadow fading or interferences that influence thetransmission range, but consider only a theoretical line ofsight path loss model to determine whether two sensor nodescan communicate or not. As in general, not all nodes cancommunicate directly with the sink, a routing protocol isrequired that determines for each nodei a path tos. Formally,this path is defined by its edges and C:Pis = (Vis, Eis). Itis evident, that all nodes which are responsible for relayingpackets carry a higher load than nodes which send only theirown measurements to the sink nodes. This is expressed by thebranch size of node i, bi := |{j ∈ N : i ∈ Vis}|, whichindicates how many paths tos traversei.

For our analysis, we assume that a circular area of diameterl around the sinks is to be monitored. The sensor nodes aredeployed homogeneously, their positions given by a spatialPoisson distribution with density. Each sensor node has totransmitλ measurements per time unitu to s.

To find an approximation for a sensor node’s energy con-sumptions, we make a very rough abstraction of the sensornode state cycle: We are only interested if nodei is trans-mitting and needs a currentItx

i (Ti), for a transmission outputpower Ti, is receiving with a current consumptionIrx

i or isidle and consumes the currentI0

i . Current consumptions ofstate of the art sensor nodes, as e.g. Tmote Sky [4] indicatethat the current draw in sleep mode is by magnitudes smallerthan the one in idle mode, this model is thus suitable for aworst case approximation. The energy consumed byi and j

for sending and receiving a packetp respectively in terms ofconsumed electrical charges are thus given asQi = tpI

txi (Ti)

and Qj = tpIrxj , where the timetp needed to transmitp

depends on the achievable data rate.An approximation fori’s current consumptions during one

time unit based on its radio operations can thus be given by

Qradioi (ε) = Γi(ε)I

txi (Ti) + ∆iI

rxi + Υi(ε)I

0i ,

where Γi(ε), ∆i and Υi(ε) describe the percentage of onetime unit u, nodei is busy with sending, receiving or is idlerespectively. If we assume, that no packets are lost and eachdata packetdat is acknowledged with a packetack, Γi, i.e.the part ofu nodei is busy with sending is

Γi = λ[bitdat + (bi − 1)tack].

Sensor nodes in the radio range of a sending node are forcedto overhear the transmission, unless they are in sleep state.


Most MAC protocols used in sensor networks follow rathersimple strategies which allow a not addressed sensor nodeto turn off its radio unit after heaving read the address fieldof the packet i.e. an amount of timetdisc [3]. To model theeffectiveness of the MAC protocol, we introduce the variableε ∈ [0, 1] which gives the percentage of unwanted transmissiona sensor could theoretically receive, the node actually hastoreceive and to discard.ε = 0 describes the idealistic situation,where no sensor node overhears transmissions of its neighbors.We obtain∆i(ε), i.e. the part of a time unit,i is busy withreceiving as

∆i(ε) = λ[(bi−1)tdat +bitack +ε∑

j∈N

bj(ϑjitdisc +ηjitack)].

The boolean variablesϑji andηji express, whether the mes-sages,j sends to its next hopk, and the acknowledgments,k

sends toj, are overheard byi: ϑji = 1, if i overhears trans-missions ofj, ηji = 1, if i overhears the acknowledgmentsk

sends toj and both are 0 otherwise. The idle time is obtainedasΥi(ε) = u−(Γi(ε)+∆i). Obviously,Γi(ε)+∆i < u musthold, otherwise, the sensor node is so heavily charged that itwon’t be able to relay all packets it is responsible for.

As an approximation for sensor nodei’s lifetime, weintroducetradio

i (ε) which indicates the number of time unitsfor which a sensor node could perform the radio operationsneeded for forwarding sensed data to the sink. It depends onthe node’s battery capacityQb

i and is given by

tradioi (ε) =

Qb

i

Qradio

i(ε)

.

III. E VALUATION

To investigate the influence of the energy model and MACprotocol efficiency, we used Monte Carlo simulation tech-nique. We examined settings for varying diameterl, density and routing algorithms. We comparedModel 1 where theenergy needed for transmitting a bit via a link is a directmapping of transmission output power to current consumptionsand low reception and zero idle costs were assumed.Model 2is following the current consumptions of Tmote Sky [4]. All inall, our experiments showed, that the influences of the energymodel are manifold. As an example, several small hops aremore energy efficient than one large hop according to Model1, but not for Model 2, since the current draw differences forvarious output powers become comparatively smaller and thecosts for receiving lie in the range of the transmission costs.

A network snapshot consists of a set of sensor nodeslocated in a circular area of 200 m radius according to aspatial Poisson process with density = 0.1 nodes/m2 andtransmitting one measurement peru = 1 minute. Fig. 1 showsthe cumulative distribution function (CDF) of the lifetimeapproximationtradio

i for all nodesi with branch sizebi = 10,in a snapshot with a minimum hop routing topology for a fixedoutput power ofT = −25 dBm, depending onε for the MACprotocol efficiency. As a typical capacity of an AA battery,Qb

i = 2500 mAh was assumed. Fig. 1(a) shows the CDFsfor the theoretical energy model and Fig. 1(b) for the currentdraw based model. To illustrate the variances oftradio

i (ε), we

00.5

1

0.999932

0.999965

10

0.2

0.4

0.6

0.8

1

εtradioi

(ε)/tradioi

(0)

cum

ulat

ive

prob

abili

ty

(a) Model 1

00.5

1

0.0651435

0.523032

10

0.2

0.4

0.6

0.8

1

εtradioi

(ε)/tradioi

(0)

cum

ulat

ive

prob

abili

ty

(b) Model 2

Fig. 1. CDFs of the lifetime approximation forb = 10 andT = −25 dBm

normalized it by its maximal deterministic value forε = 0. Asthe transmission and reception costs under both models differby magnitudes, the absolute lifetime approximations accordingto Model 1 are 1000 times higher than the ones resulting fromModel 2. In both cases,tradio

i (ε) is varying with increasingε,but the influence of the MAC efficiency is much smaller forModel 1 than for Model 2. This is caused by the different ratiosof reception and transmission costs: while under Model 1, areception does consume by magnitudes less energy than does atransmission, this is not the case for Model 2. To approximatethe lifetime of a sensor network, it is thus vital to incorporaterealistic values and ratios in the energy consumption model.

IV. CONCLUSION AND OUTLOOK

We presented a novel energy consumption model that (1)relies on realistic current draw numbers for transmission,reception, and idle mode, and (2) considers not only the energyfor transmitting and receiving the required packets but alsoincludes the energy overhead for processing headers of packetsreceived by a node but not destined for it. We introduced aparameterǫ for a compact description of the MAC protocol’scapability to avoid this reception overhead. Our results show,that among others these two realistic features of the energymodel have an enormous impact on the sensor network’slifetime and want to point out once more that using a realisticenergy model is indispensable for sensor network research.

We plan to extend our model by refining the energy over-head caused by the MAC protocol. Furthermore, we intendto introduce a parameter that describes the sensor node’scapability to switch from idle to sleep mode and to detailthe physical channel model. In order to validate our theoreticalmodel and to identify realistic values for the different overheadparameters, we intend to establish a OPNET simulation whosemodular structure enables a detailed simulation of all layers.

REFERENCES

[1] O. Landsiedelet al., “Accurate Prediction of Power Consumption inSensor Networks,” inProceedings of The Second IEEE Workshop onEmbedded Networked Sensors (EmNetS-II), Sydney, Australia, May 2005.

[2] W. Heinzelmanet al., “An Application-Specific Protocol Architecturefor Wireless Microsensor Networks,”IEEE Transactions on WirelessCommunications, vol. 1, no. 4, 2002.

[3] L. Feeney, “An Energy Consumption Model for Performance Analysis ofRouting Protocols for Mobile Ad Hoc Networks,”Mobile Networks andApplications, vol. 6, no. 239-249, 2001.

[4] “Tmote Sky: Ultra low power IEEE 802.15.4 compliant wireless sensormodule,” Moteiv Corporation, June 2006.


Abstract—We present Castalia, a simulator for WSN that

models many aspects of the WSN system and uses advanced

models especially in terms of the channel and radio behaviour.

We discuss the effects of these features in a nominally robust

algorithm designed with a simpler simulator to show the

importance of accurate modeling.

I. INTRODUCTION

ESEARCHERS in wireless sensor networks (WSN) have

heavily relied in simulation to validate their ideas and

methods. This is mainly due to the difficulty of deploying real

systems (i.e., deploying tens or hundreds of sensor nodes in the

physical environment, program them, excite them, and monitor

their behaviour and state as the algorithm implementing the

research idea unfolds). Since simulation is so central in the

WSN community one would expect to see a de facto standard

emerge out of the initial clutter of simulation efforts.

Unfortunately this has not happened yet.

Due to the wide extent of the WSN research area,

researchers usually focus on specific areas of system problems

leaving the rest of the system’s aspects to assumptions or

sometimes to chance. Consequently their simulation needs are

focused too. For example, they might only need to validate

some high level properties of an algorithm or protocol, or they

might want to have an accurate prediction of the energy

consumption of the network, or they might want to test code

running in the real platform by emulating the processor on the

sensor nodes. These needs put very different demands on the

simulator platforms used, abstracting away different parts of

the real system.

There are two problems with this situation: 1) different

simulators lead to incomparable results (even for similar tasks

researchers usually choose slightly or grossly different

simulators) and 2) the issues that are abstracted away are

usually important and do affect the validity of the results. Most

important among these issues are the various aspects of the

communication abstraction. The work of Seada et al. [8] has

showed how detrimental can be a simplistic channel/radio

model to the design of a communication algorithm

(specifically, a geographic forwarding algorithm was tested).

Moreover, we should not forget that WSN are systems and

many parts of the system affect the end result. For example the

existence of a clock drift and a randomized start time for the

nodes can make even simple protocols not work (if these

issues were not taken into account).

The need for a simulator that takes into account various

issues of the whole system and uses accurate models, (i.e., a

simulator that has a chance to become a de facto standard), is

present in the WSN field. We have developed the first version

of Castalia [2], an open source simulator for WSN built on top

of OMNeT++ [9]. Castalia features an accurate channel/radio

model based on the work of Zuniga et al. [12], detailed radio

behaviour, and forces the user to deal with many of the

unpleasant (but yet important) aspects of communication.

Castalia also features a flexible physical process model, takes

into account usually neglected issues such as clock drift,

sensor bias, sensor energy consumption, CPU energy

consumption, and monitors resources such as memory usage

and CPU time (apart form the obvious energy resource). In this

poster we present these features, and more importantly, we

discuss their effect on a nominally robust algorithm that was

designed and tested with a less accurate simulator.

II. RELATED WORK

Since many researchers in WSN come from traditional

networking background ns-2 [8] is rather popular for the

simulation of sensor networks. Ns-2 does not have the most

advanced channel/radio models suitable for systems such as

WSN. Most importantly though, the models and structure

favour traditional networks needs where the users need to put

some protocols together (or slightly modify them) to assess

some scenarios. When one tries to incorporate a distributed

algorithm running in the nodes things get messy quickly.

Researchers have identified early on the limitations of ns-2 so

some tried to create or migrate to other platforms. Work such

as [3] or [7] uses GlomoSim or OMNeT++ as their base but

they are using rather simple channel/radio models. A more

comprehensive survey of sensor network simulators can be

found in [4].

There is another kind of WSN simulators which sprung

from a different need. Researchers needed a way to test the

exact same code written for real sensor nodes in a more

controlled environment, without having to actually deploy

many sensor nodes. Platforms like TOSSIM [6] and Avrora

[11] are typical examples, incorporating an emulator of the

AVR processor found in several sensor platforms. These

simulators are very useful for debugging and other late

development efforts. Their accuracy is mainly spent on the

Poster Abstract: Castalia: the Difference of

Accurate Simulation in WSN

Dimosthenis Pediaditakis, Seyed Hani Mohajerani, and Athanassios Boulis

Networks and Pervasive Computing program, National ICT Australia

R


processor while other aspects are neglected. A more advanced

channel/radio model would benefit such simulators/emulators

but they would still remain platform specific and moderately

scalable (because of the high demands of the processor

emulator) thus making them unsuitable for initial

algorithm/protocol design and testing.

III. CASTALIA

Castalia is a WSN simulator that can be used by researchers

and developers who want to do initial testing of their

distributed algorithms and/or protocols in a realistic wireless

channel and radio model, with a realistic node behaviour

especially relating to access of the radio. Castalia can also be

used to evaluate different platform characteristics for specific

applications, since it is highly tunable, and can simulate a wide

range of platforms.

The main strength of Castalia is the channel/radio model

which builds on recent work done on modeling of the radio

and the wireless channel based on empirically measured data

[12]. We use the basic model from [12] taking into account

interference from other nodes during run-time. Thus, the

model is augmented in the sense that we do not use static

packet reception probabilities for the links between the nodes

but these probabilities are calculated on the fly based on the

transmission power of all transmitting nodes. We also allow

multiple transmission powers. From our modeling, features

such as non-unit-disk coverage, non-symmetrical links,

probabilistic nature of packet reception emerge. The lack of

any of these features is often a source of criticism for wireless

network simulations [5]. The behaviour of the radio is also

carefully modeled with respect to carrier sensing, transitions

between various states, and energy consumption. A highly

tunable MAC protocol with several parameters to adjust (e.g,

duty cycling, retransmissions, power levels) completes the

communication component. The user of Castalia can no longer

ignore the volatility of the wireless channel, collisions, energy

spent in listening, performance degradation experienced by

duty cycling and other issues that are usually overlooked by

simple simulators.

In terms of the sensing component it provides a parametric

physical process model, as well as sensing devices that spend

energy, add noise and bias to the measurements. In terms of

processing and other components, Castalia models the clock

drift found in real sensor platforms, the CPU energy

consumption and different speed/power modes and monitors

the memory usage and CPU time of an algorithm.

To showcase the value of such features we have tested a

nominally robust algorithm [1] designed using a simpler

simulator with Castalia. The algorithm created previously by

one of the authors, features distributed estimation techniques

to periodically find the maximum or minimum of a changing

physical process. We also tested the conventional approach of

periodic tree aggregation to periodically find the max/min. Our

findings can be summarized as follows:

1) The estimation algorithm worked but needed considerable

tuning of the MAC parameters.

2) The conventional periodic aggregation algorithm did not

work because sending information back to the “parent”

was not reliable enough. We had to adapt the algorithm.

3) The adapted algorithm (broadcasting, no notion of parent,

but still notion of levels, i.e., hops form the sink) was also

not working due to clock drift issues. The nodes were not

taking the samples at the same moment so a timer in the

algorithm linked to the level number of the node had little

real function.

4) Yet another modified version of the conventional

algorithm, resembling more our estimation algorithm

worked after considerable tuning of the MAC.

5) The difference in the accuracy/energy of the estimation

algorithm and the new “conventional” algorithm was not

as big as in the initial paper, it depended more on the

choice of MAC parameters.

It was clear to us that with the use of Castalia the design

tradeoffs and focus points would have changed for the

distributed estimation algorithm.

We hope that the features of Castalia and its modular design

will attract a core of developers from the WSN community to

help establish it as major WSN simulator for early-phase

algorithm and protocol design

REFERENCES

[1] A. Boulis, S. Ganeriwal, and M. B. Srivastava, “Aggregation in sensor

networks: a energy-accuracy trade-off,” First IEEE International

Workshop on Sensor Network Protocols and Applications (SNPA

2003), Anchorage, AK, USA, May 11, 2003.

[2] Castalia http://castalia.npc.nicta.com.au.

[3] G. Chen, J. Branch, M. J. Pflug, L. Zhu and B. Szymanski. SENSE: A

Sensor Network Simulator. Advances in Pervasive Computing and

Networking. B. Szymanksi and B. Yener, Springer: 249-267

[4] D. Curren, “A Survey of Simulation in Sensor Networks”, University of

Binghamton project report for subject CS580

http://www.cs.binghamton.edu/~kang/cs580s/david.pdf

[5] D. Kotz, C. Newport, R. Gray, J. Liu, Y. Yuan, and C. Elliott,

“Experimental evaluation of wireless simulation assumptions,” in Int'l

Workshop Modeling Analysis and Simulation of Wireless and Mobile

Systems (MSWiM 04). ACM Press, New York, Oct. 2004.

[6] P. Levis, N. Lee, M. Welsh, and D. Culler, TOSSIM: Accurate and

Scalable Simulation of Entire TinyOS Applications, SenSys'03.

[7] C. Mallanda, A. Suri, V. Kunchakarra, S.S. Iyengar, R. Kannan, A.

Durresi, and S. Sastry" Simulating Wireless Sensor Networks with

OMNeT++ " , submitted to IEEE Computer, 2005

[8] NS-2 http://nsnam.isi.edu/nsnam/index.php/User_Information

[9] OMNeT++ http://www.omnetpp.org

[10] K. Seada, M. Zuniga, A. Helmy, B. Krishnamachari, “Energy Efficient

Forwarding Strategies for Geographic Routing in Wireless Sensor

Networks,” 2nd International Conference on Embedded Networked

Sensor Systems, SenSys 2004, Baltimore, MD, USA, November 3-5,

2004.

[11] B. Titzer, D. Lee, and J. Palsberg, “Avrora: Scalable Sensor Network

Simulation with Precise Timing,” In Proceedings of IPSN'05, Los

Angeles, 2005

[12] M. Zuniga, B. Krishnamachari, “Analyzing the Transitional Region in

Low Power Wireless Links,” First IEEE International Conference on

Sensor and Ad hoc Communications and Networks (SECON), Santa

Clara, CA, October 2004.


Abstract—This paper outlines the advantages of applying

object oriented modeling principle to sensor network programming. This closes the gap between programming principles in the world of small things and big servers. We show that typing based on classes can make algorithms robust to changing data layouts and implementation changes. Furthermore we present an implementation based on ultra-lightweight java virtual machine running on low-power sensor nodes. Keywords—Object oriented languages, wireless sensor nodes, system architecture

I. INTRODUCTION

Object oriented programming has become the predominant language used in newly created software. Its virtual machine based runtime makes it easy to port software to a variety of platform without the need of changing implementations. The success of the J2ME (Java 2 Mobile Edition) manifested by millions of cell phone application has shown that OO based programming accelerates development cycles on highly embedded systems Sun introduced with SPOTS (http://www.sunspotworld.com/) platform a 32bit networked embedded system that resembles a sensor node. At the same time the Standard and Enterprise Edition of Java are the programming interface for many commercial business and engineering products.

In order to show how classical ultra-low power 8bit micro-controller based sensor systems can profit from a java virtual machine and can be integrated into a world of object oriented modeling tools we have implemented a Java implementation for Particle Sensor Nodes (http://particle.teco.edu).

The variety of possible sensors and values makes it many difficult cases to interpret the data correctly, for both locally on a senor node and remotely on PC system. In this poster we want to show how object orient modeling and object level helps to build robust data processing algorithm on sensor nodes.

The work presented in this poster was partially funded by the European

Community under contract no. 4270 and by the Ministry of Economic Affairs of the Netherlands under contract no. 03060.

Till Riedel is with TecO/Universität Karlsruhe, Vincenz-Prießnitz-Str. 3, 76131 Karlsruhe, Germany (e-mail: [email protected]).

Andreas Arnold is with TecO/Universität Karlsruhe, Vincenz-Prießnitz-Str. 3, 76131 Karlsruhe, Germany (e-mail: [email protected]).

Christian Decker is with TecO/Universität Karlsruhe, Vincenz-Prießnitz -Str. 3, 76131 Karlsruhe, Germany (phone: +49 721 464704 15; e-mail: [email protected]).

Figure 1: Abstract Sensor Interfaces encapsulation of data

II. OBJECT ORIENTED SENSORS

We follow the vision of classical object oriented (OO) modeling approaches such as [[1]] when we abstract real-world items and data by objects and classes. In the following we want to shortly describe just a few advantages of such an approach for sensor networks.

A. Abstract Sensor Classes

Objects encapsulate and hide the details about an the implementation and data layout. . Many information processing algorithm in sensor network tend to have a binding against the layout of the underlying data. This makes it difficult to reuse code and eventually slows down any development process.

By using abstract sensor classes generic algorithms on e.g. on scalar valued sensor data can be developed and bound to a concrete hardware instance at a late stage, even at runtime. On the most abstract level sensors and sensor values can be used polymorphic as via a very generic interface as shown in Figure 1. The „instance of“ operator and typecasting also allows disambiguation of object classes at a later stage of the processing logic again.

B. Serialization

The data encapsulation especially proves valuable when communicating data. By establishing a common id scheme it is sufficient to serialize the sensor data object together and transmit it to another party in the network. Because the object encoding is fixed inside the class files it is automatically distributed together with the interfaces and the processing logic inside the class. Such a system clearly separates data from layout and code and reduces the typing overhead to a minimum.

Poster Abstract: An OO Approach to Sensor Programming

Till Riedel, Andreas Arnold, Christian Decker


C. Type Safeness

One of the additional advantages of programming data processing in the Java language over other imperative programming approaches is its type-safeness. On micro-controller based hardware environments this is important, as there is no memory protection enforced in hardware or by the operating system. Type violations in user code can have serious side effects on other systems. Like demonstrated in SPIN project [2], type safe languages allow execution of user code at system privileges. This is why we see another focus of Java in the implementation of a robust operating system like runtime eviroment. A basic set of performance critical subsystems like bus access will still be implemented by compiled machine code. This provides a very thin abstraction layer. Higher abstraction layers providing like sensor sampling and conversion can be loaded dynamically and be executed within the VM. This allows us to design adaptable re-configurable system architecture.

Figure 2: Particle VM Memory Layout

III. I MPLEMENTATION

The implementation of the ParticleVM is based on the lightweight java byte-code interpreter NanoVM [3] and runs on 8bit micro-controllers with a minimum amount of memory. The implementation covers all static features of the Java programming language as it uses code generated by standard java compilers such as the JDK javac (see http://java.sun.com) or jikes (see http://jikes.sf.net). The class files are further optimized on byte-code level, e.g. by elimination of the constant pool.

In our version VM all language features except for exceptions and reflection have been implemented. There is a minimalist java runtime environment for Particle Computers, which maps the basic system functionality provided by the enabling services such as networking and sensory services. The implementation especially covers all performance critical memory, bus and rf access routines.

The current 2/32 Particle includes a Microchip PIC18F6720 micro controller. This low power MCU has an instruction cycle of 0,2 µs and includes only 4K of RAM and 128K of code memory. In contrast to directly executed machine code the 512K of external Flash memory can be additionally used as program memory holding Java classes.

The current implementation of the byte code interpreter occupies 60KB of code memory and 1.5K of memory. Additionally 45KB of code memory and 0.5K of RAM are dedicated to the low-level native API for the sensor note with basic operating system features and the RF functionality including message buffers. This leaves 1.5 KB of heap memory that can be used by any user program running on top of the ParticleVM. The complete memory layout is shown in Figure 2.

IV. PERFORMANCE

The performance characteristics of our first naive implementation are outlined in Table I. Especially code compression and runtime overhead can, however, further be optimized in future version. The numbers were measured benchmarking a simple aggregation functions on sensor values.

The high numbers on the interpretation overhead still show that encapsulated code does always come at higher cost. The question is if at the end of the day the reduction of complexity can even make up this.

V. CONCLUSIONS

We showed in this paper that object oriented programming on sensor nodes using java can solve many of the interfacing problems between sensor network applications. A lightweight implementing of a java VM makes it possible to conclude the fully integrate such platforms into a world of backend architectures on language level without proposing large scale middleware solutions. In our ongoing work on this matter want show how sensor networks can be integrated into larger scale application models without loosing the flexibility of a tiny, low power hardware platform.

VI. REFERENCES [1] Booch, Grady. Object-Oriented Analysis and Design with Applications.

Addison-Wesley. ISBN 0-8053-5340-2. [2] Brian N. Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gün

Sirer, Marc Fiuczynski, David Becker, Susan Eggers, Craig Chambers. Extensibility, Safety and Performance in the SPIN Operating System, Proceedings of the 15th Symposium on Operating Systems Principles, pp 267-284, Copper Mountain, Colorado, 1995

[3] Thomas Fuhrmann, Till Harbaum, A Platform for Lab Exercises in Sensor Networks. 4th GI/ITG Fachgespräch Sensornetze Zürich, Schweiz, March 23-24, 2005 pp. 29-32

TABLE I INITIAL BENCHMARK RESULTS

avg. code size 40% avg. interpretation overhead 3000%


Poster Abstract: MSPsim – an Extensible Simulatorfor MSP430-equipped Sensor BoardsJoakim Eriksson, Adam Dunkels, Niclas Finne, Fredrik Osterlind, Thiemo Voigt

Swedish Institute of Computer Science{joakime,adam,nfi,fros,thiemo}@sics.se

Abstract— Software development for wireless sensor networksis a challenging and time consuming task. The resource limitedhardware with limited I/O and debugging abilities combined withthe often cumbersome hardware debugging tools makes low-leveldebugging on the target hardware difficult. We present MSPsim,an extensible sensor board platform and MSP430 instructionlevel simulator that simulates sensor boards with peripheralsfor the purpose of reducing development and debugging time.The use of a simulator also enables testing without access tothe target hardware and makes more advanced debugging andinstrumenting possible.

I. INTRODUCTION

Due to the distributed nature of sensor networks andresource-constraints of sensor nodes, code development forwireless sensor network is a challenging and time consumingtask. Furthermore, the application development and debuggingtools are still cumbersome.

One of the most commonly used methods for debuggingsensor nodes is using on-chip emulation via JTAG that makesit possible to single-step and debug a running application onthe target hardware. This is useful for understanding execu-tion patterns, stack usage, etc, but less useful for debuggingcommunication, sensor drivers, etc.

For the development of wireless sensor network applica-tions, system simulators exist that simplify the developmentof algorithms and enable researcher to study the algorithms’behaviour and interaction in a controlled environment [1].

Cross-level simulation enables simultaneous simulation atdifferent levels of the sensor network and hence supportssimultaneous low-level debugging and application develop-ment [2]. For cross-level simulation of our MSP430-basedsensor node platforms we required an extensible instructionlevel simulation. Towards, this end, we designed and imple-ment MSPsim. As Avrora [3] MSPsim is a sensor networksimulator simulating nodes at the instruction-level, but forthe MSP430. Unlike ATEMU that emulates the operationsof individual nodes and simulates communication betweenthem [4], MSPsim is designed for instruction-level simulationbut can by design be incorporated in COOJA’s cross-levelsimulation environment.

The contribution of this paper is MSPsim, an extensibleinstruction level simulator for the MSP430 microcontroller thatis intended to be used as a component in a larger sensor net-work simulation system supporting cross-level simulation [2].For this reason MSPsim is designed to run multiple instancesof the simulator in a single process unlike other MSP430

Fig. 1. MSPsim simulating Contiki’s Blinker application on an ESB.

simulators such as the GDB MSP430 simulator [5]. MSPsimalso contains a sensor board simulator that simulates hardwareperipherals such as sensors, communication ports, LEDs, andsound devices such as a beeper. The design of MSPsim,together with its implementation in Java, makes it easy to adaptthe simulator to new sensor boards.

II. THE MSPSIM SIMULATOR

The MSPsim is a Java-based instruction level simulator forthe MSP430 microcontroller that simulates unmodified targetplatform firmware. MSPsim is an instruction-level simulatorwhich made it easy to achieve accurate timing simulation.Further, MSPsim can run unmodified target platform firmware.The simulator is easily extensible with peripheral devicesmaking it possible to simulate various types of MSP430 basedsensor nodes.

In addition to simulate the MSP430 and sensor boardhardware, MSPsim can show a graphical representation of thesensor board in an on-screen window. LEDs on the sensorboard are displayed using the correct colors. Figure 1 showsthe graphical output from MSPsim simulating an ESB node.

The graphical output allows a system designed to visuallyverify that an application is correctly simulated by inspectionof the LEDs.

A. Sensor Board Simulation

At SICS we are working with the ESB [6] and the TelosSky [7] platforms, which both use the MSP430 microcon-troller. Therefore, one of the design objectives of the MSPsimsimulator is to simplify the adaptation to different types ofsensor node platforms. To add support for a new sensor


node platform only implementations of peripherals such assensors, actuators such as beepers or LEDs, and radio andcommunication peripherals are needed. The implementation ofthose peripherals are typically relatively easy to make as manyof them do not need to conform to strict timing requirements.Figure 2 the complete MSPsim simulation system with anMSP430 microcontroller and connected peripherals.

To illustrate how a peripheral is implemented in MSPsim,Figure 3 contains a complete MSPsim serial peripheral class.The class constructor attaches itself as a listener to the USARTobject. When the firmware running on the simulated MSP430writes data to the USART, the dataReceived method of thelistener is invoked. In this example, the dataReceived methodsimply prints out the produced character on screen.

Figure 4 shows how a sensor board simulation platformconnects the MSP430 USART 1 serial port with a the serialmonitor from Figure 3.

III. EVALUATION

To evaluate the extensibility of MSPsim we measure thenumber of interfaces that must be implemented when addingsupport for a new sensor board in MSPsim. The measurementsin the Table I show the amount of interfaces that the ESBsensor board platform implements. Certain peripherals thatare present on the ESB are not yet included in the simulator:EEPROM, real-time clock, and active IR. The table showsthat the amount of interfaces that need to be implemented fora sensor board is small; only one or two methods need to beimplemented for each peripheral. Most peripherals only needa single method for either reading or writing to the peripheral.The interface for the radio is slightly more complex as itrequires two write interfaces, one for configuration and onefor the data to be transmitted.

TABLE INUMBER OF INTERFACES IMPLEMENTED BY THE ESB SIMULATOR.

Read WritePeripheral value valueLED 0 1Beeper 0 1Digital sensor (PIR, Vibration) 1 0Analog sensor (Mic, RSSI) 1 0Radio 1 2Serial (RS232) 0 1

Radio

RSSI sensor

LEDs

PIR sensor

MSP430

RS232

Fig. 2. An MSPsim simulation with an MSP430 microcontroller andconnected peripherals.

public class SerialMonitor {public SerialMon(USART usart) {

usart.setUSARTListener(this);}

public void dataReceived(USART source, int data) {System.out.print((char)data);

}}

Fig. 3. Implementation of a serial output device class attached to a USART

USART usart = (USART) cpu.getIOUnit("USART 1");serial = new SerialMon(usart);

Fig. 4. Creating a serial data monitor and attaching it to serial port 1 (USART1) in MSPsim

IV. CONCLUSIONS

In this paper we have presented MSPsim, a simulatorfor sensor nodes using the MSP430 processor. MSPsim isextensible in that adapting the simulator to new sensor boardsrequires not more than the implementation of a few Javaclasses.

ACKNOWLEDGMENTS

This work was partly financed by VINNOVA, the SwedishAgency for Innovation Systems.

REFERENCES

[1] P. Levis, N. Lee, M. Welsh, and D. Culler, “Tossim: accurate and scalablesimulation of entire tinyos applications,” in Proceedings of the firstinternational conference on Embedded networked sensor systems, 2003,pp. 126–137.

[2] F. Osterlind, A. Dunkels, J. Eriksson, N. Finne, and T. Voigt, “Cross-levelsensor network simulation with cooja,” in Proceedings of the First IEEEInternational Workshop on Practical Issues in Building Sensor NetworkApplications (SenseApp 2006), Tampa, Florida, USA, Nov. 2006.

[3] B. Titzer, D. Lee, and J. Palsberg, “Avrora: scalable sensor networksimulation with precise timing,” in IPSN ’05: Proceedings of the 4thinternational symposium on Information processing in sensor networks,2005.

[4] M. Karir, “Atemu - sensor network emulator / simulator / debugger,”Center for Satellite and Communication Networks, Univ. of Maryland,Tech. Rep., 2003.

[5] D. Diky and C. Liechti, “The GCC toolchain for the Texas InstrumentsMSP430 MCUs,” http://mspgcc.sourceforge.net/ Visited 2006-11-11.

[6] J. Schiller, H. Ritter, A. Liers, and T. Voigt, “Scatterweb - low powernodes and energy aware routing,” in Proceedings of Hawaii InternationalConference on System Sciences, Hawaii, USA, 2005.

[7] J. Polastre, R. Szewczyk, and D. Culler, “Telos: Enabling ultra-low powerwireless research,” in Proc. IPSN/SPOTS’05, Los Angeles, CA, USA,Apr. 2005.


Abstract—In this poster, we present Intellbuilding, a

real experimental wireless sensor network for datagathering on Intelligent Buildings. We use this platform toconduct an in-depth study of the capabilities of currentwireless sensor networks technologies. Through a set ofexperimental trials, we analyze the power consumption ofvarious protocol architectures.

Index Terms— sensor networks, intelligent buildings, cross -layer power-save, B-MAC, RMR

I. INTRODUCTION

Wireless Sensor Networks consist of a large number oftiny devices, powered by small-sizes batteries and operatingunattended for long periods of time. WSN s have the ability tosample, coordinate and actuate at time scales and networkdimensions not previously possible [1]. This ability shouldenable the deployment of a wide array of interestingapplications. Our research group at the Albacete ResearchInstitute of Informatics is actively involved in the study anddeployment of this technology for indoor and out doormonitoring [2]. In this paper next, we review the results fromour first set of trials on an indoor monitoring application. Ourpower efficient work methodology integrates different energy -aware network protocols through the principles of cross -layerprotocol engineering. We focus on the medium access controland network layers, as the radio device is the most powerconsumption device. We study the network time span offeredby several different protocol architectures already available inone of the most popular platforms nowadays: the Mica 2family of sensor nodes. We then report on an implementationof the B-MAC protocol [1] for the CC2420 radio chip. [3]

II. THE INTELLBUILDING APPLICATION

Our work has been motivated by the aim of effectivelydesigning and deploying WSNs for monitoring environmental

This work was supported in part by the CONSOLIDER project (CSD2006 -46) CICYT project (TIN2006-15516-C04-02) and WISEVINE project (PCI05027)

indoor conditions, such as the temperature and humidity in anoffice space. Such system should enable a quick and accuratediagnosis of the working environment: a must for productivityin a competitive society.

The hardware equipment used to measure the temperatureand humidity information consisted of two development kits ofmicaZ nodes (MOTE-KIT2400)[4] (see Figure 1). Thesoftware used is TinyOS and NesC . Figure 2 shows the actuallayout of the experimental network.

Figure 1. Experimental hardware

Figure 2. Network layout

Poster abstract: IntellBuilding, A WirelessSensor Network for Intelligent Buildings

T. Olivares, P.J. Tirado, F. Royo, J. C. Castillo and L. Orozco -BarbosaAlbacete Research Institute of Informatics

Universidad de Castilla-La Manchateresa, pjose, froyo, jccastillo, [email protected]


The node denoted B is responsible of gathering all the datasent by all the other ten nodes making part of the network. Allthe other nodes are responsible of monitoring on a regularbasis the room temperature and humid ity. Figure 3 illustratesthe data collected by one of the nodes over 100 hours ofoperation.

Figure 3. Temperature and humidity values for node 5

III. PROTOCOLS

Nowadays, power Management is one of the major issue ofthe current WSN technology is the power consumption. Manypower-aware protocols are being designed applying theprinciples of cross-layer engineering protocol engineering [5].However, the number of protocols having been implementedand tested is very limited. Furthermore, most implementationsto date have been developed over the mica -2 platform. In tourexperimental study, we have considered five different set -upusing two different platforms. In this way, we are in position tocomparing the performance of the se two platforms. Due to thelack of space, we just briefly described the experimental setupshaving been considered. Test 1: This setup is the one provided by the manufacturer

Crossbow, including in the suite MoteView. Thisapplication is defined for sensor board MTS400 andmicaZ. It implements the IEEE 802.15.4 standard. Noinformation is available regarding the routing protocolimplemented over the MAC. The application sends apacket every 8 seconds, with all the data collected by thesensor board.

Test 2: We used the same platform as for Test 1. Theprotocol stack includes the standard IEEE 802.15.4protocol and a multi-hop routing protocol. The applicationsends a packet every 8 seconds. Only the temperature andhumidity are captured by the sensor board.

Test 3: Same configuration as for Test 2, except for theIEEE 802.15.4 protocol which is replaced by the B-MACprotocol, using the listening mode 3 and the transmit mode4: 1200 ms radio on and 1100 ms radio sleep.

Test 4: same configuration as for Test 3, except that the B-MAC protocol is implemented using the listening mode 5

and the transmit mode 3: 2500 ms radio on and 900 msradio sleep.

Test 5: same configuration as for Test 4, except that theRMR routing protocol is used [6].

It is worth to mention that the implementations of the B -MAC and RMR protocols used in our experiments weredeveloped by our research team. Due to the differences ofoperation of the radio system used in the micaZ boards, theradio system has to remain active for longer pe riods of time inorder to be able to capture the whole data packet. Figure 4depicts the timing diagram of the modified version of the B -MAC protocol developed by our team [ 7]. Table 1 summarizesour experimental results. It is clear from our results that thesetup making use of the B-MAC and RMR protocols over themicaZ platform exhibits the best results: a gain of close to400% over the lifespan of the platform offered by themanufacturer.

Figure 4. B-MAC Timing Diagram.

TABLE 1. RESULTS

REFERENCES

[1] J. P., J. H., and D. C. Versatile low power media access for wirelesssensor networks. In Proceedings of the Second ACM Conference onEmbedded Networked Sensor Systems (SenSys), November 2004

[2] http://www.i3a.uclm.es[3] http://inst.eecs.berkeley.edu/~cs150/Documents/CC2420.pdf[4] www.crossbow.com[5] S. L. Kota., at all, “Cross-Layer Protocol Engineering for Wireless Mobile

Networks,” IEEE Communications Magazine, December 2005.[6] Geoff V. Merrett, Nick R. Harris, Bashir M. Al -Hashimi, and Neil M.

White, "Energy Controlled Reporting for Industrial Monitoring WirelessSensor Networks," in Proc. IEEE Sensors 2006 (in press), Daegu, Korea,22-25th Oct. 2006.

[7] F. Royo-Sánchez, Implementación de B-MAC para nodos micaZ.Desarrollo y prueba en la IntellBu ilding, PFC Universidad de Castilla LaMancha, Sept 2006 (in Spanish)


[email protected]

http://www.i3a.uclm.es

http://inst.eecs.berkeley.edu/~cs150/Documents/CC2420.pdf

www.crossbow.com

Demo Abstract: Passive Inspection of DeployedSensor Networks with SNIF

Matthias Ringwald, Marc Cortesi, Kay RomerInstitute for Pervasive Computing

ETH Zurich, Switzerland{mringwal,roemer}@inf.ethz.ch, [email protected]

Andrea VitalettiDepartment of Informatics

University of Rome “La Sapienza”, ItalyEmail: [email protected]

Abstract— We demonstrate a tool that allows inspection anddebugging of deployed wireless sensor networks (WSN) by ana-lyzing overheard radio messages. This tool can identify commonproblems such as node crashes, reboots, routing problems, andnetwork partitions without instrumentation of sensor nodes.

Existing approaches to identify performance problems andbugs in deployed WSN such as Sympathy [5] require to addlogging and debugging code to the application running on thesensor nodes, with monitoring traffic being sent in-band withthe sensor network data to the sink. These approaches result insignificantly increased resource consumption in the WSN andbugs in the sensor network may also affect the monitoringmechanism.

The presented tool is an implementation of our Sensor NetworkInspection Framework (SNIF) [6], which consists of hardware tooverhear network traffic, a data stream framework to decodeand analyze overheard messages, and a graphical user interfaceto display the network topology and node states. We will firstprovide an overview of the hard- and software before the demosetup is presented. We also briefly dicuss closely related work.

I. SYSTEM OVERVIEW

The system consists of four components:• A distributed network sniffer that can be configured to

work with arbitrary radio configurations and MAC layers• A packet description language to decode overheard mes-

sages• A data stream framework to analyze decoded packets• A graphical user interface to visualize network topology

and node statesThe network sniffer is based on a so-called deployment

support network (DSN) [1] – an additional wireless ad hocnetwork that is temporarily installed alongside the inspectedWSN during deployment. Our implementation is based onBTnode revision 3 [1], which provides two radio front-ends: aZeevo ZV 4002 Bluetooth radio and a Chipcon CC1000 low-power radio. The Bluetooth radio is used to form a robust andhigh-bandwidth ad hoc network among the DSN nodes (a so-called Bluetooth scatternet), while the Chipcon radio is usedto overhear sensor network traffic.

Using a configuration language, the Chipcon radio canbe tuned to an arbitrary frequency and data rate within itsspecification. Our tool works with any sensor MAC protocolby locating a user-defined start-of-packet symbol and packetlength indicator in the received byte stream. All overheardpackets are forwarded across the DSN to a sink.

Covered ?

Is a neighbor ?

no

Heard any packets ?

yes

Has a route ?

yes

Node dead

no

Has neighbors ?

yesno

Has a parent ?

yes

No neighbours

no

yes

Network partition ?

no

Network partition ?

no

Node OK

yes

Loops ?

Routing failure

no

Routing loop

yes

no

Network partition (no route)

yes

No parent

no

Network partition (no parent)

yes

Fig. 1. Node state decision tree.

The packet description language is based on C syntax withsome additional annotations, such that users can copy andpaste packet descriptions from the source code of the sensornetwork application. Specifically, a packet is defined by a Cstruct that can contain other, nested structs. A packet decoderallows to access the contents of a field of an overheard messagegiven the symbolic name of the field.

Overheard packets are then processed by a data streamframework to find indicators for specific bugs (e.g., a nodereboot). Essentially, this framework allows to construct adirected graph of data stream operators. Overheard packetsflow along the edges of the graph and are modified bythe operators. Besides basic data stream operators such asaggregation over a time window, we provide a number ofspecific operators to deal with overheard packets. These op-erators have two purposes. Firstly, they deal with incompleteinformation resulting from message loss and from data thatis not included in messages (e.g., sender address) but wouldbe needed to identify bugs. Secondly, they find indicators forspecific problems. For example, if no messages have been


received from a sensor node for a certain amount of time, thisindicates that the node is dead. There exist a number of suchoperators to find indicators for different problems. Eventually,found indicators are evaluated in a binary decision tree to findthe actual root cause of a problem. This binary decision treeis also implemented as a data stream operator. In the exampletree depicted in Fig. 1, the leaf nodes represent different statesof a sensor node, while inner nodes represent binary decisionswhich are taken based on the output of data stream operators.Please refer to [6] for details.

The graphical user interface of the debugger shows a graphof the sensor network topology as depicted in Fig. 2. Nodecolors indicate different classes of node states as computedby the binary decision tree (green: ok, yellow: warning, red:problem, gray: node cannot be properly observed). Edgesbetween the nodes indicate network links, while the thicknessof the edges indicates the amount of packets sent over thelink during a specified time period. Nodes can be selected todisplay a textual summary of their states.

Fig. 2. GUI of the inspection tool. Nodes are colored to provide a quickglance on the network health. In the right box, node states are detailed.

II. DEMO SETUP

The demo setup consist of a large table with roughly 20sensor nodes, about 3 DSN nodes, and one laptop computerexecuting SNIF and displaying the GUI. The transmit power ofthe sensor nodes is reduced to obtain a true multi-hop sensornetwork on top of a table. The DSN nodes will be marked so asto distinguish them from sensor nodes. They form a Bluetoothscatternet and send all overheard packets to the laptop.

The sensor network runs a typical multi-hop data gatheringapplication based on the Extensible Sensing System (ESS) [3],where nodes send sensor readings along the edges of a routingtree to a sink. Essentially, sensor nodes broadcast beaconmessages at regular intervals to allow neighbor discovery, linkadvertisement messages are sent to allow bidirectional linkestimation, path announcement messages are sent to constructthe routing tree, and data messages containing sensor readings

are sent to the sink. Based on this protocol (which was notmodified for inspection with SNIF), our demonstrator candetect the problems depicted in Fig. 1.

In the basic setup, the sensor network works as expected.To experiment with our inspection tool, a visitor can injectdifferent types of faults into the sensor network: node reboots(pressing the reset button of a node), node failures (switchingoff a node), network partition (switching off several nodes),and routing failures (pressing a special button at a sensornode). These errors will then be detected by SNIF and dis-played in the GUI.

III. RELATED WORK

Most closely related to SNIF is work on active debuggingof sensor networks, notably Sympathy [5] and Memento [7].However, both systems require instrumentation of sensor nodesand introduce monitoring protocols in-band with the actualsensor network traffic. Also, both tools only support a fixedset of problems, while SNIF provides an extensible framework.

Tools for sensor network management such as NUCLEUS[9] provide read/write access to various parameters of a sensornode that may be helpful to detect problems. However, thisapproach also requires active instrumentation of the sensornetwork.

Complementary to SNIF is work on simulators (e.g., SENS[8]), emulators (e.g., TOSSIM [4]), and testbeds (e.g., Mote-Lab [10]) as they support development and test of sensornetworks before deployment in the field. EmStar [2] integratessimulation, emulation, and testbed concepts into a commonframework.

IV. ACKNOWLEDGMENTS

The work presented in this paper was supported (in part)by the National Competence Center in Research on MobileInformation and Communication Systems (NCCR-MICS), acenter supported by the Swiss National Science Foundationunder grant number 5005-67322.

REFERENCES

[1] J. Beutel, M. Dyer, L. Meier, and L. Thiele. Scalable topology controlfor deployment-sensor networks. In IPSN ’05.

[2] L. Girod, J. Elson, A. Cerpa, T. Stathapopoulos, N. Ramananthan, andD. Estrin. EmStar: A software environment for developing and deployingwireless sensor networks. In USENIX 2004.

[3] R. Guy, B. Greenstein, J. Hicks, R. Kapur, N. Ramanathan, T. Schoell-hammer, T. Stathopoulos, K. Weeks, K. Chang, L. Girod, and D. Estrin.Experiences with the extensible sensing system ess. Technical Report 61,CENS, 2006.

[4] P. Levis, N. Lee, M. Welsh, and D. Culler. TOSSIM: Accurate andScalable Simulation of Entire TinyOS Applications. In Sensys 2003.

[5] N. Ramanathan, K. Chang, R. Kapur, L. Girod, E. Kohler, and D. Estrin.Sympathy for the sensor network debugger. In SenSys ’05.

[6] M. Ringwald, K. Romer, and A. Vialetti. Snif: Sensor network inspectionframework. Technical Report 535, ETH Zurich, Zurich, Switzerland,2006.

[7] S. Rost and H. Balakrishnan. Memento: A Health Monitoring Systemfor Wireless Sensor Networks. In SECON 2006.

[8] S. Sundresh, W. Kim, and G. Agha. SENS: A Sensor, Environment andNetwork Simulator. In Annual Simulation Symposium 2004.

[9] G. Tolle and D. Culler. Design of an application-cooperative manage-ment system for wireless sensor networks. In EWSN 2005.

[10] G. Werner-Allen, P. Swieskowski, and M. Welsh. Motelab: a wirelesssensor network testbed. In IPSN 2005.


Demo Abstract: Development and Test with theDeployment-Support Network

Jan Beutel, Matthias Dyer, Mustafa Yucel, Lothar ThieleComputer Engineering and Networks Lab

Swiss Federal Institute of Technology (ETH), ZurichCH-8092 Zurich, Switzerland

Email: beutel,dyer,yuecel,[email protected]

Abstract— The Deployment-Support Network (DSN) is a new,minimal invasive methodology for developing and testing wirelesssensor networks (WSN) in a realistic environment. A device undertest, e.g. a target sensor network is augmented with a redundantwireless backbone network and a second set of nodes to carry outthe testing logic. Enabling a developer to test a live applicationscenario on the actual target hardware on-site in an actualdeployment while maintaining correct operation of the systemenables the coordinated development as well as reproducible andrealistic profiling of the behavior of sensor network nodes.

I. INTRODUCTION

With the advancement of sensor networks beyond thepure proof of concept experience, applications and real-worlddeployments are getting increased attention. However it isstill surprisingly difficult to assemble the components andtechnologies developed for sensor networks into a functionalwhole; especially when resources are limited and a minimumperformance should be guaranteed [1]. Often, a first iterationof a sensor network system will perform only poorly and anumber of subsequent iterations are necessary to achieve asatisfactory level of confidence in the application.

The Deployment-Support Network (DSN) [2], [3] is a toolfor the development, debugging and monitoring of distributedwireless embedded systems in a realistic environment. Thebasic idea is to use a second wireless network consistingof so-called DSN-nodes that are directly attached to thetarget nodes. The DSN provides a separate reliable wirelessbackbone network for the transport of debug and controlinformation from and to the target-nodes. However, it is notonly a replacement for the cables in wired testbeds but italso implements interactive debugging services such as remotereprogramming, RPC and data/event-logging on the DSNnodes clearly separating debugging and testing logic from theexperiment.

II. DSN–ARCHITECTURE

A. Overview

Figure 1 shows an overview of the different parts in aDSN-system. On the right hand side is the DSN-node/target-node pair that is connected via a short cable or interfaceboard, referred to as the wired target interface. DSN-nodes arebattery-operated wireless nodes with a microcontroller and aradio-module, similar to the target-nodes.

Target WSN

DSN backbone networkDSN Server

Client

DSN Node Target Node

Wired Target Interface

targ

et

arc

hite

ctu

re

ind

ep

en

de

nt

targ

et

arc

hite

ctu

re

de

pe

nd

en

t

Client IF

Fig. 1. Conceptual view of a DSN-system with five DSN-node/target-nodepairs and a DSN server that can be accessed via the web.

In the center of the figure, there is a conceptual view of theDeployment-Support Network with the two separate wirelessnetworks: the one of the DSN-nodes and the one of the target-nodes. The network of the DSN-nodes is a automaticallyformed and maintained multi-hop backbone network, that isoptimized for connectivity, reliability and robustness.

The DSN-server is connected with the DSN-backbone-network and provides the client interface, over which the clientcan communicate and use the implemented DSN-services. Theclient is a target-specific application or script. The informationflow goes from the client over the DSN-server to the DSN-nodes and finally to the target nodes and vice versa. The DSN-server decouples the client from the target WSN both in timeand space. In particular, data from the target nodes are storedin a database and can be requested anytime, and commandscan be scheduled on the DSN-nodes. Separation in space isgiven through the client interface that allows for an IP-basedremote access.

B. Implications

Using this approach a minimum invasive but yet high degreeof observability is guaranteed on a target sensor networkeither in development or under test. Extending the classicalinfrastructure (serial port or Ethernet) based WSN testbed [4],[5] with wireless connectivity increases it’s versatility andmobility; making arbitrary node placements possible in a realdeployment area while still in an early phase of development.Here the MoteLab approach using fixed Ethernet back-channelis clearly inflexible as even in buildings with Ethernet cablingin place, access to this security critical infrastructure is oftenlimited if not impossible. The distribution of the centralizedcontrol and logging logic onto multiple DSN-nodes adds the


the scalability and reduces the interference caused by an in-system observer or in-network reprogramming [6]. Many, ultralow-power duty-cycle applications that transfer only a mini-mum payload or that use nodes with very limited resourcescan not support in-network reprogramming, which the DSNapproach clearly alleviates. Experience has shown that todayquite often application developers do not consider to integratedebugging and reprogramming facilities into their applicationsdue to the increased application complexity. Here, the DSNapproach with a clear separation of concerns into the targetsensor network functions on the one side and the deployment-support functions on the other side (i) allows operation ofa target sensor network application with it’s correct timingproperties, (ii) allows for frequent configuration changes with-out the burden of a heavy debugging infrastructure and (iii)simplifies the integration effort necessary to integrate all testand debugging infrastructure in a monolithic application.

III. DEVELOPMENT AND TEST: BASIC DSN-OPERATION

The implementation of the Deployment-Support Networkis based on the BTnode platform. In order to set up atestbed the BTnodes have to be programmed with the DSNapplication software and attached to target node devices usingan interface board (see Figure 2). These node pairs are thendistributed according to the test specification. They can beused either with fixed power using simple USB cabling orbe powered from batteries to allow quick changes in thelocations and independence from infrastructure (wall outlets).An access node is connected to a PC running the DSN-serversoftware that takes care of all communication to and fromthe Deployment-Support Network. Optionally and dependingon the target sensor network “under test”, a server or accessnode for the target network (e.g. a tmote connect) can also beused to monitor and control the target application.

Fig. 2. DSN-node/target-node pairs: BTnode, Tmote Sky, TinyNode, A80.

The DSN-server offers a single point of access to theDSN resource using XML-RPC and logs all interaction toa database. It can be controlled via a web-based interface(see Figure 3). Using this web interface, the DSN nodesare controlled, status is monitored, commands and softwareupdates are sent to the target nodes (via a DSN/target-nodepair), and logged data can be retrieved. Using the interfaceto the DSN-server, a developer can attach tools that suit hiscurrent needs in the development, deployment and testingprocess. For example, software for the assessment of the RF

channel and radio performance can be uploaded to differenttarget devices and operation is logged for a given period oftime. After completion of a test sequence the logged datais retrieved and analyzed. If desirable the process can berepeated, using modified target software, or by controlling theoperation of individual target devices, e.g. to inject coordinatedfaults into a system under test.

Fig. 3. Web-based control interface for the Deployment-Support Network.

In other scenarios, fine grained logging down to interruptgranularity might be of concern, e.g. when debugging lowlevel driver software, or long term logging and monitoring forapplication validation purposes.

In different case-studies [7] the Deployment-Support Net-work has proven to be a versatile and powerful tool that canbe used in a number of different ways in the development anddeployment process of wireless sensor networks.

REFERENCES

[1] G. Tolle, J. Polastre, R. Szewczyk, D. Culler, N. Turner, K. Tu, S. Burgess,T. Dawson, P. Buonadonna, D. Gay, and W. Hong, “A macroscope in theredwoods,” in Proc. 3rd ACM Conf. Embedded Networked Sensor Systems(SenSys 2005), pp. 51–63, ACM Press, New York, 2005.

[2] J. Beutel, M. Dyer, M. Hinz, L. Meier, and M. Ringwald, “Next-generation prototyping of sensor networks,” in Proc. 2nd ACM Conf.Embedded Networked Sensor Systems (SenSys 2004), pp. 291–292, ACMPress, New York, Nov. 2004.

[3] J. Beutel, M. Dyer, L. Meier, and L. Thiele, “Scalable topology control fordeployment-sensor networks,” in Proc. 4th Int’l Conf. Information Pro-cessing in Sensor Networks (IPSN ’05), pp. 359–363, IEEE, Piscataway,NJ, Apr. 2005.

[4] G. Werner-Allen, P. Swieskowski, and M. Welsh, “MoteLab: A wirelesssensor network testbed,” in Proc. 4th Int’l Conf. Information Processingin Sensor Networks (IPSN ’05), pp. 483–488, IEEE, Piscataway, NJ, Apr.2005.

[5] L. Girod, J. Elson, A. Cerpa, T. Stathapopoulos, N. Ramananthan, andD. Estrin, “EmStar: A software environment for developing and deployingwireless sensor networks,” in Proc. USENIX 2004 Annual Tech. Conf.,pp. 283–296, June 2004.

[6] J. Hui and D. Culler, “The dynamic behavior of a data disseminationprotocol for network programming at scale,” in Proc. 2nd ACM Conf.Embedded Networked Sensor Systems (SenSys 2004), pp. 81–94, ACMPress, New York, Nov. 2004.

[7] M. Dyer, J. Beutel, L. Thiele, T. Kalt, P. Oehen, K. Martin, and P. B.,“Deployment support network - a toolkit for the development of wsns,”in Proc. 4th European Workshop on Sensor Networks (EWSN 2007),pp. 195–211, Springer, Berlin, Jan. 2007.


Demo Abstract: Bytecode and Virtual Machine forSensor Networks

Rene Mueller, Michael Duller, Gustavo Alonso, Donald KossmannDepartment of Computer Science

ETH Zurich8092 Zurich, Switzerland

{muellren, dullerm, alonso, kossmann}@inf.ethz.ch

Abstract— The development of applications for sensor net-works is often a cumbersome, time-consuming, and difficult tasktypically involving low-level programming. Application changessuch as bug-fixes and code updates are expensive as, in general,the complete binary application image has to be replaced anddisseminated through the network. In this demo we presentSwissQM, a virtual machine for sensor networks. SwissQMaddresses many of these problems by raising the abstractionlevel available at the sensor network interface. Due to its compactbytecode, the resulting short programs can be easily updated anddisseminated.

I. INTRODUCTION

Application development for sensor networks is often dif-ficult due to the lack of high-level programming abstractions.On resource-constrained devices, such as sensor nodes, pro-gramming based on abstraction and encapsulation usually hasto give way to techniques such as cross-layer and assemblylevel optimisations. For instance, tasks like the routing layerand duty-cycle management are usually tightly intertwined, asboth need to be aware of the node’s sleep and active periods.Programming close to the hardware further aggravates thesituation when applications have to be ported to a differentsensor platform.

After deployment, the long-term maintenance of a sensornetwork is also complex. In existing systems, operationssuch as bug-fixes or application extensions typically requirecollecting and reprogramming each sensor node individually;for large deployments this is a very time-consuming task. Sys-tems have been proposed that allow reprogramming withoutrecollecting the sensor nodes. In Deluge [1] the entire binaryimage of the new application is sent through the network andlater written into the node’s program memory. Both sendingthe image (several kBs) over the radio and writing it into flashmemory consumes a considerable amount of energy. Anotherproposal suggests using a deployment-support network [2],a wireless cable replacement that allows individual remoteprogramming of the sensor nodes. Nodes of this maintenancenetwork are connected to the target nodes from the primarynetwork. While this approach solves the problem of havingto collect the nodes, it requires a secondary wireless networksolely for maintenance tasks.

SwissQM (Scalable WIrelesS Sensor Query Machine) [3]is a virtual machine for sensor networks that addresses theaforementioned problems. It uses a different approach than

Gateway

QM Programs

Data TuplesDatabase

Root Node

Fig. 1. Programm dissemination and result tuple tree in SwissQM

existing systems: it provides a platform independent interfacethat has been optimised for program size and high applicationturn around. As a virtual machine, it is programmable and usesan expressive bytecode. Due to a powerful bytecode instructionset the resulting application programs are small (in the order of30–100 bytes). Thus, they can be easily disseminated using asmall number of program messages, which reduces the costsfor application updates. Additionally, the bytecode providesthe same high-level programming interface across multipleplatforms. This greatly simplifies application development forsensor networks.

II. SWISSQM

SwissQM is a stack-based integer virtual machine thatruns on resource-constrained sensor nodes. The name QueryMachine (QM) emphasises the original application domainof SwissQM: the processing of queries in data acquisitiontasks. The architecture of SwissQM is shown in Fig. 1. TheSwissQM instruction set contains 37 instructions that arealso found in the Java Virtual Machine specification, and22 specific instruction that facilitate processing of streamingqueries on sensor nodes. As shown in [3], SwissQM can beused to process declarative queries, e.g., expressed in the same


BytecodeInterpreter

Operand Stack

Sensors

Synopsis TransmissionBuffer

Radio

QM Programs

Fig. 2. Architecture of SwissQM

SQL dialect as in TinyDB [4]. Queries are compiled intoQM bytecode programs at the gateway, which maintains directwire-connection to a sensor node. The compiled QM programsare then disseminated to the sensor nodes through the networkusing a broadcast mechanism. The data tuples generated by theprograms are sent back to the gateway through a spanning treerooted at the sensor node (the root node) that connects to thegateway. The application range of SwissQM is not limited toquery processing. The virtual machine can be used for a broadrange of applications, as shown in this demo.

SwissQM is implemented in nesC on TinyOS and currentlyruns on the Mica2 and tmote sky platforms. The architectureof the SwissQM virtual machine is shown in Fig. 2. SwissQMconsists of an Operand Stack that contains the operands usedby the Bytecode Interpreter. QM programs use the TransferBuffer to store data that are to be sent over the radio or toread data from received messages. The Synopsis is a datastructure that can be used to store aggregation state, e.g., toallocate a sliding window to implement temporal aggregation.SwissQM provides bytecode instructions for sampling sensors.The instruction set is extensible such that new instructions(e.g., for additional sensors) can easily be added. SwissQMis able to execute multiple programs concurrently. The pro-grams are scheduled periodically. An example program ofSwissQM’s bytecode assembly language is shown below. Itsamples the light, temperature, and humidity sensors. Everyfive seconds all nodes return their ID, a smoothed light sensorreading (using a simple first-order low-pass IIR filter), andan “air quality index”, which is computed as the average ofthe temperature and humidity value. The program consistsof two code sections. The init section is called once afterthe program is loaded. It initialises the state of the filter inthe synopsis. The delivery section is executed every fiveseconds when a tuple is due.

1 .tupleformat "nodeid","filteredlight","qualityidx"2 .section init3 get_light4 istore_sy 05

6 .section delivery, "@5s","synopsis","manualclear"7 get_nodeid # get node’s ID8 istore 0 # store it into transmission buffer

9

10 get_light # sample light sensor uk

11 iload_sy 0 # load old light value yk−1

12 iconst_413 imul14 iadd # compute uk + 4yk−1

15 ipushb 516 idiv # compute yk := (uk + 4yk−1)/517 dup18 istore_sy 0 # yk−1 ← yk

19 istore 1 # store yk in transmission buffer20

21 get_temp # sample temperature sensor tk22 get_humid # sample humidity sensor hk

23 iadd24 iconst_225 idiv # compute (tk + hk)/226 istore 2 # store it in tranmsission buffer27 send_tb # send transmission buffer

The length of the bytecode program is 25 bytes. Theprogram is disseminated using only two program fragmentmessages. The implementation of the SwissQM virtual ma-chine and its bytecode is explained in detail in [5].

III. DEMO DESCRIPTION

For the demo, a small-scale network consisting of 10 tmotesky sensor nodes is deployed. A notebook computer actsas the gateway, which runs the SwissQM interface software(assembler, network control, data visualisation, and logger)written in Java. Users can inject arbitrary programs writtenin SwissQM bytecode language from the gateway through agraphical user interface. These programs are then disseminatedthrough the network and executed concurrently on the sensornodes. Result data generated by the programs are sent back tothe root node along a spanning tree. In-network aggregationcan be applied to merge data tuples as they travel up to the rootnode. The root node forwards the data tuples to the gatewaythrough a serial USB link. At the gateway, result tuples canbe plotted and/or logged into a database for later analysis. Thedemo illustrates the power of SwissQM and the expressivenessof its compact instruction set.

ACKNOWLEDGMENT

The work presented in this paper was supported (in part)by the National Competence Center in Research on MobileInformation and Communication Systems NCCR-MICS, acenter supported by the Swiss National Science Foundationunder grant number 5005-67322.

REFERENCES

[1] J. W. Hui and D. Culler, “The dynamic behavior of a data disseminationprotocol for network programming at scale,” in SenSys 2004, 2004, pp.81–94.

[2] J. Beutel, M. Dyer, M. Hinz, L. Meier, and M. Ringwald, “Next-generation prototyping of sensor networks,” in SenSys 2004, 2004, pp.291–292.

[3] R. Muller, G. Alonso, and D. Kossmann, “SwissQM: Next generationdata processing in sensor networks,” in Proceedings of the 3rd BiennialConference on Innovative Data Systems Research, Asilomar, CA, USA,2007.

[4] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong, “TinyDB:an acquisitional query processing system for sensor networks,” ACMTrans. Database Syst., vol. 30, no. 1, pp. 122–173, 2005.

[5] R. Muller, G. Alonso, and D. Kossmann, “A virtual machine for sensornetworks,” in Proceedings of EuroSys 2007, Lisbon, Portugal, 2007.


Abstract—This demonstration shows the distributed acoustic source detection (DASD) system, which is implemented with the RETOS multi-threaded operating system. DASD uses an array of inexpensive microphones and its source detection operates in a fully-distributed manner. With this demo, we show the programming convenience of developing WSN applications using RETOS. We also demonstrate that RETOS is a mature and practical system which can be used to develop real-world WSN applications.

I. DISTRIBUTED ACOUSTIC SOURCE DETECTION DESCRIPTION Detecting the locations of acoustic sources automatically in indoor or outdoor environments has many practical applications in WSN. We have previously developed a range-free and fully-distributed acoustic source detection system (DASD) in a TinyOS environment [1]. With the development of the RETOS operating system [2,3,4], we have recently re-implemented DASD in the RETOS environment. In our demonstration we show the feasibility, efficiency and programming convenience of developing DASD by using a multi-threaded operating system.

Acoustic SourceLocation

Leader Node

Group

Interim Result

VotingGrid

Base Station

Estimated Location

Not-In-Group Nodes

In-Group Nodes

Figure 1. DASD system overview

Figure 1 illustrates the overall structure of DASD. Upon an acoustic event, a group, which is a unit of acoustic source localization, is constructed on-the-fly with all the listening nodes of the event. By comparing the listening times of all

nodes in the group, a leader is selected, which is the node closest to the acoustic source. A voting grid is then constructed in the leader node. The voting grid is a two-dimensional array of fields which are used to estimate the location of the acoustic source. Every node in the group votes separately for the possible location of the acoustic event, and the voting results are collected in the leader node to finalize the location.

II. DEMO DESCRIPTION The RETOS operating system currently supports TI MSP430, ATmega128 and Chipcon’s CC2430 family of microcontrollers. For DASD implementation, we built MSP430-based motes, which is a similar hardware to Tmote Sky[5], and an add-on sensor board. The sensor board has microphone, ultrasound, temperature/humidity and light sensors. Figure 2 shows the hardware platform used for DASD.

(a) MSP430 mote (b) Sensor board

Figure 2. Hardware platform The demo scenario is as follows. Given an indoor environment, we deploy eight sensor nodes at known positions. The nodes are time-synchronized via the FTSP protocol [6]. Once the nodes are ready for the event diction, a sound is generated by wooden sticks or hand clapping. The location of the sound’s source is then estimated in the specifically designed GUI at a base station. Figure 3 shows a snapshot of the planned demo. With this demo, we also show the usage of the RETOS operating system. First, the kernel is built and loaded into the hardware. Upon the RETOS boot, the modularized FTSP code is then loaded into the kernel via the loadable module feature of RETOS [7]. Finally, the DASD application code is loaded into the system and runs as a RETOS application. The FTSP module and the DASD application can also be removed without rebooting the system.

Demo Abstract: RETOS-based Distributed Acoustic Source Detection

Jaehyun Yoo, Youngbin You, Hyoseung Kim, Sukwon Choi and Hojung Cha

Department of Computer Science, Yonsei University Seodaemun-gu, Shinchon-dong 134, Seoul 120-749, Korea

{kjhyoo, ybyou, hskim, sukwon, hjcha}@cs.yonsei.ac.kr


Figure 3. Demo environment

ACKNOWLEDGMENTS This work was supported by the Korea Science and Engineering Foundation (KOSEF) through the National Research Lab. Program funded by the Ministry of Science and Technology (No. M10500000059-06J0000-05910).

REFERENCES [1] Y. You, H. Cha, “Scalable and Low-Cost Acoustic Source

Localization for Wireless Sensor Networks,” The 3rd International Conference on Ubiquitous Intelligence and Computing (UIC), Wuhan and Three Gorges, China, September 2006.

[2] H. Kim, H. Cha, “Toward a Resilient Operating System for Wireless Sensor Networks,” The 2006 USENIX Annual Technical Conference, Boston, Massachusetts, June 2006.

[3] H. Kim, H. Cha, “Multithreading Optimization Techniques for Sensor Network Operating Systems,” The 4th European conference on Wireless Sensor Networks (EWSN), Delft, Netherlands, January 2007.

[4] S. Choi, H. Cha, “Application-Centric Networking Framework for Wireless Sensor Nodes,” In Proc. of the 3rd Annual International Conference on Mobile and Ubiquitous Systems (MOBIQUITOUS), San Jose, California, July 2006.

[5] Tmote Sky, http://www.moteiv.com. [6] M. Maróti, B. Kusy, G. Simon, A. Ledeczi, “The Flooding

Time Synchronization Protocol,” In Proc. of the 2nd ACM Conference on Embedded Networked Sensor Systems, Baltimore, MD, 2004.

[7] H. Shin, H. Cha, “Supporting Application-Oriented Kernel Functionality for Resource Constrained Wireless Sensor Nodes,” In Proc. of the 2nd International Conference on Mobile Ad-hoc and Sensor Networks (MSN 2006), Hong Kong, China, December 2006.


Demo Abstract: SensorScope, An UrbanEnvironmental Monitoring Network

Guillermo Barrenetxea∗, Michel Bystranowski†, Olivier Couach†, Henri Dubois-Ferriere∗, Sebastien Dufey†,Mounir Krichane†, Julien Mezzo†, Severine Mortier†, Marc Parlange†, Gunnar Schaefer∗,

John Selker‡, Thierry Varidel† and Martin Vetterli∗∗School of Computer and Communication ScienceEcole Polytechnique Federale de Lausanne (EPFL)

CH-1015 Lausanne, Switzerland†School of Architecture, Civil, and Environmental Engineering

Ecole Polytechnique Federale de Lausanne (EPFL)CH-1015 Lausanne, Switzerland

‡Department of Biological & Ecological EngineeringOregon State University

Corvallis, OR 97331

Abstract— The SensorScope project is a collaboration be-tween environmental scientists and hardware/software engineersthat aims to study the energy exchanges and balances at theearth/atmosphere boundary. It consists in a large scale WirelessSensor Network deployed in the EPFL campus that measureskey environmental quantities at high spatial and time resolution.

I. PROJECTDESCRIPTION

The SensorScope project is a collaboration between envi-ronmental scientists and hardware/software engineers at EcolePolytechnique Federale de Lausanne (EPFL) that aims atbetter understanding the turbulent subgrid-scale physicsin anurban environment. SensorScope consists in a Wireless SensorNetwork (WSN) of 110 nodes (weather stations) deployed atthe university campus of EPFL. This network measures keyenvironmental quantities at high spatial and time resolution forthe purpose of modeling the influence of ground heterogeneityon meteorological parameters at local scale.

II. T HE SENSORSCOPEWEATHER STATION

The environmental data is gathered from a complete weathersensing unit specifically developed for the project to meet thefollowing requirements: inexpensive and manageable instru-ments, simple installation, energy autonomy, high-quality data,water resistant, and data available in real-time.

The sensing unit is centered around a wireless sensornode, the TinyNode module, which includes a TI MSP430microcontroller and a Semtech XE1205 radio. We chose thisplatform due to its long communication range and low energyconsumption [1].

Around the core module we have designed a solar energysubsystem, giving the stations energy autonomy for long-termoutdoor operation. The system is composed of a solar panel,a primary energy buffer, and a secondary energy buffer. Theprimary buffer is designed to be the preferred energy sourceto power the system by collecting energy from the solar panel

Fig. 1. SensorScope hardware: weather station, solar and sensor boards.

while the secondary buffer is used as a source of backupenergy during long periods of low solar energy.

The weather station includes seven external sensors, whichmakes the station capable of measuring nine different datainputs: air temperature and humidity, surface temperature, in-coming solar radiation, wind speed and direction, precipitation,soil moisture and pressure at ground level (see table). Thestation also includes a sensor interface board (Fig. 1(b)) toaccommodate all the sensors.

Sensor & Vendor Measurement Consumption Reading(mA) time (ms)

Davis 65050 solar radiation 1 15La Cross precipitation 0 0

Davis wind speed 0 0Davis wind direction 0.5 15

ECH2O EC-5 soil moisture 10 15Watermark soil moisture 6 15

Sensirion SHT7 temperature 0.55 210Sensirion SHT7 humidity 0.55 210

Zytemp TN9 infrared temp 6 500

Sensors are placed on an aluminium skeleton which includesalso a weatherproof (IP6/7) housing containing the core mod-ule, solar energy board, and interface board. Figure 1(a) showsthe complete SensorScope weather station.

All weather stations are validated before deployment: sensor


readings are compared to reference sensors over several daysof measurements.

III. N ETWORK AND SOFTWARE ARCHITECTURE

The weather station unit described previously has beendeployed following environmental requirements at over onehundred locations in the EPFL campus, which covers anarea of approximately 1200x600m. The large communicationrange provided by the Tinynode [1], together with the highreliability required in the data collection, makes the single-hop multiple-basestations approach the most suitable solutionfor our deployment.

The weather stations periodically sample their sensors every30 seconds and broadcast the readings to the basestationsin range. Using four base-stations we are able to cover thearea of interest. Depending on the location of the stations,the transmitted data can be heard by multiple basestations.This redundancy in the transmission allows to considerablyincrease the link quality in adverse scenarios such as urbanenvironments.

The stations have been programmed using TinyOS 2. Theyinclude a power control module that manage the energysystem, a sampling module and a communication module. Thecommunication module implements a Low Power Listeningwith a 10% duty cycle. The system allows to reprogramand to reconfigure the parameters of any weather station. Italso implements an alarm system that warns about differentconditions at stations: poor energy, negative energy budgets,low connectivity, and sensor aberrations.

IV. SENSORSCOPE FRONTEND

The information transmitted by the weather stations throughthe network is stored in a central database after being receivedby any of the base stations. Users can retrieve this informationtrough the Web server using one of the modules of theSensorScope web page. The are three main modules that allowthe user to view, download or plot the available data online.

The primary module of the SensorScope web page (http://sensorscope.epfl.ch/map/) is an interactive webapplication based on the Google Maps API. This web interface(Fig. 2) shows the exact location of each weather station.The Data Download module allows the user to download theavailable data from a set of weather stations for a given timeperiod in order to analyse it offline. The Data Drawing moduleallows the user to draw the available data from a weatherstation for a given time period. Finally, an administrationmodule allows the authorized users to change the location,the list of installed sensors or the photo of stations online.

V. DATA ANALYSIS EXAMPLE

The data collected from the SensorScope weather stationsis currently used in various atmospheric and environmentalmodeling projects. An example of these analysis is shown inFig. 3. It shows the air temperature distribution averaged over1 hour in the EPFL campus. To generate these maps, we use

Fig. 2. The web interface shows the latest available data from all the weatherstations in real-time.

(a) Air temperature surface on November 29th at 08:00 am

(b) Air temperature surface on November 29th at 18:00 pm

Fig. 3. Data analysis example.

the data from the weather stations and interpolate with anordinary kriging function using Arcgis.

These results show the different degree of spatial organi-zation of air temperature. It seems highly correlated with thesoil heterogeneity and these components should be taken intoaccount to predict that organization. Thus we can identifydifferent microclimate areas over the EPFL campus.

VI. SENSORSCOPEDEMO

The demo consists of a complete weather station transmit-ting sensor readings back to a basestation for display on aPC. We also show the SensorsScope front-end and the threemodules to view, download or plot the available data online.An accompanying poster shows the hardware designs (inter-face board and energy board) and software (communication,sensor and energy board drivers).

REFERENCES

[1] H. Dubois-Ferriere, R. Meier, L. Fabre and P. Metrailler, TinyNode:A Comprehensive Platform for Wireless Sensor Network Applications.Information Processing in Sensor Networks (IPSN 2006), Apr06.


Demo Abstract: Cross-level Simulation in COOJAFredrik Osterlind, Adam Dunkels, Joakim Eriksson, Niclas Finne, Thiemo Voigt

Swedish Institute of Computer ScienceEmail: {fros,adam,joakime,nfi,thiemo}@sics.se

Abstract— Traditional WSN simulators are limited to simu-lating nodes at one single abstraction level. This makes systemdevelopment and evolution difficult since developers cannot usethe same simulator for both high-level algorithm developmentand low-level development such as device-driver implementations.

The Contiki simulator COOJA allows for cross-level simula-tion, a novel type of wireless sensor network simulation thatenables holistic simultaneous simulation at different levels. InCOOJA one simulation can contain nodes from several differentabstraction levels. These are the network level, the operatingsystem level, and the machine code level.

We demonstrate a few different cross-level simulation scenariosusing the COOJA simulator.

I. COOJA

Code development for wireless sensor networks is difficultand tedious [1], [2]. Network simulators can be used tosimplify these development phases. Traditional sensor networksimulators perform simulation at one fixed abstraction levelsuch as the application, operating system or hardware level.The level at which the simulation is performed affects both thelevel at which software development can occur and the execu-tion efficiency of the simulator. A simulator that simulatesaparticular sensor node platform at the hardware level enablesthe development of low-level software such as device driversbut at the price of longer simulation times and higher codecomplexity since low-level programming languages must beused. Conversely, a high-level simulator that does not modelnode hardware may provide short simulation times but onlyallows for development of high-level algorithms.

Since the need of abstraction in a heterogeneous simulatednetwork may differ between the different simulated nodes,there are advantages in combining several different abstractionlevel in one simulation. For example, in a large simulatednetwork a few nodes can be simulated at the hardware levelwhile the rest are simulated at the application level. Usingthisapproach combines the advantages of the different levels. Thesimulation is faster compared to when emulating all nodes,but at the same time enables a user to receive fine-grainedexecution details from the few emulated nodes.

Examples of traditional simulators include NS-2 at thenetwork level, TOSSIM [3] for TinyOS at the operating systemlevel and Avrora [4] at the machine code instruction levelas shown in Figure 1. In contrast, our novel simulator forthe Contiki operating system [5] COOJA enablescross-levelsimulation[6]: simultaneous simulation at many levels of thesystem. COOJA combines low-level simulation of sensor nodehardware and simulation of high-level behavior in a singlesimulation. Furthermore, COOJA is flexible and extensible in

COOJA

NETWORK(APPLICATION)

INSTRUCTION SETMACHINE CODE

OPERATING SYSTEM TOSSIM

AVRORA

NS2

Fig. 1. COOJA can simultaneously simulate at several levels.

that all levels of the system can be changed or replaced: sensornode platforms, operating system software, radio transceivers,and radio propagation models. The simulator is implementedin Java, making the simulator easy to extend, but allows sensornode software, such as Contiki processes, to be written in C.

COOJA executes Contiki programs in two different ways.Either by running the program code as compiled native codedirectly on the host CPU, or by running compiled programcode in an instruction-level TI MSP430 emulator. COOJAis also able to simulate non-Contiki nodes, such as nodesimplemented in Java or even nodes running another oper-ating system. All different approaches have advantages aswell as disadvantages. Java-based nodes enable much fastersimulations but do not run deployable code. Hence, theyare useful for the development of e.g. distributed algorithms.Emulating nodes provides more fine-grained execution detailscompared to Java-based nodes or nodes running native code.Finally, native code simulations are more efficient than nodeemulations and still simulate deployable code.

Each simulated node in COOJA has three basic properties:its data memory, the node type, and its hardware peripherals.The node type can be shared by several nodes, and determinesproperties common between these nodes such as the simulatedsoftware. The hardware peripherals of simulated nodes are inCOOJA calledinterfaces. Interfaces enable the Java simulatorto simulate external events such as incoming radio trafficor external interrupts and to trigger events such as LEDchanges. Interfaces also represent properties of nodes such asa simulated node position. The node data memory representsthe current node state, and changes over time as the simulatedsoftware is allowed to execute.

When a simulation is running, nodes are sequentially al-lowed to act for a short time each. The node interfaces arepolled both before and after the node software is allowedto execute. When all nodes have acted the simulated time isincreased a fixed amount of time.

All interactions with simulations and simulated nodes are


performed viaplugins. An example of a plugin is a simulationcontrol that enables a user to start or pause a simulation.Both interfaces and plugins can easily be added to the Javasimulator, enabling users to quickly add custom functionalityfor specific simulations.

Each simulation in COOJA uses a radio model that charac-terizes radio wave propagation. The radio model is chosenwhen a simulation is created. This enables a user to, forexample, develop a network protocol using a simple radiomodel, and then test it using a more realistic model, or evena custom made model to test the protocol in very specificnetwork conditions. New radio models can easily be addedto the simulation environment. COOJA supports, except froma completely silent model, two different radio models. Thefirst is a unit disk graph radio model that has configurableinterference and transmission range parameters. The secondmodel is based on ray-tracing and supports multi-path effectswith radio absorbing materials.

II. CROSS-LEVEL SIMULATION

COOJA supports three different abstraction levels. Nodessimulated at theappliction or networking level are imple-mented in Java. Without any connection to Contiki, nodes atthis level can be useful when prototyping high-level algorithmswhich when tested and evaluated can be ported to deployablesensor node code. Other examples of other useful Java nodesare radio packet loggers, and traffic generators which arediscussed in further detail in Section III.

Nodes simulated at theoperating system levelexecute de-ployable Contiki code, but compiled as native code. An entireContiki system, including the core, pre-selected user processes,and a set of special simulation glue drivers, is compiled toa shared library. The library is loaded and controlled fromthe Java simulator via Java Native Interfaces (JNI). COOJAexploits the event-driven approach used in Contiki by callingthe loaded system in a way so that each simulated node handlesone event each every simulation loop.

The library memory defines the state of a node. It iscopied to, and later is fetched back from the library to thesimulator when the node handles an event. The interfaces ofthe simulated nodes communicate with the Contiki systemby manipulating this data memory. COOJA supports loadingseveral different libraries, these are loaded from different nodetype objects. And since the library code memory is read-only,all nodes of the same type share the same simulated code. Thedata memory of the library may however differ between eachsimulated node.

The machine-code levelabstraction level in COOJA isenabled by connecting a Java-based microcontroller emulatorto the simulator. It emulates an ESB node [7] (MSP430) atthe hardware level. The emulated nodes are controlled in asimilar way as the native code nodes. Each simulated nodeis allowed to execute for maximum a fixed period of time orlong enough to handle one event. Events are then, by using thecurrent node memory, transferred via the hardware interfacesto and from the simulator.

III. EVALUATION

We have previously demonstrated that, using cross-levelsimulation in COOJA, it is possible to maintain advantagesspecific to the different levels [6]. These advantages includeprocessing times and memory requirements of higher abstrac-tion levels and enabling access to fine-grained details of lowerlevels. For example it is possible to simulate 2000 nodes ina cross-level simulation (20 emulated, 1980 pure Java) in theexecution same time as a simulation with only 50 emulatednodes.

Another useful example of cross-level simulation is the sim-plicity of adding nodes with specific tasks. We implementeda radio traffic generator node at the application level, i.e.inJava. As it is much easier to implement Java code than low-level C code, the implementation only took a few hours. Thetraffic generator periodically transmits radio packets at ahighrate, thus efficiently disturbing surrounding radio traffic.

The main advantage of adding a new traffic generator nodecompared to “manually” disturbing selected radios from aplugin or a radio medium, is the flexibility it offers. Trafficgenerator nodes can be added and removed at run-time justas easily as any other simulated node. Further, the user caninteractively change the radio channels the traffic generatornodes disturb.

ACKNOWLEDGMENT

This work was partly financed by VINNOVA, the SwedishAgency for Innovation Systems, and the European Commis-sion under contract IST-004536-RUNES.

REFERENCES

[1] N. Ramanathan, K. Chang, R. Kapur, L. Girod, E. Kohler, and D. Estrin,“Sympathy for the sensor network debugger.” inACM SenSys, 2005, pp.255–267.

[2] G. Wittenburg and J. Schiller, “Running realworld software on simulatedwireless sensor nodes,” inProc. of the ACM Workshop on Real-WorldWireless Sensor Networks (ACM REALWSN’06), Uppsala, Sweden, June2006.

[3] P. Levis, N. Lee, M. Welsh, and D. Culler, “Tossim: accurate and scalablesimulation of entire tinyos applications,” inProceedings of the firstinternational conference on Embedded networked sensor systems, 2003,pp. 126–137.

[4] B. Titzer, D. K. Lee, and J. Palsberg, “Avrora: scalable sensor networksimulation with precise timing,” inInternational Conference on Informa-tion Processing in Sensor Networks (IPSN), 2005.

[5] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki - a lightweight andflexible operating system for tiny networked sensors,” inProceedingsof the First IEEE Workshop on Embedded Networked Sensors, Tampa,Florida, USA, Nov. 2004.

[6] F. Osterlind, A. Dunkels, J. Eriksson, N. Finne, and T. Voigt, “Cross-levelsensor network simulation with cooja,” inProceedings of the First IEEEInternational Workshop on Practical Issues in Building Sensor NetworkApplications (SenseApp 2006), Tampa, Florida, USA, Nov. 2006.[Online]. Available: http://www.sics.se/nes/osterlind06crosslevel.pdf

[7] J. Schiller, H. Ritter, A. Liers, and T. Voigt, “Scatterweb - Low PowerNodes and Energy Aware Routing,” inHawaii International Conferenceon System Sciences, Hawaii, USA, Jan. 2005.


Demo Abstract: GSN, Quick and Simple SensorNetwork Deployment

Ali SalehiSchool of Computer and Communication Sciences

Ecole Polytechnique Federale de LausanneSwitzerland

[email protected]

Karl AbererSchool of Computer and Communication Sciences

Ecole Polytechnique Federale de LausanneSwitzerland

[email protected]

Abstract— Wireless sensor and actuator networks are anemerging computer class based on a new platform, networkingstructure, and interface that enable novel, low cost and highvolume applications. One of the main obstacles in adaptionof the sensor networks is the lack of standardization and thecontinuous inflow of novel sensor network technologies whichhave made the sensor network deployment the main factor ofmanpower consumption. To address these problems we developedthe Global Sensor Networks (GSN) middleware with the aimsof rapid and simple deployment of a wide range of sensornetwork technologies, providing flexible integration and discoveryof sensor networks, enabling addition of new platforms quickly,and dynamically adaption of the system configuration duringoperation. In this paper we provide a brief overview of GSNwith the focus on automated wireless sensor network deployment.GSN is available for download at http://gsn.sourceforge.net.

I. INTRODUCTION AND MOTIVATION

The emergence of wireless sensor networks as one ofthe dominant technology in the coming decades has posednumerous unique challenges to researchers. These networksare designed to be composed of hundreds, and potentiallythousands of small smart sensor nodes (called motes), func-tioning autonomously, and in many cases, without access torenewable energy resources.

While the set of defined research problems in the wirelesssensor networks are diverse, we focus on practical aspectsof sensor network deployment. As organizations have begunworking with the wireless sensor networks, two significantobstacles have emerged: deploying wireless sensor networks isextremely time-consuming not only because of the complexityof creating the software that manages the networks and theircomponents but also the heterogeneity introduced due todifferent (an sometimes conflicting) application requirements.These challenges are so significant that they have sloweddeployment plans to a crawl, and have considerably temperedinitial excitement about wireless sensor network technology.

To address these problems we developed the Global SensorNetworks (GSN) middleware which supports rapid and simpledeployment of a wide range of wireless sensor network tech-nologies, provides flexible integration and discovery of sensornetworks in addition to the common data stream processingrequirements off the shelf. GSN offers virtual sensors as asimple and powerful abstraction, which enables the user to

declaratively specify XML-based deployment descriptors incombination with the possibility to integrate sensor networkdata through plain SQL queries over local and remote sensordata sources.

In the GSN we follow the standard model of sensor networkdeployment in which a sensor network can have one or morebase computers, which are dedicated to perform expensive datamining operations in addition to disseminating the outputs(processed or raw) to the interested users. GSN is designedto be used on the base computer. GSN looks at the sensornetwork as a black-box which can produce sensor data andoptionally consume control messages. Depending on hardwareand software restrictions on the sensor networks, the con-nection between the base computer and the sensor networkcan be either unidirectional or bidirectional. For instance, asensor network of RFID readers only produces a stream ofstring values representing the TagID and their contents (henceunidirectional) while a sensor network programmed to useTinyDB not only can produce the aggregated sensor readingsbut also can consume TinySQL queries (hence bidirectional).The reason for this separation is to use the in-network pro-cessing capabilities of sensor networks as much as possible.

II. GSN AND VIRTUAL SENSORS

The key abstraction in GSN is the virtual sensor. Virtualsensors abstract from implementation details of access tothe sensor network and correspond either to data streamsreceived directly from sensors or derived from other virtualsensors accessible through the network (thus a chain of virtualsensors). A virtual sensor can be any kind of data producerand/or consumer, for example, a real sensor, a wireless camera,a desktop computer, a cell phone, or any combination ofvirtual sensors. A virtual sensor may have any number of inputstreams (called sources) and produces exactly one output datastream based on the input data streams and arbitrary localprocessing. The virtual sensor descriptor (VSD), which is aXML file, provides all the necessary information requiredfor deploying and using the virtual sensors, such as themeta-data used for identification and discovery, the structureand properties of the produced data streams, a declarativeSQL-based specification of the data stream processing andfiltering and finally the functional properties related to stream


...<output-structure><field name="temp" type="double" /></output-structure><storage permanent="true" history-size="10h" /><streams><stream name="temperature"><source alias="temp" storage-size="10min">

<address wrapper="tinyos-2.x"><predicate key="host">pc15-epfl</predicate><predicate key="port">22001</predicate>

</address><query>SELECT avg(temperature) as AVERAGE

FROM WRAPPER</query></source><source alias="rfid" storage-size="1">

<address wrapper="rfid"><predicate key="host">pc16-epfl</predicate><predicate key="port">22001</predicate>

</address><query>SELECT rfid FROM WRAPPER</query></source><query>SELECT temp.average FROM

temp,rfid WHERE rfid.id = 587499</query>

</stream></streams>

...

Fig. 1. A typical virtual sensor definition.

quality management, persistence, error handling, life-cyclemanagement, and physical deployment. Figure 1 defines avirtual sensor that reads the RFID Tag from a reader andthe temperature sensors from a TinyOS-2.x network and incase the TagID equals to 58749 (representing the personnelidentifier number) outputs the latest temperature average overthat last 10 minutes.

For detailed description and analysis of all aspects of GSNwe refer the reader to [1].

III. DEMONSTRATION

The main benefits of using GSN are its modularity, exten-sibility, the low effort and experience required for deploying,and the integrating new sensor networks and the flexibility inreconfiguring all the aspects of the system while it is running.In the demonstration, our primary focus will be on deployingand integrating heterogeneous sensor networks to show thesimplicity and expressiveness we offer. The deployment andintegration of sensor networks is the major cost factor by far inthe software industry. In the demonstration we shall setup fourheterogeneous sensor networks: BTNodes using the NutOSoperating system, Mica2 nodes using TinyOS-2.x, a RFIDreader and wireless cameras. We intend to use several basecomputers to show the peer-to-peer nature of the GSN.

During demonstration, the audience is first invited to exam-ine the system using the web interface. The deployment is donesuch that the audience can issue arbitrary queries to the sensornetworks and integrate the output of the sensor networks basedon the desired application requirement. This experiment givessome initial hands-on experience of the sensor Internet. Afterthe initial familiarization with GSN, we invite the audience tointeractively change the setup of the system on-the-fly whilethe system is running. The audience will be able to monitorthe status of all components of the system and the reactions

to dynamic changes in configuration using the web interfaceand various network and system plots.

IV. RELATED WORK

Till now, the focus in the research community was onproviding energy efficient routing and data propagation al-gorithms inside one sensor network. In GSN we extendedthe idea to support interconnection and collaboration betweensensor networks independent of the algorithms used for inter-nal routing and data transmission inside each network. Oneof the close systems to GSN is [3], which suggests basicabstractions, a standard set of services and an API to freeapplication developers from the details of the underlying sen-sor networks. However, the focus is on systematic definitionand classification of abstractions and services, while GSNtakes more general view and provides not only APIs but alsoa complete query processing and management infrastructurewith fully declarative language. Other similar projects, such asthe Hourglass[4] provide connection between sensor networksand applications by providing topic-based discovery and dataprocessing services with the primary focus of maintainingquality of service of data streams in the presence of dis-connections. GSN however, targets at general abstraction,flexible configurations and distributed query support. TheHiFi[5] project’s aim is to provide efficient, hierarchical staticdata stream query processing to acquire, filter, and aggregatedata from multiple sources (with the homogeneous sensornetworks), while GSN takes the peer-to-peer perspective as-suming a dynamic environment (peers can join and leave) withheterogeneous sensor networks and allowing any node to bedata source, data sink or data aggregator.

V. CONCLUSION

GSN provides a flexible software infrastructure for rapid de-ployment and integration of sensor networks with the existingtechnologies and the outside world. GSN is designed to meetthe challenges that arise in real-world environments. GSN canhide any data source under its virtual sensor abstraction andprovides a simple and uniform API to use and interact withsensor networks. Due to space constraints we only providean overview of the GSN. A detailed description of variousaspects of GSN is given in [1], [2]. The GSN implementation,evaluation and the up-to-date documentations are available athttp://gsn.sourceforge.net.

REFERENCES

[1] K. Aberer el al., ”The Global Sensor Networks, middleware for effi-cient and flexible deployment and interconnection of sensor networks”,Tech. Rep. LSIR-REPORT-2006-006, Ecole Polytechnique Federale deLausanne, 2006.

[2] K. Aberer el al., ”A middleware for fast and flexible sensor networkdeployment” , VLDB, 2006.

[3] M.Sgroi et al., ”A service-based universal application interface for ad hocwireless sensor and actuator networks”, in Ambient Intelligence, SpringerVerlag, 2005.

[4] J. Shneidman et al., ”Hourglass: An Infrastructure for Connecting SensorNetworks and Applications”, Tech. Rep. TR-21-04. Harvard University,2004.

[5] M. Franklin, el al. ”Design Considerations for High Fan-in Systems” ,CIDR, 2005.


Demo Abstract: Spatial sensing to supportinteraction across devices

Roswitha Gostner and Hans GellersenLancaster University, Computing Department

InfoLab21, South Drive, Lancaster, LA1 1DY, UKEmail: {gostner, hwg}@comp.lancs.ac.uk

I. INTRODUCTION

We have built a sensor network called Relate which providesfine-grained relative position information to co-located sensornodes on the basis of peer-to-peer sensing. The sensor nodescan be attached to mobile devices via the USB port. Thedevices receive data from the nodes to compute a spatial modelof the relative positions of the co-located nodes [1]. Thisspatial information has been integrated in a set of widgets wecall the Relate toolkit, enabling the use of spatial informationfor different applications [2]. In this paper, we focus on theinteraction between co-located devices in terms of how thespatial information can be used to support this interactionand make interaction across devices transparent. We startby explaining the architecture of the toolkit followed bydemonstration scenarios to illustrate the capabilities of ourimplementation.

II. ARCHITECTURE

The platform is implemented in Java to enable the use of thetoolkit on mobile devices, regardless of the operating system.The Relate toolkit consists of six components (see Fig. 1):

1) The Relate Dongles forward raw measurements and hostinformation of co-located nodes via USB to the Relatetoolkit, see Fig. 1, (a) and (b) respectively.

2) The Measurement Component decodes the raw measure-ments and allows a user configureable set of filters tobe applied in order to encapsulate the processed data asevents for the Location Manager (c).

3) The Host Information Manager processes informationshared over the wireless RF network (b). Currently weexchange Relate id (a unique identifier for each node),user name, host device type (such as laptop or PDA)and IP address.

4) The Location Manager aggregates filtered distance andangle measurements and computes a best fit spatialmodel using non linear regression.

5) The P2P Device Discovery runs a device discoverylookup service, allowing the Relate toolkit to use multi-cast queries to discover all co-located Relate devices orto discover the IP address assigned to a specific Relateid (f).

6) The Spatial Model contains knowledge aggregated fromthree sources, (e,) (d) and (g) respectively and encapsu-lating it in a service providing relative coordinates, the

Fig. 1. Relate Toolkit Architecture

Relate id, user details and the IP address. This abstractrepresentation of a co-located mobile device is passedto registered applications, (h).

III. DEMONSTRATOR

We use three mobile devices, a Powerbook, an iBookand a PDA, in the demonstration scenario (see Fig. 2). Thedemonstrator shows six following aspects of the Relate toolkit:

A. Device Discovery

For the device discovery we run the application on twolaptops and a PDA. The Relate sensor nodes detect other nodesin proximity. This triggers the nodes to start acquiring distanceand angular measurements and forward them to the Relatetoolkit. The toolkit builds a spatial model which can be viewedgraphically by the device map Relate widget. This widgetshows an abstract representation of the co-located devices inthe relative spatial arrangement. This widget is illustrated inFig. 2, where the Powerbook device (a) shows the device


Fig. 2. Relate Toolkit Prototype

arrangement from its point of view, which is different fromthe device map of the iBook (b).

B. Device Position Update

The Relate sensor nodes constantly acquire measurementswhich are aggregated into the local spatial model. Any move-ment of the devices can be observed in the device map widgetas a movement of the abstract device icon. Movement appearsdifferent on each device display, as the graphical abstractionicon moves relative to the local device position and orientation.The device map widget is updated at 200ms intervals to reflectthe changes in the Relate model. Although the spatial model isupdated with each measurement, this display update rate givesthe appearance of smoothing jitter in the calculated devicepositions for the graphical display.

C. Filter Inspection Tool

An additional method of smoothing location data is to applya set of filters in the Measurement Manager. To support debugactivity and error detection we implement a filter inspectiontool. This allows the user to see a dynamically updatedgraphical representation of distance and angular measurementsbetween two nodes, while configuring filters. Here, any modi-fications in the filter configurations are immediately visible inthe same window as a before and after display.

D. Device Removal

When mobile devices move out of sensing range, or theuser stops the Relate application, the remaining active Relatenodes stop receiving measurement updates. If the spatial modelreceives no update information for a pre-defined time, it isassumed the node has disappeared and it is removed fromthe system. On the graphical interface, the device icon simplydisappears.

E. Host Information Exchange

The Relate nodes exchange host details such as Relateid, IP Address, device type and user name over the Relatenode RF network. This information is visible by a right clickmenu over the graphical representation of the mobile device.The RF network is limited in terms of the amount of non-measurement information that can be exchanged, however, weassume further information can be exchanged by wireless IPnetwork when necessary (see (f) in Fig. 1). For example,

we have implemented a scenario where the user can rightclick on the graphical representation of another mobile deviceand receive a virtual business card of its user in the VCardformat by knowing only the devices relative location. Here, theamount of contact information is too large to be transmittedonly over the RF network, so the Relate toolkit implementstransparent use of the IP network.

F. File exchange

The Relate toolkit’s implementation of transparent IP net-work access allows users to send files to remote mobile devicesby dragging and dropping the file on their abstract graphicalrepresentation. Without the Relate Toolkit, the user would needto know the IP address or machine name of the remote devicein order to connect and transfer the files over the network.

IV. CONCLUSION

The Relate toolkit demonstrator illustrates how spatial sens-ing can be used to support transparent interaction across mo-bile devices. We provide several concrete application scenariosand show how the use of spatial information can benefit theuser through the use of Relate toolkit widgets. Further researchis planned to explore new ways to use spatial information andnew Relate toolkit widget designs to support multi-device userinteraction.

ACKNOWLEDGMENT

The work was supported by Project No. 013790 FP6 ISTProgramme funded by the European Commission. The authorsthank Gerd Kortuem, Rene Mayrhofer and Carl Fischer fortheir support.

REFERENCES

[1] M. Hazas, C. Kray, H. Gellersen, H. Agbota, G. Kortuem, A. Krohn, Arelative positioning system for co-located mobile devices. In Proceedingsof 3rd International Conference on Mobile Systems, Applications, andServices (MobiSys) 2005, June, Seattle, USA.

[2] G. Kortuem, C. Kray, H. Gellersen, Sensing and visualizing spatialrelations of mobile devices. In Proceedings of the 18th Annual ACMSymposium on User Interface Software and Technology, Seattle, WA,USA, October 23-26,UIST 2005.


Demo Abstract: TinyOS on Mindstorms NXTRasmus Pedersen

Email: [email protected]

Abstract— We introduce NXTMOTE, which is a TinyOS motefor LEGO Mindstorms NXT. The LEGO Mindstorms NXTsystem can be used as a sensor node platform with a TinyOSfirmware replacement. We propose to use it for embeddedwireless sensor network applications. The LEGO NXT brickis a system with a large and growing community focused onmany different embedded operating systems and programminglanguages. TinyOS can thus be used in comparison to other em-bedded operating systems or used as a prototyping platform priorto production of more specialized motes/PCBs. NXT features anARM and AVR MCU that allows for interesting machine learningexperiments.

I. INTRODUCTION

The Mindstorms NXT system from LEGO is an interestingand flexible hardware platform. Figure 1 shows the NXT withthe standard sensors attached. The NXT PCB is equipped withan ARM MCU as well as an AVR MCU: both MCUs arefrom Atmel. Furthermore, these two MCUs are connected toinput ports, output ports, a LCD, Bluetooth radio, and USB.Moreover, there is already a rich set of sensors available fromboth LEGO and third party vendors, which enables the useof the NXT system for prototyping in relation to almost anyconceivable research project.

Fig. 1. NXT with standard LEGO sensors

The NXT brick and LEGO Mindstorms have a large userbase. The NXT brick provides open source firmware writtenin C for both processors on the board. It is likely that manydifferent embedded operating systems—besides TinyOS—areto be ported to the NXT brick. This is worthful as it possiblybecomes the first mote platform where TinyOS can be directlycompared to other embedded operating systems.

We introduce NXTMOTE [2], which is a TinyOS imple-mentation for the LEGO Mindstorms NXT Brick. It is anopen source implementation together with the documentationneeded for programming the NXT system.

II. NXT BRICK

In this section we briefly describe the NXT software, hard-ware, and sensor architecture. LEGO is publishing a detailed

set of documentation that is available from the Mindstormsweb site [1]. Finally, we cover a few of the firmware operatingsystem replacements and some of the available front-ends thatare already coming up for NXT.

A. NXT Software Architecture

The standard firmware NXT virtual machine (VM) executesprograms consisting of NXT bytecodes. These bytecodes aregrouped into six classes: math, logic, comparison, data manip-ulation, control flow, and system i/o. The NXT VM executesas many bytecodes as it can within an update round in theNXT OS. During this update round each module can performits functions; such as updating the display in the case of thedisplay module. The approach taken with the NXT software isto address shared structures and subsequently each module isresponsible for its actions. This round-robin approach dictatesa need for explicit state-control in many of the modules.

B. NXT Hardware Architecture

NXT features an ARM7 processor and an AVR: theAT91SAM7S256 and the ATmega48 as listed in Table I. Italso has a 100x64 LCD, and a Bluetooth (BT) radio that sharesthe same SPI bus. The Bluetooth chip is from CSR—namedBlueCore—and it is running the BT-stack from CSR calledBlueLab. It supports the serial port profile. The AVR controlsthe three output ports and communicates with the ARM overI2C/TWI.

TABLE INXT MCUS: ARM7 AND AVR

AT91SAM7S256 ATmega48Flash 256 KB 3 KBSRAM 64 KB 512 BytesSpeed 48 MHz 8 MHz

C. Sensors

The input and output ports features a 6 wire RJ12 connector.On the input ports there are both analog and digital ports. Onthe output ports PWM functionality is used with the motorsin the standard NXT firmware. The NXT comes with a basicset of sensors. This basic set includes an ultrasonic distancemeasurement sensor, a light intensity sensor, a sound sensor,a touch sensor, and the servo motors with a built-in rotationsensor. Furthermore, there are a number of third party sensorsavailable such as various acceleration sensors, a compasssensor, a temperature sensor etc. More complete listings are


available at the Mindsensor and Hitecnic sites (linked from[1]). The US-based Vernier also produce sensors such as pHprobes or magnetic field probes only to name a few. Finally, itis possible to define specific sensors for a given project usingfor instance the free version of EAGLE from CadSoft.

D. NXT Firmware Replacements and Front-ends

A non-exhaustive list includes a modified version of thefirmware, which can be programmed using RobotC. Front-ends to the standard firmware are also becoming available,and in this category we find the NXT Bytecodes, NBC, whichis available from the bricxx Sourceforge project. MicrosoftRobotics Studio is also a choice for programming the NXT. Itis evident that numerous firmware replacements are to becomeavailable for most embedded operating systems, and probablymultiple front-ends using most programming languages: TheJava-based Lejos (for the RCX) or this new nesC-basedNXTMOTE just to name some.

III. NXTMOTEThe NXTMOTE [2] is a TinyOS project for the NXT brick.

It is a port of TinyOS for NXT, but we also aim to include gcctoolchains, a machine learning library, tutorials etc. The intentis to complement existing motes such as mica/mica2, intel-mote2, telos, etc. by following the TEP guidelines and similardevelopment and availability policies. The ”hello world” wasachieved with nxtmote v. 0.0.1 early Nov. 2006 and the fullimplementation is ongoing work. LEGO officially released thefirmware sources Dec. 2006.

A. Toolchains

The LEGO NXT firmware is released for an IAR systemstoolchain compiler. We have converted the source code andmade the gcc-based toolchain available [2] as announced at theLEGO Users Group Network (LUGNETTM). The toolchainsare for the ARM7 (arm-elf-gcc) and for the AVR (avr-gcc).The ARM7 toolchain is based on gcc, binutils, and newlib.For the AVR, we configure the toolchain using the binutils,gcc, and libc packages. A recent version of gcc is needed forC support of the AT48 MCU.

B. Machine Learning on NXT

The TinyOS motes are effective platforms for experimentingwith energy aware machine learning algorithms [3]. We areprogressing toward a machine learning API labeled tinyml.NXT is equipped with the powerful ARM MCU and thesmaller AVR MCU. This setup makes it possible to createpower-aware configurations seeking the optimal balance be-tween using the somewhat restricted AVR versus the morepowerful ARM as new obstacles or decisions calls for morecomputational capability during deployment of the mote. Inaddition, the ARM features two instruction sets. One is the16 bit Thumb instruction set that has a smaller code foot-print while the 32 bit ARM c©instruction set provides higherperformance. The ARM c©instruction set also delivers severalDSP-like instructions that provide for low-level power andperformance optimizations.

C. Programming and Debugging

Both the ARM and the AVR can be accessed by JTAGconnectors. The J17 JTAG pins for the ARM are not mountedon the production PCB; however, it is possible to create oneusing a 1.27 mm pitch row connector. The square hole is pin 1on the PCB. Each of the eight pins from J17 can be connectedto a standard 20 port JTAG like this: 1→ 9, 2→ 7, 3→ 13,4 → 15, 5 → 5, 6 → 4, 7 → not connected, and 8 → 1. Itworks even without soldering the pins to J17. Subsequently,several options exist for flashing the ARM7: J-Link from IARor Segger, ARM-JTAG from Olimex, or the JTAGkey fromAmontec to name a few.

The NXT ARM is easily flash programmed with the stan-dard USB cable and the LabVIEW-based block programmingIDE from LEGO. A more direct approach is to use the SAM-BA program from Atmel or a Linux friendly application calledLibNxt that includes SAM-BA support for both Linux andWindows.

The AVR can be programmed using a suitable system likethe AVR ISP In-System Programmer from Atmel . Severalother options are available and a community like AVR Freakscan be a useful one to look into.

D. Radio Sensors

We are currently working on providing a 802.15.4 radiosensor for NXTMOTE in addition to the built-in Bluetoothradio. There are several approaches to accomplish this. It ispossible to tap into the SPI bus that is shared between theLCD and the BlueCore modules: this requires some additionalcontrol lines probably coming from one or two of the inputports. A different option is to use one of the input ports tocreate an I2C based sensor with an additional MCU involved.

IV. CONCLUSION

The NXT brick is a suitable platform for prototyping differ-ent TinyOS experiments for a wide variety of sensors. We havepresented the first TinyOS project for this research direction.With NXTMOTE it will be possible to add a dynamic (ie.robotic) element to the experiments as well as a machinelearning component. Finally, the great availability of NXT andcompatible sensors ensures an affordable research platform.

ACKNOWLEDGMENT

LEGO Education and LEGO Electronics R&D.

REFERENCES

[1] LEGO Mindstorms, http://mindstorms.lego.com.[2] R. Pedersen, NXTMOTE, http://nxtmote.sourceforge.net.[3] R. Pedersen, Distributed Support Vector Machine, http:

//www.diku.dk/publikationer/tekniske.rapporter/rapporter/05-01.pdf.


http://mindstorms.lego.com

http://nxtmote.sourceforge.net

http://www.diku.dk/publikationer/tekniske.rapporter/rapporter/05-01.pdf

