jWebDust: A Java-based Generic ApplicationEnvironment for Wireless Sensor Networks ?

Ioannis Chatzigiannakis1, Georgios Mylonas2, and Sotiris Nikoletseas1

1 Research Academic Computer Technology Institute, P.O. Box 1122, 26110 Patras, Greece,{ichatz,nikole}@cti.gr

2 Dept of Computer Engineering and Informatics, University of Patras, 26500, Patras, Greece,mylonasg@ceid.upatras.gr

Abstract. Wireless sensor networks can be very useful in applications that re-quire the detection of crucial events, in physical environments subjected to criti-cal conditions, and the propagation of data reporting their realization to a controlcenter. In this paper we propose jWebDust, a generic and modular applicationenvironment for developing and managing applications that are based on wirelesssensor networks. Our software architecture provides a range of services that allowto create customized applications with minimum implementation effort that areeasy to administrate. We move beyond the ”networking-centric” view of sensornetwork research and focus on how the end user (administrator, control centersupervisor, etc.) will visualize and interact with the system.We here present its open architecture, the most important design decisions, anddiscuss its distinct features and functionalities. jWebDust allows heterogeneouscomponents to interoperate (real world sensor networks will rarely be homoge-neous) and allows the integrated management and control of multiple such net-works by also defining web-based mechanisms to visualize the network state, theresults of queries, and a means to inject queries in the network. The architecturealso illustrates how existing protocols for various services can interoperate in abigger framework - such as the tree construction, query routing, etc.

1 Introduction

Wireless sensor networks are very large collections of small in size, low-power, low-cost sensor devices that collect and disseminate quite detailed information about thephysical environment. Large numbers of sensor devices can be deployed in areas ofinterest (such as inaccessible terrains or disaster places) and use self-organization andcollaborative methods to form a sensor network. The flexibility, fault tolerance, highsensing fidelity, low-cost and rapid deployment characteristics of sensor networks helpto create many new and exciting application areas for remote sensing.

This wide range of applications is based on the use of various sensor types (i.e. ther-mal, visual, seismic, acoustic, radar, magnetic, etc.) in order to monitor a wide variety of? This work has been partially supported by the IST / FET Programme of the European Union

under contract numbers IST-2004-001907 (DELIS) and the Programme PYTHAGORAS un-der the European Social Fund (ESF) and Operational Program for Educational and VocationalTraining II (EPEAEK II).

2

conditions (e.g. temperature, object presence and movement, humidity, pressure, noiselevels etc.) and report them to a (fixed or mobile) control center. Thus, sensor networkscan be used for important applications, including (a) military (like forces and equipmentmonitoring, battlefield surveillance, targeting, nuclear, biological and chemical attackdetection), (b) environmental applications (such as fire detection, flood detection, pre-cision agriculture), (c) health applications (like telemonitoring of human physiologicaldata) and (d) home applications (e.g. smart environments). For an excellent survey ofwireless sensor networks see [1].

Another possible categorization of the applications for wireless sensor networks isbased on the notification strategy of the authorities, i.e. the way that the authorities areupdated on the monitoring state. For example, in a museum, it is important to reportonly when emergency situations arise, such as an incendiary fire. On the other hand, inhabitat monitoring for instance, continuous monitoring of the physical environment isrequired so that information is gathered over a long period of time. Therefore, depend-ing on the actual application, the following services are required [3]: (i) Periodic Sens-ing (the sensor devices constantly monitor the physical environment and periodicallyreport their sensors’ measurements to a control center), (ii) Event driven (to reduce en-ergy consumption, sensor devices monitor the environment and send reports only whencertain events are realized) and (iii) Query based (sensor devices respond to queriesmade by a supervising control center).

In the light of the above categories of applications and services, we present jWeb-Dust, a software environment that allows the implementation of customized applica-tions for wireless sensor network that can (i) provide a wide range of services, (ii)minimize the overall implementation effort and (iii) considerably reduce the needs fornetwork administration. jWebDust is modular and extendable as the application imple-mentor can use a selected set of features, modify some of them and provide new onesthat best suit his needs; in this sense, jWebDust is able to deal with several kinds ofapplications (size, functionality, etc.).

jWebDust differentiates the system into two main groups: the networked sensor de-vices (from now on referred as motes) that operate using TinyOS and the rest of the net-work (e.g. control centers, database server, etc.) that is capable of executing Java code.Both system groups use an open architecture implementing the emerging component-based architecture. The standardized component interface and the exchange of data overbroadly used protocols provide increased portability. This implies that the system canbe used over different machine architectures as well as OS and server technologies.

We define and implement the Mote Discovery Service that reduces significantlythe overall network administration needed in applications for wireless sensor networks.More specifically, this novel service keeps track of the motes that participate in the wire-less sensor network and their technical characteristics (e.g. type of sensors attached toeach device, available power, etc.). During the setup phase of the network, the motesreport to the control center of the network and get registered in jWebDust’s databasewithout any further human interaction. In this sense, the time required by the adminis-trator to register the devices that make up the network and their hardware characteristicsis greatly reduced, especially in the case where the network is comprised of heteroge-neous devices [5, 8]. Furthermore, in some cases, it is possible to redeploy additional

3

Fig. 1. Multiple wireless sensor networks form a single, unified, virtual sensor network

motes in order to extend the lifetime of the network and/or increase the area of surveil-lance while the network is in operation [1, 5]. In such cases, the discovery service im-proves the scalability of the applications that are based on jWebDust, since the needfor network administration is unaffected as the size of the sensor networks increases.

A distinct feature of jWebDust is its ability to manage multiple wireless sensornetworks, each with a different control center, under a common installation (e.g. seeFig. 1). This is done by introducing the notion of a virtual sensor network that somehow,hides the actual network topology and allows the user to control the motes as if theywere deployed under a single, unified, sensor network. This abstraction significantlyreduces the overhead of administering multiple networks. Furthermore, the idea of aunified, virtual sensor network allows the integration of totally heterogeneous sensornetworks, i.e. not only regarding different kind of sensors attached to the motes of thenetwork, but also different kind of CPU architectures and communication units.

In jWebDust, the information collected by the control center of each operating sen-sor network is stored in a single, central, relational database. Based on this databaseserver, jWebDust provides a web-based, user-friendly interface that targets both toscientific as well as other less technically-trained personnel. This user interface is cus-tomizable and allows the designer to present the information in different ways and offersextendable statistics based on the needs of the application.

The component-based architecture that is used in designing jWebDust provideshigh adaptability. The software under development provides an open interface throughwhich added functionality can be implemented and integrated at later stages, probablycarried out by the final application implementor.

Although wireless sensor networks have attracted a lot of attention from researchersat all levels of the system hierarchy (from the physical layer up to the application layer),generic application environments that provide all the necessary tools and operations toallow the implementation of a wide range of applications are few [1]. To the best of ourknowledge, there are only two such environments: TinyDB [11] and Mote-VIEW [9].

TinyDB is an application that allows multiple concurrent queries, event-based queriesand time synchronization through an extensible framework that supports adding newsensor types and event types. The central idea of TinyDB is to provide an SQL-like

4

interface to the programmer that makes the wireless sensor network look like a DBMS.A tree based routing scheme is used for multi-hop communication inside the network.In addition, TASK [10] (Tiny Application Sensor Kit) is built on top of TinyDB in orderto further simplify application deployment and development. The kit includes a serverthat acts as a proxy for the sensor network on the internet, a relational database wherereadings from the sensor network are stored, and a frontend that help to choose, recordand visualize motes’ metadata. In contrast to the database schema used in TASK, ourapproach is more detailed and can be easily extended to the final application’s function-ality needs (e.g. adding new sensor types, mote types, etc.).

Mote-VIEW [9] is an application that provides tools to the user to visualize re-sults from a sensor network, combined with a data logger that runs on the sensor net-work gateway. The data logger constantly listens to readings arriving from the networkthrough a control center attached to the gateway and stores them in a relational database.The motes in the sensor network poll their sensors for readings at a sampling rate spec-ified by the user and send them to the gateway using a multi-hop protocol. The user cancheck readings from the motes’ sensors on the fly, see a visualization of the network’stopology, produce graphs from selected motes’ readings, and check their status.

2 The Architecture of jWebDust

jWebDust is designed on a component-based architecture with several and diverse de-sign goals as a guide that emphasizes on autonomy, reliability, and availability. At ahigh-level, the components of jWebDust are organized, using the N-tier applicationmodel, as follows: (i) the Sensor Tier that consists of one or more wireless sensor net-works deployed to areas of interest, (ii) the Control Tier that corresponds to the controlcenters where the wireless sensor networks report the realization of events, (iii) theData Tier responsible for storing the information extracted from the wireless sensornetwork(s), (iv) the Middle Tier that is responsible for processing the data to generatestatistics and other meaningful information and (v) the Presentation Tier that interfacesthe information with the final user in an easy way based on the capabilities of the user’smachine. The five tiers that make up jWebDust are shown in Fig. 2.The Sensor Tier. Naturally, the sensor tier is the foundation of any application basedon wireless sensor networks. The motes are usually scattered in the area of interest andform one or more sensor networks. Each of these scattered motes has the capability tocollect data and route data back to the control center and the end users. Data are routedto the control center by a multi-hop architecture (described in greater details in Sec. 3)and then the control center communicates with the other tiers of the system possibly viainternet.

The jWebDust firmware, executed by the motes, is based on the TinyOS operat-ing system and implements a mote discovery protocol for reporting their sensing andprocessing characteristics to the control center and a query dissemination protocol fordistributing queries in the sensor network and disseminating the data matching thesequeries back to the control center; these protocols are defined more formally in Sec. 3.The Control Tier. The Control Tier consists of the control centers of each sensor net-work. Control centers are responsible for the gathering of all the readings coming from

5

Fig. 2. N-tier Architecture

the sensor networks and the forwarding of the queries from the data tier to the motes;in other words, they act as gateways between the sensor tier and the data tier. On thehardware level, a typical control center consists of one mote connected to a desktop PCor laptop along with a network connection to the database server. The mote attached tothe control tier is necessary to communicate with the sensor network. Alternatively, anembedded platform can be used (e.g. Stargate [9]).

One important feature of the control tier is the ability to operate even when thereis no connection to the data tier for sustained periods of time. The importance of thisfeature is outlined by the fact that control centers themselves may have a wireless con-nection to the data tier and uninterrupted communication is not guaranteed. During sucha disconnected period, any new queries made will not be forwarded to the sensor net-work (since the control center cannot be informed about these queries), while sensorreadings received will not be sent to the data tier but will be stored locally. As soon asthe control center establishes a connection with the data tier, all locally stored readingsare forwarded to the data tier and the new queries are forwarded to the network.

Another jWebDust’s feature is the support of multiple sensor networks in a way thatthey are seen as a single virtual sensor network. For each sensor network a unique IDis given to its respective control center. This sensor network ID helps to distinguish onemote from another, when they have they same mote ID but belong to different sensornetworks, thus making it possible to manage different networks in a unified way.

The Data Tier. The components at the data tier are based on the relational databasesystem and the functionality and methods provided are related to the services requiredby the middle tier and the control tier. Our database schema consists of ten tables thatcan be organized in three categories:

(i) Mote related tables. The information related to the hardware characteristics of themotes that comprise the wireless sensor networks are organized in this categorywith the use of five tables. The database scheme supports heterogeneous sensornetworks, i.e. networks that consist of different kinds of motes (e.g. Telos, MicaZ

6

motes etc.), which in turn may have different kinds of sensors attached to them(e.g. light, pressure, humidity, temperature etc.).

(ii) Query related tables. This group of tables holds information regarding the queriesthat are made on the network that may possibly address multiple sensors and/ormultiple sensor types (for more information see Sec. 3).

(iii) Sensor readings table. All the information received from the sensor networks thatmatch a specific query is stored in this table. Each record represents a reading com-ing from a specific mote in the network concerning a single sensor.

The Middle Tier. The Middle tier is comprised by all the components that make upthe jWebDust logic and are responsible for delivering structures and data to the pre-sentation tier. The components of the middle tier can be considered as applicationsthat run on a server without a face (also referred to as servlets). These componentshave autotelic functionality that is executed independently in order to process certaindata structures and produce specified output. In this extent, components contribute toa simpler distribution of workload and allow easy development of the presentation tierservices. In jWebDust the components of the presentation tier and the middle tier canoperate simultaneously and independently.

Components are formulated based on the data structures available and the operationsrequired by each entity. For example, the management of queries is handled by a sin-gle component and the methods implemented perform actions such as createQuery,deleteQuery, updateQuery, etc. All these methods accept parameters given bythe presentation tier. The logic of the creation of a new query (i.e. check if a similarquery already exists or if the mote provides the sensors specified in the query) is stan-dardized through a single component. The query component just described, along withother similar components that are part of the jWebDust system are also referred to asthe executants. The executants provide a specified interface to the other components;thus if modifications to jWebDust logic are carried out, the implementation of this in-terface can be modified. As long as the interface remains unaffected, components thatuse the executants will not notice any change and will not require any further change.The Presentation Tier. The presentation tier is basically the user interface; it is thelayer most available to the end users, responsible for the collection of input and presen-tation of the information collected from the sensor network. The components that makeup the presentation tier are based on different technologies. The terms thin client andrich client are used to describe the capabilities of the presentation tier given the availableresources. We characterize as rich clients the components of the presentation tier thatare rich of functionality. The support of thinner clients will ensure the interoperabilityof the system through the various available machine architectures. The end users areallowed to choose among the available client solution in order to maximize the avail-able resources. The open architecture of jWebDust system allows new components tobe introduced at later stages that will cope with these issues.

3 Sensor Network Services and Protocols

Mote Discovery Service. One of jWebDust’s features is that every mote is able toregister itself and its distinct features to the system, thus giving a clear view of the

7

Fig. 3. GUI windows displaying sensor readings reported by the sensor network that match sam-ple queries made by the user to specific motes, regarding different type of sensor devices

network and removing the need to initiate a mote discovery process periodically. Themote discovery service provides the user with a detailed view of the properties of eachmote inside the (possibly heterogeneous) sensor network. Other existing applications donot provide such detailed information and thus do not cope well with the case of havingmotes with different sensors attached to them. As an example, consider the case wherewe want to have motes collecting temperature readings on the one side of the sensornetwork and on the other side motes with a different kind of sensor board collectinghumidity readings. The use of different kinds of sensor boards could also be justified interms of cost or because we want to take advantage of older equipment.

The operation of the discovery service relies on the correct programming of themotes; when installing the application firmware on the mote, the actual hardware char-acteristics are passed as parameters to the service. Each sensor type available to eachmote and its mote type are represented by an integer, in correspondence to the integerIDs used in the data tier concerning the mote and sensor types (see Sec. 2). Based onthis information, the discovery and registration of every mote in the network is achievedusing a simple protocol.

Essentially, when a mote is powered on, and after its startup and initialization phasecompletes, the mote sends out to the control center a short message containing themote’s ID, type and a list of available sensors. By sending this message, the mote regis-ters itself in jWebDust’s data tier along with an amount of useful information when thecontrol center receives the message. Note that after sending the message, the mote waitsfor an acknowledgement message from the control center. This is done to make surethat the registration message will reach the control center within a certain time period.If such an acknowledgment message is not received within the given time period (thatcan be adjusted depending on the expected network size and communication mediumparameters), the mote sends another registration message. This process is repeated untilan acknowledgement is properly received.

Time Synchronization Service. Time synchronization of the motes is a significant partof any sensor network as applications need some kind of collaboration between the

8

motes in the network, which in turn means some kind of acceptable time synchroniza-tion. jWebDust uses a time synchronization scheme that follows an approach similar toTPSN [7]. Our method provides accurate time synchronization as it performs pairwisetime synchronization between motes using the structure established by the communi-cation protocol (see below). Every mote maintains a local clock that is synchronizedwith respect to a reference mote (e.g. the control center). In order to avoid collisionsin the medium access level, at the beginning of the synchronization process, each motedecides to initiate time synchronization, individually, after a random period of timefollowing the reception of a time-sync message.

Sensor Network Communication Protocol. Communication in wireless sensor net-works presents many distinctive characteristics, which render the conventional and mostad-hoc routing approaches inadequate for use in these networks. Many routing schemeshave been proposed specifically for sensor networks [4, 6], however only a few of themhave been implemented in TinyOS. Routing protocols for TinyOS can be divided intotwo categories, based on the number of possible routing destinations.

The communication protocol used in jWebDust is based on the multi-hop tree-based routing protocol included in the TinyOS distribution, called MultiHopRouter,with an extension that aims towards reducing the energy dissipation of the motes. Morespecifically, we implement an extension that uses a mechanism for varying the transmis-sion range [2] on top of MultiHopRouter. The implementation of such a mechanismis based on the ability of TinyOS to adjust the transmission range of the motes, e.g. inthe MICA platform via the Potentiometer component.

The main idea is to periodically check whether a satisfactory number of nearbymotes is active. This done by periodically broadcasting “hello” messages from the con-trol center and flooding the network. If motes maintain network connectivity, this mes-sage will reach all the motes of the network, at a certain time point. By maintaining aflag in each mote, which should be up if any neighbors have sent “hello” messages oversome period of time and down if no such message has been received, motes can decideon whether to modify their transmission range in order to overcome network connec-tivity issues or not. The concept of a varying transmission range protocol (VTRP) anda study of ways of modifying the transmission range are described in [2].

Sensor Query and Data Dissemination Protocol. The queries supported in jWebDustare categorized using two criteria; (i) the motes they are targeted to and (ii) the way in-formation regarding the queries are reported to the control center. The first categoryincludes mote-specific and attribute-based queries, while the second category includesperiodic sensing, event driven and query based queries. These two categories are over-lapping and the actual sensor queries are combinations of these categories. jWebDustgives the users the capability to send to the sensor network all these types of queries.

In the case of a Mote-based query, we are interested in targeting specific motesby using their IDs; the protocol will send one packet per each mote included in thequery. On the other hand, attribute-based queries are not targeted to specific sensorsbut instead to the whole sensor network; the protocol will flood the network with thequery and only those motes that match the specific attribute will respond to the query.

Periodic-update queries pose another time constraint along with the start and stoptime constraints, regarding the time of reporting to the sink. They specify an interval

9

time period between successive query reports. Event-driven queries instead of posingspecific time constraints, use the notion of events in order to define the time to reportback to the sink.

Examples of possible queries to a sensor network include “give me the temper-ature and humidity readings from motes where light reading is over 200 starting from10:15 till 13:30” and “give me the light readings from mote 4 when temperature reaches30

◦C”. Thus, we have four types of possible queries, (i) attribute-based periodic up-date, (ii) attribute-based event-driven, (iii) mote-specific periodic update, and (iv) mote-specific event-driven queries.

The standard packet size in TinyOS is 34 bytes, leaving 29 bytes when using stan-dard single hop communication and less when using multihop protocols. The space leftsuffices to send all types of queries. Timestamps occupy 5 bytes, while mote IDs occupy2 bytes and sensor type IDs 1 byte. Events and attribute constraints can be expressed inthe same way, occupying 4 bytes, 1 byte for the type of sensor ID, 1 byte for the relationused (equal, greater than, etc.) and 2 bytes for the value used in the constraint.

Because of the fact that a query can poll many sensors in the same mote and onepacket might not be sufficient for sending the readings from all the requested sensors,more than one packets can be sent by motes answering a query back to the sink. Thesequential messages will contain the readings that didn’t fit in the previous ones.

Finally, the protocol supports the possibility of “cancelling” a query that is currentlyactive. The user is able to dispatch a special cancel-query message that contains one ormore IDs referring to the queries that are to be cancelled. Note that if the query thatneeds to be cancelled is mote-based, the message is sent directly to the mote involved;if it is an attribute-based the message needs to flood the whole network.

4 Concluding Remarks

We have presented the architecture and the design of the main components of jWeb-Dust, and discussed several distinct features along with their implementation and func-tionality. The main strengths of jWebDust are:

1. Provides an environment to package and manage the plethora of lower level proto-cols with minimum implementation and administration effort.

2. Allows to implement new functionality that can be easily integrated with the rest ofthe architecture at all levels of the hierarchy (i.e. sensor level, control centers level,database level, user-interface level) to best suit the application needs.

3. Supports multiple/separate sensor networks (i.e. physically separated) with multi-ple/separate control centers and allows to handle them as a single virtual sensornetwork, even if more than one sensor share the same ID.

4. Handles sensor networks comprised of devices with heterogeneous characteristics.Real world sensor networks will rarely be homogeneous, motes-only deployments.

5. Supports Disconnected/Mobile Control Centers by taking special care of long dis-connections of the control centers, and the sensor networks attached to these cen-ters, from the upper parts of the architecture (i.e. database, web, etc.), so that infor-mation is not lost.

10

6. Many users can simultaneously query, monitor, and visualize the execution of thewireless sensor network through a Web-based user interface.

7. Offers an Extended Query Language that supports (i) multiple queries per sensordevice, (ii) concurrent queries through out the network, (iii) monitoring of the activenetwork queries, (iv) mechanisms to cancel a query.

We plan to continue the development of jWebDust by improving its features and intro-ducing new ones. We plan to extend the Sensor Query and Data Dissemination Protocolby employing data aggregation techniques that can considerably reduce the commu-nication overhead and improve the lifetime of the network. Also, we wish to considerinvestigate alternate architectures that can allow multiple control centers per sensor net-work; e.g. a JVM-equipped handheld that is carried by the administrator. To this end,we are considering the use of a many-to-many routing scheme within the sensor tier.

References

1. I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, Wireless sensor networks: asurvey, Journal of Computer Networks 38 (2002), 393–422.

2. T. Antoniou, A. Boukerche, I. Chatzigiannakis, G. Mylonas, and S. Nikoletseas, A new en-ergy efficient and fault-tolerant protocol for data propagation in smart dust networks usingvarying transmission range, 37th Annual Simulation Symposium (ANSS 2004), 2004, IEEEPress, pp. 43–52.

3. A. Boukerche, R.W.N. Pazzi, and R.B. Araujo, A supporting protocol to periodic, event-driven and query-based application scenarios for critical conditions surveillance, 1st Inter-national Workshop on Algorithmic Aspects of Wireless Sensor Networks (ALGOSENSORS2004), Springer-Verlag, 2004, Lecture Notes in Computer Science, LNCS 3121, pp. 137–146.

4. I. Chatzigiannakis, T. Dimitriou, S. Nikoletseas, and P. Spirakis, A probabilistic forwardingprotocol for efficient data propagation in sensor networks, 5th European Wireless Confer-ence on Mobile and Wireless Systems beyond 3G (EW 2004), 2004, pp. 344–350.

5. I. Chatzigiannakis, A. Kinalis, and S. Nikoletseas, Power conservation schemes for energyefficient data propagation in heterogeneous wireless sensor networks, 38th Annual Simula-tion Symposium (ANSS 2005), 2005, IEEE Press.

6. I. Chatzigiannakis, S. Nikoletseas, and P. Spirakis, Efficient and robust protocols for localdetection and propagation in smart dust networks, Journal of Mobile Networks and Ap-plications 10 (2005), no. 1, 133–149, Special Issue on Algorithmic Solutions for Wireless,Mobile, Ad Hoc and Sensor Networks.

7. S. Ganeriwal, R. Kumar, and M. Srivastava, Timingsync protocol for sensor networks, 1stACM International Conference On Embedded Networked Sensor Systems (SenSys 2003)(Los Angeles, CA, USA), 2003, pp. 138–146.

8. Exploratory research: Heterogeneous sensor networks, Intel Technology Journal: Research& Development at Intel (2004),http://www.intel.com/research/exploratory/heterogeneous.htm.

9. Mote-VIEW monitoring software, Crossbow Technology Inc.,http://www.xbow.com/Products/productsdetails.aspx?sid=88.

10. Tiny application sensor kit (TASK), Intel Research, Berkeley,http://berkeley.intel-research.net/task/.

11. TinyDB: A declarative database for sensor networks,http://telegraph.cs.berkeley.edu/tinydb/.