1 / 21

Incremental Network Programming for Wireless Sensors

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

norman
Download Presentation

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 nodes … Sensor node Serial orparallelport HostMachine ProgramCode RadioChannel HostMachine In system programming ProgramCode Network programming Introduction –Loading Program to Wireless Sensors • In System Programming • Most Common. • Programming time is in proportion to # nodes. • Network Programming • Sending whole code over radio still takes time.

  3. Sensor nodes … Radio Channel Difference Program CodeVersion 2 Program CodeVersion 1 + Incremental Network programming HostMachine Introduction –Incremental Network Programming • Program source code is changed in small amounts. • Reduce programming time by sending the difference.

  4. Previous Work • Single-hop Network Programming: XNP • Multi-hop network programming: MOAP, Deluge • Extends the Range • Incremental network programming: Reijers / Kapur • Reduces the Programming Time • Virtual machine programming: Maté / Trickle • Small Application Level Code • Our incremental network programming approach • Difference Generation using Rsync. • Platform independent solution.

  5. User Application Section Host Machine Sensor Node Boot loader Section (1) Encode (2) Dissemination (3) Decode User app Dissemination binary Radio External Data Packets Flash HostMachine Sensor node Network Programming Steps –Incremental Network Programming (1) Encoding: Generates the difference. (2) Dissemination: Transmits the difference. (3) Decoding: Rebuilds the new code.

  6. Design Considerations • Reduce the amount of data transmission. • Minimize the access to the external flash memory. • Avoid expensive operations for sensor nodes.

  7. Sensor Node Memory On-chip Memory L bytes L bytes User Program(L bytes) ProgramMemory Boot loader SRAM Internal Flash ExternalFlash PreviousImage New Image For others Step 1: Difference Generation (Encoding) –Storage Organization • Program Memory • Running Program • External Flash Memory • Program images for previous / current version

  8. =? n bytes Step 1: Difference Generation (Encoding) –First Approach: Fixed Block Comparison • Comparing at fixed sized blocks: • Doesn’t work when code is shifted. Previous New Program Program Image Image B bytes B bytes insert B bytes B bytes shift B bytes B bytes Remaining

  9. Previous New Program Program Image Image B bytes =? B bytes B bytewindow For each byte B bytes Remaining Step 1: Difference Generation (Encoding) –First Approach: Fixed Block Comparison • Comparing at every byte: • Finds shared blocks with high cost. • Need an efficient way of finding shared blocks.

  10. Previous Program Image B bytes B bytes New Hash Table Program Image (Checksum, Hash) B bytes Remaining B bytewindow For each byte =? Checksum Hash Step 1: Difference Generation –How to Find Shared Blocks Efficiently? • Two level checksums (Idea of Rsync algorithm) • Finds a matching code block quickly with high accuracy. • Checksum (1st level): Fast but not accurate (32-bit). • Hash (2nd level): Not fast but very accurate (128-bit).

  11. Previous Program Image B bytes B bytes New Hash Table Program Image (Checksum, Hash) B bytes Remaining B bytewindow For each byte =? Checksum Hash Step 1: Difference Generation –Using Rsync Algorithm (1) Build hash table for previous image. (2) For the window of new image, calculate checksum. (3) Lookup hash table. • For a matching checksum, calculate hash. • Otherwise, move to the next byte and repeat (2). (3) (2) (1)

  12. Receiver Sender (1) Asks version of blocks Receiver Sender (1) Calculatesthe checksums. (2) Sends checksum list (3) Compares checksums &generatedifference (2) Generates the difference (3a) Sends difference (3) Sends thedifference. (4) Rebuildsthe latest version (4) Rebuilds the latest version Original Rsync algorithm Modified Rsync algorithm Step 2: Dissemination –Modified Rsync Protocol for Wireless Sensors • Modified Rsync protocol for resource constrained sensor nodes.

  13. Difference Previous Program New Program Message Image Image Host Machine Sensor Node Copy Matching block Download Download Non-maching block Copy Step 3: Decoding –Program Rebuild during Code Delivery • Host sends difference as a sequence of messages. • Sensor rebuilds new image using the diff. • Optimizing Flash Memory Access • Copy blocks are aligned to flash memory record boundary.

  14. Sensornodes … Test Dissemination Application + Data Modified Test Application HostProgram Experiment Setup • Test Platforms: MICA2 / MICA2DOT • Test Applications • Simple network programmable app: XnpBlink and XnpCount. • Test Steps • Test app code and modified code are given to host program. • Compare the xmit time with that of XNP (non-incremental).

  15. command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000); } event result_t Xnp.NPX_DOWNLOAD_DONE (uint16_t wProgramID, uint8_t bRet,uint16_t wEENofP){ if (bRet == TRUE) call CntControl.start(); else call CntControl.stop(); return SUCCESS; } Experiment Setup – Test Cases • Case 1: Changing a constant (XnpBlink) • Case 2: Modifying implementation file (XnpCount) • Case 3: Major change (XnpBlink XnpCount)

  16. Experiment Setup – Test Cases • Case 4: Modifying configuration file (XnpCount) • Commented out IntToLeds component. • Case 5: Modifying configuration file (XnpCount) • Commented out IntToRfm component. configuration XnpCount {} implementation { components Main, Counter, /*IntToLeds,*/ /*IntToRfm,*/ TimerC, XnpCountM, XnpC; //Main.StdControl->IntToLeds.StdControl; //IntToLeds<-Counter.IntOutput; // Main.StdControl -> IntToRfm.StdControl; // Counter.IntOuput -> IntToRfm; }

  17. Results • 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). 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 ModifyingConstant CommentLines XnpBlink toXnpCount CommentIntToLeds CommentIntToRfm

  18. Host Machine Sensor Node Previous Image Dissemination External Flash Data New Radio Image Packets For others Problems of Rebuild during Delivery–Difference Delivery Still Not Optimal Difference is decoded without being stored. • Size of copy msg is limited to bound running time. • Inefficient handling of missing copy msg.

  19. 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. • Stores the difference script in the first step • Rebuilds the program after receiving decode command.

  20. 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 ModifyingConstant CommentLines XnpBlink toXnpCount CommentIntToLeds CommentIntToRfm 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).

  21. Conclusion • Faster network reprogramming using incremental update. • Platform independent solution using Rsync algorithm. • Speed-up over non-incremental delivery • 2 – 2.5 for changing a few lines. • 9.1 for changing a constant. • Future Work • Extension for multi-hop delivery.

More Related