Prerpints.org logo
Preprint
Article

Enhancing the Fault Tolerance of a Multi-Layered IoT Network through Rectangular and Interstitial Mesh in the Gateway Layer

Altmetrics

Downloads

93

Views

28

Comments

0

A peer-reviewed article of this preprint also exists.

Submitted:

07 August 2023

Posted:

09 August 2023

You are already at the latest version

Alerts
Abstract
Most IoT systems meant for implementing mission-critical systems are multi-layered based. The majority of the computing is done in the services and gateway layer. The Gateway layer connects the Internal section of the IoT to the cloud through the Internet. The failure of any node between the services servers and the gateways will isolate the entire network leading to zero tolerance. A networking topology is required to connect the service servers to the gateways, yielding 100% fault tolerance. Empirical formulation of the model chosen to connect the service’s servers to gateways through routers is required to compute the fault tolerance of the network. Rectangular and Interstitial Mesh have been proposed in this paper to connect the service servers to the gateways through the servers that yield 0.999 fault tolerance of the IoT network. An empirical formulation is also presented using which the Fault tolerance of the IoT network can be computed. An enhancement of 11% in the fault tolerance capability of an IoT network has been achieved by implementing Rectangular and Interstitial Mesh in the gateway layer of the network.
Keywords: 
Subject: Computer Science and Mathematics  -   Computer Networks and Communications

1. Introduction

In an IoT network, many devices such as sensors, actuators, servers, gateways, controllers, base stations etc. [1] communicate as per the established communication system. IoT networks range from small local to remotely connected Global systems [2]. Many small devices (Nano Scale) and newer communication Technologies [3] are being developed and used daily.
Many smaller devices are evolving rapidly, and millions of devices are connected to the cloud through the Internet. The direct connection of sensors/actuators to the cloud requires minimum infrastructure. However, implementing such a system leads to too many bottlenecks, including latency, speed of data transmission, data handling capability and proprietary protocols.
The computation, storage and network resources are brought closer to the IoT devices through the implementation of the edge/fog computing method, which helped in eliminating the bottle networks involved when sensors are directly communicating with the cloud through the Internet. (Pan and McElhannon, 2018[4]; Adhinugraha et al., 2020) [5].
A gateway connects the local devices to the Internet through routers wherever required. A gateway helps small devices connect to the Internet, thus avoiding the necessity of connecting the small devices directly to the Internet. A gateway allows small devices in an IoT network to be connected to traditional networks [6,7]. A gateway is like a relay point to transmit data from a local IoT network to a Global network.
The way the small devices are connected to the Gateway through the routers and the way the devices communicate through the Gateway is a major issue. The networking topology will be used to connect the devices to the Gateway through a major challenge. Most of the topologies presented in the literature concentrated on cost reduction rather than enhancing or maintaining the fault tolerance of the IoT network. The number of paths that get reduced when a fault happens depends on the Routing topology [8]. It takes time to reconstruct networking topology when a fault happens, causing a delay in response time. This is unacceptable when the IoT system is implemented for a real-time system.
Several; gateways may have to be used to handle the traffic. The use of multiple gateways ensures that there is no single point of failure [9,10]. An IoT network’s reliability is also enhanced when multiple gateways are used.
The network traffic is expected to divert to another gateway when a gateway fails. Network broadcasting is generally used to find an alternative gateway [11].
When many gateways fail at once, broadcasting the message to all the nodes will block the entire network. Locating a replacement gateway located many hops away increases communication latency [12]. A Voronoi Model can be used to determine distance coverage to a gateway [13,14].
Several networking topologies can be used to establish a network between the services servers, routers, and gateways. Mesh network topology reduces network congestion to the cloud [15]. Mesh networking topology helps locate the processing, storage, or analytic services near the location from which data is routed to the cloud, thereby reducing network traffic [16]. In the case of mesh networks, sensors/servers are connected to the routers and the routers to the gateways. The data is processed at the devices (servers, routers and gateways). These devices are used not only for computing but also for routing. Mesh network is reliable, and there is no single point of failure [17].
Numerous routes exist in a mesh network which can be used for transmitting the data. A mesh network can be easily expandable by adding many processing units, including servers, Routers and gateways. The multi-hop approach can cover larger areas of processing devices [18]. The devices formed into a mesh network need not be equidistant. The devices are located such that they are within the broad costing range. There should be routes from the sensing/servicing devices so that data is moved to one of the gateways in the network. When any Gateway is out of order, other operational gateways must share the load.
A Voronoi diagram can be used to partition the processing nodes based on the nearest neighbour concept [19,20]. Voronoi diagram (VD) represents a road network with weights attached to the roots instead of considering Euclidean distances between the devices. A network graph can be developed considering the relationships between the computing resources with the help of a network Voronoi diagram (NVD)[21,22,23]. A higher-order Voronoi diagram can be constructed (HOVD) by segregating the cells in the network into different regions and then connecting the regions [24,25]. A reverse k-nearest neighbour method (RkNN) can also be used to regroup the cell [26]. Most of the focus presented in the literature is reaching out to the nearest neighbour node as fast as possible so that communication progresses in the event of failure of one or more processing nodes. None have shown the extent to which the fault tolerance of the network is improved in quantitative terms.
Modern IoT networks are built using multiple layers, including devices, controllers, services, Gateway, and the cloud. Each layer implements a different networking topology. In addition to computing the fault tolerance of a specific layer, there is a need to compute the overall fault tolerance of the IoT network. Sensors or not connected to the routers directly. Most of the processing is done in the services layer. The use of mesh networks for connecting the service’s servers to the gateways has yet to be discussed. A pragmatic method to computing the fault tolerance of the mesh network considering the services servers, routers, and gateways still needs to be attempted.

2. Related work

T. Saha et al. [27] proposed a gateway which acts as an interface between the Internet and the rest of the IoT network. The Gateway is designed to deal with hardware software and connection failures and the overall load balance of the network. Their proposed framework involves a set of observers connected with the Gateway and sensors connected with the observers. The framework built into the observers comprises prevention and detection algorithms to prevent communication failures between the sensor node and Gateway, provide alternative reliable transmission paths, and detect node faults in early stages. However, they have yet to present the extent of enhancement of the fault tolerance capacity of the IoT network due to the implementation of proposed models.
Ma et al. [28] proposed a method to determine the communication paths between nodes in a wireless sensor network (WSN). However, their method assumes an environment aggregating data from the sensor nodes to the sink nodes. The IoT sensor network assumes that the deployed resources cooperate rather than aggregate the data into one node. Using a multi-routing tree to construct the topology guarantees fault tolerance while minimizing power consumption.
Ismail et al. [29] proposed a resource allocation method assuming a mobile network environment. Their method is to find the nearest access point for the device to communicate. A mobile device can connect to multiple access points simultaneously. This differs from the IoT environment in which communication is performed by selecting one Gateway from the candidate’s gateways.
Li et al. [30] researched a method to construct a routing tree for a P2P network in distributed interactive applications by using a genetic algorithm. Their method aims to determine the route between two nodes in the environment, optimize the communication speed, and do not consider fault tolerance.
Karthikeya et al. [31] proposed a method to optimize the placement of the Gateway. Their method can minimize the introduction cost of the Gateway into the environment by optimizing the gateway placement.
Kim et al. [32] researched a method to solve the resource allocation problem to the Gateway in the IoT environment. Their method uses a genetic algorithm to find an optimum path from a source node to a destination node. This method does not aim at the quantification of improvement in the fault tolerance of the network in a specific layer or the entire network. [33] Takahashi, R have proposed a method to generate a fault-tolerant networking and routing method using a genetic algorithm such that all the communication paths do not concentrate on one Gateway. Leonardi et al., 2018 [34], and Rondón et al., 2019 [35]have proposed a mesh network for massive device deployment to ensure no single point of failure. They have not discussed fault rate computations considering the mesh networks.
He et al., 2007 [36] and Seyedzadegan et al., 2013 [37] have presented gateway management techniques, such as optimal gateway placement, to handle massive devices and high traffic demand within an IoT network. Shih and Wu, 2016 [38] have presented multi-protocol gateways to support heterogeneous networks. They have yet to focus on the issue of fault tolerance.
Jean-Philippe et al., 2004 [39] have expressed that the Mesh networks also are prone to both unplanned blackouts (Natural disasters, overload, wear out, bugs attacks on devices) and planned blackouts (Hardware replacements and maintenance). They have expressed that a gateway recovery strategy is required to maintain network reliability.
Médard et al. (2002). [40] and Choi et al. (2004) [41] proposed loopback methods through the provision of pre-computed backup paths, which should be used during a network failure.
Lakshmanan et al. (2009). [42] and Kawai et al. (2014) [43] have proposed to use of multi-gateways to avoid traffic load on a specific gateway.
Adhinugraha et al., 2021 [44] have provided pre-computed k backup routers using an order HVD. All these works focussed on a failure of a single gateway. They have not considered the issue of the failure of multiple chained gateways.
In the first method, the reserved resources will only be utilized if something happens in the network. Unlike pre-computed resources, the second method does not require reserved or pre-computed resources since the alternate plan is determined by embedding a specific recovery algorithm in the network after the incident occurs. The main advantage of calculating the recovery plan on-the-fly is to reduce the allocation of unnecessary resources. The cost of reserving resources depends on the resources needed as an alternate plan.
The authors of Kim and Shin (2011) [45] proposed an automatic recovery system (ARS) to enable a wireless mesh network (WMN) to recover from local link failures to maintain network availability automatically.
Route calculations such as SDNMesh and RADAR have been proposed by (Gilani et al., 2020) [46] (and Sarkar et al., 2007) [47], respectively, from which effective routes can be determined after node failures.
Mahiddin and Sarkar, (2019).) [48] have proposed a method to handle the traffic so that every Gateway will have a small hit. Minh et al. (2014) [49] have proposed a method called OEMAN to assign one mobile device as a substitute access point when the main Gateway fails. [50] Kiki Adhinugraha has presented a generalized model based on the k-hops Voronoi diagram to compute k backup gateways and evaluate different gateway diversion strategies to divert a router output to a gateway with the minimum hops. Kiki Adhinugraha et al. [51] have proposed a hops Voronoi diagram (HVD) method to distribute. Dependent routers are based on the nearest number of hops from the router. Moghaddam et al. [52] have classified the mechanisms proposed in the literature, which claim to be improving or retaining the fault tolerance level of the IoT network.
Research Gap
The methods proposed in the literature focussed on improving the fault tolerance of an IoT network, considering typical implementation ignoring the presence of several layers in the network and the need to communicate between the layers. Empirical formulations that can be used to compute the fault tolerance considering a single layer or e entire network have yet to be presented. The fault tolerance capability of the IoT network has been explained concerning the availability of an alternate path for communication in the event of the failure of a device. The realistic computation of the fault tolerance level of the IoT network has yet to be explained.
Research contributions
1. This paper proposes a rectangular mesh network with interstitial meshes with built-in redundancy routers to serve as backups to the other surrounding routers.
2. An empirical formulation which can be used for computing the fault tolerance of such a network can be computed using a probability model.
3. A computation method/approach which can be used to compute the fault tolerance of the entire IoT network.

3. The Method

The flow diagram that depicts the execution of the proposed methods is shown in Figure 1. The blocks relating to Metrics development, Initial prototype development and its FTA development, implementing a crossbar network in the device layer, implementing fault detection and isolation method in the sensing and actuating devices to counter the possible fault injection in the device layer and its related FTA model and the improvement in Fault tolerance capability of the IoT network have been explained by Bhupathi et al. [53,54].
Further improvements have been made to the IoT network by adding a second base station to the controller layer. The second base station has been connected to the cluster heads through an intelligent relay-based network with built-in redundancy to tackle the issue of the remoteness of the base station from the cluster heads. An intelligent pathfinding algorithm is implemented in each relay to find the shortest deal with the least traffic to reduce the latency tremendously [55].
The fault tolerance capability of the IoT network has been improved further by implementing the Load balancing feature within the controllers, which are networked through an I2C network [56]. The service servers are added with an intelligent service to estimate missing data [57].
The IoT network is further improved by adding Rectangular and Interstitial Mesh in the Gateway Layer to improve the fault tolerance in this network layer. A new reliability model has been proposed to compute fault tolerance considering a rectangular Interstitial Mesh network.
An FTA diagram for the newly introduced network is developed and combined with the FTA diagram of the prototype model. Fault tolerance values have been computed through the generation of a fault table.
A comparison of the Stage improvements in the fault tolerance of the IoT network due to the implementation of different methods in the Gateway has been presented.
Preprints 81782 g001
Figure 1. The overall computational method for enhancing the fault tolerance up to the Gateway layer.
Figure 1. The overall computational method for enhancing the fault tolerance up to the Gateway layer.
Preprints 81782 g001

4. Example IoT Network

Different methods implemented at various levels for enhancing the IoT network’s fault tolerance are shown in Table 1. A sample IoT network is presented in Figure 2. The sample IoT system implements the following in the device, controller, and services layer of the IoT network to enhance the fault tolerance of the network.
Table 1. Implementations in the Sample IoT network until the services layer.
Table 1. Implementations in the Sample IoT network until the services layer.
Layer Innovation implemented Reference
FTA computation Model A hybrid model that helps compute the FTA considering a Linier and
probability model		 [53]
Device Layer Predicting the occurrence of a Power fault and mitigating it through
isolation procedure		 [54]
Implementing a crossbar network in the device layer
Controller Layer Develop a parallel peer-to-Peer communication system to connect the
cluster heads to the 1st Base station.		 [55]
Develop a redundant network using different topologies connecting the
2nd Base station and cluster heads.
A new algorithm to find the shortest path to connect a cluster head to a
2nd base station
Networking Controllers and implementing load balancing within the controllers [56]
Connecting the controller to the servers of the service through a crossbar network
Service Layer Implementing a machine learning-based missing data estimation model [57]
The devices in a cluster are linearized and connected to a cluster head free from sensing or actuating function. A crossbar network connects the linearized clusters’ outputs to the cluster heads. The cluster heads are connected to the two base stations, which are widely situated for transmitting data from sensors into base stations. Both the base stations are interfaced with three microcontrollers in peer-to-peer mode. The microcontrollers are interconnected through an I2C network which caters for connectivity failures of the controllers to the crossbar network. The controllers are connected to service servers using a crossbar network. The services server receives the requests from the devices or users, executes the service-related code, and transmits the results to controllers or the user. A new service is implemented in the service server to predict if the missing data is not transmitted due to a device’s failure in the layer.
For developing a Fault tree of the sample IoT network, the crossbar networks in the device and controller layer have been replaced by a single device whose success rate is computed using probability models related to crossbar networks. The connectivity between the services servers, routers and gateways is complicated. Voluminous data flow happens in this layer, and failure of devices in this layer hampers the fault tolerance capability of the IoT network quite drastically. The fault tree of the residual network and a table showing the success rate computations are generated through the algorithms presented by Bhupati et al. [53].

5. Methods and Techniques

5.1. Success rate computation method for Rectangular and Interstitial Mesh network

In a mesh network, all nodes are pressing nodes. The network can be formed using the services servers, routers, and Gateways. All the non-boundary nodes have 4 four incident links. To send a message from a node to a node that is not a neighbour, a path from the node form where the message is initiated to a destination node must be identified. The message must be forwarded involving the intermediate nodes along the path. A mesh network loses its property that there should be four links to communicate from a node when it breaks down for any reason. To provide tolerance, redundant nodes are added. The redundant nodes are switched in when any of their neighbouring nodes fails.
A mesh network involving 4 service servers, 4 gateways and 10 Routers is shown in Figure 3. 4 Routers are spare, and they will come into force only when its neighbouring node fails.
The reliability of a mesh network is the probability that the mesh property is retained. The fault tolerance of such a network is computed using Equation (1).
R = is the reliability or the success rate of servers, routers, or gateways = 0.98
N = number of rows in the network = 4
M = number of columns in the network = 4
C = number of clusters in the network = (N*M)/4 with each cluster formed using 4 primary nodes and a spare node = 4
n = number of sub-meshes row wise = 2
m = number of sub-meshes column wise = 2
k = number of possible allocations = N/(n )* M/m = 4 which lead to 1-of-k model.
The reliability of such a model can be computed using Equation (1) S = probability that an n* m sub mesh can be allocated
= 1 − [ 1 − R n * m ] k = 1 − [ 1 − 0 . 98 4 ] 4 = 0.99

5.2. Revised IoT network

The following changes have been made in the Services Layer of the network.
1. A mesh network has been established connecting the Services servers, routers and gateways.
2. One spare router is included for every four processing nodes.
3. All the gateways are connected to the cloud through the Internet.
The revised network is shown in Figure 4.

6. Experimentation and Results

6.1. FTA, Example, IoT network

Developing Fault tree for the revised IoT network
The crossbar network between the controllers and services servers is replaced by a single device assigned with a success rate that is the same as the crossbar network’s success rate using its related probability model.
AN FTA diagram is generated using an algorithm described in [53]. After replacing networking topologies with a single device, the devices left in the diagram are connected using AND/OR conditions based on the precedence and data flow designed to build redundancy in the network. The modified FT diagram related to the revised IoT diagram is shown in Figure 5.

6.2. Success rate computation of Example IoT network

The success rates of every device are computed using its precedence relationships with other devices. The algorithm Bhupathi et al.[54] presented has been used to generate the success table, given the FTA diagram as the input. The generated Success table is presented in Table 2. From the table, it can be observed that the success rate of the revised IoT network is 0.980.
Table 2. success rate computations of an Example IoT network.
Table 2. success rate computations of an Example IoT network.
Sl.no Device Success Rate Gates used
For connection		 Preceding Devices Combined
Success Rate
Device
Name D1		 Device
Name D2		 Device
Name D3		 Device
Name D4
Success
Rate S1		 Success
Rate S2		 Success
Rate S3		 Success
Rate S4
1 Cluster Head1 0.950 0.950
2 Cluster Head2 0.950 0.950
3 Cluster Head3 0.950 0.950
4 Cluster Head4 0.950 0.950
5 D1 0.950 OR Cluster Head1
0.950		 0.950
6 D2 0.950 OR Cluster Head2
0.950		 0.950
7 D3 0.950 OR Cluster Head3
0.950		 0.950
8 D4 0.950 OR Cluster Head4
0.950		 0.950
9 Device Level Crossbar
NW (DLCB)		 0.987 OR D1
0.950		 0.987
10 Device Level Crossbar
NW (DLCB)		 0.987 OR D2
0.950		 0.987
11 Device Level Crossbar
NW (DLCB)		 0.987 OR D3
0.950		 0.987
12 Device Level Crossbar
NW (DLCB)		 0.987 OR D4
0.950		 0.987
13 D5 0.950 OR DLCB
0.987		 0.987
14 D6 0.950 OR DLCB
0.987		 0.987
15 D7 0.950 OR DLCB
0.987		 0.987
16 D8 0.950 OR DLCB
0.987		 0.987
17 BS1 0.950 OR D5
0.987		 D6
0.987		 D7
0.987		 D8
0.987		 0.987
18 RL1 0.950 OR Cluster Head1
0.950		 Cluster Head2
0.950		 0.950
19 RL2 0.950 OR Cluster Head2
0.950		 Cluster Head3
0.950		 0.950
20 RL3 0.950 OR Cluster Head3
0.950		 Cluster Head4
0.950		 0.950
21 RL4 0.950 OR RL1
0.950		 RL2
0.950		 0.950
22 RL5 0.950 OR RL1 0.950 RL2
0.950		 0.950
23 BS2 0.950 OR RL4
0.950		 RL5
0.950		 0.950
24 CONTROLLER 1 0.979 OR BS1
0.987		 BS2
0.950		 0.987
25 CONTROLLER 2 0.979 OR BS1
0.987		 BS2
0.950		 0.987
26 CONTROLLER 3 0.979 OR BS1
0.987		 BS2
0.950		 0.987
27 CONTROLLER LEVEL
CROSSBAR NW		 0.970 CROSSBAR NW CONTROLLER 1
0.987		 CONTROLLER 2
0.987		 CONTROLLER 3
0.987		 0.987
28 SERVER 1 0.980 AND CONTROLLER LEVEL
CROSSBAR NW
0.987		 0.967
29 SERVER 2 0.980 AND CONTROLLER LEVEL
CROSSBAR NW
0.987		 0.967
30 SERVER 3 0.980 AND CONTROLLER LEVEL
CROSSBAR NW
0.987		 0.967
31 SERVER 4 0.980 AND CONTROLLER LEVEL
CROSSBAR NW
0.987		 0.967
32 GATEWAY 0.980 OR SER 1
0.967		 SER 2
0.967		 SER 3
0.967		 SER 4
0.967		 0.980
33 INTERNET 0.980 OR GATEWAY
0.980		 0.980

6.3. FTA for revised IoT network

Developing Fault tree for the revised IoT network
The crossbar network between the controllers and services servers is replaced by a single device assigned with a success rate that is the same as the crossbar network’s success rate using its related probability model.
The mesh network is replaced with a single device with its fault rate as the fault rate computed for the mesh network using its related probability model explained in section 4.0 of this paper.
AN FTA diagram is generated using an algorithm described in [53]. After replacing networking topologies with a single device, the devices left in the diagram are connected using AND/OR conditions based on the precedence and data flow designed to build redundancy in the network. The modified FT diagram related to the revised IoT diagram is shown in Figure 6.

6.4. Success Rate computation for Revised IoT network

The algorithm presented by Bhupathi et al. [44] has been used to generate an FTA diagram for the revised IoT network. An algorithm they presented generates the success table, given the FTA diagram as the input. The generated Success table is presented in Table 3. The success rates of every device are computed using its precedence relationships with other devices. From the table, it can be observed that the success rate of the revised IoT network is 0.990.
Table 3. success rate computations of an Example IoT network.
Table 3. success rate computations of an Example IoT network.
Sl.no Device Success Rate Gates used
For connection		 Preceding Devices Combined
Success Rate
Device
Name D1		 Device
Name D2		 Device
Name D3		 Device
Name D4
Success
Rate S1		 Success
Rate S2		 Success
Rate S3		 Success
Rate S4
1 Cluster Head1 0.950 0.950
2 Cluster Head2 0.950 0.950
3 Cluster Head3 0.950 0.950
4 Cluster Head4 0.950 0.950
5 D1 0.950 OR Cluster Head1
0.950		 0.950
6 D2 0.950 OR Cluster Head2
0.950		 0.950
7 D3 0.950 OR Cluster Head3
0.950		 0.950
8 D4 0.950 OR Cluster Head4
0.950		 0.950
9 Device Level Crossbar
NW (DLCB)		 0.987 OR D1
0.950		 0.987
10 Device Level Crossbar
NW (DLCB)		 0.987 OR D2
0.950		 0.987
11 Device Level Crossbar
NW (DLCB)		 0.987 OR D3
0.950		 0.987
Device
Name D1		 Device
Name D2		 Device
Name D3		 Device
Name D4
Success
Rate S1		 Success
Rate S2		 Success
Rate S3		 Success
Rate S4
12 Device Level Crossbar
NW (DLCB)		 0.987 OR D4
0.950		 0.987
13 D5 0.950 OR DLCB
0.987		 0.987
14 D6 0.950 OR DLCB
0.987		 0.987
15 D7 0.950 OR DLCB
0.987		 0.987
16 D8 0.950 OR DLCB
0.987		 0.987
17 BS1 0.950 OR D5
0.987		 D6
0.987		 D7
0.987		 D8
0.987		 0.987
18 RL1 0.950 OR Cluster Head1
0.950		 Cluster Head2
0.950		 0.950
19 RL2 0.950 OR Cluster Head2
0.950		 Cluster Head3
0.950		 0.950
20 RL3 0.950 OR Cluster Head3
0.950		 Cluster Head4
0.950		 0.950
21 RL4 0.950 OR RL1
0.950		 RL2
0.950		 0.950
22 RL5 0.950 OR RL1 0.950 RL2
0.950		 0.950
23 BS2 0.950 OR RL4
0.950		 RL5
0.950		 0.950
24 CONTROLLER 1 0.979 OR BS1
0.987		 BS2
0.950		 0.987
25 CONTROLLER 2 0.979 OR BS1
0.987		 BS2
0.950		 0.987
26 CONTROLLER 3 0.979 OR BS1
0.987		 BS2
0.950		 0.987
27 CONTROLLER LEVEL
CROSSBAR NW		 0.970 CROSSBAR NW CONTROLLER 1
0.987		 CONTROLLER 2
0.987		 CONTROLLER 3
0.987		 0.987
28 SERVER 1 0.980 AND CONTROLLER LEVEL
CROSSBAR NW
0.987		 0.967
29 SERVER 2 0.980 AND CONTROLLER LEVEL
CROSSBAR NW
0.987		 0.967
30 SERVER 3 0.980 AND CONTROLLER LEVEL
CROSSBAR NW
0.987		 0.967
31 SERVER 4 0.980 AND CONTROLLER LEVEL
CROSSBAR NW
0.987		 0.967
32 SERVER LEVEL
MESH NW		 0.980 MESH NW SER 1
0.967		 SER 2
0.967		 SER 3
0.967		 SER 4
0.967		 0.999
33 GATEWAY 1 0.950 OR SERVER LEVEL
MESS NW
0.999		 0.999
34 GATEWAY 2 0.950 OR SERVER LEVEL
MESS NW
0.999		 0.999
35 GATEWAY 3 0.950 OR SERVER LEVEL
MESS NW
0.999		 0.999
36 GATEWAY 4 0.950 OR SERVER LEVEL
MESS NW
0.999		 0.999
37 INTERNET 0.980 MESH NW GATEWAY 1
0.999		 GATEWAY 2
0.999		 GATEWAY 3
0.999		 GATEWAY 4
0.999		 0.999

7. Discussions

Mesh networks with built-in selected redundancy will provide very high-level fault tolerance of the IoT network. A probability model derived for the Mesh network will help compute the service layer’s fault tolerance. Improving fault tolerance in the services layer will help achieve a very high fault tolerance considering the entire network. The services layer of the IoT network is the most crucial, as most computing is done in this layer. A stage-wise Fault tolerance improvement analysis, is provided in Table 4. The table shows that the IoT network’s fault tolerance improved by 11% when a mesh network was introduced in the services layer (FTA changed from 0.980 to 0.990).
Table 4. Comparative Analysis of enhancements of fault tolerance in different layers of the IoT network.
Table 4. Comparative Analysis of enhancements of fault tolerance in different layers of the IoT network.
Serial Number Type of Network Fault Tree Value
1 Prototype network [54] 0.717
2 Prototype with Changes Made in the device Levels – [55]
(Fault prediction, mitigation and
crossbar network implemented)		 0.827
3 Prototype with Changes Made in the
device Level and Base Station level
(Introduction of dual networks to connect
to two base stations and finding
the shortest for the communication
through 2nd base station) [55]		 0.948
4 Prototype with Changes Made in the
device Level and Base Station level
with load balanced at the controller Layer
(Controller interconnected through
an I2C network and implementing middleware
within the controllers) and connecting
the controllers to the service’s servers
through a crossbar network [56]		 0.980
5 Prototype with Changes Made in the
device Level and Base Station level
with load balanced at the controller Layer
(Controller interconnected through
an I2C network and implementing middleware
within the controllers) and connecting
the controllers to the service’s servers through
a crossbar network and implementing
the prediction model for predicting the missing data [57]		 0.980
6 Prototype with Changes Made in the device
Level and Base Station level with load
balanced at the controller Layer
(Controller interconnected through an I2C network
and implementing middleware within the controllers),
connecting the controllers to
the servers of the service through
a crossbar network and implementing the prediction
and estimating the to missing data and
implementing a Mesh network in the services layer
to connect the servers of the
service to the gateways.		 0.999
The fault tolerance capacity of the revised network and the mesh network included in the Services layer is compared with the fault tolerance computed based on node failure. The number of paths available for communication gets reduced in respect of NVD and HVD as the failure of the number of nodes increases. The fault tolerance of the MESH network implemented based on NVD and HVD is zero when there is a situation that 4 nodes fail at the same time. The fault tolerance of Mesh with Interstitial Mesh network remains the same even if 4 nodes fail due to the reasons of availability of the redundant nodes. Moreover, there is no empirical formulation for computing fault tolerance of the mesh network when NVD or HVD is used. At best, the NVD and HVD methods can compute the fault tolerance of the service layer, whereas the Mesh with Interstitial Mesh-based method helps to compute the fault tolerance of the entire network.

8. Conclusions

1. The services layer is the most critical in an IoT network, as most computing is done in that layer before the data is moved to the cloud through gateways.
2. Adding ¼ of nodes of the total nodes as standby or backup nodes will help the IoT network to be fully fault tolerant despite the failure of 4 Nodes at a time.
3. The Fault tolerance of the IoT network improved by 11% when a Mesh with an Interstitial Mesh network was implemented in the services layer.
4. An empirical formulation is developed, which helps compute the fault tolerance of the IoT network when a Mesh with Interstitial Mesh network is implemented in the services layer. At the same time, that is not the case with other models.
5. The Mesh with Interstitial Mesh network implemented in the services layer can be easily interconnected with networking topologies used in other network layers.
Table 5. A comparison of Rectangular and Interstitial Mesh with NVD and HVD model in the Gateway Layer.
Table 5. A comparison of Rectangular and Interstitial Mesh with NVD and HVD model in the Gateway Layer.
Parameter Mesh with Interstitial Mesh NVD [21] HVD [51]
Existence of empirical formulation for computing FTA Yes No No
Total number of nodes in the network 24 16 16
Number of paths exiting in the network 16 16 16
Number of paths available when a node fails 16 12 12
Number of paths available when two nodes fail 16 8 8
Number of paths available when three nodes fail 16 4 4
Number of paths available when 4 nodes fail 16 0 0
FTA of Network when 4 Number of nodes fails 0.999 0.000 0.00

References

  1. Khawaja, K.F.; Bokhari, R.H. Exploring the Factors Associated With Website Quality; Department of Technology Management, International Islamic University: Islamabad, Pakistan, 2010. [Google Scholar]
  2. Sastry, J.K.R.; Lalitha, T.S. A framework for assessing the quality of a WEB SITE, PONTE. Int. J. Sci. Res. 2017, 73. [Google Scholar] [CrossRef]
  3. Mantri, V.K. An Introspection of Web Portals Quality Evaluation. Int. J. Adv. Inf. Sci. Technol. 2016, 5, 33–38. [Google Scholar]
  4. Moustakis, V.S. Website quality assessment criteria. In Proceedings of the Ninth International Conference on Information Quality; 2004. [Google Scholar]
  5. Nielsen, J. 10 usability heuristics for user interface design, Nielsen Norman Group. Available online: https://www.nngroup.com/aiiicles/ux-research-cheat-sheet/ (accessed on 3 May 2021).
  6. Tognazzi, B. First principles of interaction design (revised and expanded), asking. 2014.
  7. Shneiderman, B. The eight golden rules of interface design, Department of Computer Science, University of Maryland 2016.
  8. Law, R.; Qi, S.; Buhalis, D. Progress in tourism management: A review of website evaluation in tourism research. Tour. Manag. 2010, 31, 297–313. [Google Scholar] [CrossRef]
  9. Shneiderman, B.; Plaisant, C.; Cohen, M.S.; Jacobs, S.; Elmqvist, N.; Diakopoulos, N. Designing the User Interface: Strategies for Effective Human-Computer Interaction, 6th ed., Pearson Higher Education, Essex. 2016.
  10. Morales-Vargas, A.; Pedraza-Jimenez, R.; Codina, L. Website quality: an analysis of scientific production. Prof. Inf. 2020, 29, e290508. [Google Scholar] [CrossRef]
  11. Law, R. Evaluation of hotel websites: progress and future developments. Int. J. Hosp. Manag. 2019, 76, 2–9. [Google Scholar] [CrossRef]
  12. Ecer, F. A hybrid banking websites quality evaluation model using AHP and COPRAS-G: a Turkey case. Technol. Econ. Dev. Econ. 2014, 20, 758–782. [Google Scholar] [CrossRef]
  13. Leung, D.; Law, R.; Lee, H.A. A modified model for hotel website functionality evaluation. J. Travel Tour. Mark. 2016, 33, 1268–1285. [Google Scholar] [CrossRef]
  14. Maia, C.L.B.; FU1iado, E.S. A systematic review about user experience evaluation, in Marcus, A. (Ed.), Design, User Experience, and Usability: Design Thinking and Methods, Springer International Publishing, Cham, 2016; pp. 445-455.
  15. Sanabre, C.; Pedraza-Jimenez, R.; Vinyals-Mirabent, S. Double-entry analysis system (DEAS) for comprehensive quality evaluation of websites: case study in the tourism sector. Prof. Inf. 2020, 29, e290432. [Google Scholar] [CrossRef]
  16. Bevan, N.; Carter, J.; Harker, S. ISO 9241-11 Revised: what have we learnt about usability since 1998? in Kurosu, M. (Ed.), Human-Computer Interaction: Design and Evaluation, Springer International Publishing, Cham, 2015; pp. 143-151.
  17. Rosala, M. and Krause, R. User Experience Careers: lf’hat a Career in UX Looks Like Today, Fremont, CA, 2020.
  18. Jainari, MH. , Baharum, A., Deris, F.D., Mat Noor, N.A., Ismail, R. and Mat Zain, NH. (2022), "A standard content for university websites using heuristic evaluation", in Arai, K. (Ed.), Intelligent Computing. SA! Lecture Notes in Networks and Systems, Springer, Cham, 2022; Vol. 506.
  19. Jayanthi, B. and Krishnakumari, P. An intelligent method to assess webpage quality using extreme learning machine. Int. J. Comput. Sci. Netw. Secur. 2016, 16, 81–85. [Google Scholar]
  20. Nikolic, N.; Grljevic, O.; Kovacevic, A. Aspect-based sentiment analysis of reviews in the domain of higher education. Electron. Libr. 2020, 38, 44–64. [Google Scholar] [CrossRef]
  21. Morales-Vargas, A.; Pedraza-Jimenez, R.; Codina, L. Website quality evaluation: a model for developing comprehensive assessment instruments based on key quality factors. J. Doc. 2023. [Google Scholar] [CrossRef]
  22. Khawaja, K.F.; Bokhari, R.H. Exploring the Factors Associated With Quality of Website; Department of Technology Management, International Islamic University: Islamabad, Pakistan, 2010. [Google Scholar]
  23. Sastry, J.K.R.; Lalitha, T.S. A framework for assessing the quality of a WEB SITE, PONTE. Int. J. Sci. Res. 2017, 73, 2017. [Google Scholar]
  24. Mantri, V.K. An Introspection of Web Portals Quality Evaluation. Int. J. Adv. Inf. Sci. Technol. 2016, 5, 33–38. [Google Scholar]
  25. Moustakis, V.S. “Website quality assessment criteria,” Proceedings of the Ninth International Conference on Information Quality, 2004.
  26. Graniü, A.; et al. “Usability Evaluation of Web Portals,” Proceedings of the ITI 2008, 30th Int. Conf. on Information Technology Interfaces, 2008.
  27. Singh, T.; et al. “E-Commerce Website Quality Assessment based on Usability,” Department of Computer Science & Engineering, Amity University, Uttar Pradesh, Noida, India, pp. 101-105.
  28. Anusha, R. “A Study on Website Quality Models,” Department of Information Systems Management, MOP Vaishnav College for Women (Autonomous), Chennai, 2014; vol. 4, pp. 1-5.
  29. Ricca, F.; Tonella, P. “Analysis and Testing of Web Applications,” Centro per la Ricerca Scientifica e Tecnologica, I-38050 Povo (Trento), Italy, 2001.
  30. Alwahaishi, S.; Snášel, V. “Assessing the LCC Websites Quality,” Springer-Verlag Berlin Heidelberg, in F. Zavoral NDT 2010, SI, CCIS 87, pp. 556-565, 2010.
  31. Hasan, L.; Abuelrub, E. Assessing the Quality of Web Sites. Appl. Comput. Inform. 2011, 9, 11–29. [Google Scholar] [CrossRef]
  32. Singh, K.K.; et al. Implementation of a Model for Websites Quality Evaluation – DU Website. Int. J. Innov. Adv. Comput. Sci. 2014, 3. [Google Scholar]
  33. Chen, L.S.; Chung, P. “Identifying Crucial Website Quality Factors of Virtual Communities,” Proceedings of the International Multi-Conference of Engineers and computer scientists, IMECS, vol. 1, 2010.
  34. Wah, N.L. “An Improved Approach for Web Page Quality Assessment,” IEEE Student Conference on Research and Development, 2011.
  35. Sastry, J.K.R.; et al. Quantifying quality of WEB sites based on content. Int. J. Eng. Technol. 2018, 7, 138–141. [Google Scholar]
  36. Sastry, J.K.R.; et al. Quantifying quality of websites based on usability. Int. J. Eng. Technol. 2018, 7, 320–322. [Google Scholar] [CrossRef]
  37. Sastry, J.K.R.; et al. Structure-based assessment of the quality of WEB sites. Int. J. Eng. Technol. 2018, 7, 980–983. [Google Scholar]
  38. Sastry, J.K.R.; et al. Evaluating quality of navigation designed for a WEB site. Int. J. Eng. Technol. 2018, 7, 1004–1007. [Google Scholar]
  39. Kolla, N.P.; et al. Assessing the quality of WEB sites based on Multimedia content. Int. J. Eng. Technol. 2018, 7, 1040–1044. [Google Scholar]
  40. Babu, J.S.; et al. Optimizing webpage relevancy using page ranking and content-based ranking. Int. J. Eng. Technol. (UAE) 2018, 7, 1025–1029. [Google Scholar] [CrossRef]
  41. Prasad, K.S.; et al. An integrated approach towards vulnerability assessment & penetration testing for a web application. Int. J. Eng. Technol. (UAE) 2018, 7, 431–435. [Google Scholar]
  42. Krishna, M.V.; et al. A framework for assessing the quality of a website. Int. J. Eng. Technol. (UAE) 2018, 7, 82–85. [Google Scholar] [CrossRef]
  43. Babu, R.B.; et al. Analysis on visual design principles of a webpage. Int. J. Eng. Technol. (UAE) 2018, 7, 48–50. [Google Scholar] [CrossRef]
  44. Pawar, S.S.; Prasanth, Y. Multi-Objective Optimization Model for QoS-Enabled Web Service Selection in Service-Based Systems. New Rev. Inf. Netw. 2017, 22, 34–53. [Google Scholar] [CrossRef]
  45. Bhavani, B.; et al. Review on techniques and applications involved in web usage mining. Int. J. Appl. Eng. Res. 2017, 12, 15994–15998. [Google Scholar]
  46. Durga, K.K.; Krishna, V.R. Automatic detection of illegitimate websites with mutual clustering. International Journal of Electrical and Computer Engineering 2016, 6, 995–1001. [Google Scholar]
  47. Satya, T.Y.; Pradeepini, G. Harvesting deep web extractions based on hybrid classification procedures. Asian J. Inf. Technol. 2016, 15, 3551–3555. [Google Scholar]
  48. Bhanu, S.J.S.; et al. Implementing dynamically evolvable communication with embedded systems through WEB services. Int. J. Electr. Comput. Eng. 2016, 6, 381–398. [Google Scholar]
  49. Prasanna, L.; et al. Profile-based personalized web search using Greedy Algorithms. ARPN J. Eng. Appl. Sci. 2016, 11, 5921–5925. [Google Scholar]
  50. Moustakis, V.S.; Litos, C.; Dalivigas, A.; Tsironis, L. WEB site Quality Assessment Criteria, Proceedings of the Ninth International Conference on Information Quality (ICIQ-04), pp.
  51. Oon-itt, S. Quality of health websites and their influence on perceived usefulness, trust and intention to use: an analysis from Thailand. J. Innov Entrep 2019, 8, 4. [Google Scholar] [CrossRef]
  52. Allison, R.; Hayes, C.; McNulty, C.A.M.; Young, V. A Comprehensive Framework to Evaluate Websites: Literature Review and Development of GoodWeb. JMIR Form Res. 2019, 3, e14372. [Google Scholar] [CrossRef]
  53. Barnes, Stuart & Vidgen, Richard. WebQual: An Exploration of Website Quality. 2000; 298–305.
  54. Layla, Hasan Emad Abuelrub, Assessing the Quality of the web sites. Appl. Comput. Inform. 2011, 9, 11–29. [CrossRef]
  55. Bhanu, J.S.; Kamesh, D.B.K.; Sastry, J.K.R. Assessing Completeness of a WEB site from Quality Perspective. Int. J. Electr. Comput. Eng. (IJECE) 2019, 9, 5596–5603. [Google Scholar] [CrossRef]
  56. Rekik, R.; Kallel, I.; Casillas, J.; Alimi, A.M. Int. J. Inf. Manag. 2018, 38, 201–216. [CrossRef]
  57. Lin, H.-F. An application of fuzzy AHP for evaluating course website quality. Comput. Educ. 2010, 54, 877–888. [Google Scholar] [CrossRef]
  58. Heradio, R.; Cabrerizo, F.J.; Fernández-Amorós, D.; Herrera, M.; Herrera-Viedma, E. A fuzzy linguistic model to evaluate the Quality of Library. Int. J. Inf. Manag. 2013, 33, 642–654. [Google Scholar] [CrossRef]
  59. Esteban, B.; Tejeda-Lorente, Á.; Porcel, C.; Moral-Muñoz, J.A.; Herrera-Viedma, E. Aiding in the treatment of low back pain by a fuzzy linguistic Web system. Rough sets and current trends in computing, lecture notes in computer science (Including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), 2014.
  60. Cobos, C.; Mendoza, M.; Manic, M.; León, E.; Herrera-Viedma, E. Clustering of web search results based on an iterative fuzzy C-means algorithm and Bayesian information criterion. 2013 joint IFSA world congress and NAFIPS annual meeting. IFSA/ NAFIPS 2013, 507–512.
  61. Dhiman, P. Empirical validation of website quality using statistical and machine learning methods. Proceedings of the 5th international conference on confluence 2014: The next generation Information technology summit, 2014; 286–291.
  62. Liu, H.; Krasnoproshin, V.V. Quality evaluation of E-commerce sites based on adaptive neural fuzzy inference system. neural networks and artificial intelligence, communications in computer and information science, 2014; 87–97.
  63. Vosecky, J.; Leung, K.W.-T.; Ng, W. Searching for quality microblog posts: Filtering and ranking based on content analysis and implicit links. Database systems for advanced applications, lecture notes in computer science (Including subseries lecture notes in artificial intelligence and lecture notes in bioinformatics), 2012; 397–413.
  64. Hu, Y.-C. Fuzzy multiple-criteria decision-making in the determination of critical criteria for assessing service quality of travel websites. Expert Syst. Appl. 2009, 36, 6439–6445. [Google Scholar] [CrossRef]
  65. Kakol, M.; Nielek, R.; Wierzbicki, A. Understanding and predicting Web content credibility using the Content Credibility Corpus. Inf. Process. Manag. 2017, 53, 1043–1061. [Google Scholar] [CrossRef]
  66. Jayanthi, B.; Krishnakumari, P. An intelligent method to assess webpage quality sing extreme learning machine. Int. J. Comput. Sci. Netw. Secur. 2016, 16, 81–85. [Google Scholar]
  67. Huang, G.; Ding, X.; Zhou, H. Optimization method based extreme learning machine for classification. Neurocomputing 2010, 74, 155–163. [Google Scholar] [CrossRef]
  68. Huang, G.; Zhou, H.; Ding, X.; Zhang, R. Extreme learning machine for regression and multiclass classification. Syst. Man Cybern. Part B Cybern. 2012, 42, 513–529. [Google Scholar] [CrossRef] [PubMed]
Preprints 81782 g002
Figure 2. Example IoT network.
Figure 2. Example IoT network.
Preprints 81782 g002
Preprints 81782 g003
Figure 3. Mesh network for connecting services servers to the Gateway.
Figure 3. Mesh network for connecting services servers to the Gateway.
Preprints 81782 g003
Preprints 81782 g004
Figure 4. Revised IoT network with revisions in the Gateway Level
Figure 4. Revised IoT network with revisions in the Gateway Level
Preprints 81782 g004
Preprints 81782 g005
Figure 5. FTA Diagram for the revised IoT network
Figure 5. FTA Diagram for the revised IoT network
Preprints 81782 g005
Preprints 81782 g006
Figure 6. Revised FTA diagram
Figure 6. Revised FTA diagram
Preprints 81782 g006
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
Copyright: This open access article is published under a Creative Commons CC BY 4.0 license, which permit the free download, distribution, and reuse, provided that the author and preprint are cited in any reuse.
Prerpints.org logo

Preprints.org is a free preprint server supported by MDPI in Basel, Switzerland.

facebook logotwitter logolinkedin logo
MDPI Initiatives
Important Links
Subscribe

Disclaimer

Terms of Use

Privacy Policy

© 2024 MDPI (Basel, Switzerland) unless otherwise stated