Reliable Multihop Firmware Upload Protocol for mica2 motes.

1
Reliable Multi-hop Firmware Upload Protocol for
mica2 motes.

• CSE 534 Advanced Networks
• Dmitri Lusnikov
• Fall 2004

2
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

3
Goal

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

4
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.

5
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.

6
XNP Application

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

7
Deluge protocol

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

8
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.

9
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.

10
Proposed Solution

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

11
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
• A source can generate a potentially infinite
  supply of encoding packets from the original
  data.
• A receiver can reconstruct a message of k packets
  in size, once any k encoding packets have been
  received.

12
Background LT Codes

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

13
LT Codes (Continued)

• Main factor of decoding performance is the degree
  distribution.
• Example p(1) 1
• k ln(k) packets needed.
• Soliton distribution
• k e packets needed.
• O(k ln(k)) decoding time.

14
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.

15
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.

16
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.

17
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)

18
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.

19
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.

20
Results

• Current implementation
• Requires average of kln(k) packets.
• Efficient for single hop communication.
• Transmit 81mW
• Receive/Idle 30mW
• Slower than Deluge.

21
Future Work

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

22
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. ?

23
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 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, 2002.
• Raptor codes
• A. Shokrollahi. Preprint 2002. Available online
  at
• http//algo.epfl.ch/index.php?poutput_pubs_XXdb
  pubs/pubs_fountain.txt

24
Questions ?