Implementing Software on Resource-Constrained Mobile Sensors: Experience with Impala and ZebraNet Ting Liu Christopher M. Sadler Pei Zhang Margaret Martonosi Depts. Of Electrical Engineering and Computer Science Princeton University

ZebraNet: Fusing Mobile Computing and Sensor Systems Tracking node with CPU, FLASH, radio and GPS Data Store-and-forward communications Data Base station (car or plane) Data Data Sensor Network Attributes ZebraNet Other Sensor Networks Node mobility Highly mobile Static or moderate mobile Communication range Miles Meters Sensing frequency Constant sensing Sporadic sensing Sensing device power Hundreds of mW Tens of mW

Software Design Rationales Question One: System Layering Single Software System Hardware Impala Applications Middle ground Layer 6 Layer 5 Layer 4 Layer 3 Layer 2 Layer 1 Monolithic approach: Layered approach: Software modularity Layering overhead

Software Design Rationales Question Two: Middleware Weight Applications Hardware Impala Applications Middle ground Applications Super-middleware Mini-Middleware Hardware Hardware Limited services: Overloaded services: application simplicity Middleware overhead

Impala Overview Application modularity, simplicity, adaptivity and repairability Adapter Updater Operation Scheduler Event Filter Network Support Software adaptation for sensor network performance Software update for sensor network deployment Operation scheduling for regular operations Event handling for irregular events Network support for sensor network communications

This Paper Application modularity, simplicity, adaptivity and repairability Adapter Updater Operation Scheduler Event Filter Network Support PPoPP 2003: This Paper: Adaptation and update Operation, event, network Prototyped on iPAQs Implemented on ZebraNet node

Roadmap Hardware design and constraints Problem 1: Complex hardware realities Solution: Layers and interfaces Problem 2: Miscellaneous system activities Solution: Operation scheduling and event handling Problem 3: Special communication needs Solution: Messages models Problem 4: Limited communication resources Solution: Networking strategies Conclusions

Hardware Design and Constraints Microcontroller TI MSP430F149 16-bit RISC 2KB RAM 60KB ROM 8MHz/32KHz dual clock FLASH ATMEL AT45DB041B 4Mbit 78 days data capacity GPS µ-blox GPS-MS1E 10-20s position fix time Radio MaxStream 9Xstream 902-928MHz 19.2Kbps over-the-air 0.5-1mile transmit range Power supplies SPI 667Kbps USART 38.4Kbps Solar modules 5V 3.3V Charging circuits Power Measurement (4.0V applied) System Mode Power CPU at 32KHz 9.6 mW CPU at 8MHz 19.32 mW 8MHz w/ GPS 568 mW 8MHz w/ radio transmit 780 mW 8MHz w/ radio receive 312.4 mW Memory constraint Energy constraint Device access constraint Radio packet size constraint GPS sensing time constraint FLASH storage constraint

Problem 1: Complex Hardware Realities Solution: Layers and Interfaces Radio GPS FLASH Timer CPU WDT Access and Control to All Devices Application 1 Application 2 Application 3 Application 4 GPS Data Event Radio Packet Event Timer Event Asynchronous Network Transmission Protected FLASH Access Application Timer Control GPS Data Event Handler Application Timer Event Handler Network Packet Event Handler Network Send Done Event Handler System Clock Time Read Adapter Updater Network Support Operation Scheduler Event Filter

Memory Footprint of Impala Layers

Problem 2: Misc System Activities Solution: Regular Operation Scheduling GPS-aided operation synchronization Prohibited simultaneous device operations Non-trivial radio wake-up time Potentially long GPS sensing time Stringent energy budget 1 2 4 5 7 8 3 6 Networking Period GPS Sensing Period Sleep Period 1 CPU wake up/Radio, FLASH power on 5 GPS power on 2 Radio transmitting / receiving start 6 GPS sensing time 3 Network communication time 7 GPS power off / FLASH power on 4 Radio power off/FLASH power off 8 CPU sleep / FLASH power off

Operation Scheduling Overhead Scheduling Type Impala Activity Time (cycles) CPU Scheduling To put CPU on the full-speed clock 3127 To put CPU on the slow clock 38 Radio and FLASH Scheduling To set up the first transmission time and turn on radio and FLASH 50 ms To set up the next transmission time 260 To set up the network cleanup time 265 To clean up incomplete network messages, power off radio and FLASH, and set up the next networking period 11 ms GPS Scheduling To initiate GPS sensing and set up its finish time 1247 To format GPS data, power off GPS, signal an GPS data event, and set up the next GPS sensing period 2550

Short / atomic hardware interrupts Long / preemptive software events Problem 2: Misc System Activities Solution (cont.): Handling Irregular Events Issue One: Event Abstraction Issue Two: Concurrency Abstract Application Events Short / atomic hardware interrupts Impala Idle Long / preemptive software events Miscellaneous Hardware Interrupts Issue Three: Event Prioritization High Priority Events Event Handler Event Signaler Low Priority Events

Problem 3: Special Communication Needs Solution: Message Models and Sessions Peer discovery or data 1 to 32KB One, more or unlimited destinations Data from FLASH or RAM Acknowledgment or not Connectionless Asynchronous Sensor data ACK Reliable Unicast Sensor Sensor data data ACK Unreliable Broadcast Reliable Multicast

Problem 4: Limited Comm Resources Solution: Unified MAC &Transport Control MAC: round-robin timeslots (w/ GPS-aided time synchronization) Transport control: detect packet loss and retransmit Unified: reduce data copy and overhead across protocol layers B acks packet 1-8 C acks packet 1-4 D silent B acks packet 1-8 C acks packet 1-4 D acks packet 1-8 B acks packet 9-16 C acks packet 1-4 D acks packet 9-16 A B C D A B C D A B C D A sends packet 1-8 to B, C, and D A sends packet 1-8 A gives up C and sends packet 9-16

ZebraNet Status and Next Steps January, 2004: 7 test collars deployed on zebras in Kenya. First data received: 1/19/2004 Next Steps Refine collar design; switch to lower-energy GPS, merge Impala software update code into final collars

Conclusions Propose and implement Impala middleware model Solutions for hardware constraints and app req Concrete experience with real system and application Applications Simple layering and rich services Impala Hardware