[Dataset] princeton/zebranet (v. 2007-02-14)

top

the initial version

@MISC{princeton-zebranet-2007-02-14,
  author = {Yong Wang and Pei Zhang and Ting Liu and Chris Sadler and Margaret Martonosi},
  title = {{CRAWDAD} data set princeton/zebranet (v. 2007-02-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/princeton/zebranet},
  month = feb,  
  year = 2007
}
					

The data contained in this data set are movement traces collected from
two real-world ZebraNet deployments at Sweetwaters Game Reserve near
Nanyuki, Kenya. The first deployment was in January 2004 and the second
deployment was during summer of 2005.  The data offer detailed animal
position information using UTM format.

The Princeton ZebraNet Project is an inter-disciplinary effort with thrusts 
in both Biology and Computer Systems.  On the computer systems side, ZebraNet 
is studying power-aware, position-aware computing/communication systems.  
Namely, the goals are to develop, evaluate, implement, and test systems 
that integrate computing, wireless communication, and non-volatile storage along 
with global positioning systems (GPS) and other sensors.  On the biology side, 
the goal is to use systems to perform novel studies of animal migrations and 
inter-species interactions.

The ZebraNet project has gone through two deployments. The sensor nodes
we used in the deployments were based on the ZebraNet Test nodes. The
node is built around a MSP430 processor and included a GPS module, a
radio module, and a flash module. More details on the ZebraNet hardware
experiences can be found in [zhang-hardwaqre-zebranet].

The first deployment occurred at January of 2004 and consisted of 7 
sensor nodes on seven different zebras. Due to power and packaging
issues and severe weather, they lasted less than a week. Results were
published in [liu-impala-zebranet, zhang-hardware-zebranet, wang-opportunistic].

The second deployment occurred during June/July of 2005.  Four zebras
were fitted with an improved version of the sensor nodes. 
The sensor nodes had improved hardware, software, and data collection algorithms.
The approximate running time of the network was 10 days.  Zebras
selected for collaring were picked by the biologists for their different
behavioral patterns. Collar 6 was placed on a bachelor male, which had a
tendency to move around searching for a mate. Collar 8 was a female but
had trouble with the collar position, causing it to acquire fewer GPS
fixes. Collar 10 is a female, which leads the group. Collar 14 is also a
female but her group had a characteristic of a very small home range.

[Traceset] princeton/zebranet/movement (v. 2007-02-14)

top

the initial version

@MISC{princeton-zebranet-movement-2007-02-14,
  author = {Yong Wang and Pei Zhang and Ting Liu and Chris Sadler and Margaret Martonosi},
  title = {{CRAWDAD} trace set princeton/zebranet/movement (v. 2007-02-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/princeton/zebranet/movement},
  month = feb,  
  year = 2007
}
					

The data contained in this trace set are movement traces collected from
two real-world ZebraNet deployments at Sweetwaters Game Reserve near
Nanyuki, Kenya. The first deployment was in January 2004 and the second
deployment was during summer of 2005.  The data offer detailed animal
position information using UTM format.

A ZebraNet hardware node includes global positioning system (GPS), a simple 
microcontroller CPU, a wireless transceiver, and non-volatile storage to hold 
logged data. ZebraNet does not rely on constant communication access to a base 
station or other nodes. Instead, it uses periodic node discovery and node-to-node 
communication to propagate data towards the base station in a store-and-forward
manner.

1 Hardware Overview

The ZebraNet hardware is composed of energy-efficient components ideal for use 
in mobile sensor networks. The major functional components on the board are 
the microcontroller, GPS, external FLASH, radio, and battery with solar chargers.

To control the hardware, we selected the Texas Instruments Ultra-Low-Power 
MSP430F149 16-bit microcontroller. This chip has 2KB of RAM, 60KB of internal 
FLASH memory, and two serial interfaces. It runs off an uninterruptible power 
supply as we expect it to run continuously. The microcontroller operates in a 
dual-clock configuration. It uses an 8MHz clock when accessing sensing, storage, 
or communication peripherals and a 32KHz clock at all other times. The 32KHz clock 
consumes half as much power as the 8MHz clock and can be used instead of putting the
processor to sleep.

To log the node's position, we selected the u(micro)-blox GPS-MS1E chip for 
its small size and its ability to quickly acquire locks. It has a typical hot start 
acquisition time of two to six seconds, although our experience has been 
that good GPS fixes take 10-20 seconds to acquire. The GPS communicates with 
the microcontroller through an asynchronous serial connection at a rate of 38,400 
baud (the maximum rate for this chip) over a port which it shares with the 
external FLASH. It runs off its own 3.3V power supply which can be turned on 
and off by the software to conserve power. 

To store data, we selected the ATMEL 4Mbit AT45DB- 041B DataFlash chip. 
In our system, the node has enough memory capacity to store 26 days of 
its own positional data and 52 collar-days of positional data received from 
other nodes. The chip communicates with the microcontroller synchronously at 
a baud rate of 667Kbaud. Sharing the serial port with the GPS allows for the 
FLASH and the radio to operate simultaneously. The FLASH is powered by the same 
uninterruptible source as the microcontroller.

To transmit data between nodes, we selected the Max-Stream 9XStream radio. 
It operates at 900MHz and is specified to broadcast data up to 5 miles. 
In our configuration, however, reliable ranges of 0.5-1 mile are more likely.
To transmit, the radio only requires around 1W of power. This is possible because 
as a receiver, it has a sensitivity of -107dBm. The radio communicates with 
the microcontroller through the second asynchronous serial connection at a rate 
of 38,400 baud (chosen to match that of the GPS) and with other nodes at an 
over-the-air rate of 19,200bps. It runs off its own 5V power supply which, like 
the supply for the GPS, can be turned on and off by the software to conserve power.

To power the node, we use the Panasonic CGR18650A 2A hour Lithium ion battery. 
Based on the specifications of this battery, we consider it fully charged at 4.2V
and dead at 3.1V. We chose 3.4V as the lower bound of its functional range because 
at this voltage the radio and GPS units rapidly drain the battery and, consequentially, 
cannot function properly. The battery is recharged using solar cells strategically 
placed around the collar.  

As energy-efficiency is critical in mobile sensor networks, the ZebraNet hardware 
features low-power components and efficient power supplies. We measured the power 
consumption of the system during a cycle in which it performed all possible 
operations. 

2. Hardware-Imposed Constraints on System Software Programming

The limitations of the hardware system have posed significant constraints 
on system software programming. Many of them are representative of the challenges 
in other sensor systems as well.

- Data and Program memory constraint The data memory in the microcontroller 
is only 2KB. This affects the program behavior in many aspects, especially
in data buffering. As are used to keep system states and to handle large 
flows of network data, data buffers often consume large amount of memory, and 
therefore must be carefully allocated. Additionally, the program memory is 
only 60KB. This requires software programs to be concise.

- Energy constraint The energy budget is tight as we use a solar-array 
to recharge the battery and to provide the energy essential to achieve the sensing 
and communication tasks. As is estimated, we are able to fully charge the battery 
in 50 hours of daylight. This number can vary in either direction, however, depending
on the orientation of the solar cells in relation to the sun. Therefore, efforts 
must be made to maximally save energy, and resorts must be provided to preserve
the system when the energy level is severely low.

- Device access constraint Device accesses must be carefully scheduled to avoid 
conflicts which are likely to happen due to hardware limitations. For example,
due to voltage regulation challenges, the GPS and the radio should not be turned 
on at the same time for interference-avoidance purposes. Additionally, the
GPS and the FLASH share the same serial connection to the microcontroller, and 
therefore, cannot be accessed simultaneously.

-  Radio packet size constraint The physical packet size of our radio hardware is 
only 64 bytes, an order of magnitude smaller than the Ethernet packet size, for
example. This means the multi-level packet header in the traditional TCP/IP model 
will cost a significant communication overhead. Therefore, we need a special
network protocol that requires a low overhead to accomplish the essential network 
communication services.

- FLASH data storage constraint For the FLASH memory, new data cannot be written 
to an address before the data currently at that address is erased, and the smallest 
erasable unit is a 264-byte page. This means writing data to one location will 
affect data at other locations. Therefore, a global FLASH organization is required 
to achieve efficient data storage.

- GPS sensing time constraint The time for the GPS unit to acquire an accurate 
position lock is typically 10 to 20 seconds. This considerable delay in data acquisition
implies an asynchronous access and control model is preferred to a synchronous model 
for operating this sensing device.

[Trace] princeton/zebranet/movement/baseoutUTM1 (v. 2007-02-14)

top

the initial version

@MISC{princeton-zebranet-movement-baseoutUTM1-2007-02-14,
  author = {Yong Wang and Pei Zhang and Ting Liu and Chris Sadler and Margaret Martonosi},
  title = {{CRAWDAD} trace princeton/zebranet/movement/baseoutUTM1 (v. 2007-02-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/princeton/zebranet/movement/baseoutUTM1},
  month = feb,  
  year = 2007
}
					

This trace contains detailed animal position information using UTM format,
which was collected from a real-world ZebraNet deployment at Sweetwaters 
Game Reserve near Nanyuki, Kenya in January 2004.

The first deployment occurred at January of 2004 and consisted of 7
sensor nodes on seven different zebras. Due to power and packaging
issues and severe weather, they lasted less than a week. Results were
published in [liu-impala-zebranet, zhang-hardware-zebranet, wang-opportunistic].

1. Directories and files

The directory structure is listed as follows:
- ZebraNet
  - README.txt          (this file)
  - baseoutUTM1.txt     (version 1 trace)
  - trace2ns.py         (a sample Python program to translate the 1st
                         trace to ns-2 readable format)
  - baseoutUTM2.txt     (version 2 trace)

2. File format of baseoutUTM1.txt

The file named baseoutUTM1.txt includes the data collected from the
first deployment, in space separated ASCII format.  Each location data
entry is represented by one line in the file with an interval of 8
minutes between each location reading. 
Each line consists of 11 space separated fields as follows:

Fields 1-9: "node ID" "month" "day" "year" "hour" "minute" "second" "latitude" "longitude"
Fields 10-11: movement data stored in UTM format 
(see http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system)

A sample program (trace2ns.py) illustrates how UTM we transform the UTM
data to (x,y) coordinates used in traditional simulators, such as the ns-2.

[Trace] princeton/zebranet/movement/baseoutUTM2 (v. 2007-02-14)

top

the initial version

@MISC{princeton-zebranet-movement-baseoutUTM2-2007-02-14,
  author = {Yong Wang and Pei Zhang and Ting Liu and Chris Sadler and Margaret Martonosi},
  title = {{CRAWDAD} trace princeton/zebranet/movement/baseoutUTM2 (v. 2007-02-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/princeton/zebranet/movement/baseoutUTM2},
  month = feb,  
  year = 2007
}
					

This trace contains detailed animal position information using UTM format,
which was collected from a real-world ZebraNet deployment at Sweetwaters 
Game Reserve near Nanyuki, Kenya during summer of 2005.

The second deployment occurred during June/July of 2005.  Four zebras
were fitted with an improved version of the sensor nodes. 
The sensor nodes had improved hardware, software, and data collection algorithms.
The approximate running time of the network was 10 days.  Zebras
selected for collaring were picked by the biologists for their different
behavioral patterns. Collar 6 was placed on a bachelor male, which had a
tendency to move around searching for a mate. Collar 8 was a female but
had trouble with the collar position, causing it to acquire fewer GPS
fixes. Collar 10 is a female, which leads the group. Collar 14 is also a
female but her group had a characteristic of a very small home range.

1. Directories and files

The directory structure is listed as follows:
- ZebraNet
  - README.txt          (this file)
  - baseoutUTM1.txt     (version 1 trace)
  - trace2ns.py         (a sample Python program to translate the 1st
                         trace to ns-2 readable format)
  - baseoutUTM2.txt     (version 2 trace)

2. File format of baseoutUTM2.txt

The file named baseoutUTM2.txt includes the data collected in
space-separated ASCII format with location information stored in UTM
format.  Each location entry is represented by one line in the file. The
word "BASESTATION" is an indication of the file's origin and should be
the same for all entries.  The number that follows the word "node" is
the node number.  There are 4 nodes included in this file, node 6, 8,
10, and 14. After the node number is the date and time. They are
organized in "year month day" and "hour minute" respectively. The time
information is in GMT and Kenyan time is GMT+3. The location information
is in UTM format located after the date and time. They are labeled
easting and northing. After the location information is the volt. Volt
is just a rough estimate of the voltage and only serves as an indicator
of node's energy status.  Hdop is horizontal delusion of precision
obtained from the GPS module, rounded down. In every lock, we wait until
this number is below 7 to register a lock for improved accuracy. Nsat is
the number of satellites available for the particular GPS lock. A number
7 indicates the lock was obtained with information from 7 satellites or
more.

[Author] Yong Wang

top

[Author] Pei Zhang

top

[Author] Ting Liu

top

[Author] Chris Sadler

top

[Author] Margaret Martonosi

top

[Paper] liu-impala-zebranet

top

ZebraNet is a mobile, wireless sensor network in which nodes move throughout an 
environment working to gather and process information about their surroundings. 
As in many sensor or wireless systems, nodes have critical resource constraints 
such as processing speed, memory size, and energy supply; they also face 
special hardware issues such as sensing device sample time, data storage/access 
restrictions, and wireless transceiver capabilities. This paper discusses and 
evaluates ZebraNet's system design decisions in the face of a range of 
real-world constraints. Impala-ZebraNet's middleware layer - serves as a 
light-weight operating system, but also has been designed to encourage 
application modularity, simplicity, adaptivity, and repairability. Impala is 
now implemented on ZebraNet hardware nodes, which include a 16-bit 
microcontroller, a low-power GPS unit, a 900MHz radio, and 4Mbits of 
non-volatile FLASH memory. This paper discusses Impala's operation scheduling 
and event handling model, and explains how system constraints and goals led to 
the interface designs we chose between the application, middleware, and 
firmware layers. We also describe Impala's network interface which unifies 
media access control and transport control into an efficient network protocol. 
With the minimum overhead in communication, buffering, and processing, it 
supports a range of message models, all inspired by and tailored to ZebraNet's 
application needs. By discussing design tradeoffs in the context of a real 
hardware system and a real sensor network application, this paper's design 
choices and performance measurements offer some concrete experiences with 
software systems issues for the mobile sensor design space. More generally, we 
feel that these experiences can guide design choices in a range of related 
systems.

[Paper] wang-opportunistic

top

Routing in Delay Tolerant Networks (DTN) with unpredictable node mobility is a 
challenging problem because disconnections are prevalent and lack of knowledge 
about network dynamics hinders good decision making. Current approaches are 
primarily based on redundant transmissions. They have either high overhead due 
to excessive transmissions or long delays due to the possibility of making 
wrong choices when forwarding a few redundant copies. In this paper, we propose 
a novel forwarding algorithm based on the idea of erasure codes. Erasure coding 
allows use of a large number of relays while maintaining a constant overhead, 
which results in fewer cases of long delays. We use simulation to compare the 
routing performance of using erasure codes in DTN with four other categories of 
forwarding algorithms proposed in the literature. Our simulations are based on 
a real-world mobility trace collected in a large outdoor wild-life environment. 
The results show that the erasure-coding based algorithm provides the best 
worst-case delay performance with a fixed amount of overhead. We also present a 
simple analytical model to capture the delay characteristics of erasure-coding 
based forwarding, which provides insights on the potential of our approach.

[Paper] zhang-hardware-zebranet

top

The enormous potential for wireless sensor networks to make a positive impact 
on our society has spawned a great deal of research on the topic, and this 
research is now producing environment-ready systems. Current technology limits 
coupled with widely-varying application requirements lead to a diversity of 
hardware platforms for di®erent portions of the design space. In addition, the 
unique energy and reliability constraints of a system that must function for 
months at a time without human intervention mean that demands on sensor network 
hardware are different from the demands on standard integrated circuits. This 
paper describes our experiences designing sensor nodes and low level software 
to control them. In the ZebraNet system we use GPS technology to record 
fine-grained position data in order to track long term animal migrations. The 
ZebraNet hardware is composed of a 16-bit TI microcontroller, 4 Mbits of 
off-chip flash memory, a 900 MHz radio, and a low-power GPS chip. In this 
paper, we discuss our techniques for devising efficient power supplies for 
sensor networks, methods of managing the energy consumption of the nodes, and 
methods of managing the peripheral devices including the radio, flash, and 
sensors. We conclude by evaluating the design of the ZebraNet nodes and 
discussing how it can be improved. Our lessons learned in developing this 
hardware can be useful both in designing future sensor nodes and in using them 
in real systems.