Greetings to all DTN members! I work with Professor Margaret Martonosi on the 
ZebraNet wildlife tracking project in Princeton University. Thanks to Kevin 
who introduced me to the DTN interest group. It's a great opportunity to share 
our experience on ZebraNet with DTN researchers and talk about interesting 
issues in this area.

ZebraNet is a mobile, wireless sensor network aimed at improving tracking 
technology for wildlife tracking [1]. While ZebraNet’s most immediate focus is 
to track african zebras across large regions with little communication 
infrastructure, its broader goals concern the deployment, management, and 
communication issues for large numbers of both static and mobile sensors.

To achieve a sensor network system for real deployment, we built energy-
efficient hardware nodes, developed a lightweight operating system, and 
implemented application-level peer-to-peer protocols for data communication 
[2] [3]. At the hardware level, a ZebraNet node includes a global positioning 
system (GPS) unit to gather position data, a 16-bit microcontroller CPU, a 1W 
900MHz radio with 5-mile range as wireless transceiver, 4Mbits of non-volatile 
FLASH memory to hold logged data, and solar arrays for energy supply. At the 
middleware level, Impala, ZebraNet's middleware layer, acts as a lightweight 
operating system, but also has been designed to encourage application 
modularity, simplicity, adaptivity, and repairability. It schedules regular 
operations, handles irregular asynchronous events, and provides a networking 
interface which unifies media access control and transport control into an 
efficient network protocol that supports a range of message models: reliable 
and unreliable, unicast and multicast, tailored to ZebraNet’s application 
needs. At the application-level, ZebraNet does not count on constant 
communication access to a base station, but instead uses periodic node 
discovery and peer-to-peer communication to communicate data towards the base 
station by using other peer nodes for store-and-forward routing. Rather than a 
connection-oriented scheme in which a node identifies a full route to the 
base, the data is instead transmitted to base hop by hop via other nodes, with 
heuristics that guide the data to where the base was last seen. Since the 
zebras form a sparse network over a very large area, disconnections is common 
and data homing latency is potentially long. Therefore, ZebraNet has some 
typical attributes of delay-tolerant networks.

During January 4 to 23, 2004, our ZebraNet group headed to Kenya for its first 
test deployment. We stayed at the Mpala Research Centre and deployed seven 
nodes on zebras at the 24,000-acre Sweetwaters Reserve. Several issues arised 
during the deployment which gave us lots of input on improving the system and 
are discussed here and hopefully will also be useful to the DTN-interest group.

First, the network connectivity was unexpectedly poor, which imposed design 
optimizations on the middleware and application-level network protocols. When 
we put the tracking devices on animals, we found that the radio range was 
reduced by a magnitude to several hundred meters as the radiation was 
substantially absorbed by the animal body. This greatly degraded the network 
connectiviy and the radio channel quality. Disconnection and packet loss 
became more common. As a result, the performance of our network protocols and 
therefore our design choices were affected in several aspects.
(1) Retransmission was frequent, in some cases, due to lost acknowledgements. 
This was because the ACK packets were always the first ones to transmit, 
followed by the data packets, and therefore were easier to lose due to the 
signal synchronization between the sender's radio and the receiver's radio. 
This caused our valuable communication time, which was already minimal given 
our tight energy budget, used up by transmitting duplicate data. To address 
this problem, we changed to use duplicate acknowledgements and are considering 
switching to unreliable data transmission that performs continuous data 
forwarding without requiring portion acknowledgements or retransmissions.
(2) In some other cases, retransmission was caused by the heterogeneous 
communication range and channel quality across different nodes. For example, 
when one node was multicasting to a bunch of neighors, some neighbors might be 
hard to reach and cause repeated retransmissions, while others were easy to 
reach but still had to stay idle for the retransmissions to finish before more 
data could proceed. Therefore, it would be interesting to find an appropriate 
timeout point to cut off retransmissions and balance between sending more data 
to less destinations and sending less data to more destinations in terms of 
achieving the goal of efficiently delivering all the data to the base station 
eventually.
(3) Nearby nodes sometimes could not find each other due to lost peer 
discovery messages. Even worse, after the short peer discovery period without 
hearing from any network neighbor, the nodes gave up the effort of finding 
neighbors and remained silent during the subsequent long data transfer period. 
This meant the valuable communication opportunities in the sparse network were 
not fully explored. To address this problem, we changed to use a series of 
duplicate peer discovery messages and are considering performing peer 
discovery over time rather than only in a limited period.
(4) Sometimes, the base station ignored valid incoming data packets simply 
because those packets were not addressed to it. Therefore, to maximize the 
chance of data collection, we decided that eavesdropping should be performed 
by the base station in addition to participating in the actual conversations.

The second issue that came to us was that the Impala middleware should add in 
more operating system support for several emerging application needs.
(1) In the original ZebraNet design, communcations between different nodes 
could be performed only at regular times, for example, the first five minutes 
of every two hours, and only in the assigned timeslots. However, it became 
evident that irregular, opportunistic, and long-lasting communications were 
also desired under some circumstances. For example, the base station might 
want to interrogate a node and download its full FLASH content immediately 
after they encountered, rather than waiting until the regular talk time came. 
Therefore, Impala should have support for a variety of communication patterns. 
(2) It was pointed out by our biologist collaborators that it was desirable to 
have an adjustable system which, for example, allowed the time schedule of 
device operations to change. This can be achieved by receiving a set of new 
parameters from the base station and applying to the local system. For 
example, the current GPS position sampling interval is eight minutes, however, 
based on the analysis of sampling efficiency and energy consumption, switching 
to 16-minute intervals may be better for energy-efficiency. Therefore, Impala 
should have support for parameterized adjustable system configurations.
(3) As the tracking devices were collared on zebras and were not easy to 
retrieve for diagnostic and debugging purposes, it was of high interests to 
have a remote diagnostic mechanism that could show at the base station the 
runtime system state of a deployed node. For example, this mechanism should be 
able to tell the base station that a node was not responding because it was 
having low battery voltage and hibernating. It should also respond to base 
station queries about how much data was currently stored in the FLASH and how 
many peer-to-peer communications had happened before.

Finally, some existing hardware constraints which were not realized as 
critical issues became more evident during the deployment time. The radio 
range problem mentioned before was one example. Another example was related to 
the hardware clock signal. Since each node had constant access to the GPS 
signal which provided global time synchronization across different nodes, we 
adopted a TDMA-mannered timeslot mechanism for media access control. Each 
timeslot was two seconds long. This implied that a reasonable time variance 
among the nodes should be within a hundred milliseconds. However, the clock 
signal on the hardware nodes was not as accurate. As was measured, it skewed 
on different nodes up to +/-200ms in 8 minutes which was the interval between 
two closest time synchronizations with the GPS time. If the GPS signal was not 
available in an extended period, the time variance would grow even bigger. To 
accommodate the big time variance, we chose to use non-consecutive timeslots 
for radio transmissions to prevent collision. More efficient solutions are 
still under study. For yet another example, we found that the GPS unit 
dominated the energy consumption compared with the radio unit. Therefore, 
switching to a lower-power GPS chip would effectively yield more radio 
communication time and was also included in our to-do list.

At this point, I hope the introduction to our ZebraNet project and the stories 
about our deployment trip to Kenya can give you some useful information. For 
more details, please refer to our project homepage at 
http://www.ee.princeton.edu/~mrm/zebranet.html. We will be very glad to hear 
your comments. Thanks.



Ting



[1] Philo Juang, Hidekazu Oki, Yong Wang, Margaret Martonosi, Li-Shiuan Peh, 
and Daniel Rubenstein. "Energy-Efficient Computing forWildlife Tracking: 
Design Tradeoffs and Early Experiences with ZebraNet". the Tenth International 
Conference on Architectural Support for Programming Languages and Operating 
Systems. October, 2002. 

[2] Ting Liu and Margaret Martonosi. "Impala: A Middleware System for Managing 
Autonomic, Parallel Sensor Systems". ACM SIGPLAN Symposium on Principles and 
Practice of Parallel Programming (PPoPP'03), June 2003.

[3] Ting Liu, Christopher Sadler, Pei Zhang, and Margaret 
Martonosi. "Implementing Software on Resource-Constrained Mobile Sensors: 
Experiences with Impala and ZebraNet". To appear in the Second International 
Conference on Mobile Systems, Applications, and Services (MobiSys 2004), June 
2004.



-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/