No Slide Title

Download Report

Transcript No Slide Title

MOTE Active Messages
Communication Architectures for Networked Mini-Devices
Phil Buonadonna, Jason Hill
CS-268, Spring 2000
The Study
Networked sub-devices
• Implement and investigate an Active Messages based
communication abstraction for a wireless network of “subdevices”.
• The Problem:
• What is a sub-device?
– Small (I.e. 2”x2” and smaller)
– Onboard processor and communication device (e.g IR, Radio)
– Self-contained power source (e.g. Battery, Solar)
– Limited computational ability & energy supply
– Complex, dynamic network paths with potentially high fanout
– Lossy wireless communications
• Mote (‘mOt) noun : a small particle
– A sub-device with attached sensor(s). Autonomous Sensor Node.
• Paradigm for efficient overlap of computation and
communication
Proc A
• Centered on lightweight RPC
Request
mechanism
Request Handler
– 2-phase request-reply model
– Credit based flow control
• Mote Active Messages
• We leverage aspects of the Active Messages model to
address these problems
Proc B
Reply
Reply Handler
Active Message Model
– One endpoint per mote. One endpoint for host.
– Binary credit scheme (single host request credit)
– Good small message performance
– Natural paradigm for requesting sensor data
– Minimizes memory resources required
• Ensures no overload of Mote resources
• Allows trivial retransmission scheme (assuming idempotency)
• We assume a collision resistant MAC layer
– Message Handlers:
• We demonstrate
–
–
–
–
Active Messages
A mote and host based library
A handler software design methodology based on events
A simple routing methodology
78 msec RTT (mote-mote), ~800 B/sec throughput
General Mote Architecture
• The weC Mote
–
–
–
–
ATMEL 8535 Microcontroller (4Mhz, 512B SRAM, 8KB Flash)
Communication: RF (916.5 MHz), 10Kbps raw
Sensors: Light, Temperature
Features: Wireless reprogramming, 3 LEDs
Using the AM model
Analysis
– First 9 bytes of message are used to implement a source based
route path.
• First 2 bytes are ALWAYS a Destination/Handler pair (R0/ H0)
– Handler 0 forwards to the next hop. Will insert the destination
handler (Hf) ID on the last hop (N = 1)
– Routing information is preserved so that replies can be sent along
the same path to the requestor (S)
R0 H0 N Hf R1 R2 R3 R4 S D0 D1
...
The AM Mote Message
• Host Communication
– PC Host has a reserved address (0x7e)
– Can connect to any mote in the ‘school’ through an onboard
connector. Mote connected to a host is the ‘base station’ mote.
• Route discovery application:
400
350
First bit of
request on mote
Last bit of
request on mote
First bit of reply
sent from mote
Last bit of reply
sent from mote
First bit of next
request on mote
300
250
200
150
100
50
Time (msec)
0
15.6
16.4
31.8
54.5
0
0
1
2
3
Hops
4
5
6
– Nearest neighbor with a single, static
root (the base station mote)
– Each mote broadcasts a beacon every 1
second
– Neighbor mote responds if it knows how
to get to base station
– Beacons propagate to base-station/host
RTT breakdown
RTT vs. # of Hops
• Throughput
– ~800 Bytes/sec (~6.5 Kbps) w/ 4b6 encoding
• Software Footprint
• Power consumption (sleep & idle states)
• Broadcast
– Motes & Host can send broadcast messages through an endpoint
using a reserved destination address (255)
– Broadcast requests do not invoke credit scheme.
– Permits a method of route discovery
• Active Messages defines the OS architecture for the Mote
Sample Application & Future Work
• Round Trip Time
RTT (msec)
• Routing
• Mote handlers can initiate/propagate further requests depending on the
applications needs.
• Handler names are static and globally unique. Two special handlers:
– Handler 0: A routing handler
– Handler 255: Lists installed handlers
• Mote handlers invoked through events, not polling
• Dispatch routines generated at compile time
The weC Mote
• Event Model
– Supports high conncurrency w/ minimal buffer requirements
– Prevents multiple & deep stacks
• Drawbacks
– Its not IP!
• Future Work
–
–
–
–
Screen Shot of Routing
Application
Layer AM over different MAC layers
Dynamic uploading of handler functions.
Comparison with other communication models
Examination of other routing schemes