Keyword(s): Abstract:

A Rules Based Algorithm for Self-Organizing Virtual Sensors

Malena Mesarina, Devaraj Das, John Recker

HP LaboratoriesHPL-2006-101R1

sensor networks; self-organizing; virtual sensors

Current methods of programming sensor nodes require individual programming of sensors, impeding theirusage in practical industry applications. In this paper, we present a methodology that allows sensors to beprogrammed based on functionality, providing a higher level of abstraction to applications. Our methodenables sensors to self-organize into collaborative clusters via organization rules and behavior scripts. Therules describe required sensor attributes and the behavior scripts are the programs for each sensor type. Therules and scripts are disseminated to the network and a distributed algorithm determines the clusters, aswell as when to spawn and kill behavior scripts. In addition, the system is adaptive to changes in sensorsand location, as well as scalable.

External Posting Date: March 21, 2013 [Fulltext] Approved for External PublicationInternal Posting Date: July 21, 2006 [Fulltext]

Copyright 2013 Hewlett-Packard Development Company, L.P.

A Rules Based Algorithm for Self-Organizing

Virtual Sensors

Malena Mesarina, Devaraj Das, and John Recker

Hewlett Packard Laboratories, Palo Alto, CA 94304, USAmalena.mesarina@hp.com

Abstract. Current methods of programming sensor nodes require in-dividual programming of sensors, impeding their usage in practical in-dustry applications. In this paper, we present a methodology that allowssensors to be programmed based on functionality, providing a higherlevel of abstraction to applications. Our method enables sensors to self-organize into collaborative clusters via organization rules and behaviorscripts. The rules describe required sensor attributes and the behaviorscripts are the programs for each sensor type. The rules and scripts aredisseminated to the network and a distributed algorithm determines theclusters, as well as when to spawn and kill behavior scripts. In addition,the system is adaptive to changes in sensors and location, as well asscalable.

1 Introduction

The commoditization of hardware and recent developments in middleware soft-ware [2] for wireless sensor networks (WSN) have made it possible for thesesystems to find practical use. There are substantial advantages to using wirelesssensor networks over traditional sensors systems. Wireless systems require nomanual wiring installation, enabling ad-hoc and scalable deployment of sensors.In addition, the presence of intelligent nodes enables in-situ processing for fasterlocal reactions. From manufacturing to supply chain, there are several industriesthat can benefit from WSN. In general, these environments have traditionallyused fixed wiring sensing infrastructures with centralized data and commandcontrol. These centralized systems lack flexibility in deployment, real-time dataprocessing, and the fast reactive capabilities of WSN. In addition, a central-ized system makes it difficult to scale in the number of sensors because of lackof bandwidth at the central point of data collection. Wireless sensors networkscould replace these centralized systems. However, unless they are demonstrablyeasier to program and maintain than existing solutions, they will not be widelyused.

Some of the challenges in programming wireless sensor networks arise fromthe need for sensor nodes to adapt their behavior to changes in context. How theyprocess sensor data and interact with each other may depend on the sensor typespresent and their location. For example, in a pallet tracking RFID system forwarehouses, composed of motion sensors and RFID readers, the behavior of the

sensors will vary depending on sensor type and location. In these systems, RFIDreaders and motion sensors are deployed in groups at entry doors to read theRFID tags (via RFID readers) of products passing through the door (detectedby a motion sensor). Depending on whether the motion sensor is present ornot, two behaviors are desirable. The optimal behavior is to activate the RFIDreaders only when the motion sensor detects an object in its line of sight, so as tominimize spurious reads 1. If the motion sensor breaks or is removed, the secondbest behavior is to continuously trigger the read cycles of the RFID readers,minimizing the possibility that a product may be missed. This example showsthat a change in sensors requires a change in behavior. Re-programming thesensors every time there is a change in context, however, is neither practical norfeasible, especially when the number of sensors is large.

In this paper, we propose a distributed algorithm to enable wireless sensornodes to discover each other and adaptively self-configure into sensor clustersto provide a desired functionality. We call these clusters ”virtual” sensors, sincethey represent an abstract functionality of the actual physical sensors. The algo-rithm is based on ”rules” for clustering and ”behavior” scripts. Rules prescribethe properties that nodes should have in order to be part of a cluster, for exam-ple, sensor type and location; and a behavior script is the actual program thata node should run to process data of a particular sensor type and interact withother sensors in the cluster. The rules and behavior scripts are disseminated inthe network, and the algorithm executing on each node finds all the cluster for-mations in the network that match those rules. Periodically, each node checks itssensors and location, and compares them against the rules to determine whetherto spawn or kill behavior scripts, making the system adaptive. In addition, thesystem is scalable since newly discovered nodes are automatically loaded withthe algorithm, rules, and behavior scripts by neighboring nodes.

Our implementation of the algorithm runs as a script in a sensor network mid-dleware software, Sensorware [3], which provides basic communications as well asscript spawning and migration capabilities. We have extended some commandsof Sensorware to add attribute addressing capabilities in order to support thecustomized query and communication commands needed by the algorithm [6].Attribute-addressing is a form of data-centric addressing scheme, where nodesare addressed by their sensing or resource capabilities.

We summarize our contributions as follows: our solution a) simplifies thetask of programming, enabling programming in the large since only one singleinjection of the rules and scripts is sufficient to trigger the formation of “vir-tual sensors”; b) enables adaptive behavior by spawning the appropriate sensorscripts when changes occur; and c) makes the system scalable, since any newnode is automatically programmed by neighboring nodes.

We proved the concept and validity of our algorithm in a hardware prototypesystem of wireless RFID readers and motion sensor nodes. The readers and

1 Collocated RFID readers should interleave their read cycles to avoid read collisions,which return invalid tags. For background on RFID reader technologies and collisionproblem refer to [4] and [1] respectively

motion sensors cluster to form “virtual dock-door” sensors that read RFID tagsof pallets passing through a delivery door in a warehouse.

2 System Overview

Unlike traditional wireless sensor network applications (e.g., military, outdoorenvironmental sensing) in which energy consumption is the main concern, thetype of applications of interest to us, exhibit a different profile. In these appli-cations, sensors that require high-power current sources are predominant (e.g.,RFID readers, motion sensors, cameras) and they are usually deployed in build-ing infrastructures where power outlets are readily available. Therefore, poweris not an issue for these applications. Furthermore, to support the type of op-erations that our algorithm requires (e.g., script mobility, communication prim-itives), we require middleware software that provides these mechanisms. Thistype of mobile agent middleware software requires standard OS services, andthus can only run on full-fledged processor based platforms (e.g., x86, Stron-gArm). For these reasons, our wireless sensor network consists of computingnodes, powered by a fixed current source, with medium computing and storageresources. Sensors are attached to nodes via standard communication interfaces(e.g., rs232, USB) and discovered at boot time by the nodes.

3 Algorithm Overview

The algorithm has two objectives: a) to find a set of nodes whose sensor typesand location match a given description and organize them into a hierarchicalcluster and b) to load and run the appropriate behavior script for a sensor. Forexample, a cluster can be described by three sets of sensor and location attributeswith a fixed sensor type hierarchy, such as “all temperature sensors in isle A,all temperature sensors in isle F and all RFID readers in isle C form cluster X,where the temperature sensors form a level 0 group and the RFID readers forma level 1 group”. The hierarchy, as explained later, is used to set the directionof data flow in the cluster.

The algorithm uses four main components during its execution: cluster rules,behavior scripts, a hop table and a master selection function. The cluster rulesdescribe sets of sensor and location attributes for cluster formation and the hi-erarchy of the sensors in the cluster. A behavior script defines the processingand post-processing interaction of a sensor with other cluster members and isdefined for each sensor type in the cluster. The hop table is a data structure, lo-cally maintained by all nodes, in which each sensor in the network has an entrycontaining attributes of the sensor (e.g., sensor type) and host node information(e.g., node id, location). The master selection function selects a master out ofa group of sensors of the same type and location. We divide a cluster into suchgroups of sensors to impose order; a master sensor acts as the coordinator anddata aggregator, with communications between sensor groups restricted to mas-ter nodes. The interaction between masters is restricted by a fixed order given

by the ancestor rules. The master selection criteria is application dependent, sowe include it as a function in the behavior scripts. When the algorithm needs toselect a master it makes a call to the master selection function of the appropriatesensor behavior script. The clustering process is executed periodically and con-sists of comparing the rules with the local hop table. If there is a match, sensorsgroup form a hierarchical cluster and spawn the appropriate behavior scripts.

3.1 Cluster Rules

There are two types of rules, sensor rules and ancestor rules. The sensor rulesdescribe the sensor types and location attributes required for cluster member-ship, and the ancestor rules fix a hierarchy between sensor types. Nodes comparetheir attributes with the membership properties to determine if they are partof the cluster. Furthermore, nodes that have the same sensor type and locationform a group and select a master. The hierarchy established by the ancestorrules fixes the path of data exchange between sensor groups in the cluster. Itspecifies the sensor type from which data should be received and the sensor typeto which data is to be sent. Because there could be more than one sensor ofthe same type in a cluster, the master selection for each sensor type is executedbefore the ancestor rules are applied to avoid many-to-many messages.

Table 1. Rules Description

Rule type Format

Sensor Rule <sensor type> <location> <cluster id>

Ancestor Rule <sensor type> <prev sensortype> <next sensortype> <cluster id>

Table 1 shows the format for the sensor and ancestor rules. A sensor rulehas three elements: sensortype, location and cluster id. The algorithm usesthe cluster id to differentiate between clusters. An example of a sensor rule is<RFID> <door A> <4>, which means that all RFID readers in the “doorA” location are part of cluster number “4”. An ancestor rule has four elements:sensortype, prev sensortype, next sensortype and cluster id. The prev sensortype

and next sensortype, describe the sensor type that a master node is allowed toreceive data from and send data to, respectively. An example of an ancestor ruleis <RFID> <motion sensor> <camera> <4>, which means that “an RFIDreader that is part of cluster number 4 can only receive messages from a motionsensor and can only send messages to a camera”. The combined application ofthe sensor and ancestor rules completely defines the organization of a cluster.

The rules are sent to all nodes for them to store, operation that triggers theclustering process. In our implementation using Sensorware, the rules are sentdirectly to the clustering algorithm running on a node. We use our attribute-addressing enabled version of the send command to target only nodes that areexecuting the algorithm by specifying the name of the algorithm script. Detailsof the implementation are described in section 5.1.

3.2 Hop table

This table is created and maintained by each node and is used to compute theclusters in the network. Each entry in the table, as shown in table 2, contains ahop count (to reach the source node of the entry), the id of the source node, thesensor type, the node location, and a list of the neighboring nodes in the shortestpath to the source node ( list of shortest path nodes). There could be multipleshortest paths to the source;this list keeps the node ids of the neighbors in thosepaths. Note that there is only one entry per sensor type per node, therefore,we assume that there can only be one of each kind of sensor in a node. Thissimplifies the type of information we need to keep, but if more than one sensorof the same type per node is needed, a new attribute can be added to the tableto differentiate the sensors (e.g., sensor serial number).

Table 2. Hop table format

<hop> <node id> <sensor type> <location> <list of shortest path nodes>

3.3 Cluster Organization

The output of the algorithm is the cluster formation, which is an organized sys-tem of sensors, divided into groups of nodes that share the same sensor type andlocation. Each group also has a selected master. The cluster information is storedas shown in table 3. The <cluster id> identifies the cluster, <sensor type> spec-ifies the sensor type for this group, <location> specifies the shared location ofthis group of sensors, <master> contains the node id of the master node, and<members> lists all the nodes in the group. All sensor groups with the samecluster id are part of the same hierarchical cluster, whose hierarchy is specifiedby an ancestor rule identified by the same cluster id.

Table 3. Cluster table format

<cluster id> <sensor type> <location> <master> <members>

3.4 Behavior Scripts

These are the programs that define the data processing and collaboration be-tween the sensors in a cluster. Since these operations may be designed differentlyfor a sensor depending on its role as a master or slave of its sensor group, the be-havior scripts need to retrieve this information from the clustering algorithm. Inaddition, information about the next ancestor in the hierarchy of sensor types isrequired for a master node to identify the next recipient master of its results. Weprovided three APIs to the clustering algorithm for a behavior script to retrievethis information. Table 4 gives a description of each.

Table 4. APIs to the algorithm

API Description

query master <cluster id> <sensor type> <loc>

To request the id of the node that is the masterfor sensors of <sensor type> in location<loc> of <cluster id>

query members <cluster id> <sensor type> <loc>

To request the id of the membersof a group of sensors of type <sensor type>in location <loc> of <cluster id>

query ancestor <cluster id> <sensor type> <loc>To request the id of the next ancestor

for sensor type in <loc> of <cluster id>

As in the case of the cluster rules, the behavior scripts are sent to all thenodes using our attribute-addressing enabled send command to target the clus-tering algorithm as the recipient program. As mentioned earlier, there is onebehavior script per sensor type for a cluster and this assignment is also sentalong with each script as shown in table 5. A node stores this information andbehavior scripts to be utilized during the script spawning/killing operations ofthe clustering process.

Table 5. Behavior script information table

<sensor type> <script Name> <cluster id>

4 Algorithm

The algorithm is distributed and the objective is to have all the nodes share aglobal and consistent view of every node’s sensing resources and locations, so thatthey can individually find the groups of nodes that share those attributes withthem, whose attributes also match a sensor rule. If a node’s attributes matchthose of a rule, then the appropriate behavior scripts for the node’s sensor typesare spawned. As mentioned earlier, the hop table is the data structure that carriesthe information about every node in the network. We chose the same mechanismas in the Distributed Bellman Ford algorithm to propagate the table [8]; everynode sends information (hop table) about all the nodes in the network to all itsneighbors and the information is propagated from node to node, until all nodesare updated. Although DBF suffers from table oscillation problems, for semi-static systems like ours, where sensors are not mobile and fail irregularly, DBFprovides a simple method for table propagation. It works well, once oscillationproblems are dealt with, which we explained in section 4.2.

Before describing the algorithm, we state and justify our assumptions: 1)every broadcast of the hop table eventually reaches all neighbors of a node, and2) every node only hosts one of each type of sensor. We made the first assumptionto minimize the number of broadcasts a node sends; changing it to a periodicbroadcast is trivial and does not change the algorithm. The second assumption,

as explained in section 3.2 simplifies the table organization. Adding a new at-tribute to distinguish sensors of the same type does not change the algorithm,because the process of matching a rule’s attributes to a node’s attributes isindependent of the type and number of attributes.

The algorithm is divided into two tasks, a periodic task and an aperiodictask. The periodic task is responsible for updating local context changes in thehop table and acting on them, while the aperiodic task is responsible for mergingthe tables. The periodic task consists of four operations: a) checking changes inlocal sensors and in node’s location, b) checking changes in the hop table tobroadcast the update, c) checking the addition or removal of neighboring nodesand d) forming the clusters. The aperiodic task consists of two operations thatare performed when a packet with a neighbor’s hop table is received: a) adding ordeleting entries to merge a neighbor’s table with the local table and b) updatingthe hop count and the list of shortest path nodes. The pseudo-code for thealgorithm can be found in the Appendix section, we refer to line numbers in thiscode throughout the coming section.

4.1 Periodic Operations

The first periodic operation checks for changes in local sensors or node’s location.If a new sensor is discovered, the sensor information is added to the hop tableand a search for a rule that matches the sensor type and node’s location isperformed. If a match is found, the appropriate behavior script for the sensortype is spawned (lines 4-7). If a sensor has been removed, the correspondingbehavior script is killed and the sensor removed from the hop table (lines 8-11).If a new node location is sensed, then all behavior scripts that may be runningare killed, and for each sensor type, a rule that matches the sensor type and newnode location is searched. If a match is found, then, the appropriate behaviorscript is spawned (lines 14-20). Figure 1 shows the state of the hop table ateach node right after boot time, when then nodes have just discovered their ownsensors and location.

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

� �

��������

�

��������

�

���������

�

����������

�

����������

��

�

����� ��� �

�����!��� �

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

� � �

��

�

��������� �

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

� ! �

��

�

!

����������

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

� � �

��

�

��������� �

��

��

��

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

� � �

��

�

��

��������� �

���� ������

� � �

��

�

��

��������� �

���

�

Fig. 1. Hop tables at initialization

The second periodic operation consists of broadcasting the hop table everytime the table has been updated, so that all nodes in the network can merge thenew updates with their tables (lines 23-25).

The third periodic operation checks for new or removed nodes in order toupdate the hop table. If a node detects a new neighboring node, it initializesthe new node by spawning the clustering algorithm and sending it all the rulesand behavior scripts stored in its memory, thus enabling the new node to joina cluster (lines 28-29). If a node detects that a neighboring node disappeared,it deletes all the entries in the hop table that correspond to that node, as wellas all references to that node in the list of shortest path nodes lists of all theremaining entries (lines 30-33).

The fourth periodic operation is the clustering process, which consists of anode matching the sensor rules with the hop table information in order to formthe clusters. For each sensor rule, a node searches the hop table and finds thenodes that have the sensor types and location that match the rule, groups themby sensor type and location, and calls the master selection function (section 3)to compute the master node (lines 36-40). Information about the sensor groupformed is stored in the cluster table. For example, in the scenario of figure 1, ifwe had two rules: rule 1 as <RFID> <door A> <4> and rule 2 as <camera>

<door A> <4>, assuming that the master selection function selects the node idwith the smallest number, then the cluster output would be as shown in table6.Table 6. Cluster table for network example after applying two rules: <RFID> <doorA> <4> and <camera> <door A> <4>

<cluster id> <sensor type> <location> <master> <members>

4 R A 1 1,24 C A 4 4,5,6

4.2 Aperiodic Operations

The two aperiodic operations take place when a packet with a neighbor’s hop tableis received. The first aperiodic operation consists of comparing the neighbor’stable with the node’s table and determining whether to add or to delete entriesin the local table. Because tables propagate from node to node, intermediatenodes may get inconsistent tables from neighbors at different times: one neigh-bor’s table may show entries for new sensors, while another neighbor’s table maynot show those entries yet. Thus a node needs to have a way to distinguish be-tween new and stale information in order to avoid oscillations between new andold data. Variants of DBF have dealt with oscillation problems in the context ofrouting tables. Some try to solve it by keeping track of the nodes that relayedthe information about a source node so that later, if the same node needs tofind an alternative path (because the old path does not work), a neighboringnode does not return information derived from the old path. In our case, weapply a similar criteria: information coming from neighboring nodes that are ina shortest path to the source node is considered more reliable then informationfrom other neighboring nodes in longer paths. Neighboring nodes in the shortestpaths to the source node are trusted more because they are more likely to get

the latest updates about the source node. By prioritizing the flow of informationto travel along the nodes in the shortest paths, the flow of stale data is containedand oscillations eventually die down.

This criteria translates into two tests before a node is added or deleted from anode’s hop table. Before adding a new sensor entry that appears in the neighbor’stable, a node checks whether its own id is in the list of shortest path nodes ofthe entry in the the neighbor’s table. If it is, then the node does not add thenew entry because the node itself was in the shortest path, therefore, it is morelikely that the entry was recently deleted from its table, and that the neighborhas not been updated yet ( which will occur through the node itself, lines 45-49).If the node is not in the neighbor’s list of shortest path nodes, the node addsthe entry to its table, since it does not have information that contradicts itsneighbor.

Before deleting a sensor entry because it does not appear in the neighbor’s ta-ble, the node checks whether the neighbor’s id is in the list of shortest path nodes

of the entry in its table. If it is, then it trusts the neighbor’s information be-cause the neighbor is in the shortest path and it deletes the entry. Otherwise, itkeeps the old entry (lines 52-56). Figure 2 shows the state of the tables after atable exchange between node 1 and 2, node 1 and 6, and node 4 and 5. Here allthe nodes receive brand new information from neighbors, therefore there aren’tany shortest path lists to check yet. Figure 3 shows the tables after a secondexchange between nodes 2 and 3, 6 and 3, and 3 and 4. Here node 3 receivesinconsistent tables from node 2 (or 6) and 4, and must decide whether to addor delete entries based on the criteria given above for merging tables.

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

� �

��������

�

��������

�

���������

�

����������

�

����������

��

�

����� ��� �

�����!��� �

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

� � �

��

�

��������� �

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

� ! �

��

�

!

����������

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

� � �

��

�

��������� �

��

��

��

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

� � �

��

�

��

��������� �

���� ������

� � �

��

�

��

��������� �

���

�

!

�

�

�

�

�!

� �

� �

� � � �

� � � �

�

Fig. 2. First table exchange between nodes 1 & 2, 1 & 6, and 4 & 5

The second aperiodic operation consists of updating the hop count and thelist of shortest path nodes. When a node receives a hop table from a neighbor,it performs the following operations for each entry on the table: it increments byone the hop count in the neighbor’s table and compares it with its own hop count

of the equivalent entry. If the incremented hop count is smaller then the node’scurrent hop count, the smaller hop count replaces the current hop count, and thelist of shortest path nodes is replaced with the neighbor’s node id. But if theincremented hop count is the same as the node’s hop count, the neighbor’s nodeid is appended to the list of shortest path nodes in the table (lines 57-64).

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

� �

��������

�

��������

�

���������

�

����������

�����������

��

�

����� ��� �

�����!��� �

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

� � �

��

�

��������� �

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

� ! �

��

�

!

����������

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

� � �

��

�

��������� �

��

��

��

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

� � �

��

�

��

��������� �

���� ������

� � �

��

�

��

��������� �

���

�

!

�

�

�

�

�!

� �

� �

� � � �

� � � �

��

� � � �! � � !� � � � � � ��"!� � � �

� � � �

� � � �

� � � �

�������#��$��

�����#��$�

�

Fig. 3. Second table exchange between nodes 2 & 3, 6 & 3, and 4 & 3. Also showingRFID and camera sensor groups for cluster result in table 6

5 Implementation

We implemented the algorithm as a TCL application script in Sensorware, amiddleware that supports event-based script programming and script mobility.We chose Sensorware because it provides functionality that we require: an event-centric and expandable programming language (Tcl), script spawning capabil-ity, and a modular architecture that was easy to extend. Availability of publicsource code was another decisive factor over other alternatives such as [5]. Ouralgorithm uses information about a node’s resources (e.g. scripts running) andnode’s sensing (e.g., sensor types, location) attributes for two purposes: 1) todisseminate the cluster rules and behavior scripts to nodes executing the clus-tering algorithm and 2) to build the hop tables. The former requires a form ofattribute-addressing [6] to address nodes by resource capability (script name)and the latter requires a mechanism to set and query attributes. Since Sensor-ware does not support these mechanisms, we extended Sensorware to include adevice that supports them.

5.1 Extensions to Sensorware

A device in Sensorware is a software abstraction of a sensor module or service. Alldevices present a fixed interface, that is, only specific commands can be used tointerface with a device. For example, a routing protocol could be implementedas a device that supports the send command to route a message. We imple-mented an “attribute” device that supports the commands for setting/queryingattributes and for sending (receiving) to nodes targeted by attributes. The com-mands are act, query and send.

We classified attributes into two classes, a script attribute and a systemattribute. A script attribute describes script characteristics, for example, itsname. A system attribute describes node resources, for example, sensor types.

Attributes are specified using the following syntax: [attr name=[val,]*!]*, whichdescribes attribute-value pairs. The ’,’ separates multiple values of the sameattribute, ’ !’ separates multiple attributes and ’*’ means one or more of theelements in brackets ([ ]).

The act and the query commands can set and query both classes of at-tributes. Naturally, before attributes can be used, they have to be initialized(with the act command). System attributes are initialized by device drivers inSensorware when new attached sensors are detected (e.g. act attribute -as sen-sortype=RFID), while the script attributes are initialized by a script itself (e.g.act attribute -a scriptname=rfid script).

The send command in the “attribute” device creates the packet headerwith the given attributes as destination addresses, and floods the packet to thenetwork. When a node receives a message, it compares its system attributes withthe message’s; if there is a match, it dispatches the message to the scripts withthe matching script attribute (e.g. script name). Table 7 provides a descriptionof these commands.

Table 7. Commands supported by “attribute” device

New commands Description

send attribute sensorType=RFID This sends a message with <data> to!location=north all nodes that have an RFID reader,!scripttype=dock door <data> and are in the “north” location.

If the node is running a script with name“dock door”, the message is directedto this script.

act attribute -as <attr name> =<attr value> This adds a system attribute with aname and value, i.e. sensortype=RFID

act attribute -a <attr name> = <attr value> This adds a script attribute with aname and value. A script would use thiscommand to set its name as an attribute,i.e. scriptName=RFID script

query attribute -s This will return the list of systemattributes of the node

query attribute -s <attribute-name> This will return the value of theattribute in <attribute-name>

5.2 Sensor Initialization

Sensor Initialization can be divided into two parts: ”hard” and ”soft” initial-ization. Hard initialization is the initialization of the hardware resources on thesensor node - typically the sensor instrumentation. For this implementation,these sensors are either analog sensors such as temperature, light or IR mo-tion detectors, which are accessed indirectly over a serial port connection to aPIC processor, or RFID readers. Device drivers are then linked into Sensorware,

which are responsible for sensor discovery, registration with the Sensorware core,and attribute registration with the attribute device.

”Soft” initialization, on the other hand, refers to initialization of logical at-tributes with the attribute device. Principal among these, for our application,are the sensor location. Although considerable work has been devoted to indoorlocation systems [9] [10], we believe that there are still too many issues with thesesystems to quickly and reliably deploy an indoor location system within a typicalwarehouse environment. As a result, we chose to use a symbolic location system.Each sensor node in our system is equipped with a short range RFID reader(∼ 12 cm). During deployment, a RFID tag representing a symbolic location inthe environment is passed near the RFID reader of each sensor to be grouped.For example, a user might choose to pass RFID tag ”A” past the sensors onwarehouse dock-door ”A”, and RFID tag ”B” past the sensors on dock-door”B”. The Sensorware attribute device can then be used to target messages toindividual dock-doors by specifying ”LocationTag = A,B” in the device address.This attribute is used extensively by both the hop table management and thesensor behavior scripts.

5.3 Warehouse Application

We tested our algorithm in a hardware prototype that we use to demonstratehow to automate the programming of RFID pallet tracking systems for ware-houses. Current systems use a motion sensor and one or more RFID readers ateach door to detect and read RFID tags from pallets passing through the door.These systems are replacing bar code methods to speed inventory tracking inthe supply chain. Currently, deploying these systems is labor intensive and timeconsuming, making deployment costly. The RFID readers and motion sensorsare typically connected to a wired LAN network, which requires manual wiringand network setup, and a middleware software that controls the sensors is pro-grammed by a trained technician. We propose to simplify the deployment processby replacing these systems with a wireless network of motion and RFID readernodes and applying our methodology to automate the process of configurationand programming. This process would involve sending the rules describing thesensor types (e.g. motion sensor and RFID readers) and location of the doorswhere these sensors should form a “dock-door” cluster and the behavior scriptsfor each sensor type. These scripts execute the appropriate operations to detectand read the pallet tags.

Our prototype consists of four RFID readers and two motion sensors whichare programmed as two sets of RFID door systems, with two RFID readersand one motion sensor in each set. Each of the sensor nodes consists of anIntrinsyc Cerfcube 255 Xscale platform [7] with an external PIC controller boardto interface with arbitrary sensors, a wireless 802.11 radio and a short distanceRFID reader. The RFID readers used in these application are required to coverlarge areas, so we use long range readers (∼ 5m), whose frequency band (∼ 915Mhz) do not interfere with the short distance RFID readers (∼ 128 Khz). Twobehavior scripts were written, one for the motion sensor and one for the RFID

reader. These scripts were written in TCL which is the scripting language forSensorware applications.

The location of the nodes is initialized as follows. An RFID tag is wavedin front of the short distance RFID reader of each node to assign the symboliclocation. After the location is assigned, the system is ready to be programmed.We send two sets of sensor rules, one set to form an RFID “door” system atlocation “A” and another at location “B”. The set of sensor rules for location“A” is : [RFID A 1 (RFID sensor rule) and motion A 1 (motion sensor rule)],and for location “B”: [RFID B 2 (RFID sensor rule) and motion B 2] (motionsensor rule). In this case we give different cluster id numbers (1 & 2) to each set, because we only want sensors that are on the same door to be part of the samecluster.

Finally the behavior scripts are sent to all nodes. The RFID script can besummarized as follows: it periodically checks its status as a master or slave byrequesting this information from the clustering algorithm. The script uses thequery master and query members APIs to get this information. If it is a master,it also obtains the list of slaves in its sensor group, as well as information on othersensor types (e.g. motion sensor) in the cluster. If the motion sensor is present,the master reader waits for the motion sensor to notify it of the presence ofa pallet. Otherwise, the RFID reader schedules the read times of each slaveand sends each one a message commanding them to read one at a time, ina continuous cycle. The motion sensor script is simpler since the applicationassumes there is only one motion sensor per door. The motion sensor waits for apallet to be detected and then notifies the master RFID reader of the presenceof the pallet. The motion sensor obtains the node id of the master RFID readerby querying the algorithm using the query ancestor API.

6 Related Work

One of the principal requirements of wireless sensor networks is that they be ableto operate without central control. Applications require that they self-organizetheir communications, network and tasks. Several distributed algorithmic so-lutions have been developed in these areas. We summarize here some of themore relevant work. On the communications side, protocols to regulate access tothe wireless channel are proposed [11]. They use a TDMA scheme to let nodesdiscover each other and negotiate a schedule for communicating at a selectedfrequency. On the networking side, distributed clustering algorithms to supportreliable network structures [12] [13] and efficient bandwidth allocation [14] havebeen studied. In [12], a TDMA scheme divided in to two time frames is used toexchange information between neighboring nodes to form a connectivity matrixand form one-hop size clusters. In [13], a clusterhead selection algorithm basedon weights is used to form non-overlapping one-hop size clusters. In [15], k-hopsize clusters are formed to improve the efficiency of route discovery of DSR[16].In [14] a distributed clustering algorithm produces two-hop size clusters with dif-ferent assigned codes to optimize the re-usability of codes between neighboring

clusters. This facilitates the bandwidth allocation to support multimedia pack-ets. On the tasking side, distributed algorithms to cluster sensors into groupsbased on sensing quality metrics [17] [18] have been developed. In [17] they in-troduce a quality metric, cummulative sensing degree (CSD), that represents thedegree of coverage that a sensor obtains by virtue of being connected to othernodes whose sensing fields overlap with its own. The sensors with highest CSDare selected as backbone nodes, and the rest form sensing sectors. In [18] they in-troduce a “social” utility metric that reflects the advantage agents nodes wouldgain if they collaborate with each other. Agents exchange information abouttheir services and form coalitions with neighboring agents that will maximizethe “social” utility metric. In [19] sensors organize themselves for the purposeof maximizing the quality of tracking multiple targets. They form clusters basedon the same types of targets they can detect and degree of overlapping sensingfields. In [20], hierarchical clusters of sensors are formed where each level in thehierarchy corresponds to a different sensor attribute. The idea is to respond toqueries more efficiently by flooding queries only inside clusters that contain thequery attributes.

Most of the solutions applied in these works are different than ours sincethe clustering algorithms use very different criteria for sensor selection. In thenetworking clustering algorithms, network connectivity is the main criteria forsensor selection, whereas in the tasking algorithms, the main criteria is qualityof sensing. In our case, the criteria for cluster formation is based on patternmatching between the sensors properties (sensor type, location) and the sensorrules. In this regard, the work that is closest to ours is [20], where they groupsensors at each level of the hierarchy based on one single attribute. In our case,we decouple the grouping of sensors from the hierarchy description. We groupsensors based on pattern matching of a combination of attributes (sensor rules)and we use the hierarchy description (ancestor rules) to fix the data flow betweenmaster nodes of each sensor group.

7 Conclusions

We presented a methodology for programming clusters of collaborative sensorsbased on attributes. The solution consists of rules, prescribing the attributes andhierarchical organization of a cluster, behavior scripts for each sensor task anda distributed algorithm that matches the rules attributes with nodes’ attributesand spawns the appropriate behavior scripts. Clusters adapt to changes in sen-sors, location and neighboring nodes. This programming technique can be usedfor applications that require programming of repetitive patterns of sensors, suchas in the case of RFID pallet tracking sensor systems in warehouses. We builta prototype to demonstrate the automatic programming of these systems withour solution. In general, our solution can be viewed as a method of abstractingfunctionality of a collaborative group of sensors by creating these clusters thatrepresent “virtual” sensors, like the pallet tracking “dock-door” for example. Webelieve that such level of abstraction is needed to hide the low-level details of sen-

sor types and connectivity from applications, and provide functional informationfor higher level programming.

References

1. D.W. Engels. The Reader Collision Problem. Technical Report MIT-AUTOID-WH007, 2001.

2. K. Romer. Programming paradigms and middleware for sensor networks. GI/ITGFachgesprach Sensornetze, Karlsruhe, Feb 2004.

3. A. Boulis, C.C. Han, and M.B. Srivastava. Design and Implementation of a Frame-work for Programmable and Efficient Sensor Networks. MobiSys 2003, San Fran-cisco, CA, May 5-8, 2003.

4. R. Want. The Magic of RFID. ACM Queue vol. 2, no. 7. October, 2004

5. C. Jaikaeo, C. Srisathapornphat and C. Shen. Querying and Tasking in Sensor Net-works. SPIE’s 14th Annual International Symposium on Aerospace/Defense Sens-ing, Simulation, and Control, April 2000.

6. C. Intanagonwiwat, R. Govindan and D. Estrin. Directed Diffusion: A Scalable andRobust Communication Paradigm for Sensor Networks. MobiCOM 2000, pp 56-67.

7. http://www.intrinsyc.com/products/mob ref sys/cerfcube 255

8. D.P. Bertsekas and R. G. Gallager. Data Networks, Prentice Hall, chapter 5.2.4,pages 325-333, 1987.

9. P. Bahl and V. Padmanabhan. RADAR: An In-Building RF-Based User Locationand Tracking System. Proc. of IEEE INFOCOM, pp. 775-784, (2000)

10. N. Priyantha, A. Chakraborty, and H. Balakrishnan. The Cricket Location SupportSystem. Proc. ACM Intl Conf. Mobile Computing and Networking (MobiCom), pp.32-43, Aug. 2000.

11. K. Sohrabi, J. Gao, V. Ailawadhi, and G. J. Pottie. Protocols for Self-Organizationof a Wireless Sensor Network. IEEE Personal Communication, Oct. 2000.

12. D.J. Baker and A. Ephremides. The architectural organization of a mobile radionetwork via a distributed algorithm. IEEE Trans. Commun., pp. 1694-1701, nov.1981

13. S. Basagni. Distributed Clustering for Ad Hoc Networks. Proceedings of the 1999International Symposium on Parallel Architectures, Algorithms, and Networks (I-SPAN’99),IEEE Computer Society, pp.310-315, Australia,June 23-25,1999.

14. C. R. Lin and M. Gerla. Adaptive Clustering for Mobile Wireless Networks. IEEEJournal on Selected Areas in Communications, vol., 15, no. 7, Sep. 1997.

15. D. K. Kim, S. J. Ha and Y.H. Choi. K-hop Cluster-based Dynamic Source Routingin Wireless Ad-Hoc Packet Radio Network. IEEE VTC, 1998.

16. D. B. Johnson, D. A. Maltz, and J. Broch. DSR The Dynamic Source RoutingProtocol for Multihop Wireless Ad Hoc Networks. In Ad Hoc Networking, editedby Charles E. Perkins, chapter 5, pages 139–172. Addison-Wesley, 2001.

17. M. Kochhal, L. Schwiebert and S. Gupta. Proceedings of the 2nd ACM Interna-tional Conference on Wireless Sensor Networks and Applications, pp. 98-107, SanDiego, CA , 2003.

18. M. Sims, C. V. Goldman and V. Lesser. Self-Organization through Bottom-upCoalition Formation. Proceedings of the Second International Joint Conference onAutonomous Agents and Multiagent Systems, pp. 867–874, Melbourne, Australia,2003.

19. R. A. Burne, A. L. Buczak, V.R. Jamalabad, I. Kadar and E. R. Eadan. A Self-Organizing, Cooperative Sensor Network for Remote Surveillance. SPIE Conferenceon Sensors, Boston, MA, Nov. 1998.

20. W. Ke, P. Basu, S. Abu Ayyash and T.D.C. Little, ”Attribute Based HierarchicalClustering in Wireless Sensor Networks,” MCL Technical Report TR-03-24-2003,March 2003

APPENDIX

Require: rules and behaviors scripts stored in nodes

1: PERIODICALLY:

2:

3: //Check changes in local sensors

4: for each new sensor attached do

5: add sensor to hop table6: spawn behavior script if sensor type and node’s location match a rule7: end for

8: for each removed sensor do

9: kill behavior script of sensor10: delete sensor from hop table11: end for

12:13: // Check changes in location14: if node’s location changed then

15: kill all behavior scripts16: for each sensor do

17: update location18: spawn behavior script if sensor type and node’s location match a rule19: end for

20: end if

21:22: //Check change in hop table23: if hop table changed then

24: Broadcast it to neighbors25: end if

26:27: //Check changes in neighbors28: if new neighbor then

29: send rules, behavior scripts and hop table30: else if neighbor disappeared then

31: delete neighbor from hop table32: delete references to neighbor from all list of shortest path nodes lists33: end if

34:35: //Find clusters36: for each rule in rules table do

37: group all sensors whose sensor type and node location match rule38: call master selection function39: store cluster information (master, members, location and cluster id)40: end for

41: ON RECEIVING a neighbor’s hop table:42:43: // Compare neighbor’s table with local node’s hop table44: // Before adding a new entry45: for each entry in neighbor’s hop table do

46: if local node is NOT in entry.list of shortest path nodes then

47: add entry to local node’s hop table48: end if

49: end for

50:51: // Before deleting an entry52: for each entry that is not in neighbor’s hop table do

53: if neighbor is in local node’s entry.list of shortest path nodes then

54: delete entry from local node’s hop table55: end if

56: end for

57:58: //Update hop count and list of shortest path nodes59: for each shared entry in both neighbor’s and local node’s hop table do

60: incr neighbor.entry.hop by 161: if neighbor.entry.hop < node.entry.hop then

62: replace node.entry.list of shortest path nodes with neighbor node id63: else if neighbor.entry.hop == node.entry.hop then

64: append neighbor node id to node.entry.list of shortest path nodes65: end if

66: end for