ppt

465 views
377 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
465
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

ppt

  1. 1. Incremental Network Programming for Wireless Sensors IEEE SECON 2004 Jaein Jeong and David Culler UC Berkeley, EECS
  2. 2. Introduction – Programming a Large Sensor Network <ul><li>Program is developed in the host and loaded to sensors. </li></ul><ul><li>In system Programming </li></ul><ul><ul><li>Programming time increases in proportion to # nodes. </li></ul></ul><ul><li>Network Programming </li></ul><ul><ul><li>Saves programming time. </li></ul></ul><ul><ul><li>But, sending whole code over radio still takes time. </li></ul></ul><ul><li>Goal: reduce programming time by sending the code difference. </li></ul>Host Machine Program Code Sensor node Serial or parallel port In system programming Network programming Host Machine Program Code Radio Channel Sensor nodes …
  3. 3. Network Programming Steps <ul><li>Incremental network programming </li></ul><ul><ul><li>(1) Encoding: Generates the difference of the two code. </li></ul></ul><ul><ul><li>(2) Dissemination: Transmits the difference. </li></ul></ul><ul><ul><li>(3) Decoding: Rebuilds the new code using the old code and diff. </li></ul></ul>Dissemination Data Host Machine Sensor Node (1) Encode (2) Dissemination (3) Decode Sensor node User app SREC file Radio Packets External Flash User Application Section Boot loader Section Host Machine
  4. 4. Design Considerations <ul><li>Reduce the amount of transmission. </li></ul><ul><ul><li>Network programming keeps a large amount of data. </li></ul></ul><ul><ul><li>Programming time is proportional to the data size. </li></ul></ul><ul><li>Minimize the access to the external flash memory. </li></ul><ul><ul><li>The program code is stored in the external memory . </li></ul></ul><ul><ul><li>T he external flash is slower than the on-chip memory. </li></ul></ul><ul><li>Avoid expensive operations for sensor nodes. </li></ul>
  5. 5. Difference Generation – First Approach: Fixed Block Comparison <ul><li>Storage Organization </li></ul><ul><ul><li>Two memory chunks for the previous and new program. </li></ul></ul><ul><li>Fixed Block Comparison </li></ul><ul><ul><li>Compares in fixed sized blocks. </li></ul></ul><ul><ul><li>Doesn’t work when code is shifted. </li></ul></ul><ul><li>Comparing at every byte: </li></ul><ul><ul><li>Finds shared blocks with high cost. </li></ul></ul><ul><li>Need an efficient way of finding shared blocks even with the shift. </li></ul>External Flash L bytes Previous Image Program Memory Boot loader section New Image For others L bytes L bytes B bytes B bytes B bytes Remaining Previous Program Image New Program Image B bytes B bytes B bytes =? n bytes shift insert
  6. 6. Difference Generation – Using Rsync algorithm <ul><li>How can we find shared blocks efficiently? </li></ul><ul><ul><li>Checksum of a block doesn’t change even for code shift. </li></ul></ul><ul><ul><li>Cheaper than comparing the whole block. </li></ul></ul><ul><ul><li>Idea of Rsync algorithm. </li></ul></ul>Modified … … Original Program Image … … Program Image Code Shift = =
  7. 7. Difference Generation – Using Rsync algorithm <ul><li>Use two level hash (checksum, hash)! </li></ul><ul><li>(1) Build hash table for previous image. </li></ul><ul><li>(2) For a block of new image, calculate checksum. </li></ul><ul><li>(3) Lookup hash table. </li></ul><ul><ul><li>For a matching checksum, calculate hash. </li></ul></ul><ul><ul><li>Otherwise, move to the next byte and repeat (2). </li></ul></ul>New Program Image Previous Program Image (R0, H0) (R1, H1) (Checksum, Hash) (R2, H2) (R5, H5) (R6, H6) (R4, H4) Hash Table (R3, H3) Insert hash Look up hash Copy Copy Download Copy Copy Copy matching n on - matching Copy Difference … … … … … … … …
  8. 8. Dissemination – Modified Rsync for Wireless Sensors <ul><li>Original Rsync algorithm </li></ul><ul><ul><li>Receiver scans binary data and calculates checksums. </li></ul></ul><ul><ul><li>Expensive for sensor nodes. </li></ul></ul><ul><li>Our modification </li></ul><ul><ul><li>Assumes the host knows code history of sensor nodes. </li></ul></ul><ul><ul><li>Avoids overhead on sensors. </li></ul></ul>Sender Receiver (1) Asks which blocks the receiver has. (2) Sends list of checksums for the blocks. (3a) Sends the difference. (4) Rebuilds the latest version (3) Compares the latest version with checksums. Original Rsync algorithm Sender Receiver (3) Sends the difference. (4) Rebuilds the latest version (1) Calculates the checksums. (2) Generates the difference Modified Rsync algorithm
  9. 9. Difference Msgs & Program Rebuild <ul><li>Host sends difference as a sequence of messages. </li></ul><ul><ul><li>Non-matching block  Download </li></ul></ul><ul><ul><li>Matching block  Copy </li></ul></ul><ul><li>Sensor rebuilds new image using the diff. </li></ul><ul><li>Performance Optimization </li></ul><ul><ul><li>Copy blocks are aligned to the beginning of flash memory records. </li></ul></ul>Previous Program Image New Program Image copy download copy Copy Download Download Copy Difference Message download
  10. 10. Experiment Setup <ul><li>Test Applications </li></ul><ul><ul><li>Simple network programmable app: XnpBlink and XnpCount . </li></ul></ul><ul><ul><li>XnpBlink : blinks LED. </li></ul></ul><ul><ul><li>XnpCount : counts number and outputs to LED and radio. </li></ul></ul><ul><li>Test Scenarios </li></ul><ul><ul><li>Case 1: Changing a constant ( XnpBlink ) </li></ul></ul><ul><ul><li>Case 2: Modifying implementation file ( XnpCount ) </li></ul></ul><ul><ul><li>Case 3: Major change ( XnpBlink  XnpCount ) </li></ul></ul><ul><ul><li>Case 4 and 5: Modifying configuration file ( XnpCount ) </li></ul></ul>
  11. 11. Results – Using Rsync <ul><li>Compared transmission time with non-incremental delivery. </li></ul><ul><li>Fixed Block Comparison: Almost no speedup except for case 1. </li></ul><ul><li>Using Rsync algorithm: </li></ul><ul><ul><li>Speed up of 2 to 2.5 for a small change (case 2 and 4). </li></ul></ul><ul><ul><li>Still limited speed up for big changes (case 3 and 5). </li></ul></ul>0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 Case 1 Case 2 Case 3 Case 4 Case5 Speed up Estimated Speed Up (Fixed) Measured Speed Up (Fixed) Estimated Speed Up (Rsync) Measured Speed Up (Rsync)
  12. 12. Problems: Difference Delivery still not optimal <ul><li>Difference is decoded without being stored. </li></ul><ul><li>Size of copy msg is limited to bound running time. </li></ul><ul><ul><li>May send unnecessarily many copy messages. </li></ul></ul><ul><li>Requests retransmission of all the records for a missing copy message. </li></ul>
  13. 13. Optimizing Difference Delivery <ul><li>Solution: Separate difference delivery and decoding. </li></ul>(1) Stores the difference script in the first step (2) Rebuilds the program after receiving decode command. Previous Program Image New Program Image CMD_DOWNLOADING Copy Download Download Copy Script Commands Previous Program Image New Program Image download copy Copy Download Download Copy Script Commands download CMD_DECODE_SCRIPT
  14. 14. Results – Using Rsync with separate decode <ul><li>The performance of using Rsync algorithm with separate decode command is similar to just using Rsync. </li></ul><ul><li>But, the performance for changing a constant has improved (speed up of 9.1). </li></ul>0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.00 Case 1 Case 2 Case 3 Case 4 Case5 Speedup Fixed Block Comparison Rsync Rsync + decode
  15. 15. Previous Work <ul><li>XNP: TinyOS 1.1 network programming implementation. </li></ul><ul><ul><li>Supports code dist. / reprogramming, but not incremental update. </li></ul></ul><ul><li>Reijers et al ( Delft Univ. of Tech., Netherlands) / Kapur et al (UCLA) </li></ul><ul><ul><li>Generates the incremental code update at instruction level. </li></ul></ul><ul><ul><li>But the algorithm depends on instruction set of a specific platform. </li></ul></ul><ul><li>Maté / Trickle (UC Berkeley) </li></ul><ul><ul><li>G enerates the virtual machine code, not the native code. </li></ul></ul><ul><li>Our incremental network programming approach </li></ul><ul><ul><li>Generates the code difference using the Rsync algorithm. </li></ul></ul><ul><ul><li>No assumption of code structure. Platform independent solution. </li></ul></ul>
  16. 16. Conclusion <ul><li>We extended TinyOS network programming implementation for incremental update. </li></ul><ul><li>We used Rsync algorithm to encode / decode program code difference. </li></ul><ul><li>Over non-incremental delivery, we’ve achieved </li></ul><ul><ul><li>Speedup of 2 – 2.5 for changing a few lines. </li></ul></ul><ul><ul><li>Speedup of 9.1 for changing a constant. </li></ul></ul>

×