PPT

431 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
431
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Good afternoon, everyone. We are going to present “Incremental Network Programming for Wireless Sensors”
  • Suppose we load program to wireless sensors nodes. The most commonly used methodology is In System Programming. With In System Programming, the program code is loaded to a sensor node through serial or parallel port connected to the host machine. Although this is supported by most wireless sensor platforms, it has scalability problem. Only one node can be programmed at a time and the programming time increases in proportion to the number of nodes. This is addressed by Network Programming. In Network Programming, the program code is distributed to multiple sensor nodes over the radio with a single transmission. This saves the effort of programming each individual nodes. However, it still takes time to send the whole program code.
  • Then, how can make the network programming faster? In many cases of software development, the program source code is changed in small amounts. Our idea is to reduce the programming time of the network programming by sending this difference rather than whole program code. And we call this “Incremental Network Programming”.
  • There have been a number of works on network programming. XNP, which is the network programming implementation for TinyOS 1.1, supports single hop network programming. Network programming is extended in three directions. First, multi-hop network programming extends the range of the network programming by sending the program code over multiple hops of the communication links. This is done by MOAP from UCLA and Deluge from UC Berkeley. Second, incremental network programming reduces the programming time by sending the difference rather than the whole program code. This is doen by Reijers et al from Delft Univ of Technology in Netherlands and Kapur et al from UCLA. Third, virtual machine programming reduces the programming time by sending a small application level code. Our work has focused on incremental network programming. We generate the difference using the Rsync algorithm. Since it does not depend on code structure, it provides platform independent solution for incremental network programming.
  • In general, network programming is done in three steps: encoding, dissemination and decoding. For incremental network programming, the encoding step takes the two versions of the program code (old program code and new program code) and generates the difference. The dissemination step transmits the difference. And finally, the decoding step rebuilds the new program code using the old program code and the difference.
  • For our incremental network programming, we considered the followings: First, reducing the amount of transmission. This is because the programming time is proportional to size of data to transmit. Second, minimizing the access to the external flash memory. The external flash memory which we will use to store the program code has big storage space compared to other on-chip memory. But, its access time is much longer. Third, we tried to avoid any expensive operations for sensor nodes.
  • As the first step of incremental network programming, the host generates the difference of the two program versions. Then, where are these program images located? The running program is located in the program memory. Since we cannot write to the program memory directly, the downloaded program code is saved in the temporary storage. As the temporary storage, we use external flash memory because it is big enough to hold two versions of the program image (previous and new).
  • To generate the difference of the two program images, one might consider the following schemes. We will call this scheme as “Fixed Block Comparison”. Fixed Block Comparison divides the two program images into fixed sized blocks (let us say it’s B bytes). For a fixed sized block in the previous program image, we find any matching block in the new program image. This scheme sounds easy, but it doesn’t work when the program code is shifted. As you can see in the figure, if the code slide of arbitrary size is inserted, the rest of the program image is shifted and doesn’t match any blocks of the previous program image.
  • On the other extreme, we can have find a matching block by moving the window at every byte. This can find shared blocks even though program code is shifted in arbitrary size. However, the cost of comparison is very high. So we need an efficient way of finding the shared blocks even though the program code is shifted.
  • Then, how can we find the shared blocks efficiently? We can use two level checksums. By using two level checksums, we can find a matching code block quickly and with high accuracy. 1 st level checksum is 32-bit and it can find possible matching block fast. Since this 1 st level checksum can have false match, we need to use more accurate 2 nd level checksum. For 2 nd level checksum (hash), we calculate 128-bit message digest. This is used to verify the possible matching block. And this is the idea of Rsync algorithm.
  • Then, how does Rsync algorithm work? First, it builds the hash table for the previous image. Second, it calculate checksum for the B byte window of the new program image. Third, it looks up the hash table to find any matching checksum. If it finds a matching checksum, then it calculates the hash and compares it with the hash table entry. Otherwise, it moves the window to the next byte and repeat from (2).
  • To disseminate data, we modified Rsync protocol for resource constrained sensor nodes. Originally, in the Rsync algorithm, the sender asks the version of blocks the receiver has before it generates the difference. This has the advantage that the sender doesn’t need to keep track of the code history of the receiver. But, the receiver has to scan the program image and calculates the (checksum, hash) pairs, which is a costly operation for sensor nodes. For simplification, we assumed that the sender knows the code history of the receiver. The sender simply compares the two versions of the program code and generates the difference.
  • After generating the difference, the host program sends the difference as a sequence of “copy” and “download” messages. The sensor node rebuilds the new program image. For a copy message, it copies code blocks from the previous program image to the new program image. For a download message, it writes the data bytes in the download message into the new program image. To minimize the access to the flash memory, we made an optimization so that the copy blocks are aligned to the flash memory record boundary.
  • To evaluate the performance, we set up the experiment. As our test platform, we used MICA2 and MICA2DOT sensor nodes. As test applications, we used simple network programmable applications: XnpBlink and XnpCount. These applications are based on TinyOS sample applications. We performed the test in the following steps: First, we had a test application and its modified version compiled to binary code. Second, we sent the difference of the two binary code and measured the transmission time. We also measured the transmission time with XNP as a base case.
  • Then, how can we modify the program code for our test? We considered five different test cases. For case 1, we modified a constant in XnpBlink program. We expect this is the smallest modification that does not change the structure of the binary code. For case 2, we commented out a few lines in the implementation file source code. We expect this will shift the program code. For case 3, we give two different applications XnpBlink and XnpCount as input of host programs. We expect the difference between these two program code is much bigger than the first two cases.
  • For case 4 and 5, we modified the configuration file to remove a TinyOS component. For case 4, we commented out IntToLeds component which displays an integer data to the LED. For case 5, we commented out IntToRfm component which outputs an integer data as a radio packet.
  • We measured the transmission time when we used Fixed Block comparison, Rsync algorithm and XNP. We calculated the speed up of the incremental network programming schemes over XNP. Fixed block comparison had no speed up except for case 1. This is because fixed block comparison cannot find shared blocks when the program code is shifted. When we used Rsync algorithm for difference generation, we could get the speed up of 2 to 2.5 for case 2 and case 4. These cases are relatively small modification. However, the speed up was still limited for big changes like case 3 and 5.
  • Up to now, we have focused on generating the difference efficiently. However, the difference delivery is still not optimal. The sensor node decodes the difference command as soon as it receives without saving it. But, this causes some problems. First, a copy message cannot be bigger than a certain size to bound the running time. This means that a copy command for a shared block may have to be split to multiple copy commands and the transmission time increases. Second, handling the missing command is inefficient. When a copy message is lost, there is no way to request just the missing copy message because we didn’t keep it. Instead, we need to scan the flash memory and requests retransmission of all the records for the missing copy message.
  • Then, how can we handle the difference delivery efficiently? We can have a separate buffer space for the difference command on the sensor node. In the first step, the sensor node just stores the difference commands without decoding it. Since it does not have to decode the script immediately, we don’t need to split a copy command that spans a large shared block. After receiving all the difference commands, the sensor node decodes the difference script only after it receives the DECODE_SCRIPT command. In case a copy message is lost, the sensor just needs to request the retransmission of that command.
  • We did the experiment after we changed the delivery scheme. The performance of using separate decode command was similar to the previous case. But, the performance for changing a constant has improved from 6 to 9. This is mainly because we didn’t need to split a copy command.
  • To make a conclusion, we implemented faster network reprogramming for wireless sensors by updating the program code incrementally. We used Rsync algorithm to generate the program code difference. Since it doesn’t assume any structure of the program code, this can be applied to any sensor platform. Compared to non-incremental delivery, we were able to get 2 to 2.5 for changing a few lines in the source code and 9 for changing a constant. As a future work, we plant to improve delivery mechanism so that it can support incremental network programming over multi-hop.
  • PPT

    1. 1. Incremental Network Programming for Wireless Sensors IEEE SECON 2004 Jaein Jeong and David Culler UC Berkeley, EECS
    2. 2. Introduction – Loading Program to Wireless Sensors <ul><li>In System Programming </li></ul><ul><ul><li>Most Common. </li></ul></ul><ul><ul><li>Programming time is in proportion to # nodes. </li></ul></ul><ul><li>Network Programming </li></ul><ul><ul><li>Sending whole code over radio still takes time. </li></ul></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. Introduction – Incremental Network Programming <ul><li>Program source code is changed in small amounts. </li></ul><ul><li>Reduce programming time by sending the difference. </li></ul>Incremental Network programming Host Machine Program Code Version 1 Radio Channel Sensor nodes … Program Code Version 2 + Difference
    4. 4. Previous Work <ul><li>Single-hop Network Programming: XNP </li></ul><ul><li>Multi-hop network programming: MOAP , Deluge </li></ul><ul><ul><li>Extends the Range </li></ul></ul><ul><li>Incremental network programming: Reijers / Kapur </li></ul><ul><ul><li>Reduces the Programming Time </li></ul></ul><ul><li>Virtual machine programming: Maté / Trickle </li></ul><ul><ul><li>Small Application Level Code </li></ul></ul><ul><li>Our incremental network programming approach </li></ul><ul><ul><li>Difference Generation using Rsync. </li></ul></ul><ul><ul><li>Platform independent solution. </li></ul></ul>
    5. 5. Network Programming Steps – Incremental Network Programming <ul><li>(1) Encoding: Generates the difference. </li></ul><ul><li>(2) Dissemination: Transmits the difference. </li></ul><ul><li>(3) Decoding: Rebuilds the new code. </li></ul>User app binary Dissemination Data Radio Packets External Flash User Application Section Boot loader Section Host Machine Sensor Node ( 1) Encode (2) Dissemination (3) Decode Host Machine Sensor node
    6. 6. Design Considerations <ul><li>Reduce the amount of data transmission. </li></ul><ul><li>Minimize the access to the external flash memory. </li></ul><ul><li>Avoid expensive operations for sensor nodes. </li></ul>
    7. 7. Step 1: Difference Generation (Encoding) – Storage Organization <ul><li>Program Memory </li></ul><ul><ul><li>Running Program </li></ul></ul><ul><li>External Flash Memory </li></ul><ul><ul><li>Program images for previous / current version </li></ul></ul>External Flash L bytes Previous Image Program Memory Boot loader New Image For others On-chip Memory Sensor Node Memory SRAM Internal Flash User Program (L bytes) L bytes
    8. 8. Step 1: Difference Generation (Encoding) – First Approach: Fixed Block Comparison <ul><li>Comparing at fixed sized blocks: </li></ul><ul><ul><li>Doesn’t work when code is shifted. </li></ul></ul>B bytes B bytes B bytes Remaining Previous Program Image New Program Image B bytes B bytes B bytes shift insert =? n bytes
    9. 9. Step 1: Difference Generation (Encoding) – First Approach: Fixed Block Comparison <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. </li></ul>B bytes B bytes B bytes Remaining Previous Program Image New Program Image B byte window =? For each byte
    10. 10. Step 1: Difference Generation – How to Find Shared Blocks Efficiently? <ul><li>Two level checksums (Idea of Rsync algorithm) </li></ul><ul><ul><li>Finds a matching code block quickly with high accuracy. </li></ul></ul><ul><ul><li>Checksum (1 st level): Fast but not accurate (32-bit). </li></ul></ul><ul><ul><li>Hash (2 nd level): Not fast but very accurate (128-bit). </li></ul></ul>Hash Table (Checksum, Hash) New Program Image B byte window For each byte B bytes B bytes B bytes Remaining Previous Program Image =? Checksum Hash
    11. 11. Step 1: Difference Generation – Using Rsync Algorithm <ul><li>(1) Build hash table for previous image. </li></ul><ul><li>(2) For the window 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>(1) (2) (3) Hash Table (Checksum, Hash) New Program Image B byte window For each byte B bytes B bytes B bytes Remaining Previous Program Image =? Checksum Hash
    12. 12. Step 2: Dissemination – Modified Rsync Protocol for Wireless Sensors <ul><li>Modified Rsync protocol for resource constrained sensor nodes. </li></ul>Sender Receiver (1) Asks version of blocks (2) Sends checksum list (3a) Sends difference (4) Rebuilds the latest version (3) Compares checksums & generate difference 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
    13. 13. Step 3: Decoding – Program Rebuild during Code Delivery <ul><li>Host sends difference as a sequence of messages. </li></ul><ul><li>Sensor rebuilds new image using the diff. </li></ul><ul><li>Optimizing Flash Memory Access </li></ul><ul><ul><li>Copy blocks are aligned to flash memory record boundary. </li></ul></ul>Previous Program Image New Program Image Copy Download Download Copy Difference Message Matching block Non-maching block Host Machine Sensor Node
    14. 14. Experiment Setup <ul><li>Test Platforms: MICA2 / MICA2DOT </li></ul><ul><li>Test Applications </li></ul><ul><ul><li>Simple network programmable app: XnpBlink and XnpCount . </li></ul></ul><ul><li>Test Steps </li></ul><ul><ul><li>Test app code and modified code are given to host program. </li></ul></ul><ul><ul><li>Compare the xmit time with that of XNP (non-incremental). </li></ul></ul>+ Dissemination Data Host Program Test Application Modified Test Application Sensor nodes …
    15. 15. Experiment Setup – Test Cases <ul><li>Case 1: Changing a constant ( XnpBlink ) </li></ul><ul><li>Case 2: Modifying implementation file ( XnpCount ) </li></ul><ul><li>Case 3: Major change ( XnpBlink  XnpCount ) </li></ul>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; }
    16. 16. Experiment Setup – Test Cases <ul><li>Case 4: Modifying configuration file ( XnpCount ) </li></ul><ul><ul><li>Commented out IntToLeds component. </li></ul></ul><ul><li>Case 5: Modifying configuration file ( XnpCount ) </li></ul><ul><ul><li>Commented out IntToRfm component. </li></ul></ul>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. 17. Results <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) Modifying Constant Comment Lines XnpBlink to XnpCount Comment IntToLeds Comment IntToRfm
    18. 18. Problems of Rebuild during Delivery – 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><li>Inefficient handling of missing copy msg. </li></ul>Dissemination Data External Flash Host Machine Sensor Node Radio Packets Previous Image New Image For others
    19. 19. Optimizing Difference Delivery <ul><li>Solution: Separate difference delivery and decoding. </li></ul><ul><li>Stores the difference script in the first step </li></ul><ul><li>Rebuilds the program after receiving decode command. </li></ul>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
    20. 20. 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 Modifying Constant Comment Lines XnpBlink to XnpCount Comment IntToLeds Comment IntToRfm
    21. 21. Conclusion <ul><li>Faster network reprogramming using incremental update. </li></ul><ul><li>Platform independent solution using Rsync algorithm. </li></ul><ul><li>Speed-up over non-incremental delivery </li></ul><ul><ul><li>2 – 2.5 for changing a few lines. </li></ul></ul><ul><ul><li>9.1 for changing a constant. </li></ul></ul><ul><li>Future Work </li></ul><ul><ul><li>Extension for multi-hop delivery. </li></ul></ul>

    ×