Implementing Software on Resource-Implementing Software on Resource-Constrained Mobile Sensors: Constrained Mobile Sensors:

Experience with Impala and ZebraNetExperience 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 ZebraNet: Fusing Mobile Computing and Sensor Systemsand Sensor Systems

DataBase station (car or plane)

Data

Data

Store-and-forward communications

Data

Tracking node with CPU, FLASH, radio and GPS

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 RationalesSoftware Design Rationales

Layer 1

Layer 2

Layer 3

Layer 4

Layer 5

Layer 6

Layered approach:

Question One: System Layering

SingleSoftware System

Monolithic approach:Software modularity Layering overhead

Hardware

Impala

Applications

Middle ground

Software Design RationalesSoftware Design Rationales

Limited services: Overloaded services:

Question Two: Middleware Weight

application simplicity Middleware overhead

Hardware

Impala

Applications

Middle ground

Hardware

Mini-Middleware

Applications

Hardware

Super-middleware

Applications

Impala OverviewImpala Overview

Adapter UpdaterNetworkSupport

OperationScheduler

EventFilter

Application modularity, simplicity, adaptivity and repairability

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

Adapter UpdaterNetworkSupport

OperationScheduler

EventFilter

Application modularity, simplicity, adaptivity and repairability

Prototyped on iPAQs

PPoPP 2003:Operation, event, network

This Paper:Adaptation and update

Implemented on ZebraNet node

RoadmapRoadmap

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

Memory constraint Energy constraint Device access constraint Radio packet size constraint GPS sensing time constraint FLASH storage constraint

MicrocontrollerMicrocontrollerTI MSP430F149

16-bit RISC2KB RAM

60KB ROM8MHz/32KHz dual clock

FLASHFLASHATMEL AT45DB041B

4Mbit78 days data capacity

GPSGPSµ-blox GPS-MS1Eµ-blox GPS-MS1E

10-20s position fix time10-20s position fix time

RadioRadioMaxStream 9Xstream

902-928MHz19.2Kbps over-the-air

0.5-1mile transmit range

Power suppliesPower supplies

SPI667Kbps

USART38.4Kbps

USART38.4Kbps

Solar modulesSolar modules

5V 3.3V

Charging circuitsCharging circuits

Hardware Design and ConstraintsHardware Design and Constraints

System ModeSystem Mode PowerPowerCPU 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

Power Measurement Power Measurement (4.0V applied)(4.0V applied)

Problem 1: Complex Hardware Realities Problem 1: Complex Hardware Realities Solution: Layers and InterfacesSolution: Layers and Interfaces

Radio GPS FLASH TimerCPU WDT

Access and Control to All Devices

Application 1 Application 2 Application 3 Application 4

GPS Data EventRadio Packet EventTimer Event

Asynchronous Network TransmissionProtected FLASH AccessApplication Timer Control

GPS Data Event HandlerApplication Timer Event HandlerNetwork Packet Event HandlerNetwork Send Done Event HandlerSystem Clock Time Read

Adapter UpdaterNetworkSupport

OperationScheduler

EventFilter

Memory Footprint of Impala LayersMemory Footprint of Impala Layers

Code Size

0

10

20

30

40

50

60

70

KB

Firmware ImpalaApplication Unused

Data Size

0

500

1000

1500

2000

2500

Byt

es

Firmware ImpalaApplication Unused

Problem 2: Misc System Activities Problem 2: Misc System Activities Solution: Regular Operation SchedulingSolution: Regular Operation Scheduling

4 51 2

3

7 8

6

Networking Period GPS Sensing Period Sleep Period

1 CPU wake up/Radio, FLASH power on

2 Radio transmitting / receiving start

3 Network communication time

4 Radio power off/FLASH power off

5 GPS power on

6 GPS sensing time

7 GPS power off / FLASH power on

8 CPU sleep / FLASH power off

GPS-aided operation synchronization Prohibited simultaneous device operations Non-trivial radio wake-up time Potentially long GPS sensing time Stringent energy budget

Operation Scheduling OverheadOperation Scheduling Overhead

Scheduling Type Impala ActivityTime

(cycles)

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

Problem 2: Misc System Activities Problem 2: Misc System Activities Solution (cont.): Handling Irregular EventsSolution (cont.): Handling Irregular Events

Impala

Abstract Application Events

Miscellaneous Hardware Interrupts

Issue One: Event Abstraction

Short / atomic hardware interrupts

Long / preemptive software events

Idle

Issue Two: Concurrency

High Priority Events

Low Priority Events

EventEventSignalerSignaler

EventEventHandlerHandler

Issue Three: Event Prioritization

Problem 3: Special Communication Needs Problem 3: Special Communication Needs Solution: Message Models and SessionsSolution: 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

data

Sensor

Sensor

data

Reliable UnicastReliable Unicast

Reliable MulticastReliable Multicast

ACK

data

Unreliable BroadcastUnreliable Broadcast

Sensor

ACK

Problem 4: Limited Comm Resources Problem 4: Limited Comm Resources Solution: Unified MAC &Transport ControlSolution: Unified MAC &Transport Control

A sends packet 1-8

A B C D A B C D A B C D

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

A sends packet 1-8 to B, C, and D

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

A gives up C and sends packet 9-16

B acks packet 9-16 C acks packet 1-4 D acks packet 9-16

ZebraNet Status and Next StepsZebraNet 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

ConclusionsConclusions

Propose and implement Impala middleware model Solutions for hardware constraints and app req Concrete experience with real system and application

Hardware

Impala

Applications

Simple layering and rich services