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 1.1.8

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 ScaleAdam Chlipala, Jonathan W. Hui, and Gilman Tolle. Fall 2003.Advisor: Prof. David E. Culler, University of California, Berkeley.

PSFQ: A Reliable Transport Protocol For Wireless Sensor NetworksC. 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, 2002.

Raptor codesA. Shokrollahi. Preprint 2002. Available online athttp://algo.epfl.ch/index.php?p=output_pubs_XX&db=pubs/pubs_fountain.txt

Questions ?