INTERNET-DRAFT Dr. Humayun Bakht Expires: May 2014 Director of Studies Request for Comments London School of Commerce draft-bakht-maoddp-02.txt Email: humayunbakht@yahoo.co.uk Category: Informational December 2013 Fault Detection and Recovery in Wireless Sensors Network Abstract Wireless Sensors networks (WSNs) are type of wireless ad-hoc networks with reduced or no mobility. These networks combine wireless communication with minimal onboard computation facilities for sensing and monitoring of physical and environmental phenomena. Much work has been reported on different aspects of wireless sensors networks;however,less attention has been paid on addressing fault detection and recovery in these networks. Fault could be any thing which can lead communication break down as a whole or part of a wireless sensors network.Thus, detection of such fault attains a primary focus to support routine operations within such networks. Mobile Ad-hoc On Demand Data Delivery Protocol (MAODDP) belongs to on-demand data delivery type routing family of mobile ad-hoc networks. The contribution of this paper is to introduce an efficient fault detection and recovery mechanism for WSNs network. We believe proposed two step model can offer a robust solution for the fault management in Wireless Sensors Network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress." This Internet-Draft will expire in May, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trusts Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bakht Informational [Page 1] RFC Fault Detection and Recovery in Wireless Sensors Network December 2013 Table of Contents Abstract 1 Status of This Memo 1 2. Introduction 2 3. Fault Detection and Recovery in a Wireless Sensors Network3 3.1. Time State 3 3.2. Data Communication 3 3.3. Dead Node 3 3.4. Sleep Mode 4 3.5. Route Finder 4 4. Discussion 4 5. References 5 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels". Bakht Informational [Page 2] RFC Fault Detection and Recovery in Wireless Sensors Network December 2013 2. Introduction With the recent advances in technologies miniaturization of computing and sensing technologies enables the development of tiny, and low-cost sensors and controller [1]. There is an increasing focus on these systems is observed in the civil domain to monitor and to protect critical infrastructure such as bridges and tunnels etc [2]. Such wireless networks of distributed sensor nodes are commonly known as Wireless Sensor Networks (WSNs) [3]. WSNs have its origin from mobile ad-hoc network [4]. Mobile ad-hoc network is the collection of mobile nodes establishing network without requiring any supporting infrastructure [5]. Sensor link the physical world with the digital world by capturing, interacting and revealing real-world objects into a form that can be stored, processed and analyzed [6]. Sensor can help to monitor and avoid catastrophic infrastructure failures, conserve precious natural resources, increase productivity, and enable new applications such as smart homes and smart cities technologies [7,8]. Mobile ad-hoc on-demand data delivery protocol (MAODDP) is an on-demand data delivery protocol focusing route establishment and data delivery one after the other simultaneously at the same time. MAODDP has been extended to support similar operations in related network. The contribution of this work is to introduce a novel two step model of fault management for WSNs. In this context, this work has been organized as follows. In section 3 A detail overview of the proposed two step model is presented and in section 4 A conclusive discussions on the presented model is covered. 3. Fault Detection and Recovery in a Wireless Sensors Network The structure of wireless sensor network could take one of many forms therefore standard fault detection mechanisms might not be suitable under different scenarios or structure formation. However, types of faults to some extent directly related with specific structural deployment of a WSN. It is therefore important to know what types of fault could encounter in an established WSNs. Among the many types of faults, link breakage could be seen as one of the common faults which might be found in any wireless sensors network irrespective of which structure it follows. Such faults could happen in one of many situations which depend of various restrictions of devices participating in a network. Therefore, it is important that fault detection mechanisms should put minimum or in ideal case no extra burden on network available resources. Examples of some such resources are bandwidth and battery power as in the case of wireless sensors networks. Bakht Informational [Page 3] RFC Fault Detection and Recovery in Wireless Sensors Network December 2013 It has been mentioned that devices in a sensors network generally operate at a low battery power. Extra operational requirements may develop a situation where most of the available battery power consumes in tasks other then real communication. Similarly the same could pose additional requirements to the available bandwidth resulting slowing down communication or data transfer, thereby, degrading performance of a WSN. It is quite understandable that the CLUSTER HEAD (CH) OR GROUP LEADER of a GROUP cannot all alone handle such failures OR errors. In due course, errors could also be some thing other then fault detection. However, this term has been used synonymously in place of faults in the available literature. CH can function better if a fault detection mechanism can follow a distributed set of an operation. Since, it is quite obvious that in most of the network life CH would be busy in communicating with SINK in order for collected data to be delivered at the base station. It is off interest that there is one of many possible ways of CH selection as reported in the existing literature. However, in a general sense a NODE or a STATION with high power and storage capacity could be a standard choice. It is highly unlikely that a fault detection and recovery solution requiring some additional tasks for Cluster Head to perform could full-fill all the requirements. It is partially due to the same reasons that this particular area stands alone and requires some better mechanism of handling issue being discussed. Fault detection and fault recovery are interrelated with each other. On one hand where fault detection is considered on other side fault recovery has to be taken on board at the same time. A general principle as outlined in the above discussion has been followed in the proposed fault detection and recovery for WSNs and is as follows. 3.1. Time State It is in view of the above discussion a TIME state has been introduced as a part of HEADER of a data packet in MAODDP. Such factor could be used either to calculate or to determine a successful data delivery. It is important to mention that TIME factor is one of some novel factor of the presented mechanism. Wireless node has also been made responsible to take necessary steps in case a node feels some communication disturbances. This model has been named as a two steps due to the above mentioned actions which are introduced to ensure error free communication. TIME state T not only ensures effective communication but also validates known path entries of WSNs nodes. 3.2. Data Communication if an acknowledged or replied is not receive within the time T a wireless node regardless of status i.e. head or a member can either consider resending the data packet or a query could be initiated to the node closest to the desired destination. A limit of maximum two reattempts has been added as a crucial part of the proposed scheme. In between these two attempts the first one must be done and the second is optional. Therefore, if the node is not in a position where it can make a second attempt subsequent retry is not required. A sensor node could chose to conserve power then to consume it in another attempt. If after first or second retries NO STATUS UPDATE is received, such destination is MARKED as UNAVILABLE OR DEAD. In order to minimize addition tasks, SOURCE node is not required to ISSUE any UPDATE notification about the DEAD node rather a NOVEL approach has been introduced. Bakht Informational [Page 4] RFC Fault Detection and Recovery in Wireless Sensors Network December 2014 3.3. Dead Node In the adopted procedure in MAODDP, a node having information about a DEAD node, add a reference to it in the next communication to any node in the network. Such entries are marked with (D + MNO) where D represents a Dead node and MNO represent the dead node member number. A retry to any of the wireless node can alert all the nodes in the path to the destination node about a possible break. Such node would also follow the above procedure for minimum of one subsequent communication cycle. It is self explanatory that all group members became aware of a possible DEAD node in due time. An account of SLEEPING MODE has also been considered; therefore a soft measure of RE-ALIVE Header has been added. In essence if a node misses a communication due to being in a sleep mode and discover again, any such discovering could be marked as (RAL+MNO), here RAL denotes re-alive and MNO is for member number. Such MARKS are added only once by all the nodes in the path in very next data transmission. 3.4. Sleep Mode In relation with SLEEP MODE depends on a wireless sensors network formation, a node might be given permission to switch into SLEEP MODE. In other words, during such mode nodes are considered in an active transmission. In addition to the above, though Status Time calculation can also reflect such situation, however, such precaution is added to avoid any minor possibility. In second step of a two steps model if a node does not hear delivery confirmation from the CH, it can follow the same procedure of retries as mentioned earlier in STEP one. 3.5. Route Finder Based on relation between CH and a member node retries does not mean that NODE should STOP sending collected data rather a ROUTE FINDER PACKET (RFP) is broadcast by a node who have lost path to the CH. Such measures are necessary to enable node performing primary tasks of such deployments. A ROUTE FOUND PACKET (RFP) is sent back to such node from any of the NODE having an active path to the CH. 4.Discussion It is evident from the above discussion that such approach is feasible in terms of refreshing route or communication path between the member nodes and the CH. Moreover, it is also beneficial in avoiding NETWORK REBOT option which could otherwise result in data lost. NETWORK REBOTTING is an available option if a WSNs suffers badly with huge faults resulting communication dropped at a large scale. Such situation could force a WSNs to reboot in order to reconfigure network topology. In worst scenarios, network formation pattern could also be taken into account. It can be concluded that proposed mechanism offer a reliable and quick FAULT detection and recovery for a WSN. Similarly, based on the given specification very less temporary additional tasks are taken to make it an effective solution for fault management in a wireless sensors network. Bakht Informational [Page 5] RFC Fault Detection and Recovery in Wireless Sensors Network December 2014 5. References [1] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, A survey on sensor networks," presented at the IEEE Communication Magazine, 2002. [2] H. Karl and A. Willig, Protocols and Architectures for Wireless Sensor Networks: John Wiley & Sons, Ltd, West Sussex, England, 2005. [3] B. krishnamachari, Networking Wireless Sensors: Cambridge University Press, New York, 2005. [4] K. Sohraby, D. Minoli, and T. Znati, Wireless Sensor Networks: Technology, Protocols, and Applications. [5] H.bakht Mobile Ad-hoc on-Demand Data Delivery Protocol (MAODDP), IETF draft, November 2010. [6] H.Bakht, Mobile Ad-hoc Networking, Create Space, January 2010. [7] C. Cordeiro and D. P. Agrawal, Ad hoc & sensor networks, Theory and Applications: World scientific publishing, 2006. [8] S. Gupta and N. Parveen, "Optimum Node Deployment Strategy for Heterogeneous Wireless Sensor Network by Estimating Network Lifetime," presented at the 2nd International Conference on Emerging Trends in Engineering and Technology (ICETET09), 2009. Bakht Informational [Page 10] Expires: May 2014 RFC Fault Detection and Recovery in Wireless Sensors Network December 2013 Editors Addresses Dr. Humayun Bakht Director of Studies London School of Commerce United Kingdom