Reliable Multi-hop Firmware Upload Protocol for mica2 motes. CSE 534 Advanced Networks Dmitri Lusnikov Fall 2004

Motivation Current situation:  Sensor network are application specific  Nodes are hard-wired to perform a specific task Problem:  Many details only become obvious after the deployment. Changes in the environment and the application. Scalability, expansion of the network. Testing and debugging cycle

Goal Flexible sensor node hardware suitable for most sensor network applications. Capability for re-tasking on location.  In network reprogramming.  No need for redeployment.

Hardware MICA2 Hardware resources:  Atmel ATmega128L microcontroller:  Internal flash: 128KB  External flash: 512KB  Configuration EEPROM: 4KB  SRAM: 4KB Possibility to program the internal flash memory with data from external flash.

Current Approaches XNP Application  Simple java program from TinyOS distribution. Deluge Protocol  Software package designed specifically for in- network re-tasking of mica motes.  Will be released as part of TinyOS PSFQ Protocol  Research effort to develop an efficient data dissemination protocol for sensor networks.

XNP Application Very basic functionality:  No multi-hop.  No error correction, reliability of transmission techniques.  No image validation (CRC).

Deluge protocol Integrated Solution  Multi-hop routing  “Epidemic Propagation”  Reliability through ARQ, CRC  Golden Image Transport protocol influenced by PSFQ

Pump Slowly, Fetch Quickly Protocol (PSFQ) Data dissemination protocol.  Good for multicast. Pump Slowly:  Data is injected at base station at regular time intervals.  Allow time for propagation, packet loss recovery. Fetch Quickly:  In case of packet loss, data is fetched from neighboring nodes.

Problem ARQ schemes are inefficient for large data dissemination in sensor networks. Noisy communication channels:  Big increase in communication overhead with high packet loss rates. Multi-hop communication:  Big latency, low throughput on lengthy slow communication channels. Multicast:  High traffic incident at the source node.

Proposed Solution Rateless Forward Error Correction.  Low overhead in case of packet loss.  Unidirectional communication.  Great for multicast.

Background: Fountain Codes Idea:  Imagine filling a cup of water form a fountain. You do not care what exact drops of water get inside the cup, it is only important that a cup gets full. Two Properties: 1) A source can generate a potentially infinite supply of encoding packets from the original data. 2) A receiver can reconstruct a message of k packets in size, once any k encoding packets have been received.

Background: LT Codes First practical realization of rateless codes.  (published in 2002). Encoding: 1) Choose a degree d for the encoding symbol, according to a predetermined distribution. 2) Choose d distinct message symbols uniformly at random. 3) XOR all chosen symbols to produce the encoding symbol.

LT Codes (Continued) Main factor of decoding performance is the degree distribution.  Example: p(1) = 1 k * ln(k) packets needed.  Soliton distribution k + ε packets needed. O(k * ln(k)) decoding time.

LT Codes (Continued) Problems:  Degree is not constant. Decoding time for a single encoded packet is not known. Buffer size is not known. Can be up to the size of entire message. Does not fit into mica2 RAM.  Decoding time is O(k * ln(k)) Hard to decode packets on the fly.

Background: Raptor Codes Extend the idea of LT codes. Pre-code the message by encoding it with a fixed erasure code. (e.g. Tornado codes) Now, no need to recover all packets, just a constant fraction of packets. Consequence:  Degree can be bound by a constant.  Decoding time is linear.

Design: Base Station Components:  TOSBase  SerialForwarder  Control program in Java. No strict limitations for computational resources and energy consumption.  Favor asymmetric protocols that offload processing from the motes.

Design: Sensor Nodes Transport protocol:  Delivers program image.  Interacts with network protocol stack.  Verifies data integrity. Control program:  Integrates into primary application.  Application layer of protocol stack.  Handles control messages.  Puts mote into reprogramming mode.  Saves/restores TinyOS state. Boot time reprogramming routine:  Internal OS component.  Programs microcontroller flash memory.  Can choose between several boot images (e.g. Golden Image)

Network Protocol Stack Link Layer  ActiveMessage protocol. Routing  TinyOS multi-hop routing component.  Controlled flood.  Single node addressing by 16 bit mote ID.  Multicast using 8 bit group ID. Transport  Custom implementation using rateless FEC. addr 16bit type 8bit group 8bit length 8bit data 232bit crc 16bit

Implementation Development using TOSSIM. Problems with LT codes implementation. “All-At-Once distribution”: p(1) = 1 Packet format:  16 bit fragment number.  27 bytes data. ACK when entire image is received.

Results Current implementation:  Requires average of k*ln(k) packets.  Efficient for single hop communication. Transmit: 81mW Receive/Idle: 30mW  Slower than Deluge.

Future Work Implement transport protocol using Raptor codes. Compare performance with Deluge, PSFQ, XPN.

Conclusion Implementing rateless FEC in sensor nodes is hard, but not impossible. Great solution for multi-hop multicast and large data transfers. In-network reprogramming is awesome.

References Deluge: Dissemination Protocols for Network Programming at Scale Adam Chlipala, Jonathan W. Hui, and Gilman Tolle. Fall Advisor: Prof. David E. Culler, University of California, Berkeley. PSFQ: A Reliable Transport Protocol For Wireless Sensor Networks C. Y. Wan, A. T. Campbell, and L. Krishnamurthy. Proceedings of the First ACM International Workshop on Wireless Sensor Networks and Applications (WSNA 2002). LT codes. Michael Luby. In The 43rd Annual IEEE Symposium on Foundations of Computer Science, Raptor codes A. Shokrollahi. Preprint Available online at

Questions ?