You are on page 1of 7

116

(IJCNS) International Journal of Computer and Network Security, Vol. 2, No. 2, February 2010

Efficient Code Dissemination Reprogramming Protocol for WSN
R.P.Shaikh 1, Dr. V.M. Thakare2, Dr. R.V. Dharaskar3
1

Computer Science Department GHRCE, Nagpur rpshaikh@gmail.com

2

HOD , Computer Science Department GHRCE, Nagpur. rvdharaskar@gmail.com

3

HOD , Computer Science Department SGB Amaravati University. vilthakare@rediffmail.com

Abstract: Network reprogramming is a way of reprogramming wireless sensor nodes by disseminating the program code over radio for uploading new code or for changing the functionality of existing code.. Existing reprogramming protocols, such as Deluge,achieve this by bundling the reprogramming protocol and the application as one program image, hence it increases the overall size of the image which is transferred through the network. This increases both time and energy required for network reprogramming. A proposed protocol divides the code image into application and reprogramming support. It preinstalls the reprogramming protocol as one image and the application program equipped with the ability to listen to new code updates as the second image that mitigates the above problem. Keyword : Wireless Sensor Network, Sensor, Wireless reprogramming, code dissemination.

can disseminate efficiently a large data object from one node to many other nodes over an entire wireless sensor network. The three important steps for code dissemination protocols is: advertisement of available software, selection of a source, and reliable download to the target,which may then become a source in turn (Figure1).

1. Introduction
A wireless sensor network is expected to consist of a potentially large number of low-cost, low-power, and multifunctional sensor nodes that communicate over short distances through wireless links. Due to their potential to provide fine-grained sensing and actuation at a reasonable cost, wireless sensor networks are considered ideal candidates for a wide range of applications, such as industry monitoring, data acquisition in hazardous environments, and military operations. It is desirable and sometimes necessary to reprogram sensor nodes through wireless links after they are deployed, due to, for example, the need of removing bugs and adding new functionalities. The process of propagating a new code image to the nodes in a network is commonly referred to as code dissemination. Traditionally, reprogramming was done manually. Therefore, nodes were reprogrammed one by one. However, as the size of sensor nodes becomes larger and larger this technique is not very efficient. What is more, it might be impossible to collect all the nodes from the field and then to reprogram them. Hence, reprogramming needs to be accomplished without physical contact with the nodes. A reliable data dissemination protocol is to be implemented which takes under consideration the previous factors and

Figure 1. Three Way handshake for code distribution Thus, reprogramming sensor nodes, i.e. changing the software running on sensor nodes after deployment, is necessary for sensor networks. A scheme is required to wirelessly reprogram the nodes The scenario poses many challenges, of them being energy, bandwidth and reprogramming. Requirements and Properties of Code Distribution are : 1. The complete image, starting from specific points in the network, must reach all the nodes. This is a requirement. We do not consider the ex- tended problem of reaching only a subset of the nodes. 2. If the image cannot fit into a single packet, it must be placed in stable storage until the transfer is complete, at which point the node can be safely reprogrammed. This is also a required property. 3. The lifetime of the network should not be severely affected by the distribution operation. This is a desirable property.

(IJCNS) International Journal of Computer and Network Security, 117 Vol. 2, No. 2, February 2010

4. The memory and storage requirements of the mechanism should not be very high since that would limit the available space for the normal application. This property is also desirable.

2. Relatedwork
Code dissemination protocols have been developed to propagate new code images using the wireless network formed by the sensor nodes. Data dissemination in wireless networks, retransmission of broadcasts can lead to the broadcast storm problem, where redundancy, contention, and collisions impair performance and reliability. Scalable Reliable Multicast (SRM) is a reliable multicast mechanism built for wired networks [15], using communication suppression techniques to minimize network congestion and request implosion at the server. SPIN-RL is an epidemic algorithm designed for broadcast networks that makes use of a three phase (advertisement-request-data) handshaking protocol between nodes to disseminate data [16]. The epidemic property is important since WSNs experience high loss rates, asymmetric connectivity, and transient links due to node failures and repopulation. However, their results show control message redundancy at over 95% as it only considers the suppression of redundant request messages, and SPIN-RL does not perform as well as naive flooding for lossy network models. The earliest network reprogramming protocol XNP[17] only operated over a single hop and did not provide incremental updates of the code image. . A special Boot Loader must be resident in a reserved section of program memory, and the xnp protocol module must be wired into an application (to allow for subsequent XNP updates). A host PC application xnp loads the image, via a base station mote running TOSBase (this acts as a serial-to-wireless bridge) to one (mote-id specific) or many (group-id specific) nodes within direct radio range of the base. The image is sent in capsules, one per packet; there is a fixed time delay between packet transmissions. In unicast mode, XNP checks delivery for each capsule; in broadcast mode, missing packets are handled, after the full image download has completed, using a follow-up query request (nodes respond with a list of missing capsules). The program is loaded into external (nonprogram) memory. Applications are halted during the program download. When a reboot command is issued (via the xnp host program), then the boot loader is called: this copies the program from external to program memory, and then jumps to the start of the new program. MOAP [4] is a multi-hop, over-the-air code distribution mechanism. It uses store-and-forward, providing a ‘ripple’ pattern of updates; lost segments are identified by the 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. The basestation broadcasts publish messages advertising the version number of the new code. Receiving nodes check this against their own version number, and can request the update with subscribe messages. A link-statistics mechanism is used to try to avoid unreliable links. After waiting a period to receive all subscriptions, the sender

then starts the data transfer. Missing segments are requested directly from the sender, which prioritises these over further data transmissions. Once a node has received an entire image, it becomes a sender in turn. If a sender receives no subscribe messages, it transfers the new image to program memory from EPROM, and reboots with the new code. Sliding window acknowledgements reduce power consumption (reduced EEPROM reads) at the cost of reduced out-of-order message tolerance. There is no support for rate control, or suppressing multiple senders (apart from link statistics). Trickle[6] runs under TinyOS/Mate – it acts as a service to continuously propagate code updates throughout the network. Periodically (gossiping interval τ) using the maintenance algorithm every node broadcasts a code summary (‘metadata’) if it has not overheard a certain number of neighbours transmit the same information. If a recipient detects the need for an update (either in the sender or in the receiver) then it brings everyone nearby up to date by broadcasting the needed code. Trickle dynamically regulates the per-node, Trickle-related traffic to a particular rate (rx + tx), thus adjusting automatically to the local network density. This scales well, even with packet loss taken into account. A listen-only period is used to minimise the short-listen problem (where de synchronised nodes may cause redundant transmissions due to a shift in their timer phases). The CSMA hidden-terminal problem does not lead to excessive misbehaviour by Trickle, as long as the traffic rate is kept low. By dynamically changing the gossip interval, Trickle can propagate changes rapidly, while using less network bandwidth when there are no known changes. Programs fit into a single TinyOS packet.

3. System Models
The conventional reprogramming protocol system model for sensor networks is depicted in figure 2, in which the code images are propagated from base station to every sensor node in the network

Figure 2. Reprogramming model for sensor network

118

(IJCNS) International Journal of Computer and Network Security, Vol. 2, No. 2, February 2010

4. The three substantially more sophisticated protocols :
4.1 MNP The design goal of MNP[8] is to choose a local source of the code which can satisfy the maximum number of nodes. They provide energy savings by turning off the radio of nonsender nodes. MNP is targeted at MICA2 motes running TinyOS and uses the XNP boot loader along with a dedicated network protocol to provide multi-hop, in-network programming. The MNP protocol operates in 4 phases: 1. Advertisement/Request, where sources advertise the new version of the code, and all interested nodes make requests. Nodes listen to both advertisements and requests, and decide whether to start forwarding code or not (this acts as a suppression scheme to avoid network overload); 2. Forward/Download, where a source broadcasts a StartDownload message to prepare the receivers, and then sends the program code a packet at a time (in packet-sized segments) to the receivers to be stored in external memory (EEPROM) – there is no ack, the receiver keeps a linked-list of missing segments in EEPROM to save RAM space; 3. Query/Update, where the source broadcasts a Query to all its receivers, which respond by unicast by asking for the missing packets (segments) – these are then rebroadcast by the source node, and then another Query is broadcast until there are no requests for missing packets. The receivers, having received the full image, now become source nodes and start advertising the new program; 4. Reboot, entered when a source received no requests in response to an advertisement, where the new program image is transferred to program memory, and the node reboots with the new code. A node sends a download request to all senders, this assists in sender selection, and also allows the hidden terminal effect to be reduced (as other potential senders can overhead this request). The sender selection algorithm attempts to allow only one active sender in a particular neighborhood. 4.2 FRESHET Freshet[10] is different in aggressively optimizing the energy consumption for reprogramming. It introduces a new phase called blitzkrieg when the code update is started from the base node. During the blitzkrieg phase, information about the code and topology (primarily the number of hops a node is away from the wave front where the code is at) propagates through the network rapidly. Using the topology information each node estimates when the code will arrive in its vicinity and the three way handshake will be initiated – the distribution phase. Each node can go to sleep in between the blitzkrieg phase and the distribution phase thereby saving energy. Freshet also optimizes the energy consumption by exponentially reducing the meta-data rate during conditions of stability in the network when no new code is being introduced, called the quiescent phase. 4.3 DELUGE

Deluge[6] is a density-aware protocol with epidemic behavior that can help propagate the code reliable over unpredictable network conditions. It represents the data object as a set of fixed-size pages, a key feature needed for spatial multiplexing. Deluge is based on protocol Trickle , a protocol designed for manipulating code updates in sensor networks. Deluge's basinality (borrowed from Trickle) is the suppression and dynamic adjustment of the broadcast rate so as to limit the transmitted messages among n. Deluge uses an epidemic protocol for efficient advertisement of code meta data and spatial multiplexing for efficient propagation of code images. Deluge is generally accepted as the state of the art for code dissemination in wireless sensor networks, and has been included in recent TinyOS distributions Deluge is a data dissemination protocol and algorithm for propagating large amounts of data throughout a WSN using incremental upgrades for enhanced performance. It is particularly aimed at disseminating software image updates, identified by incremental version numbers, for network reprogramming. The program image is split into fixed size pages that can be ‘reasonably’ buffered in RAM, and each page is split into fixed size packets so that a packet can be sent without fragmentation by the TinyOS network stack. A bit vector of pages received can be sent in a single TinyOS network packet. Nodes broadcast advertisements containing a version number and a bit vector of the associated pages received, using a variable period based on updating activity. If a node determines that it needs to upgrade part of its image to match a newer version, then, after listening to further advertisements for a time, it sends a request to the selected neighbour for the lowest page number required, and the packets required within that page. After listening for further requests, the sender selects a page, and broadcasts every requested packet in that page. When a node receives the last packet required to complete a page, it broadcasts an advertisement before requesting further pages – this enhances parallelisation (‘spatial multiplexing’) of the update within the network (as the node can now issue further requests in parallel with responding to requests from other nodes). The protocol keeps the state data to a fixed size, independent of the number of neighbours. There are no ACK’s or NACK’s – requesters either request new pages, or re-request missing packets from a previous page. There is no global co-ordination to select senders; heuristics are used to try and elect relatively remote senders in order to minimise radio network contention. Incremental updating is supported through the use of Complete Advertisements which indicate which pages in an image have changed since the previous version; requesters can then request just the changed pages. Future versions of Deluge are expected to address the following issues: control message suppression, running updates concurrently with applications, explicitly reducing energy consumption, and support for multiple types and versions of images.

5. Proposed Protocol
Each protocol discuss above transfers the image of the entire reprogramming protocol together with the minimally necessary part.The researchers have found that it is difficult

(IJCNS) International Journal of Computer and Network Security, 119 Vol. 2, No. 2, February 2010

to improve over Deluge the rate of transfer of data over the wireless link. Hence to optimize what needs to be transferred, keeping the basic mode of transfer the same as in Deluge ,transfer just what is needed, in other words, the application code (or the code of the updates to the application).This idea gives rise to our proposed protocol.It transfers close to the minimally required image size by segmenting the total program image into an application image and the reprogramming image.(Application image refer to the user application , reprogramming image refer to protocol component for protocol, such as MNP ,Deluge or Freshet) The benefit of our protocol shows up in fewer number of bytes transferred over the wireless medium leading to increased energy savings and reduced delay for reprogramming 5.1 Protocol Description An application is modified by linking it to a small component called Application Support (AS) while Reprogramming Support (RS) is pre-installed in each node. Overall, design principle is to limit the size of AS and providing it the facility to switch to RS when triggered by a code update related message. Consider that initially all nodes have RS as image 0 and the application with AS as image 1 Each node is executing the image 1 code. The node that initiates the reprogramming is attached to a computer through the serial port and is called the base node. Following is the description of how Stream works when a new user application, again with the Stream-AS component added to it, has to be injected into the network. 1.Reboot procedure takes place as follows: a. The base node executing image 1 initiates the process by generating a command to reboot from image 0. It broadcasts the reboot command to its one hop neighbors and itself reboots from image 0. b. When a node running the user application receives the reboot command, it rebroadcasts the reboot command and itself reboots from image 0. 2.When all nodes receives reboot command they all start running RS. Then the new user application is injected into the network using RS. 3.Reprogramming of entire network stars using three way handshake as discussed above. Each node maintains a set S containing the node ids of the nodes from which it has received the requests for code. 4. Once the node downloads the new code completely, it performs a single-hop broadcast of an ACK indicating it has completed downloading. 5. When a node receives the ACK from a node, it removes the id of from its set S. 6. When the set S is empty and all the images are complete and after sometime entire network is reprogrammed and nodes will reboot from apllcation support. 5.2 Advantages : •Reduce transmitted bit over wireless medium leading to increased energy savings and reduced delay for reprogramming

•Reduce programming time, energy costs and program memory •Improve the protocol for a new node to get image from network •It optimizes the steady state energy expenditure by switching from a push-based mechanism where periodically node sends advertisements to pull based mechanism where newly inserted node request for the code. •In Freshet to save energy the sleeping time of node is to be estimated prior and this estimation if often found inaccurate due to variability of the wireless channel however stream protocol achieve this goal by rebooting the node from Stream-RS only when new node arrives at one of its neighbors thus the user application running on the node can put the node to sleep till the time to reboot comes. This opportunistic sleeping feature conserve energy in resource constrained sensored network. •In Deluge, once a node’s reprogramming is over, it keeps on advertising the code image it has hence radio resources are continuously used in the steady state but in stream ,Stream-AS does not advertise the data it has .

5.3 Evaluation Results

With the help of reprogramming using the ns-2 simulator we have to evaluate the message inter-arrival period and compared it with the total energy consumption of the sensor nodes. Indeed our aim is to compare our proposed protocol with the known Deluge protocol [6] for wireless sensor network and obtain the result and graph as displayed in Table I.and fig 3. Main objective is observe that the energy consumption has also been reduced because of the reduction in the overall size of the program image that needs to be transferred over the wireless medium which may increase the time and energy required for reprogramming the sensor nodes. Thus fewer number of bytes transferred over the wireless medium leading to increased energy savings and reduced delay for reprogramming Table 1: Time Taken for Download Phase Code Size Case 1 Case 2 Case 3 Case 4 Case 5 45.2 KB 54.3 KB 67.8 KB 75.7 KB 80.2 KB Download time 112 sec 120 sec 135 sec 139 sec 141 sec

120

(IJCNS) International Journal of Computer and Network Security, Vol. 2, No. 2, February 2010

station for dissemination, sending the update to a number of seed nodes for further dissemination, and sending the update individually to each node. 4. It is likely that an energy aware approach will have to be taken in order to respond to current energy patterns in a sensor net (ref. energy-aware MAC layers, and energyaware Routing). 5.In order to support the various possible patterns in which software updates may be received, and to support any requirements for backwards and forwards version compatibility, tighter control over the order of node activation will be required. 6. There are a number of aspects of this which are not directly related to software updating, but the key ones which are related are: checking the downloaded software before activation (integrity, version mismatches, platform mismatches) and dynamically checking the operation of the downloaded software after is has been activated. It is likely that further advances will be necessary in this area, probably using techniques from autonomic computing, to increase the robustness of software updates. Figure 3. Message inter arrival period (SEC) Other Parameters of implementation on ns-2 is as shown in in Table II Table 2: Parameters for Implementation on ns2 7. There is a need for tools to monitor the ‘version’ state of a WSN and report status and problems to an operator/user. These will be able to use existing techniques for fusing data to reduce the overhead, and for tracking update-related faults. 8. The normal issues of: key-distribution, authentication, secrecy, integrity, and authorization needing to be addressed. Results from existing WSN security research will be needed, along with other work specific to the software update problem. 9. The protocols used need to be energy-aware, so that the current energy-state of both individual nodes and the entire network can be taken into account during an update. 10. Recovering from faulty updates methods are required before execution and during execution has been done

6. Conclusion
This paper examines the challenges of incorporating scalable bandwidth management scheme and reducing the reprogramming time, the number of bytes transferred, the energy expended, and the usage of program memory for wireless reprogramming in WSN environment with brief description of some existing proposals that specifically address this problem . In future analysis of parameters as shown in table I & tableII by Simulation experiments to show the increasing advantages of proposed protocol over Deluge with larger network sizes. Certain issues were not addressed in this work, like the security issue, reliability etc. If an acknowledgement/code segment lost in a particular hop of multihop network due wireless medium constraints, then the nodes which are in that hop have to take some necessary actions to achieve reliability.

There are a number of open research problems common to all the classes: 1.Before initiating an update, it would be invaluable to be able run a model (such as a simulation) to determine/analyze reprogramming time and the energy cost of different update options on the current network configuration, and thus allow the user to make informed tradeoffs against energy. For example: which is the best injection strategy for the current configuration? What size reduction technique will result in the quickest update? etc. 2. There is not yet a definitive answer to the best way to reduce the size of updates, with modular, differences-based, and compression all showing promise in different circumstances. 3. There are a number of different injection strategies in use: simulating a base station, sending the update to a base

References
[1] P. Levis, N. Patel, S. Shenker, D. Culler, “Trickle: a selfregulating algorithm for code propagation &

(IJCNS) International Journal of Computer and Network Security, 121 Vol. 2, No. 2, February 2010

maintenance in wireless sensor network,” in: Proceedings of the First USENIX/ACM Symposium on Networked Systems Design and Implementation “ (NSDI 2004) . [2] “Remote Incremental Linking for Energy-Efficient Reprogramming of Sensor Networks”,Joel Koshy & Raju Pandey University of California, Davis, California 95616, USA. [3] J.W. Hui, D. Culler, The dynamic behavior of a data dissemination protocol for network programming at scale, in: The Proceedings of the Second International Conference on Embedded Networked Sensor Systems, Baltimore, MD,USA, 2004, pp. 81–94. [4] T. Stathopoulos, J. Heidemann, D. Estrin, A remote code update mechanism for wireless sensor networks, Technical Report CENS Technical Report 30, 2003. [5] Synapse: A Network Reprogramming Protocol for Wireless Sensor Networks using Fountain Codes” Michele Rossi, Giovanni Zanca, Luca Stabellini Riccardo Crepaldi, Albert F. Harris III and Michele Zorzi Dept. of Information Engineering, University of Padova, 35131 Padova, Italy. [6] R.K. Panta, I. Khalil, S. Bagchi, “Stream: low overhead wireless reprogramming for sensor networks, in: Proceedings of the 26th IEEE International Conference on Computer Communications (INFOCOM), May 2007, pp. 928–936.” [7] M. D. Krasniewski, S. Bagchi, C-L. Yang, W. J. Chappell, “Energy efficient, On-demand Reprogramming of Large-scale Sensor Networks,” Submitted to IEEE Transactions on Mobile Computing (TMC). Available as Purdue ECE Technical Report TRECE-06-02, 2006. [8] S.S.Kulkarni and L. Wang, “MNP: Multihop Network Reprogramming Service for Sensor Networks,” in IEEE ICDCS, Columbus, Ohio, USA, Jun. 2005. [9] Efficient wireless reprogramming through reduced bandwidth usage and opportunistic sleeping,” Rajesh Krishna Panta , Saurabh Bagchi , Issa M. Khalil a Dependable Computing Systems Lab, School of Electrical and Computer Engineering, Purdue University [10] N. Reijers, K. Langendoen, “Efficient code distribution in wireless sensor networks, in:” Proceedings of the Second ACM International Conference on Wireless Sensor Networks and Applications (WSNA), 2003, pp. 60–67. [11] J. Koshy, R. Pandey, “Remote incremental linking for energy efficient reprogramming of sensor networks” in: Proceedings of the Second European Workshop on Wireless Sensor Networks (EWSN), 2005, pp. 354–365 [12] “Updating Software in Wireless Sensor Networks: A Survey” S. Brown, Dept. of Computer Science, National University of Ireland, Maynooth C.J. Sreenan, Mobile & Internet Systems Laboratory, Dept. of Computer Science, University College Cork, Ireland Technical Report UCCCS- 2006-13-07 [13] Shen,, Srisathapornphat, Jaikaeo: “Sensor Information Networking Architecture and Applications”. In: Proc. of the International Workshop on Pervasive Computing, Toronto, Canada, August. IEEE(2004) 52-59

[14] Stann, F., Heidemann, “RMST: Reliable Data Transport in Sensor Networks”. In: Proc. of the 1st IEEE Intl. Workshop on Sensor Network Applications and Protocols. IEEE (2003) 102-112 [15] Beutel, J., Dyer, M., Meier, Ringwald, Thiele: NextGeneration Deployment Support for Sensor Networks. TIK-Report No: 207. Computer Engineering and Networks Lab, Swiss Federal Institute of Technology(ETH), Zurich (2004) [16] S. K. Kasera, G. Hj´almt´ysson, D. F. Towsley, and J. F.Kurose. “Scalable reliable multicast using multiple multicast channels. IEEE/ACM Transactions on Networking, 8(3):294–310, 2000.” [17] J.Kulik, W. R. Heinzelman, and H.Balakrishnan.” Negotiation-based protocols for disseminating information in wireless sensor networks. Wireless Networks,8(2-3):169–185, 2002.” [18] Crossbow Tech Inc.,” Mote In-Network Programming” User Ref, http://www.tinyos.net/tinyos 1.x/doc/Xnp.pdf, 2003 [19] Q.Wang, Y.Y. Zhu., L. Cheng, “Reprogramming wireless sensor networks: challenges and approaches”, IEEE Networks, 2006, 20(3): 48. [20] A. Chlipala, J. Hui, and G. Tolle. Deluge: Data dissemination for network reprogramming at scale.

Authors Profile

Dr V M Thakare is Professor and Head of PG department of computer Science and Engg in SGB Amravati University Amravati, Maharastra (India) and has completed ME in Advance Electronics and Ph.D. In computer Science/Engg. His Area of Research are Robotics and Artificial Intelligence, Information Technology. He is Recognized Giude for computer science and computer engineering in this University and In other universities also. He has also received received national level Award for excellent paper award. More than 10 candidates are working for Ph D Under his supervision. He has Published and presented more than 115 papers at National and international level. He has worked on various national level bodies like AICTE/UGC and also worked on various bodies of other universities. He is presently member of BOS, RRC, BUTR of this university and also chairman and Member of various committees of this university . Dr. Rajiv Dharaskar is presently working as Professor at PG Department of Computer Science and Engineering, GH Raisoni College of Engineering, Nagpur. He is Ph.D. in Computer Science & Engineering in the Faculty of Engineering & Technology, M.Tech. in Computers, P.G. Dip., M.Phil., and M.Sc. He is

122

(IJCNS) International Journal of Computer and Network Security, Vol. 2, No. 2, February 2010

having 24 years of teaching and 18 years of R&D experience in the field of Computers & IT. He is approved PhD guide for Computer Engineering and Science for Nagpur and Amravati University and 22 research scholars are perusing Ph.D. degree under his guidance. He is an author of number books on Programming Languages.

Riyaz Shaikh received B.E degree in Computer Technology from Nagpur University.Joined as MIS INCHARGE in Govt Project at ZP.Before that she also worked as Lecturer in Polytechnic and MCA college. Presently perusing Master of Engineering degree in Wireless communication and Computing branch under Computer Science department at GHRCE , Nagpur university , India . Her area of interest are wireless adhoc and sensor network.