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

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

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

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:
Adaptation and update
Operation, event, network
Prototyped on iPAQs
Implemented on ZebraNet node

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

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

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

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

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

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

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

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