princeton/zebranet2007021424200702142007-02-15princeton/zebranetDataset of animal movement traces collected from real-world ZebraNet deployments.

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 initial version2007-02-142004-01-122005-06-279899100101102http://www.princeton.edu/~mrm/zebranet.htmlhttp://www.crawdad.org/wiki/pmwiki.php?n=Main.Dataset.princeton-zebranetsensor networkGPSlocationUser Mobility Characterizationsensor networkThe 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.36200702142007-02-15princeton/zebranet/movementTraceset of animal movement traces collected from real-world ZebraNet deployments.

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.

the initial version2007-02-142004-01-122005-06-27User Mobility CharacterizationA 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./download/princeton/zebranet/ZebraNet.tar.gzprinceton/zebranet82200702142007-02-15princeton/zebranet/movement/baseoutUTM12004 trace of animal movement traces collected from real-world ZebraNet deployments.

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 initial versionfalse2007-02-142004-01-122004-01-13The 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.princeton/zebranet/movement83200702142007-02-15princeton/zebranet/movement/baseoutUTM22005 trace of animal movement traces collected from real-world ZebraNet deployments.

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 initial versionfalse2007-02-142005-06-242005-06-27The 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.princeton/zebranet/movement98princeton/zebranetYong Wangyongwang@princeton.eduPrinceton UniversityDepartment of Computer SciencePhD studenthttp://www.cs.princeton.edu/~yongwang/99princeton/zebranetPei Zhangpeizhang@princeton.eduPrinceton UniversityDepartment of Electrical EngineeringPhD student100princeton/zebranetTing Liutliu@cs.princeton.eduPrinceton UniversityDepartment of Computer SciencePhD studenthttp://www.cs.princeton.edu/~tliu/101princeton/zebranetChris Sadlercsadler@princeton.eduPrinceton UniversityDepartment of Electrical EngineeringPhD studenthttp://www.princeton.edu/~csadler/102princeton/zebranetMargaret Martonosimartonosi@princeton.eduPrinceton UniversityDepartment of Electrical EngineeringProfessor

Dept of Electrical Engineering, Engineering Quad, Room B216, Princeton University, Princeton, NJ 08544-5263

609-258-1912609-258-3745http://www.princeton.edu/~mrm/liu-impala-zebranetTing LiuChristopher SadlerPei ZhangMargaret MartonosiProceedings of the Second International Conference on Mobile Systems, Applications, and Services (MobiSys)--06--2004

Boston, MA

USENIX Associationhttp://portal.acm.org/citation.cfm?id=990064.990095Sensor Networks, Middleware System, Operation Scheduling, Event Handling, Network CommunicationsZebraNet 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.wireless-meas,crawdadmeasurementwirelessprinceton_zebranetcrawdadprinceton/zebranet20040601wang-opportunisticYong WangSushant JainMargaret MartonosiKevin FallProceeding of the 2005 ACM SIGCOMM workshop on Delay-tolerant networking--08--2005

Philadelphia, PA

ACM Presshttp://portal.acm.org/citation.cfm?id=1080140Routing, Delay Tolerant Network, Erasure CodingRouting 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.wireless-meas,crawdadmeasurementwirelessprinceton_zebranetcrawdadprinceton/zebranet20050801zhang-hardware-zebranetPei ZhangChristopher SadlerStephen LyonMargaret MartonosiProceedings of the 2nd international conference on Embedded networked sensor systems (Sensys)--11--2004

Baltimore, MD

ACMhttp://portal.acm.org/citation.cfm?id=1031495.1031522Sensor Networks, Sensor Deployment, ZebraNet, GPSThe 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.wireless-meas,crawdadmeasurementwirelessprinceton_zebranetcrawdadprinceton/zebranet20041101