ISSN 2347 - 3983

Volume 8. No. 2, February 2020

JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509
International Journal of Emerging Trends in Engineering Research
Available Online at http://www.warse.org/IJETER/static/pdf/file/ijeter37822020.pdf
https://doi.org/10.30534/ijeter/2020/37822020

Enhancing Fault Tolerance of IoT Networks within Device Layer

Dr. JKR Sastry1, Mr. Bhupathi2

1
Koneru Lakshmaiah Education Foundation (Deemed to be University), Vaddeswaram, India, [email protected]
2
Koneru Lakshmaiah Education Foundation (Deemed to be University), Vaddeswaram, India, [email protected]

ABSTRACT are being built these days using the IoT based networks,
including the home automation, defense, and surveillance
IoT based systems are error-prone and fragile, leading to the systems.
creation of faults in the entire network, causing misbehaviour
many times. Many types of faults do happen within IoT Every device in an IoT network fails and therefore needs to
networks due to the node, link, protocol conversion, and be made fail-free. Failure as such can happen due to
communication failures. Failures can happen due to breakdown, malfunctioning, or security leakage. Failures in
malfunctioning of hardware and software installed into the IoT networks can happen at the device level, local network
devices. Among all network failures due to failure of nodes level, controller level, gateway level, internet level, and
or links are more serious. A network topology which
remote storage and computing level. Wherever the failure
considers alternate links and redundant devices greatly
happens, the IoT network shall become in-operational and
improves the reliability of an IoT network.
serves no purpose. IoT systems must be fault-tolerant, or else
An IoT network as such, built through different inter-linked entire investment will go to waste and sometimes leads to
layers which include Device, controller, restful services, disasters.
gateway, internet and storage, and computing layers. Most of
the studies in the literature have considered single topology Fault tolerance as such could be as an integral part of the
generally hierarchical for connecting devices situated in design of IoT based system. Fault tolerance must be in-built
different layers. The fault tolerance level of an IoT network as part and parcel of the very IoT system itself. A typical IoT
dependent on the topology used as many issues such as system must cater for implementation of many of the fault-
alternate paths for communication, use of redundancy, and tolerant strategies that have, in the literature.
many such factors considered while building a network. A
single computational model normally used for computing the In this paper, a hybrid topology presented that considers a
fault tolerance level of an IoT network. Sometimes the fault butterfly topology at the device level, and a hierarchical
tolerance computing model chosen may not suit the topology topology within other layers with both the topologies
used for building a network for a specific layer within an IoT interconnected forming a composite topology.
network. Use of different topologies suiting a sub-network in
a layer and choice of different fault-tolerance computing The fault tolerance of IoT networks greatly improves when
models will help accurately determine the fault tolerance networking is done using butterfly topology. IoT is a
level of an IoT network. network of physical objects or ‘things’ that can interact with
each other to share information and take action. The Internet
In this paper, a Fault computing model that considers
of Things (IoT) is the interconnection of uniquely
different topologies for developing sub-nets in different
layers and computing models suited to a specific topology identifiable embedded computing devices within the existing
presented. The improvement in the fault tolerance of an IoT Internet infrastructure.
network achieved through consideration of two topologies,
which include hierarchical and butterfly networks presented Every device in an IoT network fail and therefore needs to be
in this paper. made fail free. Failure as such can happen due to breakdown,
malfunctioning, or security leakage. Failures in IoT can
Key words: IoT network, Network Topologies, Fault tree happen at any level of an IoT network. Wherever the failure,
analysis, Statistical models for computing reliability, the IoT shall become in-operational and serves no purpose.
butterfly topology, hierarchal topological models.
Fault tolerance as such realized as an integral part of the
1. INTRODUCTION design of IoT based system. Fault tolerance must be in-built
IoT technologies are the next generation of technologies after as part and parcel of the very IoT system itself. It is
internet technologies. IoT technologies are dynamic and necessary to find and identify various strategies that one can
differ from conventional networks. IoT networks must be adopt to ensure a very high level of fault tolerance of the IoT
scalable, maintainable, and Fault-tolerant. Many applications based system.

491
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

Faults within any network are bound to happen due to Choice of a topology suiting to the fault tolerance level of
various reasons. A network called fault-tolerant when it the devices contained in each layer and choice of the proper
functions even normally when faults occur while the network method to compute fault tolerance of a sub-net will lead to
is in use. IoT networks are fragile and therefore, must be high fault-tolerant IoT network. In this paper, a composite
made fault-tolerant. IoT networks used in the medical model that considers different networking topologies and
domain must be fault-tolerant as any misinformation flow fault tolerance computing models that enhance the fault
will cause a devastating effect even to the extent of loss of tolerance level of an IoT network presented.
human life. A small fault may lead to serious negative
results. 2. RELATED WORK

When a Fault happens, generally, the data acquired is lost. Maheswari et al., [1], have presented different kinds of
Data must be preserved and retained at any cost. Use of Non- failures that can happen in a mobile network that include
volatile memory within IoT based systems will help in power failures, energy failures, and network failures such as
recovering from the loss of the normal operation when a fault node and link failures. They have presented different
occurs. Fault tolerance is essential even at the cost of techniques considering a subset of a set of failures and have
incurring overhead die to use of non-volatile memories. shown the reliability of the network and the way the
reliability enhanced through consideration of other aspects of
The common approach to enhance the fault tolerance is fault tolerance that include alternative power, energy, and the
Making a process to be running through several instances network management.
and adding many devices in parallel such that when one fails,
there is another instance/device to take over. Computing Generally, mission-critical real-time systems implemented
fault tolerance is as such complex due to the existence of through distributed embedded systems. The real-time
many intricate issues. characteristics of an embedded system mapped to the
requirements of a distributed system which are dynamic.
Fault tolerance of network generally expressed quantitatively Most of the techniques available for computing the fault
in terms of success or failure rate is the rate of failure of tolerance of a system don not considered the distributed
topmost nodes existing in a Fault Tree — the success rate considerations of a system. FTA based systems consider
computed as 1 – Failure Rate. In a typical network success every working component and the connectivity between
rate is the probability that at least one transmission path them, whereas the distributed systems built through logical
exists from a transmitting device to the destination device — models that describe connectivity between the components.
the failure rate obtained by subtracting the success rate from
1. Paul Rubel et al.,[2], have presented approaches /techniques
using which FTA applied for computing the fault tolerance
An IoT network typically contains many layers such as of distributed embedded systems. They have considered
device, controller, restful service, gateway, internet and three FT based techniques/ approaches that include auto-
storage & and computing layers. Many devices are configuration of dynamic systems, mixed-mode
interconnected through the realization of a subnet in each of communication, and maintenance of redundancy into peer-
the layers generally using the same topology. The topology peer communication. They have described an integrated
to be used as such is dependent on the kind of devices used system that combines an off the shelf middleware with
and the fault-tolerant characteristics of those devices. A different FT based techniques that have been the advanced
single topology as such may not be suitable for all layers of models implemented by them.
the IoT network. The network can be designed using
different network topologies and architecture and different Choreography is a mechanism generally used to define
implementation methods and a certain level of redundancy object interaction dynamically not withholding any of the
built into the system. statically defined object linkages. This technique generally
affects the coherence that exists between the objects. Due to
Many types of faults happen within IoT networks, and each this reason, there could be loss of messages flowing across
of the faults must be considered and find the methods to various objects contained in an application. There could be
mitigate the same. IoT networks typically are recognized into several faults occurring due to this reason leading to the
several layers. A fault-tolerance computing model used could failure of a system. Sylvain Cherrier et al.,[3], have
differ from layer to layer. Fault tolerance of a network proposed the method that synchronizes, de-synchronizes and
generally computed using a single computational model. A a re-synchronizes the objects such that coherence between
single computational model is generally not stuffiest as the the objects intact leading to failure-free systems while
networks in each layer may have deterministic or dynamically configurable systems implemented through the
probabilistic behavior. process of choreography.

492
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

All the devices in an IoT network interconnected as a subnet For developing an IoT network, three things focused; the
in the bottom-most layer of the network. The protocols used network should be efficient, economical, and robust. Kai
for effecting communication between the devices are also Fan et al.,[8], have presented random topologies, which
pre-identified and taken in to count while designing the IoT promises high performance by reducing the cost of network
based systems. In this process, there could be a possibility establishment. It automatically explores to build temporary
that unlike devices may be connected leading to the routing when unpredicted failure occurs, which will not
generation of unwanted faults during the working of these affect the overall network. By implementing these methods,
devices. On the other hand, Chen Wang1 et al.,[4], have they have improved the fault tolerance and availability of the
recommended the analysis of data generated by the Networks.
respective devices and established/predict the logical
relationships between those devices which can be used as a Huge data is collected using the IoT network, which is made
basis to predict faults and maintenance requirements of an available to several local and remote users. Routing the
application/objects. Generally, this needs fault diagnosis and information across the IoT network must cater for faults that
in a way, enhancing the fault tolerance/reliability through may occur while the IoT system is in running state. Zaki
periodic maintenance of the devices which are predicted to Hasan et al., [9], presented a routing algorithm which is
be error-prone. capable of constructing and recovering and also selecting k-
disjoint paths that are fault free and then communicate the
WSN networks are fault-prone due to loss of communication data across those few selected fault-free paths, The authors
link, loss of data during transmission and, missing sensor considered optimization of energy required to communicate
nodes, etc., due to the occurrence of various factors such as the data across the network while ensuring that minimum
asymmetric communication links, dislocation of sensor node delay in communicating the data. They have compared
and collision, radio interference, environmental impact, and PMSO with other similar algorithms and shown the
power depletion. There are several mechanisms presented in efficiency and effectiveness of the algorithm.
the literature that includes cluttering, inducing redundancy,
deployment of objects dynamically to mitigate the failures The architecture of an IoT network designed considering the
that can happen within WSN networks. Gholamreza possibility of occurrence of the faults within the network. A
Kakamanshadi et al., [5], have presented an analysis of the fault-tolerant architecture proposed by Asad Javeda et al.,
techniques considering the weakness and strengths of the [10], used for implementing a variety of IoT based
mechanisms and arrived at suitable mechanisms deployed applications. In the architecture, they have considered the
given a composer of failure situations. placement of software stacks at different locations for
making deployment decisions at run time. They have also
Cloud computing technologies deal with a large amount of considered many other issues such as long-distance network
data, so it is cost-effective for implementing IT-based connectivity, faults happening within edge devices, harsh
solutions. Many issues are to be addressed considering the operating environment, etc. In the architecture that included
usage of the cloud. Among all, fault tolerance and securing the issue of processing that should take place at both the
the data are the most important issues. DBK Kamesh et al., edges of devices and the cloud.
[6], have presented that a fault occurring in one device might
lead to faults occurring in one or more connected devices. Implementing a fault-tolerant IoT based system is complex
They have implemented a design method to achieve high as one has to deal with many of the dynamically evolvable
reliability, which leads to improvising the fault tolerance of and coupled systems. Alexander Power et al., [11], built a
the networks that connect clouds. framework using Micro-services. In the framework, they
have included the support required for the IoT system to
Customers are using Cloud computing for meeting their IT tolerate the faults when they happen through the inclusion of
requirements. However, the users are concerned with the machine learning processes. The machine learns when the
security and availability of the data as cloud computing faults happen and then take tolerant actions immediately so
infrastructure can be affected due to attacks by malicious that the network will fail free.
users and due to the generation of different types of faults
that happen due to failure of either Hardware or software. A cluster or a leader node used for communicating within the
Susmitha et al., [7], have discussed the challenges that one IoT, WSN, and Adhoc networks. The node must be selected
should address while using cloud computing for meeting such that it has maximum energy or located to the extreme
their IT requirements. One such challenge is to create fault left of the network such that it would be the last node. If the
tolerance within a network that connects various physical head node or the leader node fails, the entire IoT network
and logical resources. An architectural framework has been will fail. Routing algorithms are the key to any
recommended implementation of which will provide fault communication. Routing algorithms must be intelligent to
tolerance within the network elect a cluster head when a fault happens such that fail free
communication happens. Achene Bounceur1 et al., [12],
have expressed that the leader must be elected dynamically

493
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

considering the paths that must have failed. They have failures of nodes, links, routers, and communication, which
presented an algorithm for electing a leader through the use all get culminated into topologies which take into account all
of a local minimum as a root and the concept of flooding is aspects of failures of the networks.
used to determine a spanning tree for routing the
communication over the spanning tree. The two spanning Building fault tolerance at the topology level takes into
trees coincide, the better one is selected, and the other account almost all aspects related to fault tolerance. In the
ignored. The root of the spanning tree will be the leader literature, the dynamic adaption of network topologies
through which the communication is affected. suggested which is very complicated for implementation as
the IoT network as such is heterogeneous, especially within
A cloud-based IoT network architecture proposed by Jatinder the bottom level of the network
Grover et al., [13],. The architecture built with the
components required for making the network survive even in In this report, a methodology has been presented taking into
the presence of failure of the edge servers. The network account the static nature of the IoT networks considering
recognized as different hierarchies, and the communication is improving the fault tolerance in terms of establishing
re-directed to different hierarchy when a fault noticed in a alternative networking, especially looking at the device level
different hierarchy. They have included mobile agents on the of the IoT networks.
servers that share the system states, data, and other agents if
the system fails at fog, edge, mist, or cloud. Inclusion of 4. PROTOTYPE IoT NETWORK FOR
these components will help re-direction in the case of any EXPERIMENTATION AND RESULTS
server failure.
4.1 Overview of prototype IoT network
IoT is a layered network which is having different layers; it
deals with many heterogeneous subnetworks. Failure rates of An IoT network typically contains several layers of
an IoT system are dependent on network topology as the networking that include Device Layer, Controlling Layer,
faults can happen within the network hardware device and Services layer, gateway Layer, and cloud computing Layer.
even can happen in the software that runs in different layers. The IoT network must be fault-tolerant at every layer. In this
Every IoT based must be scalable, maintainable, and highly paper, an approach has been built considering all the layers
reliable. Failure of an IoT system will lose its identity and in the network while exploring the fault tolerance in device
leads to customer dissatisfaction. One has to implement quite layer while assuming that the fault tolerance of the layers in
number strategies to make an IoT system more reliable. the network fixed and no variances noticed in those layers.
Many authors considered the reducing levels of the
performance as a kind occurrence of faults with IT and A typical IoT network developed for carrying the
therefore performance of an IoT system must also be experimentation shown in Figure 1. The IoT network has
considered for assessing the fault tolerance of the IoT based been built considering all the layers situated in a typical and
system[14][15[16][17][18][19][20][21][22][23][24][25] [26] comprehensive IoT network. The network is built
[27][28][29][30][31]. considering all the layers that include device layer, controller
layer, services layer, gateway layer, and computing layer
3. COMPARATIVE ANALYSIS
Device Layer:
Table 1 shows the comparison of findings by various
researchers relating to fault tolerance of IoT networks that One has to face many challenges to implement a fully
are established either through wired, wireless, and those operational IoT based system all the time. One has to look
networks connected through backend cloud computing into several issues which include connectivity between the
infrastructure. Many mechanisms have been proposed in the devices, power management, scalability, interoperability,
literature using which fault tolerance can be improved. The security, and availability. Management of the IoT devices by
Mechanisms include redundancy, clustering, and deployment using standard protocols by using the standard services
based mechanisms. The after-effects of improving the fault rendered by third-party vendors is the key issue.
tolerance in terms of higher availability increase in accuracy,
savings in energy, enhanced network life, minimization of Efficient management of the device will lead to proper
the failures of the components, increase in efficiency, and integration, monitoring, organizing, and remotely controlling
robustness explained in the literature. the functioning of the devices through the provision of
internet-enabled or interfaced devices. These kinds of
The issues of fault tolerance have been addressed implementations will help to implement the required
considering the kind of faults that can happen and redundancy, fault tolerance, security, and connectivity of the
mechanisms to mitigate the same without much IoT devices and as such, helpful in managing the entire life
consideration to the extent to which fault tolerance can be cycle of the devices. Some of the important processes
improved. The focus of the researchers, however, is on the included in an IoT based system include
494
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

authentication/authorization, registration, provisioning, internet, Cloud-based users also can get the access the data
monitoring and diagnostics, configuration, troubleshooting, stored in the cloud transmitted through services server.
etc.
Gateway Layer:
Unlike other system, IoT systems are application dependent.
Based on the kind of application implemented, one has to There can be multiple paths to the cloud. The service's
select appropriate communication, networking, and servers have the option of sending the data through any
connectivity protocols used with the devices that are internet chosen path to the cloud. While the server supported with
enabled. The users have many options at their hand for few communication interfaces, the cloud might have several
selecting different connectivity and communication interfaces, in which case a gateway implemented. The main
protocols, which include MQTT (Message Queuing aim of an IoT network is to connect thousands of devices
Telemetry Transport), DTLS (Datagram Transport Layer that collect and send data through the internet. Several of the
Security), CoAP (Constrained Application Protocol), etc. communications systems implemented that include Cellular
Many options also exist for selecting wireless (2G-5G), wireless (Wi-Fi, ZigBee), wired (Ethernet), etc. A
communication protocols that include Bluetooth, Wifi, local network connected to a gateway through wireless and
Zigbee, LPWAN, IPv6, RFID, NFC, Z-Wave, etc., wired communication systems.
Communication between the devices can also be affected
through the use of Satellite, cellular and Ethernet-based optic Cloud / Application Layer:
fiber communication. Each of the options has a bearing on
bandwidth, range power requirements. The devices that The topmost layer in an IoT based network is the
participate in an IoT based communications must be selected applications layer in which several of the user applications
considering all those aspects above. situated. Users interact with a chosen application. The user-
Controller Layer: defined applications situated on mobile phones, laptops, or
desktops. In this layer, several tools used for different
The middle tier of an IoT Based system is the controller purposes such as connecting, communicating, displaying,
layer. The components included in the middle tier are and visualizing any intelligent applications such as logistics
primarily responsible for data collection; aggregations and management, intelligent transportation, disaster recovery,
transmission of the data form the devices situated in the ensuring safety, etc. the 5 Layer architecture used for
lower tier of the IoT based system. The controller is building IoT based networks provides a framework used for
primarily responsible for collecting the data, processing, and developing different types of networks. With the
then transmission of the same to back end systems where the implementation of IoT based networks internet is being
information is stored. The periodicity of data collection, moved away from transmitting data to providing different
processing, and transmission depends on the streaming of the kinds of services. WEB servers predominantly used for
data in real-time, and the speed with which buffering, providing the requested services to the end-users, The
encoding, decoding done. A certain amount of processing is services layer generally built with a WEB server such that
also done on the collected data based on pre-defined rules, user requests serviced by the WEB server
regulations, and policies and actuating if any required will be
locally triggered. Many types of controller exits which vary 4.2 Hardware Specification – Prototype IoT network
a lot based on the availability of interfaces to get connected
with the devices, availability of security provisions and the The prototype IoT network has been developed using 3
kind of devices that can be connected to deal with various Arduino-Uno Microcontrollers that are used to collect three
environmental factors. The devices can be connected to the types of data that include Temperature, Light using operation
controllers through different networking options that include of three devices that drive, FAN, Light and Air conditioner.
LAN, USB, WAN, CAN, RS485, I2C, and firewire. Two sensors used for detecting the temperatures and Light
(DHT11, LDR). All three Arduino – Uno microcontrollers
Services Layer: are interfaced with Wi-Fi communication modules
externally.
The data collected by the controller can be used for
processing locally or moved to other devices incoherent All these controllers are networked to form into clusters
manner. It has been a serious challenge to collect a large through two cluster heads established through “Node MCU”
amount of data at one location and move the same to remote Microcontroller that has inbuilt Wi-Fi interface to establish
locations, where It gets stored and processed. The controller communication in-between the cluster head and the data
is responsible for sending the data to remote locations. Since acquisition systems and the node MCU has been built using
data communication power of a controller is a week, the data externally interfaced ZigBee systems in addition to its
routed through a server called services server. Remote users internally situated Wi-Fi system. The dual communication
can route their service request to this server through the systems using Wi-Fi and ZigBee provides for reliable
communication between the Cluster heads and the controller.

495
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

Given an IoT network, analysis has to be done to find the

The controller function implemented through Raspberry Pi fault tolerance strength of the network. The faultiest used
Microcontroller that has in-built Wi-Fi and ZigBee technique is Fault tree Analysis. Fault tree analysis is an
communication. The cluster heads communicate with analytical technique. In this approach, an undersized state of
Microcontroller through dual communication channels that the system is defined and then the same is analysed in terms
include ZigBee and Wi-Fi communication protocols. The of environment, operation, safety, criticality, etc. and then
controller connected to the restful server through two find different ways in which the undesired event can occur.
communication channels, which include Ethernet and Wi-Fi A fault tree is a graphical model that has all combinations of
communication systems in peer-to-peer communication the faults, both sequential and parallel that can occur, leading
mode. The restful server is built using Intel i7 technologies to an undesirable event. The faults as such can be hardware
which run windows operating system. A restful services faults, network faults, software faults, or faults occurring due
server implemented on this machine. Three services to human error. The basic interrelations between the faults
developed include FAN service, AC service, and LIGHT and the events are depicted using a fault tree. The undesired
service. event will be the top node of the fault tree. A fault tree is not
a model that can capture all system failures or that causes
These services triggered from outside using a service request that lead to system failures.
initiated through a SOAP protocol which is an XML code.
The XML code is interpreted to find the service requested by The top node of a fault tree relates to the occurrence of a
the external user. The SOAP request is parsed to find the specific event, which is a kind of system failure. The faults
service which translated to a command which is then tree deals with those faults that lead to the top event. There
transmitted to the controller to execute the command and the can be many and many faults that could be related to the top
result of the execution of the command transmitted to Restful of the event, making the construction of the tree complex. To
services server which intern communicates the service avoid this few venerable and most important faults are
outcome to the external user through the gateway. selected and modelled into the tree. AND gates and OR gates
are used to show the relationships among the faults that can
An application running on the internet can make a request to occur on different devices. A fault tree model is not a
Restful service server for want of service. The user quantitative model, and In fact, it is a qualitative model that
application can also initiate a request for data through cloud can be measured quantitatively
computing infrastructure through the invocation of SaaS
service or initiating a request to the WEB server for want of In the fault, tree gates used for passing through the effect of
data. The interface between the User application and the the faults up the ladder to reach the root node. The
restful service server achieved through either a gateway or relationship between the events modelled through the gates.
using the direct connection using a Wi- fi Channel for It shows how the lower order events trigger higher-order
imitating a service request The gateway developed through events. The out from a gate is the higher-order event. The
three different communication modes both the input and lower order events are the inputs to the gates. The gates are
output interface which include ZigBee, Wi-Fi, and GSM and not like logic gates. The gates are just symbolic to show what
Ethernet. The gateway is intelligent to receive input from one output event raised due to the occurrence of the lower order
of the active input channels and translate the protocol to one events. The occurrence of an output event due to the
of the active, outgoing interfaces, thus working as an active occurrence of one or more input events modelled through the
communication protocol converter. The gateway is designed OR gate, the occurrence of the output events when all input
to consider the communication speed, buffering, arbitration, events occur modelled through AND gate.
timing, etc. The outgoing channels of the Gateway connect
to the application, WEB server, and the cloud computing Assessing fault tolerance of IoT networks is required as the
infrastructure. devices in the network are fragile and lightweight. The fault
tolerance of an IoT network is majorly dependent on the way
The restful service server invokes a WEB service or a cloud various hardware elements are interconnected and the kind of
computing service to submit the data collected by the device devices selected for achieving the network. Network
cluster especially through the invocation of web server topology is the most important aspects considered from the
service or a cloud computing service for storing the data in a perspective of fault tolerance of the IoT network. The
database. The application is also built to retrieve the data topology as such takes care of many failure conditions that
from the database for doing analytics if any, by using one of can generally happen within an IoT network.
the standard statistical tools.
Many methods/models are in existence for computing the
5. INVESTIGATIONS AND FINDINGS reliability of any given network, the most important being
reliability analysis through fault tree analysis and
5.1 Fault Analysis of IoT networks probability models.

496
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

5.2 Estimating Fault Tolerance of an IoT Network using  (i )  1  ql (1)

the FT Analysis Where k = Number of stages, ρl = probability that a link fails
and Φ (i) is the probability that a switch box in stage K can
FT analysis carried on the prototype model, and the derived fail. Φ(k) can be computed using equation (2).
FT diagram for the prototype model, a part of which shown
in Figure 2. The relationships among different elements that
form the network are connected through OR and gates to
 (i)  1  (1  pl (i  1)) 2 (2)
simulate the failure model of the prototype IoT network.
Fault computations carried through compilation of failure Due to the simplicity of the butterfly topology, it has been
rates of the devices and the failure of one device due to contemplated to modify the original prototype IoT network
failure of other devices based on the relationships that exist using Butterfly topology to assess the change in the fault
among the devices through AND or OR relationships among tolerance state of the IoT network. Figure 3 shows the
the devices. The fault computations are undertaken using a revised network topology.
bottom-up approach until the root node arrives. The failure
rate of the root node is considered to be the failure rate of the 5.4 Modifying the Prototype IoT network into a Hybrid
IoT network. The failure rates of each of the device obtained Topology model
through Manufacturer data. Table 2 shows the fault
commutations of the Prototype model. From the table, one The Prototype IoT network is modified using two topologies.
can observe that the success rate of the prototype IoT model While the butterfly model used for building a network within
is 0.729. The failure rate of the prototype model will then be the Device level of the IoT network, the other layers of the
1 – 0.729 = 0.271. network are connected using hierarchical networking
topology. The reliability computation of such a network
5.3 Modifying the IoT network with standard networking achieved through probability model prescribed for Butterfly
topology networks and by conducting FTA on the Hierarchical model.
The composite Fault tolerance computational model
The prototype model discussed in section 3 is a pure presented that include both the computational models;
hierarchical networking diagram and as such, do not follow Butterfly model at the device level and hierarchical models at
any specific topology. Many networking topologies exist in other levels of the IoT network. The revised IoT network
the literature that includes Butterfly, crossbar, multi-stage, placed in Figure 4.
mesh, and such other combination of topologies. It is easy to
compute the reliability of these networks due to the existence 5.5 Computation of Fault tolerance at device Level using
of probability-based computational methods for computing the butterfly network
reliability.
An IoT network developed in terms of different layers of the
The failure rate of the network reduces by implementing networks which get connected hierarchically. The layers
different topologies than the tree topology used for the generally include Device, Controller, Services, Gateway, and
sample IoT network. In a multistage network, there will be cloud computing layers. In the work modification of
multiple stages at which the inputs are processed to networking, topology is considered at device level only
transform inputs to outputs. The switching nodes sutured in while keeping the rest of the network static and
different processing stages to not all undertake to process, hierarchically laid.
but all move the processed outputs to the nodes situated in a
different stage. In the revised working diagram, a 4X4 butterfly network has
been constructed at the device level considering 3 Inputs
The network is built using N X N switches. Each switch (AC, FAN, and LIGHT. The reliability of the device level
takes N inputs and produces N Outputs. The switches network computed through the use of probability models
interfaced through different connections that include the discussed in section 4.2. Following are the reliability
cross, straight, lower broadcast, and upper broadcast. A 2 X computation of the butterfly network built at the device level.
2 network is called the butterfly network. Using equation (1) and equation (2)

The devices are networked using Butterfly model. The Links pl  0.98, ql  0.02
that are at a distance two are connected to switch box. A 4 X
4 butterfly network achieved through two 2 X 2 Butterfly
networks. Figure 3 shows a 4 X 4 Butterfly network.

Consider Φ(0), which is the probability that at least one line

out of a switch box at the output stage is functional then the
probability is 1-ql, where ql is the failure rate of the link.

497
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

 (i )  1  (1  pl (i  1))2
6. CONCLUSIONS
 (1)  1  (1  0.98 (1  1))2
IoT networks are fragile that connect numerous devices
 1  (1  0.98 (0))2
using many protocols and interfaces. IoT networks are
 1  (1  0.98(1  ql ))2 lightweight, and fault tolerance levels of such networks are
quite low. The reliability of IoT networking is quite
 1  (1  0.98(1  0.02))2
dependent on the kind of topology, and the way networking
 1  (0.02(0.98))2 carried.
 1  (0.0196)2 IoT networks contain many layers, and a sub-net exists in
 1  0.00038 each layer connecting the devices used in a specific layer.
Networking of the devices in the sub-nets generally done
 0.998 using the same topology and establish the connectivity
The fault tolerance of the cluster head which receives the between the sub-nets hierarchically. Fault tolerance of an IoT
outputs out of the device level network thus computed to be network depends on the topology used as the topology
of value 0.998. The Cluster heads considered as devices in a dictates the availability of alternate paths of execution,
hierarchical network having a fault tolerance value 0.998. availability of the redundancy fault tolerated switching
system, etc., One has to choose a suitable topology based on
5.6 Computation of Fault tolerance of the entire network the kind of devices connected within the sub-net. Choice of a
proper topology in each of the layer is the key that dictates
The modified network thus can be further modified, as the overall fault tolerance of the IoT network.
shown in Figure 4, considering that the process flow
commences from the cluster head. A fault tree analysis Choice of a Butterfly network at the device level and
conducted on the modified IoT network. Figure 5 shows the hierarchical topology at the higher levels improved the fault
faulty tree Analysis Diagram. The fault tolerance tolerance of the prototype model. The success rate of the IoT
computations are shown in Table 3, considering the FTA network enhanced by about 17% moving from 0.729 to
diagram shown in Figure 6. From the computation can be 0.900. The success rate is consistent, considering the
seen, the fault tolerance value is improved from 0.79 to 0.90 computations undertaken through FTA and Probability
due to the usage of the butterfly model at the device level. models.

5.7 Comparative Analysis of Fault computations of IoT Choice of a computational model for computing the success
Network rate is also very important to arrive at realistic estimates.
Choice of probability model when it comes to the butterfly
An analysis of fault tolerance computed through Fault Tree network and FTA model when it comes to hierarchical
analysis of original network, fault tolerance computed networks has been proved to be quite effective.
through FTA Analysis and Probability model is placed below
in Table 4. From the table, one can see that the reliability of Developing an IoT network using butterfly topology greatly
an IOT based network increased tremendously when IoT improves the fault tolerance level while reducing the
network established as a Butter Fly network. Even the complexity of the very network, especially in reducing the
complexity of the network decreases tremendously. 21 communication interfaces.
Communication modules are reduced to 4 Communication
models when networking carried as per Butterfly networking REFERENCES
architecture. In the case of a hierarchical star topology, it is
not possible to represent the operational aspects of the 1 D.Maheshwari1, A. Dhanalakshmi, Fault Tolerance in
network as probability models. Even if an attempt made, it Mobile ad hoc Network: A Survey. International
would be a too complicated model which makes the Journal of Advanced Research in Computer Science
computations quite complicated. and Software Engineering, Volume 3, Issue 3, pp: 191-
195
Table 4: Comparative Analysis of Reliability assessment 2 Paul Rubel, Aniruddha Gokhale, Aaron Paulos,
considering different topologies Matthew Gillen, Jaiganesh Balasubramanian, Priya
Narasimhan, Joseph Loyall, Richard Schantz, (2007).
Success Rate Fault-tolerant approaches for distributed real-time and
Success rate based on
Type of topology used Based probability
FTA Analysis
models
embedded systems. (DARPA) under contract
Hierarchical star NBCHC030119
0.729 --
Topology https://ieeexplore.ieee.org/document/4455043, pp: 1-8
Butter Fly Topology 0.900 0.900 3 Sylvain Cherrier, Yacine M. Ghamri-Doudane,
Stéphane Lohier, and Gilles Roussel, (2014). Fault-

498
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

recovery and Coherence in the Internet of Things IoT. International Journal of Engineering and
Choreographies. IEEE WF-IoT, HAL Id: hal-00957056, Technology(UAE), 7 (2.7), pp: 352-355
pp:1-7 17 Poonam Jain, S., Pooja, S., Sripath Roy, K., Abhilash,
4 Gholamreza Kakamanshadi, Savita Gupta, Sukhwinder K, Arvind, B. V., (2018). Implementation of
Singh, (2015). A Survey on Fault Tolerance Techniques asymmetric processing on multi-core processors to
in Wireless Sensor Networks. IEEE, 978-1-4673-7910- implement IOT applications on GNU/Linux framework.
6/15/$31.00, pp: 168-173 International Journal of Engineering and Technology
5 Chen Wang1, Hoang Tam, (2015). An IoT Application (UAE), 7 (2.7), pp:710-713
for Fault Diagnosis and Prediction, IEEE, 978-1-5090- 18 Raja Sekhara Naidu, G., Venkat Ram, N, (2018). Urban
0214-6/15, DOI 10.1109/DSDIS.2015.97, pp: 726-731 climate monitoring system with IoT data analytics.
6 DBK Kamesh, JKR Sastry, Ch. Devi Anusha, P. International Journal of Engineering and Technology
Padmini, G. Siva Anjaneyulu, (2016). Building Fault (UAE), 7 (2.20), pp: 5-9
Tolerance within Clouds at Network Level. 19 Poonam Gupta, Kopparti Veera Venkata Satyanarayan,
International Journal of Electrical and Computer Dilip Devchand Shah, (2018). Development and testing
Engineering, Vol. 6, No. 4, pp: 1560-1569. of message scheduling middleware algorithm with SOA
7 S. L. Sushmitha, Dr. D. B. K. Kamesh, Dr. J. K. R. for message traffic control in the IoT environment.
Sastry, V. V. N. Sri Ravali, Y. Sai Krishna Reddy, International Journal of Intelligent Engineering and
(2016). Building Fault Tolerance within clouds for Systems. Vol.11, No. 5, DOI:
Providing Uninterrupted Software as Service. Journal 10.22266/ijies2018.1031.28, pp: 301-313
of Theoretical and Applied Information Technology, 20 Poonam Gupta, Kopparti Veera Venkata Satyanarayan,
Vol.88. No.1, ISSN: 1992-8645, pp: 65-76 Dilip Devchand Shah, (2018). IoT multitasking:
8 Kai Fan, Jiapeng Lu, Dazhen Sun, Yong Jin, Ruimin Development of hybrid execution service-oriented
Shen, Bin Sheng, (2017). Failure Resilient Routing Via architecture (HESOA) to reduce response time for IoT
IoT Networks. 978-1-5386-3066-2/17, DOI application. Journal of Theoretical and Applied
10.1109/iThings-GreenCom-CPSCom-SmartData. Information Technology, 96(5), pp. 1398-1407,
9 Mohammed Zaki Hasan and Fadi Al-Turjman, (2017). 21 Yasaswini, A., Daya Sagar, K. V, Shri Vishnu, K., Hari
Optimizing Multipath Routing With Guaranteed Fault Nandan V, Prasadara Rao, P. V. R. D., (2018),
Tolerance in the Internet of Things. IEEE Sensors Automation of an IoT hub using artificial intelligence
Journal, Digital Object Identifier techniques. International Journal of Engineering and
10.1109/JSEN.2017.2739188. VOL. 17, NO. 19, pp: Technology(UAE), 27DOI: 10.14419/ijet.v7i2.7.10250,
6463-6473 Vol 7, No 2.7, pp. 25-30
10 Asad Javed, Keijo Heljanko, Andrea Buda, and Kary 22 Ramaiah, C. H., Parimala, V. S., Kumar, S. P., Reddy,
Främling, (2018). A Fault-Tolerant IoT Architecture for G. B., Rahul, Y. (2018). Remote monitoring through
Edge and Cloud. IEEE, 978-1-4673-9944-9/18, the tab. International Journal of Mechanical
DOI:10.1109/wf-IoT.2018.8355149, pp: 813-818. Engineering and Technology, Volume 9, Issue 1,
11 Alexander Power and Gerald Kotonya (2018). A January 2018, pp. 490–498
Microservices Architecture for Reactive and Proactive 23 Y. Shanmukha Sai, K. Kiran Kumar, (2018). Internet of
Fault Tolerance in IoT Systems. IEEE, 978-1-5386- things and their applications. International Journal of
4725-7/18/$31.00, DOI:10.1109/wowmom. Engineering and Technology(UAE), Vol 7, No 2.7, pp.
2018.8449789, pp: 1-6 422-427
12 Ahc`ene Bounceur, Madani Bezoui, Massinissa Lounis, 24 J. Rajasekhar , Dr. JKR Sastry, An Approach to
Reinhardt Euler, Ciprian Teodorov, (2018). A New hybridisation of embedded system networks,
Dominating Tree Routing Algorithm for Efficient International Journal of Engineering & Technology 7
Leader Election in IoT Networks. IEEE 978-1-5386- (2.7) (2018) 384-389
4790-5/18, DOI:10.1109/ccnc.2018.8319292, pp:1-2 25 T. Pavithra1, J. K. R. Sastry, Strategies to handle
13 Jitender Grover and Rama Murthy Garimella, (2018). heterogeneity prevalent within an IOT based network,
Reliable and Fault-Tolerant IoT-Edge Architecture. International Journal of Engineering & Technology, 7
DOI: 10.1109/ICSENS.2018.8589624, pp:1-4 (2.7) (2018) 77-83
14 Murty, A. S. R., Teja, K., Naveen, S. (2018). Lathe 26 Bhupathi, Dr. JKR Sastry, A framework for effecting
performance monitoring using IoT. International fault tolerance
Journal of Mechanical Engineering and Technology 27 within IoT network, Jour of Adv Research in
(IJMET), Volume 9, Issue 4, pp. 494–501 Dynamical & Control Systems, Vol. 10, 02-Special
15 Rambabu, K., Venkatram, N. (2018). Traffic flow Issue, 2018
features as metrics (TFFM): Detection of application 28 K.V. Sowmya1, Dr. JKR Sastry, Performance
layer level DDOS attack scope of IoT traffic flow. evaluation of IOT systems – basic issues, International
International Journal of Engineering and Technology Journal of Engineering & Technology, 7 (2.7) (2018)
(UAE), 7(2), pp. 203-208 131-137
16 K., Prabu, A.V., Sai Prathyusha, M., Varakumari, S., 29 Dr. J, Sasi Bhanu, Dr. JKR Sastry, P. Venkata Sunil
(2018). Performance monitoring of UPS battery using Kumar, B. Venkata Sai, K.V. Sowmya, Enhancing
Performance of IoT Networks through High
499
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

Performance Computing, Volume 8, No.3, May - June

2019
30 M. Sai Rama Krishna, J K R Sastry , J Sasi Bhanu,
Building Fault Tolerance Within Wireless Sensor
Networks: A Butterfly Model, Research Jourml of
Applied Sciences 12 (2): 139-147, 2017
31 J. K. R. Sastry, K. Sai Abhigna, R. Samuel, D. B. K.
Kamesh, Architectural models for fault tolerance
within clouds at infrastructure level, ARPN Journal of
Engineering and Applied Sciences, VOL. 12, NO. 11,
JUNE 2017

Restful Server
Router WEB Server

Cloud
Access Point Computing
System

Controller
Gateway User
Application
ZIGBee WI-
FI

Cluster Head1

FAN
AC Cluster Head2

LIGHT

Figure 1: Prototype - IoT Network

500
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

Com9

Com8
AC
Com7

Light

Fan

Com4

Com1 Com2

Light AC

501
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

Com24

Com23
AC
Com22

Light

Fan

Com19

Com16 Com17

Light AC

Figure 2: FT Diagram for the Prototype Model

502
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

0 0
2 1

Outputs
inputs

1 2
3 3

Stage1 Stage0
4 X 4 Butterfly Network

Figure 3: 4 X 4 Butterfly network

503
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

WEB
Server
Router
Restful
Server

Cloud
Access
Computing
Point
System

Controller
Gateway User
Application
ZI WI
Gb -FI
ee

Cluster Head1
COM
COM

Cluster Head2
COM
COM
COM

COM
LIGHT
FAN

NC
AC

COM

COM
LIGHT

AC
FAN

NC

Figure 4: Modified IoT network using Butterfly topology

504
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

WEB Server

Router

Restful Server

Cloud Computing
Access Point System

Controller
Gateway
User Application

zigbee Wifi

Cluster Head1

Cluster Head2

Figure 5: Modified IoT Network from Cluster Head

505
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509
CLOUD

COM 14

WiFi Server

Gateway

COM 13

COM 15
ACCESS POINT

REST SERVER

COM 11

CONTROLLER

COM 10 COM 10

CLUSTER HEAD 1 CLUSTER HEAD 2

Figure 6: FTA Diagram for Modified IoT network

506
 8.
7.
6.
5.
4.
3.
2.
1.
Sno.

Kai Fan
Susmitha
Paul Rubel
Maheswari

Chen Wang1
Author Name

DBK Kamesh
Sylvain Cherrier

Gholamreza Kakamanshadi
Frameworks

Architectures

Random
Topologies

√
√
Link Failures

√
Path Failures
√

Power depletion
√

Energy depletion

Mis-Behaving nodes
√
√

(Increase in Latency)
Network Failures

√
√

Faulty Nodes
Node Failures

Communication/

507
√

Messaging
Failures\Routing
Device failures based on
health indexing and
√

functional relationships
among the devices
√

Network Management
Table 1: Comparison of Fault Tolerance approaches

Scaling
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

Heterogeneity
√

Real-time
√

Parallel Processing
Distributed Networks

Power Depletion
√

Environmental Impact
√

Radio Interference
√

Asymmetric Communication Links

√

Dislocation of Sensor Nodes

Wireless Networks

Collision

Network-level
√

Service Level
– Cloud
Computing
Fault Tolerance

Migration Level
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

Table 2: Fault computations based on FT Diagram

Preceding Devices
Sl.no Device
Success Gates used For Device name D1 Device name D2 Device name D3 Device name D4 Device name D5 Combined
Rate Connection Success
Success Rate S1 Success Rate S2 Success Rate S3 Success Rate S4 Success Rate S5 Rate
COM4 COM3
1 LIGHT 0.980 AND 0.810
0.900 0.900
LIGHT
2 COM1 0.900 AND 0.810
0.810
COM1 COM2
3 FAN 0.980 AND 0.729
0.810 0.900
COM5 COM6
4 AC 0.980 AND 0.810
0.900 0.900
AC
5 COM2 0.900 AND 0.810
0.810
FAN
6 COM3 0.900 AND 0.729
0.729
AC
7 COM4 0.900 AND 0.810
0.810
FAN
8 COM7 0.900 OR 0.729
0.729
LIGHT
9 COM5 0.900 AND 0.810 0.810
0.810
COM14 GATEWAY
36 CLOUD 0.980 OR 0.729
0.729 0.729

508
JKR Sastry et al., International Journal of Emerging Trends in Engineering Research, 8(2), February 2020, 491 - 509

Table 3: Fault computations of the revised networking of prototype model

Preceding Devices
Gates used
Sl.no Device Success Rate For Device name D1 Device name D2 Device name D3 Device name D4 Device name D5 Combined
Connection Success Rate
Success Rate S1 Success Rate S2 Success Rate S3 Success Rate S4 Success Rate S5

1 Cluster Head1 0.998 0.998

2 Cluster Head2 0.998 0.998

CLUSTER HEAD1
3 COM5 0.900 OR 0.900
0.998
CLUSTER HEAD2
4 COM6 0.900 OR 0.900
0.998
COM5 COM6
5. CONTROLLER 0.980 OR 0.900
0.900 0.900
CONTROLLER
6. COM7 0.900 OR 0.900
0.900
REST SERVER
8 COM8 0.900 OR 0.900
0.900
COM8
9 ACCESS POINT 0.980 OR 0.900 0.900
0.810
GATEWAY COM10
15 CLOUD 0.980 OR 0.900
0.900 0.900

509