Incremental Network Programming for Wireless Sensors

Abstract

We present an incremental network programming mechanism which reprograms wireless sensors quickly by transmitting the incremental changes using the Rsync algorithm; we generate the difference of the two program images allowing us to distribute only the key changes. Unlike previous approaches, our design does not assume any prior knowledge of the program code structure and can be applied to any hardware platform. To meet the resource constraints of wireless sensors, we tuned the Rsync algorithm which was originally made for updating binary files among powerful host machines. The sensor node processes the delivery and the decoding of the difference script separately making it easy to extend for multi-hop network programming. We are able to get a speed-up of 9.1 for changing a constant and 2.1 to 2.5 for changing a few lines in the source code

MCP: An Energy-Efficient Code Distribution Protocol for Multi-Application WSNs

“…[16] and [4] proposed to generate and propagate a diff script instead of the complete binary code image. [12] performed update conscious register allocation and data allocation to reduce the script size.…”

The LiteOS Operating System: Towards Unix-Like Abstractions for Wireless Sensor Networks

“…This approach remotely echoes the differential patching idea [17,28] in application distributions over networks. Different from that idea, however, we directly encode relocation information into application binaries, by fitting differential patches with mathematical models, and distributing these models together with binary images.…”

Sluice: Secure Dissemination of Code Updates in Sensor Networks

“…While [21] is very effective at reducing the amount of data to be transferred, it takes advantage of instruction-set details to build the edit script, and so, is architecture dependent. A platform independent approach based on the rsync algorithm is presented in [8]. This approach effectively handles code shifts and small binary changes, but presents a negligible speedup with large code changes.…”

“…This approach effectively handles code shifts and small binary changes, but presents a negligible speedup with large code changes. Both [21] and [8] assume nodes to be in a consistent state, and can only update nodes that are a single version behind the pending data object.…”