Implementing Software on Resource-Constrained Mobile Sensors: Experience with Impala and ZebraNet

1. 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

2. 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

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

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

5. 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

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

7. 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

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

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

10. Memory Footprint of Impala Layers

11. 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 7 8 4 5 3 6 Networking Period Sleep Period GPS Sensing Period 1 5 CPU wake up/Radio, FLASH power on GPS power on 2 6 Radio transmitting / receiving start GPS sensing time 3 7 Network communication time GPS power off / FLASH power on 4 8 Radio power off/FLASH power off CPU sleep / FLASH power off

12. Operation Scheduling Overhead

13. 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

14. 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

15. 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 9-16 C acks packet 1-4 D acks packet 9-16 B acks packet 1-8 C acks packet 1-4 D acks packet 1-8 A B C D A B C D A B C D A gives up C and sends packet 9-16 A sends packet 1-8 to B, C, and D A sends packet 1-8

16. ZebraNet Status and Next Steps • Status • 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

17. 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