1 / 36

Over-the-air Reprogramming of Wireless Sensor Nodes

Over-the-air Reprogramming of Wireless Sensor Nodes. Tom Yeh Haruhisa Yamamoto. Why reprogram?. Reasons for reprogamming Add new functionality Bug fixes Continuing app development Deploy new application. Why over-the-air?. Reasons for over-the-air Hard to physically reach once deployed

baby
Download Presentation

Over-the-air Reprogramming of Wireless Sensor Nodes

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. Over-the-air Reprogrammingof Wireless Sensor Nodes Tom Yeh Haruhisa Yamamoto

  2. Why reprogram? • Reasons for reprogamming • Add new functionality • Bug fixes • Continuing app development • Deploy new application

  3. Why over-the-air? • Reasons for over-the-air • Hard to physically reach once deployed • Time-consuming • Data tempering

  4. 3 parts to Over-the-air programming • What to send? • Entire new binary • Compressed format • Gzip, tar, lzh etc. • Differential commands • How to send it? • Neighborhood-by-neighborhood dissemination • Multicast • ODMRP • How to reprogram? • Decode • Load into program memory

  5. ~ 10 m (Mote) Sensor Node Power Constraint Computation vs Communication Mote-class Node Incoming information Outgoing information Channel Receive electronics Transmit electronics Power amplifier Source : Lecture slide #7

  6. Idea Ver.2 Ver.2 Ver.1 Costly Transmitting entire new program over the air is costly in terms energy. It’s cheaper to send just the differential command that turns old program into new program.

  7. Idea Ver.2 Diff Ver.2 Ver.1 Transmitting entire new program over the air is costly in terms energy. It’s cheaper to send differential commands that turns old program into new program.

  8. Diff Commands Source Destination You want to turn ver.1 into ver.2 Ver. 1 Ver. 2

  9. Diff Scenarios Source Destination • Exactly Same • OS modules Function A Function A Function B Function C v2 Function C • Order changed • Code changed • New function added • Address shifted Function B Data Function D Data Empty

  10. Source 0 Ver. 1 99 Copyfrom 0, length 100 Destination Copy Region eg. Same function used in both code

  11. Repairoffset 50, 2 byte Source Destination Ver. 1 F0 34 50 • Changed function • Changed data Offset from the start address of previous copy or from the end of the last repair

  12. Insert 20 byte Source Destination Ver. 1 eg. Adding new function Append explicit data to the partial file

  13. Diff Commands Source Destination Ver. 1 Ver. 2

  14. Copy Optimization Source Destination 0 Ver. 1 Copy Region 99 Copy Region Insert 100 179 Copy from 0, 100 bytes Insert 50 bytes Copy from 100, 80 bytes

  15. Copy Optimization Source Destination Sending information of starting address cost 2bytes 0 Ver. 1 Copy Region 99 Insert 100 179 Copy Region Copy from 0, 100 bytes Insert 50 bytes Copy from 100, 80 bytes Copy from 0, 100 bytes Insert 50 bytes Copy continue, 80 bytes

  16. Copy Optimization Source Destination 6000 Ver. 1 Copy Region 6050 Insert 6080 Copy Region 6130 Copy from 6000, 50 bytes Insert 30 bytes Copy from 6080, 50 bytes

  17. 6000: 0x1770 6080: 0x17C0 MSB is same Now, only 1 byte Copy Optimization Source Destination Do we need 2 bytes? 6000 Ver. 1 Copy Region 6050 Insert 6080 Copy Region 6130 Copy from 6000, 50 bytes Insert 30 bytes Copy from 6080, 50 bytes Copy from 6000, 50 bytes Insert 30 bytes Copy reuse 0xC0, 50 bytes

  18. Source Destination Ver. 1 Ver. 2 Function Granular Compares

  19. Source Destination Function A Function A Function B Function C v2 Function C Function B Data Function D Data Function Granular Compares

  20. Sample Status File

  21. Differential Reprogramming • Diff original & new application binaries • Effectively compresses new binary using entire original binary and parts of new • Function granular comparisons • Optimized linking of diff segments • Address patching • Energy cost calculation • Enable different diff implementations • Unix diff • Do as much optimization on PC side as possible

  22. Generating diff script • Function level compare by unix diff • Match based on byte cost and instruction complexity calculation • Assuming energy of 200 ops = energy 1 bit transmission • If names match && same binary * Copy from begin to end • If name match && diff script cost < threshold (75%) * Use diff script • If diff script cost >= threshold or no name match * Diff with all other functions * Find best match based on cost/complexity • If all scripts’ cost > # of bytes in function * Insert entire function

  23. File diff from appending local diff’s funcA: copy from 0, 200B repair offset 29, 1B repair offset 48, 2B funcB: copy from 200, 150B repair offset 48, 2B funcC: insert 10B copy 360 100B Optimized linking copy from 0, 450B repair offset 29, 1B repair offset 48, 2B repair offset 168, 2B repair offset 100, 10B Generating diff script • Optimized linking to generate final diff script

  24. Repair Repair Repair Repair Address Patch Source Destination 100 Function A Function B Copy 200 500 Function A Function B 600 Call 100 +100 Call 100 Costly Call 200 +100 Call 200 Jump100 +100 Jump 100 patch Call 100 +100 Call 100 Function C Function C Copy

  25. Address Patch Source Destination 100 Function A Function B Copy 200 500 Function A Function B 600 Call 100 Call 200 Copy Call 200 Call 300 Jump100 Jump 200 patch Call 100 Call 200 Function C Function C

  26. jump or call? jump or call? In the table? jump or call? jump or call? In the table? jump or call? jump or call? Cost of Patch On every copy…. Copied Region Compare Table lookup Add offset add add call call 800 800 jump jump 130 230 130 load load # of copied Instruction # of jump & call X Entries in Table # of actual patch

  27. Cost of Patch • Approximate cost • Calculate save Each successful patch replaces a 2-byte repair 2-byte repair costs 3bytes of transmission save = 3 * actual patches • If cost of patch > save from patch • Delete the patch entry

  28. diff generator binary converter decoder Comparison Normal Flow src.cxx src.cxx dest.cxx dest.cxx src.bin src.bin dest.bin dest.bin dest.bin final diff script final diff script final diff script verification dest.bin verification dest.bin Final diff binary Match!

  29. Normal Flow Demo!!

  30. diff generator address patch diff generator Complete diff Script Address Patch Flow src.cxx src.cxx dest.cxx dest.cxx dest.cxx initial diff script initial diff script patch list newSrc.cxx newSrc.cxx final diff script

  31. Address Patch Flow Demo!!

  32. Test Cases and Performace Data

  33. Future Work • Decoder on motes • Decoder available right now on PC side. • Connect to dissemination application • Enhance encoder compression • Try different diff algorithms • Try simple compression schemes • Add support for address patching more instructions • Optimize speed • More thorough analysis of data • Fix encoder 2 corner case bugs • errors isolated in the repair conversion in postprocess subroutine. • Fix address patch errors • output format differs from parser expectation

  34. Hardware Enhancement • More energy efficient processor may allow complicated compression schemes to be applied. • Currently use ATMega128L: 242 MIPS/W @ 4MHz( 4nJ/Instruction) • 480 MIPS/W for ARM Thumb @ 40 MHz (2.1 nJ/Instruction) • 0.2 nJ/Instruction for Cygnal C8051F300 @ 32KHz, 3.3V • 0.35 nJ/Instruction for IBM 405LP @ 152 MHz, 1.0V • 0.8 nJ/Instruction for TMS320VC5510 @ 200 MHz, 1.5V • 1.1 nJ/Instruction for Xscale PXA250 @ 400 MHz, 1.3V • Memory map instructions and data to specific regions – helps to avoid false patches. • Dedicated hardware decoder for complex compression scheme. • This may also be used for packet data compression.

  35. References • Reijers N., K. Langendoen, “Efficient Code Distribution in Wireless Sensor Networks,” 2nd ACM Int. Workshop on Wireless Sensor Networks and Applications (WSNA '03), San Diego, CA, USA, September 2003. • Stathopoulos Thanos, John Heidemann, & Deborah Estrin, “Multi-hop Code Distribution for Sensor Networks” CENS First Annual Research Review Poster & Demonstration Event October 10, 2003. • TinyOS http://webs.cs.berkeley.edu/tos/ • AVR Instruction Set for ATMega128L http://www.atmel.com/dyn/resources/prod_documents/DOC0856.PDF • Motorola SREC format http://www.amelek.gda.pl/avr/uisp/srecord.htm • Lee, S.-J., W. Su, and M. Gerla, "On-Demand Multicast Routing Protocol in Multihop Wireless Mobile Networks," ACM, 2000. • D. Gusfield. Algorithms on Strings, Trees and Sequences, chapter 6.1: Linear-Time Construction of Suffix Trees, Ukkonen’s linear-time suffix tree algorithm. Cambridge University Press, June 1997. • G. A. Stephen. String searching algorithms. In D.T. Lee, editor, Lectures Notes Series on Computing, volume 3, chapter 3, String Distance and Common Sequences, pages 39–86. World Scientific, Singapore, 1994.

More Related