Single Versus Multi-hop Wireless Reprogramming in Sensor Networks

Purdue University

Purdue e-Pubs ECE Technical Reports

Electrical and Computer Engineering

2-13-2008

Single Versus Multi-hop Wireless Reprogramming in Sensor Networks Rajesh Krishna Panta Purdue Universitiy, [email protected]

Issa Khalil Purdue University, [email protected]

Saurabh Bagchi Purdue University, [email protected]

Luis Montestruque Emnet LLC, [email protected]

Panta, Rajesh Krishna; Khalil, Issa; Bagchi, Saurabh; and Montestruque, Luis, "Single Versus Multi-hop Wireless Reprogramming in Sensor Networks" (2008). ECE Technical Reports. Paper 372. http://docs.lib.purdue.edu/ecetr/372

This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information.

Single versus Multi-hop Wireless Reprogramming in Sensor Networks Rajesh Krishna Panta, Issa Khalil, Saurabh Bagchi Dependable Computing Systems Lab, School of Electrical and Computer Engineering, Purdue University 465 Northwestern Avenue,West Lafayette,IN 47907 Email: {rpanta,ikhalil,sbagchi}@purdue.edu Abstract— Wireless reprogramming of the sensor network is useful for uploading new code or for changing the functionality of the existing code. In recent years, the research focus has shifted from single hop reprogramming to multi-hop reprogramming primarily because of its ease of use. Practical experience from a multi-hop sensor network for monitoring water pollution, called CSOnet, deployed in South Bend, IN, indicates that single-hop reprogramming may be preferable under certain conditions to minimize reprogramming time and energy. In this, the user gets close to a node to be reprogrammed and wirelessly reprograms a single node at a time. The choice between single hop and multi-hop reprogramming depends on factors like network size, node density and most importantly, link reliabilities. We present a protocol called DStream having both single and multi-hop reprogramming capabilities. We provide mathematical analysis and results from testbed experiments (including experiments conducted on CSOnet networks) and simulations to give insights into the choice of the two reprogramming methods for various network parameters. Keywords- Network reprogramming; sensor networks; single hop reprogramming; multi-hop reprogramming; link reliability.

I.

INTRODUCTION

Large scale sensor networks may be deployed for long periods of time during which the requirements from the network or the environment where the nodes are deployed may change. The change may necessitate uploading a new code or re-tasking the existing code with different sets of parameters. The deployed software on a network may need to be changed, to correct software bugs. Wirelessly reprogramming the nodes is particularly useful because the network may be deployed over a wide geographical region and some nodes may be in difficult to reach places. However, remote reprogramming in sensor networks poses several challenges. First, the reprogramming should be 100% reliable, i.e. each node being reprogrammed should receive the code in its entirety. A program image is relatively large for the low-bandwidth wireless radio. Therefore, code delivery has to be done efficiently to minimize redundant transmissions due to multiple senders and extra retransmissions due to link losses or collisions. Also, a sensor node has limited power supply and memory. So, it is important to minimize the energy and memory consumption for network reprogramming. In recent years, the focus of the sensor network reprogramming has shifted from single hop reprogramming (only nodes within the transmission range of the base node (BN) are reprogrammed) to multi-hop reprogramming (all nodes in the multi-hop network are reprogrammed) because of various reasons. First and perhaps the biggest advantage is that from a user’s point of view, it is tedious to perform many

Luis Montestruque Emnet LLC 12441 Beckley Street, Granger, IN 46530 Email: [email protected]

rounds of single hop reprogramming to completely reprogram the multi-hop network. Second, multi-hop reprogramming protocols like Deluge [3], Freshet [6] and Stream [5] spatially pipeline the code transfer (also called spatial multiplexing) and thus reduce the time to reprogram the network. That is, a node does not need to completely download the code image before starting to send the code to its neighbors. These protocols divide the entire code image into pages consisting of fixed number of packets. When a node completes downloading a single page, it can send that page to other nodes in the network. But in some deployment conditions, like in combined Sewage Overflow (CSO) project implemented in South Bend, Indiana, multi-hop reprogramming can be costly in terms of reprogramming time and energy. In CSO, a multi-hop sensor network, called CSOnet, with nodes mounted on traffic lights and lamp-posts, is used to collect alerts from monitoring sensors planted in the manholes of the municipal sewage system. The network then forwards these alerts to gateways at major traffic intersections which make distributed control decisions to channel the flow to temporary reservoirs so that dumping the waste water into rivers or lakes can be avoided. At first glance, it may appear pointless to sacrifice the relative ease of the multi-hop reprogramming in favor of node by node reprogramming. The conditions in which a sensor network is deployed may change over time. For example, the link reliabilities between the nodes in the network may change because of varying environmental factors. When link reliabilities are low, sending entire application image over multiple links imposes a heavy burden in terms of retransmissions. This increases the reprogramming costboth reprogramming energy and timeand congestion in the wireless links which may be better utilized in transferring critical data. In fact, for all current reprogramming protocols, except Stream, what needs to be transferred over the network is the entire application image plus the reprogramming protocol image. This exacerbates the problem by increasing the number of packets that needs to be transmitted reliably through the network. The increase is sometime by a factor of 20 [5]. This specific problem reared its head in the CSOnet deployment where it was observed that the batteries were being drained much faster than the theoretical calculations had predicted. Our investigation revealed that regular code updates being sent using the multi-hop method were the culprit for parts of the network, particularly the parts having linear topology and unreliable links. We decided to explore the possibility of judiciously using single hop reprogramming. In contrast to multi-hop reprogramming, in the single-hop

method1, the user visits each node in the deployment field and remotely reprograms it being physically as close as possible to the node. The severity of the above problem can thus be greatly reduced because the user goes as close as possible to the node to be reprogrammed to maximize link reliability. This reduces the number of retransmissions and hence reprogramming time and energy will be conserved. Generally hardwired reprogramming (by directly connecting the sensor node to the computer via say serial port) cannot be a substitute for single hop reprogramming to tackle the high cost of multi-hop reprogramming. For example, in the CSOnet deployment, since the sensor nodes are situated on top of the traffic posts, it is tedious and difficult to bring down the sensor nodes from the traffic posts and manually upload the code to these sensor nodes. The company responsible for the implementation of the project EmNet LLC in Granger, Indianareports high cost and logistical difficulties in reprogramming the sensors manually. This mode of operation cost EmNet $200 to reprogram each node including 3 persons involved and the rental cost of a bucket truck. Moving to a single hop reprogramming brings the cost down by a factor of 10 and therefore, economically, the single hop wireless reprogramming appears a good compromise. In this paper, we present a protocol called DStream having both single and multi-hop reprogramming capabilities. DStream is built on top of Stream [5]. It does not sacrifice the advantages of Stream with respect to code size and memory footprint We use the terms DStream-SHM and DStream-MHM to represent the single and multi-hop reprogramming modes of Stream. Using mathematical analysis, testbed experiments and simulations, we draw valuable inferences about the two reprogramming approaches. The common insight that all three give us is that single hop may be more energy efficient and faster than multi-hop in some scenarios. For a given topology, the cutoff depends on the link reliability of the links in the network. High link reliability favors multi-hop reprogramming. However the cross-over point depends on which metric is of interest to the network owner- if it is reprogramming time, the cross-over happens at a lower link reliability value than for energy. Second, for networks that are linear (or close to linear), single hop reprogramming tends to be favored since a single broadcast of the code image can satisfy only a few nodes. The actual choice between the two modes will also be determined by the human cost of reprogramming a node at a time as in single hop reprogramming. For reference, we quantify this value for the CSOnet deployment. To summarize, in this paper, we discuss our experience in reprogramming the CSOnet a sensor network in the South Bend area of Indiana and our contributions are: 1) Motivate the community to consider situations where single hop method may be more attractive than the currently held view of multi-hop reprogramming. 2) Design a dual reprogramming protocol, DStream that does not significantly increase the code size or the memory footprint over the previous Stream protocol. 3) Through analytical, experimental and simulation results, provide a set of guidelines that help the network owner to choose single or 1

multi-hop reprogramming approach based on current network conditions. The rest of the paper is organized as follows. Section II surveys related work. Section III provides the detailed DStream design. Section IV presents the mathematical analysis. Section V explains the testbed and the simulation results. Section VI concludes the paper with the recommendations for a network owner. II. RELATED WORK In recent years, there has been significant research work aimed at developing protocols for reprogramming sensor networks. To the best of our knowledge, all of the existing reprogramming protocols provide either single or multi-hop reprogramming features, but not both. Importantly existing work is silent on the choice between the two approaches for different deployment conditions. The earliest network reprogramming protocol XNP [1] operated over a single hop. The Multi-hop Over the Air Programming (MOAP) protocol extended this to multiple hops [2]. It introduced several concepts which are used by later multi-hop reprogramming protocols, namely, local recovery using unicast NACKs and broadcast of the code, and sliding window based protocol for receiving parts of the code image. However, it did not leverage the pipelining effect with segments of the code image. The three protocols that define the state-of-the-art today are Deluge, MNP, and Freshet. They are all based on the idea of epidemic based reliable multicast whereby code images are flooded through the network in a controlled manner guaranteeing reliability through the use of epidemic multicast. Deluge [3] was the earliest and laid down some design principles used by the other two. It uses a monotonically increasing version number, segments the binary code image into pages, and pipelines the different pages across the network. It builds on top of Trickle [7], a protocol for a node to determine when to propagate code over a single hop. The design goal of MNP [4] is to choose a local source of the code which can satisfy the maximum number of nodes. The authors provide a detailed algorithm for sender selection using the number of requests seen by a sender as the key parameter for the selection. They provide energy savings by turning off the radio of all the nodes that are not selected as the sender. Freshet [6] aggressively optimizes the energy consumption for reprogramming by allowing a node to sleep till the code reaches its neighborhood. It also reduces the energy consumption by exponentially reducing the meta-data rate during conditions of stability in the network when no new code is being introduced. Stream [5] uses the principles of Deluge for code propagation but greatly reduces the reprogramming time and energy compared to Deluge. Section III presents a brief description of Stream. There have been some studies which show how low link reliabilities cause problems in multi-hop networks. [11] showed that shortest path algorithm in a network with lossy links selects a path with poor reliability. In [10], the authors evaluate Deluge and MNP for different densities and packet organizations. But as far as we know, there has been no prior work to study the effect of parameters like link reliabilities on the performance of multi-hop reprogramming. In this paper, we show how poor link qualities adversely affect multi-hop reprogramming making the alternate single hop reprogramming approach attractive.

Technically this method is single node reprogramming. However, the term single hop reprogramming follows the standard usage in the literature.

2

III. A.

PROTOCOL DESIGN

protocol avoids the entire reprogramming component from being transferred to all the nodes each time the network needs to be reprogrammed. The exact saving in terms of the number of pages transferred depends on the application. Any application that uses radio communication will need to add about 11 more pages if Deluge is used while Stream-AS adds only one more page [5].

Background and Rationale It is desirable to have the sensor nodes equipped with the facility of both single and multi-hop reprogramming so that a choice can be made at runtime based on the current network conditions (topology, link reliabilities, density etc). The obvious approach is to have two separate reprogramming Design Approach of DStream protocols (a single hop protocol like XNP and a multi-hop C. Next we describe DStream that can provide both single protocol like Stream) stored in each node’s permanent storage (external flash) so that it can run the appropriate protocol and multi-hop reprogramming features. Let initially all nodes when required by loading that protocol from external flash to have Stream-RS as image 0 and the application with Streamthe program memory. This is not an attractive solution AS as image 1. Each node is executing the image 1 code. because requiring a node to store two reprogramming Consider that a new user application has to be injected into protocols decreases the storage (e.g. external flash for Mica2 the network. is 512KB) for the application running on the nodes. Our 1. If multi-hop reprogramming is to be used, in response to the reboot command from the user, all nodes in the proposed approach is to have a single protocol with both network reboot from image 0. This is accomplished as single and multi-hop reprogramming capabilities. Existing follows: single-hop reprogramming protocols, such as XNP, were not a. From the computer, the user sends the command to designed with the ability of propagating the code updates reboot from image 0 to the BN. through the network in a multi-hop manner. Therefore they b. The BN executing image 1 broadcasts the reboot cannot serve as a starting point for our protocol. Multi-hop command to its one hop neighbors and itself reboots reprogramming protocols like Deluge, Stream and Freshet are from image 0. more suited for this purpose. Since Stream is the most energy c. When a node running the user application receives the efficient and fastest among these protocols, we chose Stream reboot command, it rebroadcasts the reboot command and modified it to DStream, having both single and multi-hop and reboots from image 0. reprogramming capabilities. For this paper, the meaning of single hop reprogramming 2. If single hop reprogramming is to be used, in response to the reboot command from the user, a single node specified is that only a single node, specified by the user, within single by the user reboots from image 0. This is accomplished as hop of the BN is reprogrammed. Contrary to what the name follows: suggests, single hop reprogramming does not mean that all a. From the host computer, the user sends the command to the nodes within the single hop of the BN are reprogrammed reboot a single node, say nodeα, from image 0 to the by this approach. This is because the main rationale behind BN. single hop reprogramming is to avoid reprogramming nodes b. The BN running image 1 broadcasts the reboot which have low link reliability to the BN but may technically command along with the user specified node id α to its be considered within a single hop of the BN. If we attempt to one hop neighbors. The BN then reboots from image 0. reprogram a node within single hop of the BN but with low c. Each node that receives the reboot command, link reliability, this may take considerable time and energy to determines if the reboot command is targeted to it. If be reprogrammed defeating the purpose of single hop yes, it reboots from image 0. Otherwise, it ignores reprogramming. the reboot command. So, only the node α reboots from B. Design Approach of Stream image 0 (Stream-RS) and is subsequently reprogrammed. The main disadvantage of multi-hop reprogramming 3. Stream-RS starts to reprogram the node(s) that has protocols like Deluge, MNP and Freshet is the overhead rebooted from image 0. Thus, Stream-RS which forms the involved in reprogramming. Each protocol transfers the entire bulk of the reprogramming protocol does not need any reprogramming protocol image together with the new user modification to support the single-hop mode of operation. application image. Since the reprogramming protocols are of 4. Stream-RS uses the three way handshake method for considerable complexity, the inflation in the program image reprogramming [5] where each node broadcasts the size that gets transferred over the wireless medium increases advertisement about the code pages that it has. When a greatly. The idea in Stream is to have all nodes in the network node hears the advertisement of newer data than it be pre-installed with the Stream-ReprogrammingSupport currently has, it sends a request to the node advertising (Stream-RS) component that includes the complete newer data. Then the advertising node broadcasts the functionality for network reprogramming. Stream-RS is requested data. Each node maintains a set S containing the installed as image 0. The application image augmented with node ids of the nodes from which it has received the the Stream-ApplicationSupport (Stream-AS) component that requests. provides minimal support for network reprogramming is 5. Once the node downloads the new user application installed as image 1. The addition to the size of the program completely, it performs a single-hop broadcast of an ACK image over the application image size with Stream is indicating it has completed downloading. In single-hop significantly less than for previous protocols. When a new reprogramming, only one node sends the ACK while in program image is to be injected into the network, all the multi-hop all nodes in the network are ultimately nodes in the network running image 1 reboot from image 0 reprogrammed and send the ACK message. and the new image is injected into the network using Stream6. When a node n1 receives the ACK from node n2, n1 RS. The new image again includes Stream-AS and the removes the id of n2 from the set S. Note that in multi-hop 3

reprogramming case, set S is maintained by all the nodes that are participating in sending code to any of its neighbors, while only the BN has a non-empty set S in single hop reprogramming and it only contains the node id α. For the set S at a node A, the following invariant holds: A.S = {x | REQ( x, A) = true ∧ ACK ( x, A) = false} This ensures that the set S at a node A consists of the ids of those nodes to which it is currently sending code fragments. The condition for a node A to reboot from the user application (image 1) is as follows: A.S = φ ∧ A.# pages = Total number of pages The first condition is that A is not sending code to any node and the second condition is that A itself has downloaded all the pages of the application. 7. When the set S is empty and all the images are complete (by complete we mean that all pages of all images have been downloaded), the node reboots from image 1. So, in multi-hop case, at completion, the entire network is reprogrammed and all nodes reboot from image 1. In the single hop case, the set S is always empty for the node α that is reprogrammed and hence immediately after it completes downloading the image, the node α sends ACK and reboots from image 1. When the BN receives the ACK from the node α, it removes the id of node α from its set S and reboots from image 1. From the above discussion, it is clear that DStream can provide both multi-hop and single hop reprogramming features. If the user specifies the id of the node to be reprogrammed in the reboot command, DStream reprograms only the specified node (single hop reprogramming). Besides this, the user can also specify an option (switch_SH) for automatic switching between single and multi-hop approaches. When this option is specified, DStream starts with multi-hop reprogramming. When a node n1 receives a request from a node n2 for a page of the new image, n1 keeps track of how many packets are requested for the same page in the next request by n2. This gives n1 the estimate of the link reliability between n1 and n2. If the estimated link reliability is less than some threshold (user specified), a message is sent back to the BN informing it about the current link reliability between n1 and n2. The BN then forwards that message to the computer. This suggests the user to switch to single hop reprogramming for n2. In this way, nodes with low link qualities are reprogrammed using single hop method and other nodes are reprogrammed using multi-hop method. The details of the three way handshake (advertisementrequest-data) used by Stream-RS for reprogramming are explained in [3]. The operation of each node is periodic according to a fixed size time window. The first part of the window is for listening to advertisements and requests and sending advertisements. The second part of the window is for transmitting or receiving code corresponding to the received requests. Within the first part of the time window, a node randomly selects a time at which to send an advertisement with meta-data containing the version number, the number of complete pages it has, and the total number of pages in the image of this version. When the time to transmit the advertisement comes, the node sees whether it has heard a threshold number of advertisements with identical meta-data, and if so, it suppresses the advertisement. When a node hears code that is newer than its own, it sends a request for that code and the lowest number page it needs. In the second part of the periodic window, the node transmits packets with the

code image, corresponding to the pages for which it received requests. IV. MATHEMATICAL ANALYSIS Here we present an approximate analysis of the reprogramming time and energy for DStream-SHM and DStream-MHM for linear and grid networks. For linear networks, we assume that the spacing between consecutive nodes is equal to the transmission range and for grid networks, it is √2 times the grid spacing. Let the application consist of Np pages with Apkt packets per page. Let LRS and LRM be the link reliability of single hop reprogramming (for the link between the BN and the single node being reprogrammed) and multi-hop reprogramming (we assume identical link reliability for all links) respectively. Let Ps be the probability of successful transmission of a packet over a single link, which is equal to LRS in single hop mode and LRM in multi-hop mode. A. Reprogramming Time The reprogramming model that we use for the analysis is an approximation of the behavior of DStream. We divide the time line into fixed-size rounds. The source sends the advertisement at the beginning of each round and the destination, the one hop neighbor of the source that hears the advertisement, sends one request for each new advertisement received. We assume, for tractability of analysis, that the advertisement and the request packets are reliably delivered. This can be achieved in practice by either having a separate control channel or by transmitting the control signals multiple times to give a desired reliability. If this assumption is not true, then the multi-hop reprogramming time we find is a lower bound. Once the source receives the request, the data packets are sent immediately. If all the data packets in a page do not reach the destination, the remaining data packets are sent over the following one or more rounds. The time Tr is defined as the time to send a new advertisement, receive a request, and send all the Apkt packets of the page being advertised when the link reliability is 1.0. The number of rounds that it takes for all the packets in a page to be received at the destination is thus a random variable, call it Nr. The probability of completing the upload of the entire page within the kth round since the start of transmitting the page is the probability that each packet in the page is successfully delivered within k rounds. Assuming independence of the losses of different packets within a page, Apkt

 k j −1  P( N r ≤ k ) =  ∑ Ps (1 − Ps )  (1)  j =1  The expected number of rounds for successfully sending a whole page is ∞

∞

i =1

i =1

E[ N r ] = ∑ i ⋅ P ( N r = i ) = ∑ P ( N r ≥ i ) ∞

∞

i =1

i =1

E[ N r ] = ∑ (1 − P( N r < i ) ) = ∑ (1 − P( N r ≤ i − 1) )

(2) (3)

Apkt   i −1  j −1  E[ N r ] = ∑ 1 −  ∑ Ps (1 − Ps )   (4) i =1      j =1 The code transmission is pipelined. That is, a node does not have to completely download the new image before sending it to the next hop. As soon as the node downloads the first page of the new application, it can send that page to the ∞

4

other nodes if it gets the request for that page. Since the page transmission is pipelined, the expected number of rounds it takes to download the whole application at a node h-hop away is given by E[ N r , h ] = min {3 ⋅ ( N p − 1) + h), N p ⋅ h} E[ N r ] (5) Here h.E[Nr] is the number of rounds to download the first page, 3.(Np-1).E[Nr] is the number of rounds to download the rest of the pages if the network spans across more than 4 hops because of two-hop interference effect on pipelining, i.e. at any point of time, if a node at hop h receives data from hop h1, no node at hop h+1 can send data at the same time because of collision at hop h [3] . For networks with maximum hop separation less than 4, there is no pipelining of the code transfer and Np.h.E[Nr] is the number of rounds to download all the pages [3]. From Equation (4) and Equation (5), E[ N r , h ] = min {3 ⋅ ( N p − 1) + h), N p ⋅ h} ⋅

For the linear topology, as the network size increases the multi-hop mode reprogramming is faster due to the pipelining effect of multiple pages. However for the 5 node network, when the multi-hop link reliability is less than 0.8, single hop reprogramming is preferred from the delay point of view. For the grid topology, the reprogramming time of the multi-hop mode is always better than that of the single hop mode due to two factors— the spatial multiplexing and multiple nodes receiving the same single broadcast of the code packet. The spatial multiplexing becomes more efficient with increasing network size, which explains the advantage of multi-hop reprogramming as network size increases.

Apkt   i −1  (6) j −1  1 −  ∑ Ps (1 − Ps )   ∑ i =1      j =1 Assuming maximum number of hops to be hmax and the round time to be Tr, the expected multi-hop reprogramming time is Tconv ( M ) = Tr ⋅ E[ N r , hmax ] (7) ∞

For multi-hop reprogramming, Ps = LRM. For single-hop reprogramming, Ps = LRS, and the pages can not be pipelined. Therefore, if there are N nodes in the network, the reprogramming time for the single-hop mode is Apkt ∞    i −1 j −1   Tconv ( S ) = N ⋅ Tr ⋅ N p ∑ 1 −  ∑ LRS (1 − LRS )   (8) i =1      j =1 For DStream-SHM, we find the time to reprogram a single node and multiply that value by the number of nodes in the network. Note that we do not include the time required by the user to move from one node to another because such travel times differ from deployment to deployment. In order to compare the single and multi-hop reprogramming times for a given sensor network deployment, one should add these travel times to the single hop reprogramming times mentioned in this paper. Alternatively, all nodes can be concurrently reprogrammed through multiple base stations at a higher resource cost. The relative reprogramming time of single-hop to that of multi-hop is given by Tconv ( S ) Tconv ( S / M ) = = Tconv ( M )

Figure 1. Relative reprogramming time (single hop : multi-hop) as a function of link reliability for linear topologies

Figure 2. Relative reprogramming time (single hop : multi-hop) as a function of link reliability for grid topologies

B.

Energy Cost Let C be the energy cost of transmitting a single packet. The energy cost of receiving packets depends on the specifics of the underlying application such as sleeping schedules. Apkt ∞   Moreover, since receiving and idle listening have almost the  i −1 j −1  N ⋅ N P ⋅ ∑ 1 −  ∑ LRS (1 − LRS )   (9) same energy cost, the energy overhead beyond packet i =1    transmission can be directly computed from the   j =1 Apkt reprogramming time. Hence, in this analysis, we use the ∞    i −1 j −1  number of transmitted packets as a measure of the (3 ⋅ ( N P − 1) + hmax )∑ 1 −  ∑ LRM (1 − LRM )   reprogramming energy. The expected number of  i =1  j =1     Using Equation (9), Figure 1 and Figure 2 show the transmissions over a link for a successful transmission of a relative reprogramming time (single hop/ multi-hop) packet Nret is k =∞ 1 respectively for linear and grid topologies as a function LRM K = E[ N ret ] = ∑  k ⋅ ( Ps (1 − Ps )k −1 )  = (10) for different network sizes with LRS=0.95, Np=12 pages, Ps k =1 Apkt=48 packets, hmax=N-1, for the line topology, where N is Let the redundant set at hop h be Sh, where Sh is the set of the number of nodes, and hmax = m-1 for the n×m grid nodes at hop h that can be reprogrammed by one node at hop (ignoring the edge effects). h-1. Let |Sh| be the average size of the set. Moreover, let αh be 5

the cardinality of the subset of nodes at hop h-1 that can reprogram all the nodes at hop h. The additional energy cost to reprogram all the nodes at hop h given that all the nodes at hop h-1 have been reprogrammed is given by N p ⋅ N pkt ⋅ C ⋅ α h (11) Eh = K ⋅ N p ⋅ N pkt ⋅ C ⋅ α h = S Ps h The total energy overhead of multi-hop reprogramming all the nodes in a network with hmax maximum number of hops is h = hmax h = hmax  N p ⋅ N pkt ⋅ C ⋅ α h  E M = ∑ Eh = ∑  (12)  S LRMh h =1 h =1    For a linear topology of N nodes with Rtx = d, where d the spacing between nodes, and Rtx is the transmission range, Figure 3. Relative energy overhead (single hop : multi-hop) as a ,αh=1, |Sh|=1, and hmax = ( N − 1) . For an n×m grid topology, function of link reliability for linear topologies n   ignoring edge effects, with r = √2d,αh= , |Sh| =3, and  2 hmax = (m − 1) (ignoring the edge effects). Let Npkt = Apkt + 1 + E[Nr], where the second term is to account for the advertisement packet and the last term represents the expected number of request packets to successfully transmit the whole page (Equation 4). For single-hop reprogramming (Ps = LRS), the total energy to reprogram all the nodes is given by N p ⋅ N pkt ⋅ C ⋅ N ES = (13) LRS The relative energy consumption of single-hop to multihop reprogramming is given by, ES / M =

ES = EM

N p ⋅ ( Apkt + 1 + ES [ N r ]) ⋅ C ⋅ N LRS h = hmax

∑ h =1

 N p ⋅ ( Apkt + 1 + EM [ N r ]) ⋅ C ⋅ α h    S LRMh  

Figure 4. Relative energy overhead (single hop : multi-hop) as a function of link reliability for grid topologies

Apkt V. EXPERIMENTS AND RESULTS  ∞   (14)  i −1 j −1  S N ⋅ LRMh  Apkt + 1 + ∑ 1 −  ∑ LRS (1 − LRS )    We implement DStream having both multi-hop and single  i =1       j =1  hop features using the nesC programming language in = Apkt h = hmax   ∞  TinyOS. In this section, we compare the performances of j −1   i −1 S S LRS ∑ (α h )  Apkt + 1 + ∑ 1 −  ∑ LRMh 1 − LRMh   DStream-SHM and DStream-MHM using both testbed   h =1 i =1       j =1  experiments and simulations. The metrics that we use to

(

)

compare single and multi-hop reprogramming approaches are reprogramming time and energy. A. Calculation of Reprogramming Time and Energy For multi-hop reprogramming, time to reprogram the network is the time interval between the instant t0 when the BN sends the first advertisement packet to the instant t1 when the last node (the one which takes the longest time to download the new application) completes downloading the new application. Since clocks maintained by the nodes in the network are not synchronized, we cannot take the difference between t1 and t0. Although a synchronization protocol can be used to solve this issue, we do not use it in our experiments because we do not want to add to the load in the network (due to synchronization messages) or the node (due to the synchronization protocol). Instead we follow the following approach. When the BN sends the first advertisement packet, it reads its local clock and stores the current local time t0i in its external flash. Then it broadcasts a special packet called the sync packet after putting its node id i in the src field of the packet. It stores the time t1i when the sync packet is sent (i.e. when sendDone( ) event is signaled). Each node i in the network stores the local time t0i when it receives the first sync packet. It also stores the id of the node from which it received

Using Equation 14, we plot relative energy overhead (single hop/ multi-hop) versus LRM for linear and grid topologies for different network sizes. Figure 3 shows that the single hop mode is more efficient than the multi-hop mode for the linear topology with link reliability less than 0.8. Moreover, the difference increases, in favor of the single hop mode, as the network size increases. In linear topologies, only one node can be satisfied by the transmission by a node and this negatively impacts the energy consumption of the multihop mode. This is due to the low link reliabilities with |Sh| =1 for the line topology. Figure 4 shows that for a grid topology, almost irrespective of its size, the single hop mode is better when the link reliability is less than or equal to 0.8 and the multi-hop mode is better otherwise. Below multi-hop link reliability of 0.8, a redundant set of size |Sh| = 3 is not enough to compensate for the lower reliability, however, it becomes enough for multi-hop link reliabilities of more than 0.8. For a deployment with higher transmission ranges and hence higher values of |Sh|, the balance will shift in favor of multi-hop reprogramming.

6

the first sync packet. Let us define a parent of a node i to be the node j from which the node i receives the first sync packet. Then the node i broadcasts the sync packet (with its id inserted into the src field) after random time uniformly distributed between some interval (0,T). This is to avoid the collision of the sync messages broadcast by different nodes within the communication range of each other. Finally the node i stores the time t2i when it completes downloading all the pages of the new image. Note that a node i may receive many sync packets but it discards all of them except the first one. Also, a node sends a sync packet only once. So, this approach floods the sync packet across the network in a controlled manner. Let Ri be the reprogramming time for a node i- the time interval between the instant when the BN sends the first advertisement packet and the instant when the node i downloads the new code image completely. Let the parent of the node i be i1 whose parent is i2 and so on, and in is the BN. Reprogramming time Ri for node i is

packet is dropped. Otherwise if n1 and n2 are neighbors, n1 generates a random number u uniformly distributed in the interval [0,1] and if u