1 Demo Abstract: DHV - An Efficient Code Consistency Management Protocol for Wireless Sensor Networks Thanh Dang and Nirupama Bulusu and Wu-chi Feng and SeungWeon Park Department of Computer Science Portland State University Portland, OR, USA, 97201 Email: {dangtx,nbulusu,wuchi,swpark}@cs.pdx.edu Abstract—Ensuring that every sensor node has the same code version is challenging in dynamic, unreliable, multi-hop sensor networks. When nodes have different code versions, the network may not behave as intended, wasting time and energy. We demonstrate DHV, a code consistency maintenance protocol to ensure that every node in a network will eventually have the same code. DHV is based on the simple observation that if two code versions are different, their corresponding version numbers often differ in only a few least significant bits of their binary representation. DHV allows nodes to carefully select and transmit only necessary bit level information to detect a newer code version in the network. DHV can detect and identify version differences in O(1) compared to the logarithmic of current protocols in terms of messages and latency. Simulations and experiments on a real MicaZ testbed show that DHV reduces the number of messages by 50%, converges in half the time, and reduces the number of bits transmitted by 40-60% compared to DIP, the state-of-the-art protocol. I. I NTRODUCTION Experience with wireless sensor network deployments across application domains has shown that sensor node tasks typically change over time, for instance, to vary sensed pa- rameters, node duty cycles, or support debugging. Typically, this leverages the ability to reprogram sensor devices using wireless communication. The goal of network reprogramming is to not only reprogram individual sensors but to also ensure that all network sensors agree on the task being performed. Network reprogramming creates the need for a protocol to ensure that all network nodes have the same up-to-date code items, which can be binary images, code segments, or configuration parameters. We refer to such a protocol as a Code Consistency Maintenance Protocol (CCMP). Depending upon the application, the bandwidth and energy consumption of a CCMP can be comparable to sensing, particularly for networks with mobility or large churn. Key requirements for a CCMP are: • A CCMP must ensure that the all network nodes eventu- ally have the same updated code. • A CCMP should enable a node with an old code item to discover a newer code item and update it with low latency. • A CCMP should conserve energy and bandwidth. • A CCMP should scale with both the network size and the total number of code items. Code items are often represented as a set of (key, version) tuples. Each key uniquely identifies a code item. The cor- responding version indicates if the code item is old or new (the higher the version, the newer the code). Previous CCMP protocols like DRIP [1] and DIP [2] incur high latency, high cost and may be complicated. Both DRIP and DIP are built on top of Trickle [3], a self-regulating algorithm for code propagation and maintenance in wireless sensor networks. In DRIP, a node randomly broadcasts each of its own (key, version) tuples to its neighbors separately. DRIP scales linearly with the total number of items (O(T )). DIP improves the total number of messages and latency to O(log(T )) by searching for a different (key, version) using hashes of the (key, version) tuples. A common feature in both approaches is that they try to detect and identify differences of versions as a whole. We demonstrate a new code consistency maintenance proto- col called DHV. We observe that if two versions are different, they often only differ in a few least significant bits of their version number rather than in all their bits. Hence, it is not necessary to transmit and compare the whole version in the network. DHV aims to detect and identify differences of version-levels for code items with the goal of transmitting much less data in the network compared to DRIP and DIP. The name DHV comes from the three steps in the protocol — D ifference detection, H orizontal search, and V ertical search. Each step requires only O(1) total messages and latency with respect to the total number of items. So DHV can identify a difference with as few as 3 transmissions. II. THE DHV PROTOCOL DHV has two main phases — detection and identification. In detection, each node broadcasts a hash of all its versions called a SUMMARY message. Upon receiving a hash from a neighbor, a node compares it to its own hash. If they differ, there is at least one code item with a different version number. In identification, the horizontal search and vertical search steps identify which versions differ. In horizontal search, a c  Thanh Dang et al. 2009