Incremental Network Programming for Wireless Sensors

1
Incremental Network Programming for Wireless
Sensors

• IEEE SECON 2004
• Jaein Jeong and David Culler
• UC Berkeley, EECS

2
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
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 external flash is slower than the on-chip
  memory.
• Avoid expensive operations for sensor nodes.

5
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.
• Doesnt 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
Difference Generation Using Rsync algorithm

• How can we find shared blocks efficiently?
• Checksum of a block doesnt change even for code
  shift.
• Cheaper than comparing the whole block.
• Idea of Rsync algorithm.

7
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
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 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
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
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
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)
• Generates the 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, weve achieved
• Speedup of 2 2.5 for changing a few lines.
• Speedup of 9.1 for changing a constant.