Internet DRAFT - draft-bakht-maoddp
draft-bakht-maoddp
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
