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

Base station
(car or plane)

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
Applications

Layer 6
Layer 5

Single
Software System

Impala

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

Mini-Middleware
Hardware
Limited services:
application simplicity

Applications

Impala

Hardware
Middle ground

Applications

Super-middleware

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
USART 10-20s
positionconstraint
fix time
Memory
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

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
3

Networking Period

GPS Sensing Period

Sleep Period

CPU wake up/Radio, FLASH power on

GPS power on

Radio transmitting / receiving start

GPS sensing time

Network communication time

GPS power off / FLASH power on

Radio power off/FLASH power off

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

To format GPS data, power off GPS, signal an GPS data event, and
set up the next GPS sensing period

2550

CPU Scheduling

Radio and FLASH

Scheduling

GPS Scheduling

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

A sends packet 1-8

to B, C, and 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

A sends packet 1-8

A gives up C and
sends packet 9-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

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