The Princeton ZebraNet Project: Sensor Networks for Wildlife - PowerPoint PPT Presentation

The Princeton ZebraNet Project: Sensor Networks for Wildlife Tracking Margaret Martonosi VET NOV TES TAM EN TVM Dept. of Electrical Engineering Princeton University

ZebraNet as Biology Research � Goal: Biologists want to track animals long-term, over long distances – Interactions within a species? – Interactions between species? – Impact of human development? � Current technology is limited: – VHF Triangulation is difficult & error- prone – GPS trackers limit data to coarse sampling and require collar retrieval � Overall, energy and info retrieval are key limiters � Peer-to-peer offers opportunity to improve

ZebraNet as Computing Research Tracking node with CPU, FLASH, radio and GPS Data Store-and-forward Data communications Data Data Base station (car or plane) ZebraNet vs. Other SensorNets � All sensing nodes are mobile Research Questions � Large area: 100’s-1000s sq. kilometers � Protocols and mobility? � “Coarse-Grained” nodes � Energy-efficiency? � GPS on-board � Software layering design? � Long-running and autonomous

Biologist’s Wishlist ➨ ZebraNet Design Design Issues: Research Questions � What are suitable protocols for � Lightweight ➨ Energy-efficient the expected mobility patterns? � How to model mobility well � Detailed 24/7 archival position enough to determine this? logs ➨ GPS-enabled � Can systems of sufficient radio range be designed to operate � Mobile ➨ Wireless energy-efficiently enough? � How can one design software � No fixed base station (no layers that enable long-lived cellular) ➨ Peer-to-peer routing adaptable software and yet are and data storage also very energy-efficient? � Restricted human access ➨ One year of autonomous operation

Talk Outline � Sensor Networks: Intro & Overview � ZebraNet – Problem statement and system overview – Protocols and mobility models – Impala middleware – Hardware details and energy issues � Broader view…

ZebraNet Hardware Design Mode Power Microcontroller FLASH TI MSP430F149 32Khz CPU 9.6 mW ATMEL AT45DB041B 16-bit RISC 4Mbit 2KB RAM, 60KB ROM 78 days data capacity 8MHz/32KHz dual clock 8MHz CPU 19.32 mW Radio 8MHz w/ 568 mW GPS MaxStream 902-928MHz GPS µ-blox GPS-MS1E 19.2Kbps, 10-20s position fix time 8MHz + 780 mW 0.5-1mile transmit range radio xmit Power supplies, solar modules, charging circuits 8MHz + 312 mW radio rcv

What data to track? Current: – GPS Position sample every 3 minutes – Sun/Shade indication – Detailed information for 3 minutes every hour: • Detailed position sampling: standing still or moving? Speed? “Step rate” � ~256 bytes per hour � 1 “collar-day of info” ~ 6KB � ~170 collar-days in 8Mbit FLASH chip Future: – Head up or down: “bite rate”, Ambient temperature, Body temperature, Heart rate, Low res digital images, … – Bit rate & storage needs could increase further…

Basic System Operation Tracking Node A A B A B Tracking Node B B A B A

Basic System Operation Potentially much later and far from node A… Tracking Node B C B A C Tracking B A Node C C A Daily/weekly; C B A B Car or Plane B A C B A C

Talk Outline � Sensor Networks: Intro & Overview � ZebraNet – Problem statement and system overview – Protocols and mobility models – Impala middleware – Hardware details and energy issues � Broader view…

Zebra Lifestyles… F F F F F M F F F F F M F F F F F F F F M M M F F F M M M � Harem: Long-term bond between 1 male and several M females + offspring � Herd: Looser coalition of several harems ➨ Track 30-50 samples from several harems + bachelors

Zebra Lifestyles II P in_gw P in_fm speed gw speed fm speed g P out_gw P out_fm GRAZING GRAZE-WALKING FAST MOVING � Mostly: herbivores graze Water � Sometimes: graze-walk � “thirsty” ~once a day while looking for greener � Model at random time pastures. � Walk to nearest water � Rare: run to/away from � After drink, resume ambient something motion

Zebra Movement Speeds From field data: 18 16 � Grazing: 0.017m/s 14 � Graze-walking: 12 0.072 m/s 10 8 � Fast: 0.155 m/s 6 4 � Turns ~ < 60° 2 0 1 3 5 7 9 1 3 5 7 9 1 3 5 7 1 1 1 1 1 2 2 2 2 net meters traveled in 3 minutes

ZebraNet Protocol Evaluations: ZNetSim � Evaluated communications issues using ZNetSim – coarse-grained mobile communication simulator using field observations for mobility model � For results here: – 50 collars – Tracked across a 20km by 20km area – For one month – Discovery/Transfer for 30 minutes every 2 hours – Base station: daily drive-bys � Vary radio range to understand trends

ZebraNet Protocols � Two peer-to-peer protocols evaluated here – Flooding: Send to everyone found in peer discovery. – History-Based: After peer discovery, choose at most one peer to send to per discovery period: the one with best past history of delivering data to base. � Compared to “direct”: no peer-to-peer, just to base � Success rate metric: Of all data produced in a month, what fraction was delivered to the base station?

Protocol Success Rate: Ideal � Radio range for direct hist flood 100% delivery: 100 – No peer-to- %data to base 90 80 peer: ~12km 70 60 – With Peer-to- 50 40 peer: ~6km 30 20 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 4 6 8 0 2 4 1 1 1 radio range (meters)

Protocol Success Rate: Constrained Bandwidth direct hist flood 100 90 80 % data to base 70 60 50 Short-range: Flooding best 40 Long-range: History best. 30 (Flooded data swamps 20 limited bandwidth) 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 4 6 8 0 2 4 1 1 1 radio range (meters)

Protocol Energy Dissipation 9 8 normalized energy 7 6 Energy normalized to “direct” 5 protocol of same radio range. 4 flood History tracks “direct” 3 history Flooding energy explodes 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 4 6 8 0 2 4 1 1 1 radio range (meters)

Mobility & Protocol Summary � Mobility model key to � Radio range key to data protocol evaluations homing success: ~3-4km for – Fast random moves hurt 50 collars in 20kmx20km area history � Success rate: – Chicken and Egg: – Ideal: flooding best mobility model is the – Constrained bandwidth: biology research goal history best � Energy trends make selective protocols best

Talk Outline � Sensor Networks: Intro & Overview � ZebraNet – Problem statement and system overview – Protocols and mobility models – Impala middleware – Hardware details and energy issues � Broader view…

Impala: Middleware Support for Application/Protocol Modularity Individual Protocols A A B B A B B C D Aggregate Protocol C D D Impala Layer Layered Approach Monolithic Approach Goals: Applications Adaptive application software � Remote software updates � Update Adapt Middleware adapts, updates � Impala apps, protocols dynamically Updates New protocols can be plugged Device Hardware � via radio in at any time

Impala Architecture & Programming Model Application A Application B Application C Application D Initialize Query Packet Data Terminate Send Done Timer Application Application Updater Adapter Event Filter Device Packet Data Event Event Event Send Done Timer Event Event

Impala Middleware Layer Application 1 Application 2 Application 3 Application 4 Asynchronous Network Transmission GPS Data Event Handler Protected FLASH Access Application Timer Event Handler Application Timer Control Network Packet Event Handler System Clock Time Read Network Send Done Event Handler Operation Event Network Adapter Updater Scheduler Filter Support GPS Data Event Access and Control to All Devices Radio Packet Event Timer Event CPU Radio GPS FLASH Timer WDT

Impala Code Updates A C D B Node Update Updater On a single sensor node Full network ZebraNet Characteristics Design Implications High Node Mobility Incomplete Updates � � Constrained Bandwidth Updates vs. Execution � � Wide Range of Updates Out of order Updates � �

On-demand Software Transmission for Remote Software Update Stage 1 Stage 1 I have Version 3.0 Complete Version: 3.0 Complete Version: 1.0 Node A Node B Node A Node B Incomplete Version: I have Version 1.0 Incomplete Version: 2.0, 3.0 Stage 2 I want Module 5 Complete Version: 3.0 Complete Version: 1.0 from Version 3.0 Node A Node B Incomplete Version: Incomplete Version: 2.0 and 3.0 Stage 3 Module 5 from Version 3.0 Complete Version: 3.0 Complete Version: 3.0 Node A Node B Incomplete Version: Incomplete Version: Repeat as needed … Repeat interval backs off if frequent updates not needed

Impala Implementations Initially prototyped on HP/Compaq iPAQ Pocket � PC Handhelds – 206MHz CPU, 32MB flash RAM, 16MB flash ROM, running Linux Now (as of 2 weeks ago!) also implemented on � ZebraNet hardware