Implementing Software on ResourceConstrained 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
Data
Sensor Network Attributes
Node mobility
Communication range
Sensing frequency
Sensing device power
Base station
(car or plane)
Data
ZebraNet
Highly mobile
Miles
Constant sensing
Hundreds of mW
Other Sensor Networks
Static or moderate mobile
Meters
Sporadic sensing
Tens of mW
Software Design Rationales
Question One: System Layering
Applications
Layer 6
Layer 5
Single
Software System
Layer 4
Impala
Layer 3
Layer 2
Hardware
Monolithic approach:
Software modularity
Middle ground
Layer 1
Layered approach:
Layering overhead
Software Design Rationales
Question Two: Middleware Weight
Applications
Applications
Applications
Super-middleware
Mini-Middleware
Hardware
Limited services:
application simplicity
Impala
Hardware
Middle ground
Hardware
Overloaded services:
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
PPoPP 2003:
Adaptation and update
Prototyped on iPAQs
Operation
Scheduler
Event
Filter
Network
Support
This Paper:
Operation, event, network
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
USART
38.4Kbps
Radio
MaxStream 9Xstream
902-928MHz
19.2Kbps over-the-air
0.5-1mile transmit range
Power
Measurement
FLASH
applied)
ATMEL(4.0V
AT45DB041B
SPI
667Kbps
4Mbit
System
Mode
78 days data capacity
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
312.4 mW
GPSreceive
µ-blox GPS-MS1E
Memory
USART  10-20s
position constraint
fix time
38.4Kbps


5V

Power supplies
Charging circuits

Solar modules
Energy constraint
Device access constraint
3.3V
Radio packet
size constraint
GPS sensing time constraint
FLASH storage constraint
Problem 1: Complex Hardware Realities
Solution: Layers and Interfaces
Application 1
Application 2
Application 3
Asynchronous Network Transmission
Protected FLASH Access
Application Timer Control
System Clock Time Read
Adapter
Updater
GPS Data Event Handler
Application Timer Event Handler
Network Packet Event Handler
Network Send Done Event Handler
Operation
Scheduler
Radio
Event
Filter
Network
Support
GPS Data Event
Radio Packet Event
Timer Event
Access and Control to All Devices
CPU
Application 4
GPS
FLASH
Timer
WDT
Memory Footprint of Impala Layers
Code Size
Data Size
2500
70
60
2000
40
Bytes
KB
50
30
1500
1000
20
500
10
0
0
Firmware
Application
Impala
Unused
Firmware
Application
Impala
Unused
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
4 5
3
6
Networking Period
GPS Sensing Period
8
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)
To put CPU on the full-speed clock
3127
To put CPU on the slow clock
38
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
To initiate GPS sensing and set up its finish time
1247
CPU Scheduling
Radio and FLASH
Scheduling
GPS Scheduling
To format GPS data, power off GPS, signal an GPS data event, and
2550
set up the next GPS sensing period
Problem 2: Misc System Activities
Solution (cont.): Handling Irregular Events
Issue One: Event Abstraction
Abstract Application Events
Issue Two: Concurrency
Short / atomic
hardware interrupts
Impala
Idle
Miscellaneous Hardware Interrupts
Long / preemptive
software events
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
Sensor
ACK
Reliable Unicast
Sensor
data
Unreliable Broadcast
data
ACK
data
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
A
B
C
A sends packet 1-8
to B, C, and D
D
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
A sends packet 1-8
D
A
B
C
A gives up C and
sends packet 9-16
D
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
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