Detecting Node Failures in Mobile Wireless

Networks: A Probabilistic Approach

ABSTRACT

Detecting node failures in mobile wireless networks is very

challenging because the network topology can be highly dynamic, the
network may not be always connected, and the resources are limited.
In this paper, we take a probabilistic approach and propose two node
failure detection schemes that systematically combine localized
monitoring, location estimation and node collaboration. Extensive
simulation results in both connected and disconnected networks
demonstrate that our schemes achieve high failure detection rates
(close to an upper bound) and low false positive rates, and incur low
communication overhead. Compared to approaches that use
centralized monitoring, our approach has up to 80% lower
communication overhead, and only slightly lower detection rates and
slightly higher false positive rates. In addition, our approach has the
advantage that it is applicable to both connected and disconnected
networks while centralized monitoring is only applicable to connected
networks.
 CHAPTER 1

INTRODUCTION

INTRODUCTION

WIRELESS SENSOR NETWORK

Wireless sensor network (WSN) becomes an important topic for researchers in recent
year. IEEE 802.15.4 is the standard for WPAN which provided physical (PHY) and medium
access control (MAC) layers . This standard support a low cost, low power and low data rate
which is well-suited for WSN. IEEE 802.15.4 networks support star, mesh, and cluster-tree
network. This network consist of two types of devices; Full Function Device (FFD) (2)
Reduce Function Device (RFD). FFD can play a role of a router which can connect to other
FFD and RFD devices. On the other hand RFD can only connect to FFD devices.

ZIGBEE NETWORK:

Zigbee is an emerging worldwide standard for wireless personal area network. Under
the main goal to provide low-power, cost-effective, flexible, reliable, and scalable wireless
products, ZigBee Alliance has been developing and standardizing the ZigBee network. On
December 2004, they released the ZigBee Specification version 1.0 [1] to the public. Based
on IEEE 802.15.4, ZigBee Specification defines a network layer, application framework as
well as security services. Since ZigBee devices are designed for low cost and low data rates,
it is expected their use in home and building automation with significantly small costs.
Moreover, ZigBee networks support star and mesh topology, self-forming and self-healing as
well as more than 65000 address spaces; thus, network can be easily extended in terms of size
and coverage area.

Among many useful functions in ZigBee network layer, the tree routing algorithm
supports simple but reliable routing for any destination address. In ZigBee, network addresses
are assigned using a distributed addressing scheme that is designed to provide every potential
parent with a finite subblock of network addresses. Due to such addressing scheme, the
network constructs a tree topology; each device can manage the address space of its
descendant. If the destination address is in the address space that a node is managing, the
node forwards the packet to one of its child nodes. Otherwise, it forwards the packet to its
parent node.

Fig. 1. ZigBee protocol stack

The parent or child node which receives the packet selects the next hop node
according to the destination address in the same manner. Tree routing algorithm is thus able
to find the next hop node for a given destination address without routing tables. However, a
sender cannot know if the destination is located nearby or if it’s not in the sub-tree which the
sender is contained in, since tree routing concerns only about the parent and descendants of
the sender node. Although the tree routing is efficient in the view point of memory usage, the
routing cost is sometimes inefficient. This paper proposes the shortcut tree routing algorithm
to archive both memory efficiency and routing efficiency.

The ZigBee Alliance is an association of companies working together to enable

reliable, cost-effective, low-power, wirelessly networked, monitoring, and control products
based on open standards. It is composed of about 200 member companies including 14
promoters such as Motorola, Freescale, Philips, and Samsung. Since their release of the
ZigBee Specification version 1.0 on December 2004, a new version was announced on
September 2006 including multicast, end device mobility and routing mobility.
 A. IEEE 802.15.4

The ZigBee protocol stack is described in Fig. 1. As we can see, the IEEE 802.15.4 and
the ZigBee network are tightly coupled to provide the consumer standardization for low
power and low-rate wireless communication devices.

Fig.1 shows ZigBee protocol stack. ZigBee network defines three kinds of devices
personal area network (PAN) coordinator, router, and end device

IEEE 802.15.4 PHY layer provides 16 channels for ISM 2.4 GHz, 10 channels for ISM
900 MHz, and 1 channel for 868 MHz IEEE 802.15.4 PHY provides LQI (Link Quality
Indicator) in order to characterize the quality of links between nodes, as well as data
transmission and reception.

Personal Area Network (PAN) coordinator: is a FFD device acting as the core
component of the network and responsible to initiate the network by setting network’s
parameters which contain how many nodes can join to and the types of nodes (router and
end devices) in this network. After setting up the network, PAN coordinator is responsible
to accept or reject nodes depending on network parameters also handles the routing of
packets through network nodes and chooses the routing techniques in the network. In
ZigBee network it has one coordinator which is mostly connect to the power supply.

Router device: is a FFD device that a PAN coordinator uses it as intermediate node to
carry out the multi-hops routing message through the network from source nods to the sink
node. Also router device can accept another router or end device node to join the network by
assigning network address to this new node and create a communication link between them.
This link will use to transfer data packets to sink node.

End device: is a RFD device acting as the leaf of the network with limit functionality. It is
work for the purpose of sensing data from the environment and transmits to router device
which is joined through it to the network. End device can’t accept any device to join the
network and it has limit energy for that it going to sleep mode to save its energy.

ZIGBEE NETWORK TOPOLOGY:

The application layer consists of three parts: the Application Sublayer (APS), the Application
Framework (AF), and the endpoints. The Application Sublayer interfaces the Zigbee
application layer to the Zigbee networking layer and it provides a common set of data
transport services to all the endpoints. There are also a couple of other services that the APS
provides and we’ll get into that when we discuss the app layer in more detail. 

Network Formation

When the user app decides to form a network instead of joining an existing one, it will
instruct the ZDO to call the network formation function. Only a router that is coordinator-
capable can form a network and this is indicated in the application layer’s information base.
It’s just a fancy term for the app layer’s configuration table.
The Application Framework is just a glorified multiplexer and container for all of the
endpoints. All of the endpoints register themselves with the AF, and when a data frame
comes into the application layer, the AF will check its destination endpoint and forward it
there. 

The endpoints are what most people associate with Zigbee. Each endpoint houses what’s
called an application object which is basically a device profile with whatever extra
functionality you decide to add. When the device is started, all the endpoints will register
themselves with the application framework and provide descriptions of their device profile
and their capabilities. Endpoint 0 is a special endpoint and always contains the Zigbee Device
Object (ZDO). This object implements the Zigbee

Device Profile which has multiple functions, one of them being the network manager.
When the network formation function is called, a list of allowed channels needs to be
supplied to which may be limited to a subset of the total available channels (16 channels @
2.4GHz). It’s usually based on certain requirements like avoiding channels that overlap with
an existing 802.11 network. Incidentally, coexistence of Zigbee with 802.11 is a major debate
point between other competing radio providers. The main issue is that they claim Zigbee is
susceptible to interference from Wi-Fi networks whereas other radios operating at non-2.4
GHz frequencies are not. I won’t inject myself into the debate here, but I’d suggest locating
any routing nodes a few feet away from an 802.11 access point. I think 3-6 feet is the magic
number that I often hear. Otherwise, just take care to avoid 802.11 channels in your channel
list.

The network formation function will call the MAC’s energy scan and active scan services and
perform scans on the supplied channel list. When the scans are finished, the MAC’s scan
confirm function will return the energy readings and network scan descriptors to the function
via the MAC’s scan confirmation. From there, the network formation function will need to
decide on the channel to join. The usual criteria is to choose a channel with the lowest energy
reading (lowest amount of traffic) and the fewest networks. If you have access to the source
code, you can also modify the channel decision function to add additional criteria.

Once the channel is decided on, the newly crowned coordinator will decide on a PAN ID and
set the channel in the radio. The final step is for the NWK layer to call the MAC start service
which configures the MAC layer. After that, confirmations go back all the way up to the user
app

Network Discovery

As the name implies, the Zigbee network discovery service is used to discover the
existing networks on the current channel. It’s mostly just used when the device is started to
find out if there are any suitable networks to join, although it can also be called at any time
via the user app.

When a network discovery is requested by the ZDO (or user app), the discovery function will
call the MAC’s active scan service which, in turn, will broadcast a beacon request. When
other devices see the beacon request, they will respond with an 802.15.4 beacon frame. If you
remember from my 802.15.4 articles, an 802.15.4 beacon frame contains MAC information
about the responding device as well as a beacon payload for generic data. Within that
payload, the responding device will include Zigbee network information such as the protocol
ID and version, amount of routers and end devices allowed to join, the device profile that is
being used, and other somewhat useful information.
Network Join

Joining a device or allowing a device to join is probably one of the most complicated
processes in Zigbee. There are actually two sides to the network join function: the child side
which sends the request and the parent side which processes the request and sends the
response. To get a thorough understanding of the join process, I’ll treat each sequence
separately. I won’t go into the details of the 802.15.4 association sequence since an
explanation of that can be found in the MAC tutorial. 

Network Join – Child

The first part of the join process for the child is to do a network discovery. This is usually
done when the device is first started and is not associated with any network as mentioned
previously. Once the network discovery is finished and the potential parent has been decided
on according to the join criteria, then it’s time for the network join process to start.
  

When the potential parent has been chosen, a network join request is called by the ZDO. The
network join request will call the MAC’s association service and issue an association request
to the potential parent. From there, the procedure follows the MAC’s association sequence
until the association response is received from the potential parent. 

When this response is received, it will get passed up to the network layer via the MAC’s
association response. If the join was successful, the device will update it’s NWK and MAC
information tables to include the new network address, PAN ID, and also update the neighbor
table to specify its parent. Once the administrative work is taken care of, the network join
confirmation is sent up to the ZDO where it can inform the application about the join status.
If the join status was unsuccessful, then the ZDO/user app will choose another potential
parent from the neighbor table and retry the join procedure until it eventually joins a network
or runs out of potential parents. 

One of the last things that occur after a successful join is that the device will broadcast a
device announcement informing everyone on the network that it has joined the network as
well as it’s 16-bit network address and 64-bit IEEE address. This is important because if the
device was previously joined to the network with a different network address, the other
devices will be able to find out from it’s IEEE address and can clear all references to the old
network address. Also, the address info will be added to everyone’s address map which tracks
all the devices on the network.

Network Join – Parent

The parent side of the join process is slightly easier. When a MAC association request
arrives at the potential parent, it sends an indication to the network layer that a device is
trying to join. The potential parent will then search its neighbor table to see if the 64-bit IEEE
address already exists. If it does, then that means that the device was already previously
joined and the parent will just issue the same network address to it. If not, and the parent is
allowing devices to join it, then it will simply add the device to its neighbor table specifying
that it’s a child device and generate a new network address for it. This all gets packaged up
and sent out as a MAC association response. Again the rest goes according to the MAC’s
association service.

Classification of Routing Protocols According to the Network Structure

In WSNs, routing protocols are classified into three types such as flat routing protocol,

hierarchical routing protocol and geographic routing protocol.

Flat routing protocol

It is difficult to assign global identifiers to each node of a sensor network given the large
number of deployed nodes .This absence of a global addressing scheme with the random
deployment of sensor nodes makes it hard to select a specific set of sensor nodes that to be
queried. Therefore, data is generally transmitted from each sensor node deployed in the
region with significant redundancy. This redundancy penalizes in terms of energy
consumption. Thus, this thinking leads to the use of a routing for the selection of a group of
nodes and data. aggregation. The recipient requests by its target regions and waits to receive
data from sensors located in the selected region.

Hierarchical routing protocol

These protocols are adopted to allow the system to cover a wider area without degradation of
service. The principal aim of hierarchical routing is to reduce energy consumption and
routing cost of sensor nodes by making them within a cluster in order to perform aggregation
and reduce the number of messages transmitted to the base station. This routing is based
primarily on the gateway nodes. In fact, ordinary nodes know that if the recipient is not in
their immediate vicinity, they just send the request to the gateway. In turn, it will forward the
request to the target node.

Geographic routing protocol

Routing protocols use location-based information service for discovery of routing and data
transmission [Li et al. (2009)]. They allow the directional transmission of information to
avoid the flooded data across the network. Therefore, the routing cost will be reduced and the
routing algorithm will be more optimized. In addition, the use of network topology based on
location information of nodes provides easily control and management of network. The
disadvantage of these routing protocols is that each node must know the locations of other
nodes.

Routing Challenges in WSN

The design of routing protocol in WSN is influenced by many challenges due to several
characteristics that differentiate WSN from other wireless network. These challenges must be
overcome to achieve efficient communication in WSN. First despite the development in
microsensor technology, sensor nodes are tightly constrained because of limited resources
(energy, storage memory, transmission power) thus it require careful management and
efficient routing protocol to maximize the network lifetime and minimize energy expenditure
from the network. Second, routing scheme should be scalable to work with a large number of
nodes and response to any events happen in the phenomena or any changing in the network
topology [3]. Third, most of the applications in WSN require to transmit the data from
different source nodes to one sink node, for that routing protocol should have the ability to
handle this kind of data. Forth, when sensor nodes deploy in environment it’s happen that
some sensors generate similar value of attribute such data redundancy needs to be handle by
routing protocols to improve the performance of the network. Due to such differences, many
algorithms have been proposed to solve these problems of routing protocol in wireless sensor
networks. These routing mechanisms have considered the characteristics of sensor nodes
along with the application and architecture requirements.

CHAPTER 2

SYSTEM ANALYSIS

In this phase a detailed appraisal of the existing system is explained. This

appraisal includes how the system works and what it does. It also includes
finding out in more detail- what are the problems with the system and what user
requires from the new system or any new change in system. The output of this
phase results in the detail model of the system. The model describes the system
functions and data and system information flow. The phase also contains the
detail set of user requirements and these requirements are used to set objectives
for the new system.

2.1 CURRENT SYSTEM:

This approach assumes that there always exists a path from a node to the central
monitor, and hence is only applicable to networks with persistent connectivity.
In addition, since a node can be multiple hops away from the central monitor,
this approach can lead to a large amount of network-wide traffic, in conflict
with the constrained resources in mobile wireless networks. Another approach
is based on localized monitoring, where nodes broadcast heartbeat messages to
their one-hop neighbors and nodes in a neighborhood monitor each other
through heartbeat messages. Localized monitoring only generates localized
traffic and has been used successfully for node failure detection in static
networks.

2.2 SHORTCOMINGS OF THE CURRENT SYSTEM:

 Therefore, techniques that are designed for static networks are not
applicable. Secondly, the network may not always be connected.
 Therefore, approaches that rely on network connectivity have limited
applicability.
 Thirdly, the limited resources (computation, communication and battery
life) demand that node failure detection must be performed in a resource
conserving manner.

2.3 PROPOSED SYSTEM:

In this paper, we propose a novel probabilistic approach that judiciously

combines localized monitoring, location estimation and node collaboration to
detect node failures in mobile wire-less networks. Specifically, we propose two
schemes. In the first scheme, when a node A cannot hear from a neighboring
node B, it uses its own information about B and binary feedback from its
neighbors to decide whether B has failed or not. In the second scheme, A
gathers information from its neighbors, and uses the information jointly to make
the decision (see Section V for details). The first scheme incurs lower
communication overhead than the second scheme. On the other hand, the
second scheme fully utilizes information from the neighbors and can achieve
better performance in failure detection and false positive rates.

2.4 ADVANTAGE OF PROPOSED SYSTEM:

 In addition, since a node can be multiple hops away from the central
monitor, this approach can lead to a large amount of network-wide traffic,
in conflict with the constrained resources in mobile wireless networks.
 Another approach is based on localized monitoring, where nodes
broadcast heartbeat messages to their one-hop neighbors and nodes in a
neighborhood monitor each other through heartbeat messages.
 Localized monitoring only generates localized traffic and has been used
successfully for node failure detection in static networks.