1 / 24

Reliable Multi-hop Firmware Upload Protocol for mica2 motes.

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:

isaura
Download Presentation

Reliable Multi-hop Firmware Upload Protocol for mica2 motes.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 + ε 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. addr 16bit type 8bit group 8bit length 8bit data 232bit crc 16bit 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 k*ln(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?p=output_pubs_XX&db=pubs/pubs_fountain.txt

  24. Questions ?

More Related