Support document for sensor networks prototype from dissertation work of Bhanu Pisupati

The objective of this exercise is to use filesystem abstractions to enable implementation of data and event based applications in the sensor domain, as also programming sensors nodes using common file operations. The sensor network model universally used in this work is cluster based, meaning that the entire sensor network is divided into one or more clusters of sensors that are in close proximity (within radio communication range) to one another. Typically in such a model, each cluster is managed by a cluster head node, which has superior computational and networking resources as compared to lightweight sensor nodes constituting the cluster. A cluster head class device from Crossbow known as Stargate, is based on a 400 MHz Intel XScale processor that has 64MB of RAM at its disposal. Individual sensor nodes - such as motes - have more limited computational, memory and communication resources available on board.

While my dissertation presents the high level motivation for this work, this writeup is meant to serve as a guide to setup and operate the associated prototypes. Due to constraints on available software, for the purposes of this prototype, a cluster is defined by a workstation with a set of sensor nodes in close proximity. The workstation fulfills the role of a cluster head, by executing appropriate software. It communicated with the various sensor nodes within its cluster through a 'base station node' connected to it through USB. The layout is illustrated in the figure below. As shown, a network may consist of multiple clusters, which are accessed and programmed remotely.

The system consists of software executing at three levels - within the sensor nodes, at the cluster head level and at the workstation level. The sensor nodes execute software implementing a sensor filesystem (SFS). The cluster head (a workstation in our case) utilizes the SFS exported from various sensor nodes to implement a cluster filesystem. The various cluster filesystems are mounted locally at the workstation level, which allows sensor network applications to interact with the sensor nodes through conventional file operations.

Data and Event Based Applications

The first application demonstrates use of file abstractions to access sensor data and configure network events from applications common file operations. Specifically, the application shall demonstrate use of the filesystem to:

read values off sensors
issue commands to sensors
configure events at the sensor/cluster levels
enable network level applications to learn about these events as and when they occur

Step 1: setting up sensor nodes

The first step in setting up the prototype is to program one or more sensor nodes and to get them running. The steps for achieving this are outlined below:

download the package containing the sensor software (how?)
extract the package if necessary - this renders a sensorfs directory
build the sensor software, by executing make [target name] - target name can be one of pc, tmote, telosb etc. Note that this assumes that TinyOS is already installed in the system.
download the software on a mote;
To program a sensor node, attach it to a USB port on the workstation, and note the assigned virtual com ports (through the motelist command). cd to the sensorfs target build directory (eg: build/tmote) wherein the hex file was created by the build operation. Then program each mote one after the other by issuing the make reinstall program as follows:
```
make reinstall,< com port> bsl,< network num>
```
Here 'com port' refers to the number of the assigned virtual COM port at which the sensor node is connected in Unix format, with COM1 represented by '0', and moving upwards from there. For instance, using this representation, COM2 would be refered to by the number '1'. Network num refers to the integer number identifying the network address of a sensor node. This should start from 1 and increase incrementally. To program a sensor node that is connected at COM2 with the sensorfs binary, while assigning it a network address of 3, the following command is issued:
```
make reinstall,1 bsl,3
```
The sensor filesystem application is setup so that sensors nodes with odd network numbers boot up as temperature sensors, while sensor nodes with even network numbers boot up as photo sensors.
Workstations communicate with sensor nodes using base stations; these are sensor nodes that are connected to the workstations directly. The steps for setting up the base station are outlined below:
- Locate the ToSBase application within the support software, and make and build and program it on a sensor node it using the procedure outlined for sensorfs.
- Connect the base station to the workstation through an available USB port
- set the MOTECOM environment variable to serial@COMn:tmote, where COMn refers to the virtual serial port assigned to the base station; this information can be retrieved through the motelist command described earlier.
  Step 2: setting up the cluster filesystem
  The second step in setting up the prototype involves running the cluster head software. As described earlier, the role of the cluster head is fulfilled by a workstation in close proximity to the sensor nodes, which communicates to them through a base station. The cluster head executes a 9P based synthetic filesystem using a Java based application named JStyx.
  The procedure for setting up and executing this filesystem are listed below:
  - download the JStyx archive (from where?) and extract it
  - download the 'jclasses' package that contains class definitions (NIMA among others) necessary for JStyx
  - download the TinyOS java class files, which provide the cluster filesystem with the ability to communicate with motes through a base station
  - modify the 'path_script' so as to set the CLASSPATH variable appropriately, so that the Java classes may be loaded
  The cluster filesystem may be started from the command line by executing the following command:
```
java uk.ac.rdg.resc.jstyx.server.ClusterFS [number of sensor nodes]
```
  The number of sensor nodes specified should equal the number of sensor nodes programmed and started up in Step 1. The port number on which the filsystem is exported is 9876
  Upon starting up, the cluster filesystem 'discovers' the various sensor nodes present within the cluster and appropriately generates a filesystem. During discovery, the cluster filesystem reads the discovery resource of sensor nodes at increasing network numbers to identify the resources on board each of them. Lookup Section 4.5 in the thesis for more information on the discovery process. Based on the information gathered during the discovery process, the cluster filesystem generates a namespace of the sort shown in below:
  
  Multiple such 'clusters' may be setup based on the availability of motes, each exporting its own cluster filesystem. aes
  Step 3: Running workstation software
  Once the cluster filesystems are up and running, they may be mounted on a remote workstation and used to interact with the network. The cluster filesystems are exported using the 9P protocol (NOTE: this is different from the 9p2000 protocol, which is a more sophisticated protocol in the same family). A straightforward means to access remote 9P filesystems is through the Inferno operating system (version 3) to mount 9P filesystems. Inferno may be downloaded here. It runs in 'hosted' mode under various common operating systems such as Linux and Solaris. Instructions to install the operating system are available within the downloaded package.
  An alternative approach is to mount the 9P filesystems locally within Linux using Fuse based approaches as described in the embedded debugging writeup
  Once Inferno is installed, start it up the emulator as follows:
```
emu -r[path to the root of inferno installation]
```
  Mount each of the cluster filesystems locally
```
mount -A tcp![ip address of 9P fs]![port number] [path to where the filesystem should be mounted]
eg: mount -A tcp!129.79.246.181!9876 /tmp/sensornet/cluster0
```
  Reading sensor data
  To retrieve reading of sensor node 1 in cluster 0:
```
cat /tmp/sensornet/cluster0/sensor1/tempsensor0
```
  These operations may be packed in limbo scripts; one such script named sensor-dataread.b is included as part of the software package accompanying this dissertation. The core operation within the script is to open the temperature reading file and read the sensor value off it:
```
	snsrfd := sys->open("/tmp/sensornet/cluster1/sensor0/tempsensor0", sys->ORDWR);
 	n = sys->read(snsrfd, databuf, 5);		
```
  Configuring and processing events
  Implementing event based applications involves completing a series of steps as illustrated in sensor-events.b script.
  The event file is first opened:
```
	eventfd := sys->open("/tmp/sensornet/cluter1/sensor0/tempevent0", sys->ORDWR);
```
  The second step involves setting a sensor value threshold:
```
	# set threshold to 50 by writing to event file @ offset 1
	databuf[0] = byte(50+48);
  	n := sys->write(eventfd, databuf, 1);		
```
  As described in the dissertation, when sensor values exceeding this threshold are detected, an event is fired.
  
  The third step involves enabling event notification:
```
	# enable event notification by writing ASCII '1' to event file @ offset 0
	databuf[0] = byte(49);
  	n = sys->write(eventfd, databuf, 1);		
```
  This is done by writing the character '1' to the event file (writing '0' disables event notification).
  
  The final step is to learn about occurence of the event and react accordingly. In our framework, this is achieved by a performing a read operation on the associated event file; the operation blocks until the corresponding event occurs.
```
	# wait for notification
 	sys->seek(eventfd, 0, sys->SEEKSTART);		
  	n = sys->read(eventfd, databuf, 1); # blocking call
	sys->print("event recvd\n");
	# now react to the event
```
  Sensor Application Configuration & Deployment
  While the previous two scenarios represent filesystem usage during network operation, file abstractions can help during the sensor application configuration and deployment phases as well. They do so by enabling the three operations at the core of building and deploying software, namely: configuration, compilation and installation as is done conventionally using configure, make and make install. The objective is not necessarily to apply these tools directly, but instead to draw associated principles. The objective here is to describe the procedure for setting up and executing applications that illustrate the configuration and deployment functionality.
  As with the earlier application, program the sensor nodes with the sensorfs. This application is equipped with a TinyOS component named 'Deluge' that makes remote reprogramming(deployment) of sensor nodes possible. The network numbers assigned to the sensor nodes should be incremental, starting with 1.
  Program and attach a base station node to the workstation.
  The cluster filesystem for the second application is implemented by the ClusterFSprog.class available in the enclosed software. Setup the Java environment just as in the first application by downloading the supporting classes and setting the CLASSPATH variable. Then start up the cluster filesystem:
```
java uk.ac.rdg.resc.jstyx.server.ClusterFSprog [number of sensor nodes]
```
  On a workstation, mount the exported filesystem within Inferno, using the steps outlined for the earlier application. Example:
```
mount -A tcp!129.79.246.181!9876 /tmp/sensornet/cluster0
```
  Sensor Software Configuration
  To illustrate the role that filesystems can play in configuration of sensor software, consider the task of compilation of sensor applications in TinyOS. In this process, makefiles are often written to accept sensor architecture as a build target. Using our approach, this information may be obtained from the network automatically as shown below, instead of being set manually apriori. Having mounted the filesystem locally, the software may be built as shown below:
```
$ cat /tmp/sensornet/cluster0/platformtype
tmote
$ make `cat /sensornet/cluster0/platformtype` -C /sensorapps/RedBlink
```
  Sensor Software Deployment
  As always, the ideas behind the procedure outlined here are described in detail in the dissertation - in Section 4.4 Once sensor software has been compiled, it can be deployed on sensor nodes through uniform file operations. As alluded to earlier, programming is made possible through the Deluge module provided by TinyOS. Deluge allows sensor programming over radio and USB. We will discuss both cases here. The steps described here are captured in the script-program script included with the support software. NOTE: this is a shell script, and not a limbo script. So it should be involed from the shell using the 'sh' command as shown below:
```
sh script-program
```
  As always, first program the sensor nodes with the sensorfs software.
  The subsequent steps differ slightly between the USB and radio cases. Next, start up the cluster filesystem. Depending on whether programming needs to occur over radio or not, include the -r command line flag, as illustrated below:
```
java uk.ac.rdg.resc.jstyx.server.ClusterFSprog -r [number of sensor nodes]
```
  programming over USB
  In this default case, sensor nodes are connected to the programming workstation (cluster head) over USB based virtual COM ports. As before, multiple clusters may exist, with each consisting of the programming workstation along with its associated set of sensor nodes.
  Start up the ClusterProg filesystem as before:
```
java uk.ac.rdg.resc.jstyx.server.ClusterFSprog [number of sensornodes]
```
  This starts up a filesystem at port 9876, that enumerates the various sensor nodes present within the cluster and generates its namespace accordingly.
  On the remote workstation, mount the various cluster filesystems from within Inferno as shown below:
```
mount -A tcp!129.79.244.162!9876 /sensornet/cluster0
mount -A tcp!129.79.246.180!9876 /sensornet/cluster1
```
  The various sensor nodes being programmed have to be associated with the COM ports over which they are connected to the programming workstation. This is acheived by writing the address command with the appropriate COM port number to the sensor control file, as shown below. An improvement over the current implementation would be to enable this association to happen automatically.
```
echo -n 'address COM5' > /sensornet/cluster0/sensor0/sensorctl
```
  In the above scenario, the sensor node '0' in cluster '0' has been registered at COM5 by the programming workstation.
  The sensor binary that is to be deployed within the sensor nodes is then transferred to the cluster binary repository. This is acheived by first erasing the existing binary in the repository, by writing the 'e'(erase) command to the image repository control file (imagectl), as shown below:
```
# erase the existing image 
cd /sensornet/cluster0
echo -n 'e' > imagectl
```
  Now transfer the binary (hex file) of the sensor application to the cluster. This is acheived by writing the the contents of the binary file to the cluster image repository file (image). Note that copying the file is not an option as the remote filesystem does not allow new file creation. The binary transfer operation is shown below:
```
 
cat /usr/bpisupat/main.ihex > image
# tell the filesystem we are 'd'one
echo -n 'd' > imagectl
```
  Finally, program the sensor node by writing the 'p'rogram command to its control file:
```
cd /sensornet/cluster0/sensor0
echo -n 'p' > sensorctl
```
  programming over radio
  The procedure for programming sensor nodes over radio has some minor differences. The cluster filesystem is started with the the -r option, as shown below:
```
java uk.ac.rdg.resc.jstyx.server.ClusterFSprog -r [number of sensornodes]
```
  The second difference is that there is no need to configure the address for each sensor node (by writing to the address file) - infact the sensor nodes would most likely be placed remotely from the programming workstation, rather than being tethered using a USB connection.
  An advantage of this approach is that it can easily be scaled to configure and deploy large, heterogeneous sensor networks consisting of multiple clusters, each having numerous sensors. The basic programming operation outlined above, can be iterated upon for multiple sensor nodes by repeating them within loops as shown below:
```
 
for(c in /sensornet/cluster*) {
      cd $c

      #transfer the image to each cluster
      echo -n 'e' > imagectl
      cat /usr/bpisupat/main.ihex > image
      echo -n 'd' > imagectl

      #program each sensor

      for (i in $c/sensor*) {
          cd $i
          echo -n 'p' > sensorctl
      }

}
```

Support document for sensor networks prototype from dissertation work of Bhanu Pisupati

Data and Event Based Applications

Step 1: setting up sensor nodes

Step 2: setting up the cluster filesystem

Step 3: Running workstation software

Reading sensor data

Configuring and processing events

Sensor Application Configuration & Deployment

Sensor Software Configuration

Sensor Software Deployment

programming over USB

programming over radio