1. Phil Buonadonna, Jason Hill CS-268, Spring 2000 MOTE Active Messages Communication Architectures for Networked Mini-Devices Networked sub-devicesActive Messages Paradigm for efficient overlap of computation and communication Centered on lightweight RPC mechanism –2-phase request-reply model –Credit based flow control Using the AM model Implement and investigate an Active Messages based communication abstraction for a wireless network of sub- devices. The Problem: –Limited computational ability & energy supply –Complex, dynamic network paths with potentially high fanout –Lossy wireless communications Round Trip Time The Study Analysis Active Message Model Sample Application & Future Work We leverage aspects of the Active Messages model to address these problems –Good small message performance –Natural paradigm for requesting sensor data –Minimizes memory resources required What is a sub-device? –Small (I.e. 2x2 and smaller) –Onboard processor and communication device (e.g IR, Radio) –Self-contained power source (e.g. Battery, Solar) Mote (mOt) noun : a small particle –A sub-device with attached sensor(s). Autonomous Sensor Node. 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 General Mote Architecture The weC Mote Throughput –~800 Bytes/sec (~6.5 Kbps) w/ 4b6 encoding Software Footprint Power consumption (sleep & idle states) Event Model –Supports high conncurrency w/ minimal buffer requirements –Prevents multiple & deep stacks Drawbacks –Its not IP! Route discovery application: –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 Mote Active Messages –One endpoint per mote. One endpoint for host. –Binary credit scheme (single host request credit) Ensures no overload of Mote resources Allows trivial retransmission scheme (assuming idempotency) We assume a collision resistant MAC layer –Message Handlers: 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 Active Messages defines the OS architecture for the Mote Routing –First 9 bytes of message are used to implement a source based route path. First 2 bytes are ALWAYS a Destination/Handler pair ( R 0/ H 0 ) –Handler 0 forwards to the next hop. Will insert the destination handler (H f ) 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) The AM Mote Message RTT vs. # of Hops RTT breakdown 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 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. We demonstrate –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 Future Work –Layer AM over different MAC layers –Dynamic uploading of handler functions. –Comparison with other communication models –Examination of other routing schemes Screen Shot of Routing Application