1 / 16

Incremental Network Programming for Wireless Sensors

Incremental Network Programming for Wireless Sensors. IEEE SECON 2004 Jaein Jeong and David Culler UC Berkeley, EECS. Sensor node. Serial or parallel port. Program Code. In system programming. Sensor nodes. …. Radio Channel. Host Machine. Host Machine. Program Code.

spriggsj
Télécharger la présentation

Incremental Network Programming for Wireless Sensors

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. Incremental Network Programming for Wireless Sensors IEEE SECON 2004 Jaein Jeong and David Culler UC Berkeley, EECS

  2. Sensor node Serial orparallelport ProgramCode In system programming Sensor nodes … RadioChannel HostMachine HostMachine ProgramCode Network programming Introduction – Programming a Large Sensor Network • Program is developed in the host and loaded to sensors. • In system Programming • Programming time increases in proportion to # nodes. • Network Programming • Saves programming time. • But, sending whole code over radio still takes time. • Goal: reduce programming time by sending the code difference.

  3. User Application Section Boot loader Section HostMachine External User app Radio SREC file Packets Flash Network Programming Steps • Incremental network programming • (1) Encoding: Generates the difference of the two code. • (2) Dissemination: Transmits the difference. • (3) Decoding: Rebuilds the new code using the old code and diff. Host Machine Sensor Node (1) Encode (2) Dissemination (3) Decode Dissemination Data Sensor node

  4. Design Considerations • Reduce the amount of transmission. • Network programming keeps a large amount of data. • Programming time is proportional to the data size. • Minimize the access to the external flash memory. • The program code is stored in the external memory. • The externalflash is slower than the on-chip memory. • Avoid expensive operations for sensor nodes.

  5. Boot loadersection ProgramMemory Forothers L bytes L bytes L bytes PreviousImage NewImage ExternalFlash New Program Image Previous Program insert Image =? B bytes B bytes n bytes shift B bytes B bytes B bytes B bytes Remaining Difference Generation –First Approach: Fixed Block Comparison • Storage Organization • Two memory chunks for the previous and new program. • Fixed Block Comparison • Compares in fixed sized blocks. • Doesn’t work when code is shifted. • Comparing at every byte: • Finds shared blocks with high cost. • Need an efficient way of finding shared blocks even with the shift.

  6. Original Modified = = … Program Image Program Image … CodeShift … … Difference Generation –Using Rsync algorithm • How can we find shared blocks efficiently? • Checksum of a block doesn’t change even for code shift. • Cheaper than comparing the whole block. • Idea of Rsync algorithm.

  7. New Previous Hash Table Program Program (Checksum, Hash) Image Image … … … Difference Look up hash Insert hash (R0, H0) … (R1, H1) (R2, H2) Copy (R3, H3) Copy (R4, H4) Copy (R5, H5) Download (R6, H6) Copy … Copy … … Copy matching … non-matching Difference Generation –Using Rsync algorithm Use two level hash (checksum, hash)! (1) Build hash table for previous image. (2) For a block of new image, calculate checksum. (3) Lookup hash table. • For a matching checksum, calculate hash. • Otherwise, move to the next byte and repeat (2).

  8. Receiver Sender (1) Asks which blocksthe receiver has. (2) Sends list of checksumsfor the blocks. (3) Compares the latest version with checksums. (3a) Sends the difference. (4) Rebuildsthe latest version Original Rsync algorithm Receiver Sender (1) Calculatesthe checksums. (2) Generates the difference (3) Sends thedifference. (4) Rebuilds the latest version Modified Rsync algorithm Dissemination –Modified Rsync for Wireless Sensors • Original Rsync algorithm • Receiver scans binary data and calculates checksums. • Expensive for sensor nodes. • Our modification • Assumes the host knows code history of sensor nodes. • Avoids overhead on sensors.

  9. Difference New Program Previous Program Message Image Image Copy copy Download download Download download Copy copy Difference Msgs & Program Rebuild • Host sends difference as a sequence of messages. • Non-matching block  Download • Matching block  Copy • Sensor rebuilds new image using the diff. • Performance Optimization • Copy blocks are aligned to the beginning of flash memory records.

  10. Experiment Setup • Test Applications • Simple network programmable app: XnpBlink and XnpCount. • XnpBlink : blinks LED. • XnpCount: counts number and outputs to LED and radio. • Test Scenarios • Case 1: Changing a constant (XnpBlink) • Case 2: Modifying implementation file (XnpCount) • Case 3: Major change (XnpBlink XnpCount) • Case 4 and 5: Modifying configuration file (XnpCount)

  11. 7.00 Estimated Speed Up (Fixed) 6.00 Measured Speed Up (Fixed) Estimated Speed Up (Rsync) 5.00 Measured Speed Up (Rsync) 4.00 Speed up 3.00 2.00 1.00 0.00 Case 1 Case 2 Case 3 Case 4 Case5 Results – Using Rsync • Compared transmission time with non-incremental delivery. • Fixed Block Comparison: Almost no speedup except for case 1. • Using Rsync algorithm: • Speed up of 2 to 2.5 for a small change (case 2 and 4). • Still limited speed up for big changes (case 3 and 5).

  12. Problems: Difference Delivery still not optimal Difference is decoded without being stored. • Size of copy msg is limited to bound running time. • May send unnecessarily many copy messages. • Requests retransmission of all the records for a missing copy message.

  13. Previous New Previous Script New Script Program Program Commands Commands Program Program Image Image Image Image CMD_DECODE_SCRIPT CMD_DOWNLOADING Copy Copy Download Download Download Download Copy Copy download download copy Optimizing Difference Delivery • Solution: Separate difference delivery and decoding. (1) Stores the differencescript in the first step (2) Rebuilds the program after receiving decode command.

  14. 10.00 Fixed Block Comparison 9.00 Rsync 8.00 Rsync + decode 7.00 6.00 Speedup 5.00 4.00 3.00 2.00 1.00 0.00 Case 1 Case 2 Case 3 Case 4 Case5 Results – Using Rsync with separate decode • The performance of using Rsync algorithm with separate decode command is similar to just using Rsync. • But, the performance for changing a constant has improved (speed up of 9.1).

  15. Previous Work • XNP: TinyOS 1.1 network programming implementation. • Supports code dist. / reprogramming, but not incremental update. • Reijers et al (Delft Univ. of Tech., Netherlands) / Kapur et al (UCLA) • Generates the incremental code update at instruction level. • But the algorithm depends on instruction set of a specific platform. • Maté / Trickle(UC Berkeley) • Generatesthe virtual machine code, not the native code. • Our incremental network programming approach • Generates the code difference using the Rsync algorithm. • No assumption of code structure. Platform independent solution.

  16. Conclusion • We extended TinyOS network programming implementation for incremental update. • We used Rsync algorithm to encode / decode program code difference. • Over non-incremental delivery, we’ve achieved • Speedup of 2 – 2.5 for changing a few lines. • Speedup of 9.1 for changing a constant.

More Related