Mechanism for code update on logical groups through exploiting multiple base stations in sensor networks

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.


Wireless Sensor Networks (WSNs) are finding increasing Internet-user access for public and commercial applications due to their presence now on the World Wide Web. Internet users (aka clients) utilize sensors on the web for arbitrary applications anytime. Likewise, the web portals (aka servers) attempt to multiplex disparate applications for an increasing number of clients. To accommodate time-varying requirements of multiple applications, user application codes are dynamically updated on WSNs. While current protocols for code update address resource efficiency through in-network communication and computational optimizations for code updation, however, none of the work reported so far addresses the facts that a) Code update through multiple base stations is totally oblivious to the code heterogeneity as in web portals, b) short-lived applications may spur code update over the entire WSN eventually dominating the applications' execution duration, c) the long-lived applications may wastefully update code on sensor nodes which have limited remaining lifetime, d) applications which just require limited number of sensor nodes tend to trigger futile code update on all the sensor nodes of that type, e) without any regard to the constraints of forwarding sensor nodes, code update tends to be greedy for shortest paths and nearest sensor nodes f) retransmissions of lost segments are acknowledged back to penultimate hop, engaging the limited memory resource of the sensor node. In this paper, we propose SIPHON code update mechanism for web-portals based WSNs which i) exploits existence of multiple base stations to perform code update on all the sensor nodes of certain type, ii) performs application-time-aware selective code update by comparing it with the code update time, resulting in network longevity, iii) achieves network longevity and avoids network disconnections by performing sensor node energy aware code update, iv) performs code update on only the required number of sensor nodes of certain type, with an aim of achieving path stability and quick convergence, v) provides energy consumption fairness and prevents wasteful code forwarding on tracks which are vulnerable to disconnections resulting into a load balanced code update, vi) uses nearest base station based lost page recovery mechanism to reduce multihop retransmissions. Our testbed implementation shows that SIPHON achieves considerable savings in code update latency and conserves energy for large file sizes through multiple base stations as the number of applications (logical groups) increase. It also improves communication optimization by circumventing wasteful retransmissions.

1. Introduction

Multi-Application Wireless Sensor Networks (MA-WSNs) in these days have become focal point for researchers. Large number of small, inexpensive devices that integrate sensing, computation and communication are now available even over the World Wide Web (WWW) enabling internet-users to access them. These clients utilize them according to their custom needs. The requirements and demands of time varying clientele may also change with time leading towards the need of dynamic update of application code on MA-WSNs. In large scale MA-WSNs, Sensor Nodes (SNs) can be arbitrarily located any where within the network for performing code update on such networks. At present, dynamic update of application-code on them is performed with emphasis on resource efficiency that is achieved through communication and computational optimization. However, in WWW, the clients have a single ingress/egress point of contact with MA-WSNs through web-portals, which are also responsible for multiplexing and scheduling respective applications. Such noncompliance of contemporary code update protocols with web-portals warrants significant overhaul to these schemes.

Current code update protocols [1-10] are, by definition, tailored to single base station-based WSN topologies. These protocols a) either overlooked the fact that today's WSN deployments are realized through multiple Base Stations (BSs) for performance gains, load-balancing, and reliability or b) code heterogeneity that results from logical grouping of SNs into multiple application groups is unbeknownst to them. For instance, Freshet [11] uses multiple BSs for code update by sending same application code to all the SNs. However, it does not address Logical Group (LG) specific code update requirements of different types of SNs.

WSNs' applications usage varies according to the missions they ought to perform and may therefore be categorized into two groups a) short-lived applications and b) long-lived applications. Respective examples can be like capturing snapshot of an object of interest through image sensor and continuous temperature monitoring of certain premises. In MA-WSNs, there might be a scenario where code update for a short-lived application is initiated unfeeling to the fact that Code Update Time (CUT) for widely scattered SNs, belonging to that LG, may dominate application's execution time itself. As a contrary example, there may be a scenario where code updates of long-lived applications are launched on SNs with limited remaining life time (owing to depleted batteries), committing unreliable SNs that may give in quickly and never execute the application at all. Such wasteful code updates should not be performed at all. Existing protocols do not appreciate let alone address these issues.

LGs of SNs have been proposed in [5, 14] which consider only the type and location of sensors to be the metadata to group SNs into LGs. Code updates on such LGs as proposed in [3, 4] are however aloof to the users' requirements, and lead to unnecessary code update on all the members of the LG. Neither of the proposed work attempts to customize code update in terms of specific user requirements.

To propagate code on LGs, recent code update protocols [3, 4] repeatedly use closest SNs for forwarding code to the destination, resulting in early die out of nearest SNs and form a disconnected network. Such greedy forwarder selection procedures compromise network connectivity and should not be adopted since code updation is merely a network configuration activity that should not be detrimental to sensing activities.

Existing protocols address lost segments recovery by either unicast request to the source, which is only one hop away [2] or broadcast request to the immediate hop [15]. The sources and the SNs at the immediate hop maintain the segments in their external memory for a defined time, until the SNs in next hop get updated. This approach is good for WSNs where all the SNs are needed to be updated, but these mechanisms unnecessarily utilize the in-network memory resources, especially for LGs where only a subsets of SNs, not collocated are needed to be updated. Such mechanisms must also be modified for updating code on LGs.

In this paper, we present SIPHON, a code update mechanism that carefully addresses the aforementioned shortcomings. SIPHON is a multiple BSs exploitation scheme, which performs an overall remote code update management. SIPHON focuses on network longevity, reduced latency in code update, avoidance of network disconnections, stabilized sensing and network operations, sensing fairness, prevention of beaten tracks and reduction of multihop retransmissions. SIPHON is developed to support remote code update on LGs with following design considerations.

a) Application-time-aware code update: achieves network longevity by establishing a cost-benefit relationship between the CUT and Application Execution Time (AET).

b) Node-energy-aware selective code update: avoids network disconnections and SN outages by mapping the AET with the remaining energy resource of the SNs.

c) User-specified objective function-based code update: achieves node-level balance between code updation activities and routine sensing related operations for SNs of the same LG, by preferring subsequent code update activities on SNs which were less utilized earlier.

d) Topology-aware code update through load balancing: provides energy consumption fairness and prevents wasteful code forwarding on tracks which are vulnerable to disconnections.

e) Nearest BS-based lost page recovery request: reduces requirements for extensive in-network memory resources for retransmission of code segments and mitigates multihop retransmissions by sending requests to and getting retransmissions done from the nearest BS.

We have implemented testbed showing that SIPHON significantly reduces CUT during code update mechanism. The results show that energy consumption at SN and network level is reduced for large file sizes, through multiple BSs, as the number of applications (LGs) increase. SIPHON results in improved communication optimization by circumventing wasteful retransmissions.

The remainder of the paper is organized as follows. Section 2 presents the related work. Focus of section 3 is on the detailed design of SIPHON. SIPHON operations are presented in Section 4 of the paper. Section 5 provides implementation details and finally Section 6 concludes the paper.

2. Related Work

The earliest sensor network reprogramming protocol XNP [6] only operates over a single hop and updates all the SNs with in the range of single radio.

The MOAP [2] extended this to operate over multiple hops. MOAP distributes the code update to the whole WSN through a single BS by utilizing store and forward mechanism. Lost segments are identified by receiver using a sliding window and are re-requested using a unicast message to prevent duplication. A keep alive timer is used to recover from unanswered unicast retransmission requests. When it expires, a broadcast request is sent. However MOAP does not addresses a scenario where subset of SNs requires code update. MOAP also uses strong assumption that latency does not affect code update whereas real time applications do not accommodate latency. Store and forward mechanism consumes memory of every SN in the network which is a scarce resource. MOAP doesn't compromise on receiving code update segments out of order thus increases overhead of re-requesting. It is a time consuming process because if network comprises hundreds of SNs, then single BS will take a very long time to update code on the whole network.

SCUBA [7] performs code updates in three-phased approach. SCUBA permits corrupted SNs to be repaired through code update in the presence of an attacker given that the attacker is not in the network at the time of the repair and blacklists irreparable SNs. In the first phase of basic recovery process, BS commands a SN to setup Indisputable Code Execution environment (ICE) and certifies it using Pioneer. Then, in the second phase it sends the SCUBA update program to run in the secure environment, which then updates the code. In the third phase, attestation primitives certify the update program, the update to be installed, and processor state. Like MOAP, SCUBA does not support code update on subset of SNs. If a SN to be updated is many hops away from BS, then all the intermediate hop SNs have to be part of code update process voluntarily or involuntarily thus using maximum time and energy resources of the network.

The protocols that are substantially more sophisticated than MOAP and SCUBA, and which define the foundation work today are Deluge [8], MNP [9], Stream [10] and Freshet [11].

Deluge [8] shares many features with MOAP and additionally allows intermediate SNs to reliably transmit code images without receiving complete image of the code. Deluge propagates the same code all across the sensor network and does not support heterogeneous code update for disparate SN platforms. Since Deluge relies on heuristics in order to prevent SN contention, relatively suboptimal paths may be formed in the code update topology. Aqueduct [12] is an enhancement of Deluge that addresses its incapability to support heterogeneous hardware platforms. Likewise, MNP [9] addresses the hidden terminal problem that arises due to parallelization of advertising and page downloading.

Stream [10] is an enhancement common to Deluge and MNP that decouples code that is to be updated and the reprogramming protocol code. It proposes pre-emptive deployment of reprogramming protocol code on SNs. Code update is therefore done with significantly reduced redundancy in bandwidth utilization. The authors have also proposed duty-cycle aware code update that allows SNs to sleep while these are not participating in code update activity.

Freshet [11] uses multiple sources to deliver code update to SNs targeting energy conservation while speeding up the code update process. All the sources in Freshet broadcast same code image to all the SNs at the same time by partitioning the network into smaller portions according to source region only. However, it does not address application specific code update requirements of different types of SNs.

The closest work to our theme of utilizing LGs is Melete [3]. It proposes reliable storage and execution framework for simultaneous applications that run over subset of SNs. These SNs may not be grouped together on the basis of proximity, rather on the basis of commonality of application code. However, Melete does not optimize simultaneous code update across multiple applications.

MCP [4] is a recently published paper on code update on multi-application WSNs. It is a multicast based code redistribution protocol that addresses statelessness of Melete. Here, instead of updating code on all SNs MCP sends code to selected SNs by using subset of neighboring sensors to contribute in code update. MCP enables SNs to take code update from its neighbor SNs instead of querying BS. Using in-network sources instead of BS, results in reduced update time and communication overhead. Doing so, however, affects life time of sensor network by over utilizing individual SNs' resources, resulting in quick battery depletion and SN outages. This may cause network disconnections resulting in total operational failure. Likewise, if none of the neighboring SNs contain required code segment, the request and response must travel through long hops resulting in communication overhead.


This section describes SIPHON at length in order to realize code update mechanism for LGs in WSNs.

3.1 Assumptions

Our architecture is based on the integration of Internet with WSN which is based on Commercial Off-The-Shelf (COTS) hardware through a default BS. Internet users access WSN through a web portal to subscribe different sensing services. The WSN may consist of multiple BSs and several static SNs. Each SN has multiple on-board sensors, e.g., temperature, light, sonar, vibration, etc. When a user subscribes to a certain type of application, such as surveillance application, all the SNs with on-board temperature sensor become potential candidates for servicing the application, forming a group. Since, these SNs may not be in spatial proximity, such a group is henceforth referred to as a LG. Such groups are temporal in formation, and consequently, a single SN may become part of multiple LGs simultaneously. Every SN, BS, and group all have unique IDs.

BSs maintain resource and topology information of the network. The SNs communicate with each other and with BSs wirelessly. Inter-communication of BSs is either wired or wireless. The wired BSs are aware of each other's presence because they are under the same administrative domain. The wireless BSs may or may not know each other because their deployment is ad hoc. In case they don't, BSs can discover each other by discovery procedures, and form a spanning tree rooted at the originator BS. The communication between BSs and SNs can be single hop or multihop. Fig. 1 shows physical view of a SIPHON architecture, where a sensor network, containing LGs LG1, LG2, LG3, is operating through multiple BSs, and is connected to the Internet.

3.2 SIPHON Layered Architecture

Existing code update protocols deploy single BS for updating code on all the SNs at large scale. It suits well to the environments where all SNs are needed to be updated; however they face challenges like reliability and latency degradation because as the network grows deeper, the probability of successful forwarding of code update pages decreases, and per hop latency adds up cumulatively. For the networks where LGs are required to be updated, single BS deployment doesn't perform very well, as it requires number of forwarding SNs to reach remotely placed LG nodes; this seemingly avoidable use of forwarding SNs results in reduction of its life time and an early die out of the network. This mechanism of sending code update to LGs, involves all the intermediate SNs albeit unwillingly, unnecessarily utilizes the network resources.

SIPHON, our multiple BS exploitation scheme performs remote code update through multiple BSs. It does so upon LGs to achieve solution to problems stated above. In addition, it achieves reduction in number of end to end hops, energy consumption of the SNs and improves overall performance of the network. Multiple BSs are also exploited to address congestion collapse in the network during heavy reprogramming activity. Sinceplacement strategy of multiple BSs is not the ambit of our research, we refer readers to optimal BS placement strategies as in [17-20]. Fig. 2 shows the layered architecture of the proposed mechanism, wherein

* Communication layer provides interfaces to the hardware layer and OS layer.

* Code update layer contains number of existing code update mechanism and our proposed mechanism SIPHON along-with the modules.

* Application layer consists of the application service components that perform application specific tasks. These components are built on top of the code update layer and are run over the modules in code update layer.

Table1 enlist variables and notations used throughout in SIPHON.






Wireless sensor network




World wide web


Code update


Sensor node


Version number of application


Base station


Node ID of receiver


Logical group


ID of the originator BS


Code update time

Flag = 3-bit

* ACK=acknowledgment

* NACK= no acknowledgment

* WC=wrong code


Application execution time


Received signal strength indication


User interaction module


Path cost


Round Trip Time


Number of retransmissions


Communication control module

Table1: List of used variables and notations

3.2.1 User Interaction Module

Requirements of internet-users change according to their needs. There might be some internet-user A whose requirement is to continuously monitor variations in temperature of certain premises. Such a temperature monitoring application is executed through a temperature LG. A needs all SNs of the temperature LG to respond. For such user, BSs simply solicit all sensors of temperature LG. On the contrary there can be another user B, whose requirement is more specific in the sense that B wishes to receive temperature from limited number of sensors of temperature LG. Here, the role of User Interaction Module (UIM) comes into play. It takes desired count of SNs of temperature LG and helps SIPHON achieve restricted node-level code updation activities and allows more time and resources for routine sensing-related operations. UIM also maintains code update counts as the number of code updates performed earlier on a specific SN belonging to a LG. Proc_1 () presents UIM, where sending of code update to limited number of SNs is demonstrated. Thus it helps BS to search SNs with the least code update counts within a LG. If the searched SNs are more than required, then BS selects SNs according to lesser transmission costs in terms of hop count, RSSI and number of retransmissions.

Procedure 1: User Interaction Module

Begin Proc_1 ()

Code_Update_Count [node_number] =0;

For (all the nodes in LG)

If (code updated)

code_update_count[node_number]=Code_update_count[node_number] +1;

End if

End for

If (code update is required on lesser nodes in LG)

Search the database for the nodes with lesser Code_update_count

If nodes with lesser Code_update_count > user required nodes

Select target nodes according to less transmission cost

End if

Send code update to the selected nodes

End if

End Proc_1 ()

3.2.2 Application Time Management Module

The code update requests received by BS may contain requests where CUT, for widely scattered SNs belonging to that LG, is dominating application's execution time. To avoid such inconsistency in updation process, there is dire need for establishing a cost-benefit relationship between CUT and AET that should perform application time-aware code update. To cater for it, application time management module in Proc_2 () is proposed that works as follows: if time to be taken in code update is greater than the user specific AET then instead of updating all SNs of the target group only SNs closer to BS are chosen. Such a mechanism results in network longevity. Note that SIPHON allows user requirements to be somewhat serviced without compromising on lifetime of the network.

Procedure 2: Application Time Management Module

Begin Proc_2 ()

If (CUT > AET)

Then do not update the entire LG

For (no. of nodes in LG)

Select nodes nearest to BS

End for


Update whole group

End if

End Proc_2 ()

3.2.3 BS Discovery Module

For special instances of deployment, in which multiple BSs are not aware of each other, it is important to introduce a discovery mechanism. Such discovery allows these BSs to synergize the code update activities. In order to do so, BS discovery module is explained in Proc_3 (). According to Proc_3 () originator BS broadcasts BS discovery request in the wireless network. Receiving BSs further broadcast discovery request till it reaches BSn. Every BS waits for a RTT, measured on the basis of propagation time and stall-time.

Propagation time is maximum distance between BSs.

Stall-time is in micro seconds for a reason that BSs are high-end machines.

BS_waiting_ time = RTT

RTT = 2 * propagation time * stall-time

In case a BS hears same request it waits twice of the BS_waiting_time, understanding that there are other BSs in the network and BS must wait till all BSs are discovered. After expiration of BS_waiting_time, BSs recursively reply and get informed about each other's existence.

Procedure 3: BS Discovery Module

Begin Proc_3 ()

Broadcast BS discovery request up-to BSn

If receiving BS does not hear same request

Wait up-to BS_waiting_time


Wait up-to twice of BS_waiting_time

End if

After expiration of RTT BSs reply recursively

End Proc_3 ()

The output of BS discovery process is listed in Table 2. Distance field shows the hop distance of every BS from other.

No. of BSs





BS2=1, BS3=1, BS4=2



BS1=1, BS3=2, BS4=1



BS1=1, BS2=2, BS4=3



BS1=2, BS2=1, BS3=3

Table 2: Output of BS discovery process

3.2.4 Inter-BSCommunication Module

After BS discovery, all BSs must also become aware of the SNs which can be most conveniently accessed from each BS. The information is collected individually and subsequently shared by all BSs with their neighbors as a distance vector. This information includes important statistics as shown in fourth column of the Table 3.

No. of BSs



ID of SN , RSSI, PC, NoOfReTx, Battery



LG1 (A1, A2, A3, A5)

LG2 (A1, A2, A5, A6)

LG3 (A1, A2, A4)

(A1, 53, 1, 3, 2.9), (A2, 58, 2, 7, 2.9), (A3, 22, 1, 0, 3.0), (A4, 66, 2, 3, 2.7), (A5, 72, 4, 5, 2.8 ), (A6, 55, 5, 10, 2.9)



LG1 (A1, A2, A3, A5)

LG2 (A3, A4, A5, A6)

LG3 (A1, A2, A4)

(A1, 20, 3, 6, 2.9), (A2, 25, 4, 7, 2.9), (A3, 42, 2, 4, 3.0), (A4, 86, 2, 2, 2.7), (A5, 95, 1, 3, 2.8), (A6, 125, 1, 2, 2.9)

Table 3: Important statistics of LGs and SNs at every BS

SIPHON uses this information to select suitable BSs which have the best candidate forwarding nodes to the target SNs. BS is selected according to cost matrix defined on the basis of Received Signal Strength Indication (RSSI), Path Cost (PC) and Number Of Retransmissins (NoOfReTx). BS having stronger RSSI, lesser PC and lesser NoOfReTx to a particular node or LG is chosen accordingly.

RSSI is a measurement of the power present in a received radio signal.

PC is an estimate of the number of transmissions required to send a packet from a SN to its base. It takes into account the number of hops and the number of retransmissions per hop that is necessary for a SN to send its packet to BS.

NoOfReTx is a measurement of accumulative retransmissions on a particular SN during one session

SIPHON uses two different procedures for using this information to select suitable BSs which have the best candidate forwarding nodes to the target SNs.

IBS Selection for Code Update on LGwith Single Node

Proc_4_1 () explains the inter-BS communication for BS selection for a single SN. All BSs check the costs of all other BSs to reach SN. The most suitable BS requests application code from the originator BS. If it is not an adjacent BS to originator BS, the intermediate BSs simply relay the code update.

Procedure4_1: Inter-BSCommunication for BS Selection for Single Node LG

Begin Proc_4_1 ()

Originator BS keeps cost record from all other BSs

Compare cost of other BSs

Select BS with least cost

Send application code to selected BS

End Proc_4_1 ()

IIBS Selection for Code Update on LG with Multiple Nodes

There may be a situation when there are more than one nodes within a logical group, and more than one BS are eligible for updating code on some of the SNs. In such case, BS closer to the originator BS is a stronger candidate for updating code. It results in time savings to relay code to soliciting BS. Proc_4_2 () explains the procedure.

Procedure 4_2: Inter-BSCommunication for BS Selection for Group

Begin Proc_4_2 ()

Originator BS keeps cost record from all other BSs

Compare cost of other BSs

If more than one BSs eligible for CU on individual LG nodes

Select BSs closer to originator BS


Select BS with least average cost for group

End if

Send application code to the selected BSs

End Proc_4_2 ()

3.2.5 Communication Control Module

This part explains Communication Control Module (CCM) at BS and target sensor nodes individually.

I. Communication Control Module at BS

In the reported literature, code update phase tends to be greedy for shortest paths and nearest SNs, without giving due consideration to the constraints of the forwarding SNs. These intermediate SNs are chosen repeatedly for forwarding, resulting in an early depletion of their batteries and consequent network disconnections. To ensure energy consumption fairness, SIPHON must perform topology-aware code update through load balancing and choose forwarding SNs on the basis of their remaining battery statuses. This is achieved through CCM as defined in Proc_5_1 (), which monitors energy levels of each node and chooses a forwarding node at every hop towards the target SN. CCM enables the prevention of wasteful code forwarding on those tracks which are vulnerable to disconnections.

Procedure 5_1: Communication Control Module

Begin Proc_5_1 ()

BS is sending code segments

While (node! = target node)

Join one node from each hop to form a forwarding path // from BS to target node

If there are more than 1 node in ith hop

Then select node with higher battery and better connectivity

End if

End while

End Proc_5_1 ()

II. Communication Control Module at Target Sensor Node

In SIPHON, whenever a SN receives code update it checks if the application code received is of the same LG. In case it is, SN checks for the version number. SN only accepts and installs the application code if it is a newer version. After installation, SN sends an acknowledgment to BS, to ensure that the target SN has installed the application code correctly as mentioned in Proc_5_2 ().

Procedure 5_2: Set of Actions to be Performed at Target Node

Begin Proc_5_2 ()

If CU received!=functionality performed by node for particular LG

Set wc = 1 and send msg to BS



If Vno > current Vno

Accept and install

If installed

Set ack=1


Set nack=1

End if



End if

End if

End Proc_5_2 ()

3.2.6 Energy Management Module

Existing push-based code update mechanisms launch code update on a SN without taking the fact into consideration that the target SN might be low in resources and die out during following operational phases

* While receiving code segments of the application,

* After receiving the application but during installation phase,

* After receiving and installing the application but during performing operations.

Sending code update to such SN not only results in useless resource utilization, and early outages of SN, but also becomes basis of disconnection of that network. SIPHON avoids these issues by mapping the AET with the remaining energy resource of the SNs and presents energy management module in Proc_6 (). BS compares the AET with the remaining batteries of the SNs of LG. If remaining battery of any of the SN is lesser than the AET, then it checks whether that SN is the sole SN of the group sensing in that region. In case it is, another check is introduced that determines if sending code update on that SN may disconnect the network. For such case, the code update activity is called off, and vice versa.

Procedure 6: Energy Management Module

Begin Proc_6 ()

If (remaining battery of the node < AET)

If (no. of nodes in ROI = 1)

Switch (case)

Case 'network will disconnect by removal of that node';

Do not update code

End case

Case 'network will remain connected';

Do update code

End case

End if

End if

End Proc_6 ()

3.2.7 Retransmission Management Module

The existing protocols consider segment loss of a code update page to be simply another packet retransmission activity. It is due to the fact that segments of a particular page follow the same path. Loss of a segment or a few segments implies unicast retransmissions from the previous hop taxing its energy and memory resources. In situations, where the previous hop does not contain the requested segment, the request is relayed all the way back to BS. These mechanisms suit well to the situations where whole network is getting updated because each SN keeps code into its memory until all SNs in the next hop get updated completely. The networks where subsets of SNs are getting updated, these mechanisms unnecessarily utilize the in-network memory resources and limited energy of every SN.

SIPHON however considers lost segment recovery as a special case. SIPHON modifies the mechanism and uses nearest BS for recovering lost segment as mentioned in Proc_7 (). This approach a) reduces all wireless hops for large-scale networks and b) minimizes memory requirement at each SN, as SNs do not maintain code segments in their memory.

Procedure 7: RetransmissionManagement Module

Begin Proc_7 ()

If (segment lost)

Node will request nearest BS // lost segment retransmission

If nearest BS has not requested CU

Request originator BS for CU

End if

BS sends CU to requested node

End if

End Proc_7 ()


This section describes different operational scenarios of code update. Code update can either be proactively initiated through BS or solicited by the SNs. Therefore SIPHON presents two variants:

* SIPHON-push; push-based code update

* SIPHON-pull; pull-based code update

In both cases, code update request can be accepted, rejected or delayed.

4.1 SIPHON-push

BS initiates code update on a logical group periodically or a-periodically as shown in Fig. 6. Periodic updates are based on administrative policies (upgrade or addition) and software maintenance requirements. Administrative policies could include inserting newer applications into the system, refreshing middleware, upgrading new software versions into running system, modifying data collection and managing performance control etc.

A-periodic updates can be event based or error-based. Event-based code updates include reconfiguring performance, reconfiguring security and accounting etc. On the other hand, error-based code updates include patching logical errors and fixing bugs.

4.2 SIPHON-pull

A single SN or multiple nodes belonging to a logical group may request for code update a-periodically as mentioned in Fig. 7. SIPHON-pull is triggered when either a SN or a group of SNs request code update. Consequently, following code update scenarios might arise

* code update is triggered on the SN itself

* code update is triggered for the members of its logical group

* code update is triggered on a set of SNs, on another parameter other than logical group

SIPHON-pull may include routing kernel configuration on some available nodes in the near vicinity of a node that faces battery depletion and cannot route anymore. Likewise, due to mobile behavior of some of the SNs, with the commissioning of new nodes into the network, and time-varying distribution of sensed events, topological changes and modifications to communication paradigm might be required. Some of the consequent code updates could include sensor settings, user profile settings and mobility support configurations.

4.3 Operations

This part describes the procedures necessary for code update in different operational scenarios as in SIPHON-push and SIPHON-pull. If there are more than one BS in the deployed topology, SIPHON allows them to be utilized for efficient code update by appropriating BS discovery protocol. According to the defined assumptions there can be a) one or more than one SN in the LG, b) one or more than one BSs, c) BSs can be wired or wireless and d) wireless BSs may or not know each other. Considering these aspects, possible scenarios in each category of wired BSs and wireless BSs are listed in Table 4 and Table 5 respectively. Before discussing them few definitions are enlisted here:

The presence of a single BS is represented by 0 and for multiple BSs it is represented by 1. A LG with a single SN is represented by 0 and for many, it is 1. Likewise, known BSs are those which are aware about each other are represented by K as 0 and vice versa, 1

















Same as Fig. 8

Table 4: Code updates generated by wired BSs














Same as Fig. 8





Same as Fig. 8





Same as Fig. 8





Same as Fig. 8





Same as Fig. 9





Same as Fig. 10





Same as Fig. 10 with a minor change of performing routine 1 for BS discovery

Table 5: Code updates generated by wireless BSs

4.3.1 Operational Scenarios for SIPHON-push

All SIPHON-push scenarios (1, 4, 6, 7, 8, and 9) have a common denominator-single BS. Consequently, the effect of the awareness of BSs and of the number of SNs to be updated is trivialized. In essence, scenario 1 satisfies for all. Scenarios (2,10) and (3,11) being internally different in terms of wired and wireless connectivity, are only different in terms of code update on single SN or multiple SNs of a logical group. Therefore each of these sets can be characterized by scenario 2 and scenario 3 respectively. Scenario 5 is given as a distinct scenario since it involves BS discovery procedure.

I. Operational Scenarios for Wired BSs

a)Scenario 1: Single BS, LG with single node

In this scenario, BS sends application code to LG of single SN, given in Fig. 8. After receiving code update, target SN performs Proc_5_2 () explained in CCM at target sensor node operation module.

b)Scenario 2: Multiple BSs, LG with single node

In this scenario before updating code on single node LG, BS selection is done according to Proc_4_1 () explained in inter-BS communication module. Sequence diagram in Fig. 9 explains the operations to be performed for scenario 2 where multiple BSs are part of the network for updating a single SN.

c)Scenario 3: Multiple BSs, Multiple nodes LG

In this scenario BS selection is performed according to Proc_4_2 (), explained in inter-BS communication module. Sequence diagram in Fig. 10 explains the operations to be performed for scenario 3 where multiple BSs are part of the network.

II. Operational Scenarios for Wireless BSs

d)Scenario 5: Multiple BSs, Single node LG, Not known

For the scenario where deployed BSs are unaware of each other, before sending code update to target SN, the initial step is to discover BSs. BS discovery is performed according to Proc_3 (). After discovering BSs, inter-BS communication takes place for selecting BS with lesser cost according to Proc_4_1 (). The selected BS sends code update to target SN as explained in Fig. 11.

4.3.2 Operational Scenarios for SIPHON-pull

In SIPHON-pull, SN requests for code update. The only difference SIPHON-pull operation has from SIPHON-push is that the request is routed through the shortest path at that time (Fig. 12). A BS that has received the request now executes the most appropriate SIPHON-push procedure(s) and if request-receiving BS is not originator then it requests originator BS for application code and sends it to SN. After receiving the code update, SN performs Proc_4_2 (). It is interesting to note that this scenario underpins the exact functional difference routing packets and updating code.

5. Implementation

5.1 SIPHON operation

SIPHON is based on multiple BSs deployment scheme which is used for overall remote code update management. Internet clients use web browser to access the webpage (Fig. 13b) in order to specify User Requirements, which in turn are passed on to Originator BS. Other BSs are connected through Ethernet (100BaseT). RSSI, PC, NoOfReTx, and BatteryStatus of each SN is monitored on all BSs and a copy is sent to the Originator BS after TimeOut= 10 minutes. When a SN or group of SNs asks a BS for code update, this request is first sent to the Originator BS. BS which has the best (PC, RSSI, NoOfReTx) is chosen for code updation. Battery voltage of at-least 2.7V is our deliberate check for triggering code update to prevent SNs from collapsing after code update, and failing to execute application. Furthermore, load balancing is also achieved through it by leaving out SNs with lower battery voltages for code forwarding.

Usecase specific SIPHON Considerations

a) Application time management module: If time to be taken in code update (RTT + Application_TX_Time) is greater than Application_EXECUTION_Time (specified by the user) then code update is not triggered on all SNs within that LG. Instead only the SNs with the minimum PC to BS are chosen for code updation

b) Energy management module: If in case, there is only one SN with acceptable BatteryStatus in a certain region of interest, and depletion of the battery of this SN does not result into network disconnection, only then code update activity may be performed, otherwise refused.

c) User interaction module: Application requiring limited number of SNs from a LG of SNs must only choose the SNs on the criterion of lowest code_update_count (number of code updates previously done on a specific SN).

5.2 Testbed setup

A test bed of 7 Crossbow Iris nodes is deployed in an office area of 30x25 meters. Two BSs were placed at a distance of 10 meters, connected with Ethernet cable. BS1 was declared as Originator BS. SNs were deployed as shown in Fig. 13a between BS1 and BS2. The SIPHON mechanism is implemented in C by modifying the operation of XOTap [8, 13, 16] at BSs. BS implements all procedures as given in section 5.1 through a file

A SN within the network can be in different operation states. A SN can be idle, receiving/transmitting or logging data into its flash memory. Fig. 14 depicts the state diagram of a SN in different operation states.

For the test bed topology in Fig. 13 a, if SN number 2 is being programmed then the status of other SNs will be either transmitting/receiving or idle as shown in the Table 6. Each state draws different current from the battery and energy consumption varies according to the operation status of SN. The SN which is more used in forwarding takes more energy as it draws more current from the battery. Multiple BSs technique uses less number of forwarding SNs and hence saves battery.



Radio Transmit

Radio Receive

Data logging into flash

Total current consumed by each mote/sec







Current in each state





Table 6: Current Requirements for iris nodes under different operations

5.3 Trials and experimental results

Usecase A: User requests a CountToLedsAndRfm code update only on 3 SNs with the lowest PathCost. Since SN 4 has battery voltage less than 2.7V, it is not selected, although it meets the PathCost constraint. Instead, SN 3 gets selected for code update. Note that code update is not triggered on other SNs, although all of them have the requisite LEDs needs to execute the requested application.

Usecase B: We have also performed code update to substantiate its efficacy both in time and energy consumption. We have varied code sizes (Blink, SensorAcquisition, Oscilloscope, CountToLedsAndRfm and MutihopBroadcast), and the number of BSs, shown in Table 7.







Size in Kbps






Code update time from single BS* (sec)






Code update time from multiple BS* (sec)






Table 7: Code update time of different applications

It is evident from Fig. 15 that while using SIPHON, considerable reduction in code update latency for large file sizes through multiple BSs is achieved. As Large files have more pages of code segments to be sent over the air and suffer more from retransmissions so by deployment of SIPHON, time delay is controlled. In short code update is a function of time, file size and shortest path.

To estimate the average voltage drop at destination SNs the network was deployed for 10 hrs. The code update on LGs were performed number of times by using single BS and multiple BSs, for observing voltage drop on different times. Results show that battery depletion is lesser in the case of multiple BSs as shown in Fig. 16.

It can be seen from the obtained results in Fig. 17 that number of retransmissions considerably reduces by SIPHON.

Multiple BS deployment provides the SNs of the network with strong connectivity which results in reduction in path cost as compare to the path cost in single BS network shown in Fig. 19. Lesser the path cost lesser the time of transmitting the code to the target SN.

6. Conclusion

In this paper, we propose a code update protocol, SIPHON, multiple BSs exploitation scheme, for achieving network longevity, reduction in latency for code update, network connectivity, stabilized sensing and network operations, sensing fairness and reduction of multihop retransmissions in code update in MA-WSNs over the WWW. The layered architecture shows that SIPHON, a) achieves network longevity by performing application time aware code updates, b) avoids network disconnections by monitoring the status of SNs, c) evades unnecessary communication messages and d) keeps most of the computation workload over BSs. SIPHON selects forwarder SNs in every hop to achieve load balanced code update resulting in increased network life time. Experimental results are obtained for single BS based code update and for SIPHON, multiple BS based code updates. The results show that i) with every increase in file size CUT lessens in SIPHON as compare to single BS based code update, ii) retransmissions reduce significantly, iii) RSSI gets strong, iv) the path cost reduces in SIPHON and v) average battery depletion of the network also lessens by SIPHON.

7. References

[1] Levis, P. and Culler, D. 2002. Mat´e: a tiny virtual machine for sensor networks. In ASPLOSX: Proceedings of the 10th international conference on Architectural support for programming languages and operating systems. 85-95.

[2] T. Stathopoulos, J. Heidemann, and D. Estrin. A remote code update mechanism for wireless sensor networks. Technical Report CENS-TR-30, UCLA-CENS, November 2003.

[3] Y. Yu, L. J. Rittle, V. Bhandari, and J. B. LeBrun, "Supporting Concurrent Applications in Wireless Sensor Networks," In International Conference on Embedded networked sensor systems (SenSys), pages 139-152, 2006.

[4] Weijia Li, Youtao Zhang, Bruce Childers: MCP: An Energy-Efficient Code Distribution Protocol for Multi-Application WSNs. DCOSS 2009: 259-272

[5] Mottola, L., Picco, G.: Programming Wireless Sensor Networks with Logical Neighborhoods. In: Proc. of the 1st Int. Conf. on Integrated Internet Ad hoc and Sensor Networks (InterSense 2006).

[6] J. Jeong, S. Kim, and A. Broad, "Network Reprogramming," Berkeley, California, USA, Aug. 2003. [Online]. Available:

[7] Arvind Seshadri, Mark Luk, Adrian Perrig, Leendert van Doorn, and Pradeep Khosla. "SCUBA: Secure Code Update By Attestation in Sensor Networks." ACM Workshop on Wireless Security (WiSe), September 2006.

[8] J. Hui and D. Culler. The dynamic behavior of a data dissemination protocol for network programming at scale. In Proceedings of ACM Conference on Embedded Networked Sensor Systems (SenSys), November 2004.

[9] S. S. Kulkarni and L. Wang, "MNP: Multihop Network Reprogramming Service for Sensor Networks," in IEEE ICDCS, Columbus, Ohio, USA, Jun. 2005.

[10] R. K. Panta, I. Khalil, and S. Bagchi, "Stream: Low Overhead Wireless Reprogramming for Sensor Networks," in IEEE INFOCOM, Anchorage, Alaska, USA, May 2007.

[11] M. D. Krasniewski, R. K. Panta, S. Bagchi, C.-L. Yang, and W. J. Chappell, "Energy-efficient, On-demand Reprogramming of Large-scale Sensor Networks," ACM Trans. on Sensor Networks, vol. 4, no. 1, 2008.

[12] Lane A. Phillips. B.S., University of Nebraska, 2000. Aqueduct: Robust and Efficient Code propagation in Heterogeneous Wireless Sensor Networks

[13] XMesh User's Manual Revision C, March 2007 PN: 7430-0108-01

[14] Martin J Colley and Robert P Stacey, "Forming Logical Node Groupings in Sensor Networks," 2nd Intl. Conf. Intelli. Envi. July 2005.

[15] C.Y. Wan and A.T. Campbell. PSFQ: A Reliable Transport Protocol For Wireless Sensor Networks. In Proceedings of First ACM International Work-shop on Wireless Sensor Networks and Applications(WSNA), Atlanta, Georgia, USA, September 2002. ACM.

[16] P. Levis, N. Patel, D. Culler, and S. Shenker, "Trickle: A self-regulating algorithm for code propagation and maintenance in wireless sensor networks," in NSDI, (2004)

[17] J. Wong, R. Jafari, and M. Potkonjak, "Gateway Placement for Latency and Energy Efficient Data Aggregation in Wireless Sensor Networks," UCLA TR #, pp. 1-15, 2004.

[18] Yi Shi, Y. Thomas Hou, "Optimal Base Station Placement in Wireless Sensor Networks," ACM Trans. on Sensor Networks, vol. 5, no. 32, 2009.

[19] Soo Kim,Jeong-Gil Ko, Jongwon Yoon, Heejo Lee, "Multiple-Objective Metric for Placing Multiple Base Stations in Wireless Sensor Networks," in IEEE ISWPC, San Juan, Feb. 2007.

[20] Ping Zhou, B. S. Manoj, Ramesh Rao, "A gateway placement algorithm in wireless mesh networks,"In Proceedings of the 3rd International Conference on Wireless Internet, Austin, Texas, 2007.