# Fuzzy Logic-based Robust Failure Handling Mechanism for Fog Computing

Ranesh Kumar Naha, Saurabh Garg, Muhammad Bilal Amin  School of Technology,
Environments and Design
University of Tasmania
Hobart, Australia
<EMAIL_ADDRESS>Rajiv Ranjan  School
of Computing
Newcastle University
Newcastle, United Kingdom
<EMAIL_ADDRESS>
###### Abstract

Fog computing is an emerging computing paradigm which is mainly suitable for
time-sensitive and real-time Internet of Things (IoT) applications. Academia
and industries are focusing on the exploration of various aspects of Fog
computing for market adoption. The key idea of the Fog computing paradigm is
to use idle computation resources of various handheld, mobile, stationery and
network devices around us, to serve the application requests in the Fog-IoT
environment. The devices in the Fog environment are autonomous and not
exclusively dedicated to Fog application processing. Due to that, the
probability of device failure in the Fog environment is high compared with
other distributed computing paradigms. Solving failure issues in Fog is
crucial because successful application execution can only be ensured if
failure can be handled carefully. To handle failure, there are several
techniques available in the literature, such as checkpointing and task
migration, each of which works well in cloud based enterprise applications
that mostly deals with static or transactional data. These failure handling
methods are not applicable to highly dynamic Fog environment. In contrast,
this work focuses on solving the problem of managing application failure in
the Fog environment by proposing a composite solution (combining fuzzy logic-
based task checkpointing and task migration techniques with task replication)
for failure handling and generating a robust schedule. We evaluated the
proposed methods using real failure traces in terms of application execution
time, delay and cost. Average delay and total processing time improved by 56%
and 48% respectively, on an average for the proposed solution, compared with
the existing failure handling approaches.

###### Index Terms:

Fog Computing, Application Failure, Dynamic Resource, Fault Tolerance,
Robustness

##  I Introduction

Fog computing is a distributed computing paradigm in which any device that has
computation capability can contribute to application processing. These devices
include mobile, network, handheld and mobile devices [1]. Cloud computing has
latency issues in which time-sensitive real-time application execution cannot
be performed. Hence, Fog computing has emerged; it can process user
application requests with minimum latency, since Fog devices are located close
to the users. Applications in a smart environment must be able to respond
instantly, without delay. Some example of these kinds of applications are
smart cars, augmented reality applications, online multiplayer games and
emergency response applications.

Fog is a highly distributed environment in which numerous autonomous devices
contribute to processing application requests; these are known as Fog devices
[1]. The contributing devices can produce a financial benefit by allowing the
Fog platform to use their resources for Fog application processing [2]. Unlike
cloud resources, fog computing resources are not managed service, hence, they
have high probability of failure. Furthermore, the devices in Fog environment
are not completely dedicated to Fog application processing [3]. Hence, there
is no guarantee that devices are always available. The device can even fail
after starting the processing of the Fog application. In such a scenario, it
is important to make the scheduling of the application robust for successful
execution in the Fog environment, despite any failure of the Fog devices at
this stage. This will reduce the impact of any application failure in the Fog
environment.

Without ensuring proper failure handling mechanisms, it is not possible to run
time-sensitive real-time applications in the Fog environment. This is because
the failure of a Fog application or device might contribute to the high rates
of delay which lead to the execution of the application being unsuccessful.
Thus, this is an important and challenging area for research. The need for the
successful execution of Fog applications in the dynamic Fog environment
motivated us to explore the reasons for failure and to investigate possible
solutions.

In order to meet the time sensitivity of the applications, handling failure in
the Fog environment is an important and challenging task [4]. For application
processing, the cloud computing environment mostly depends on the cloud data
centre [5] in which the rate of failure is not that high compared with the Fog
environment. Fog devices are controlled by decentralised entities while cloud
data centres are managed by some central entities. Hence, predicting
application failure in the cloud environment is less complicated compared with
such predictions in Fog computing. In the Fog environment, it is difficult to
predict the failure of the computation resources due to the unstable
characteristics of the available resources in the Fog devices. Thus, a robust
scheduling algorithm needs to be developed. On the other hand, to prove the
correctness of the robust scheduling, an evaluation with real failure traces
is required. Robust scheduling is a mechanism by which application will be
executed in a way in which there will no opportunity for application failure.
Even if there is a failure robust adaptation mechanism can bring back the
system to stable state. To ensure this, applications might need to execute in
different places at the same time, in order to avoid the risk of failure.

Two methods are available for handling failures in service-oriented computing;
these are proactive and reactive failure handling mechanisms [6] [7].
Proactive failure needs to be considered in a highly distributed environment
in such a way that failure handling has taken place before occurrence of the
failure. However, proactive failure handling will not always be suitable
because some failures might occur beyond our prediction. This is because of
the possibilities of device malfunction, user interruption and uncertain
changes in resource availability. Therefore, we need to consider reactive
failure handling which usually takes place after the failure has occurred. Due
to the unstable nature of Fog devices, applying either of the methods is not
always useful for ensuring the successful execution of the application in a
time-sensitive manner. Hence, we used task replication methods, along with
proactive and reactive failure handling methods.

In this paper, we propose a composite solution by using proactive and reactive
failure handling methods with replication. The key contributions of this paper
are as follows:

  1. 1.

We propose a fuzzy logic-based method to deal with unpredicted and predicted
failures.

  2. 2.

Our failure handling method considers time sensitivity of the application, as
well as dynamic changes in the available resources in the devices.

  3. 3.

We evaluate the proposed failure handling method using real failure traces.

The rest of the paper is organised as follows: Section II presents related
literature of failure handling mechanisms in the P2P system, a cluster, a
grid, the cloud and the Fog computing paradigm. Section III discusses the
application scenario for the proposed solution. Section IV discusses the
definition of the problem. A brief description of various resources failures
and their solutions is presented in Section V. Section VI gives a detailed
description of the proposed Fuzzy logic-based solution. Section VII discusses
the experimental setup and evaluation technique. Section VIII presents
experimental results and discussion. Finally, Section IX concludes the paper.

##  II Related Work

This section describes some related work on failure handling mechanisms in
different distributed computing paradigms. We chose to survey failure handling
methods in order to verify the uniqueness of our research. We reviewed some
methods that are being used for the P2P system, as well as cluster, grid,
cloud and Fog computing paradigms, in order to make the system fault-tolerant.

###  II-A Failure handling in P2P System

Samant and Bhattacharyya [8] examined the impact of node failure on the
accessibility of resources on P2P networks. Their work examined how search
efforts, the topology of the network and redundant resources can influence
accessibility when various level node failures take place. Vanthournout and
Deconinck [9] proposed three strategies to realise the use of self-
organisation mechanisms for failure handling and failure detection.

Lin et al. [10] presented an efficient fault-tolerant approach for the super-
peers of peer-to-peer (P2P) file-sharing systems. Mawlood-Yunis et al. [11]
identified the disconnection failure problem, due to temporary semantic
mapping faults, and proposed a game theory based Fault Tolerant Adaptive Query
Routing (FTAQR) algorithm to resolve it.

###  II-B Failure handling in Cluster

Li and Lan [12] proposed FT-Pro, an adaptive fault management mechanism that
optimally chooses migration, checkpointing or no action to reduce the
application execution time in the presence of failures based on the failure
prediction. Various methods have been used in cluster computing to predict
failure event. These methods include genetic algorithms [13], rule-based data
mining [14, 15, 16] and Markov chain [17]. Many other works focus on fault
management techniques which are based on prediction. Leangsuksun et al. [18]
proposed a predictive failure handling mechanism which scheduled deliberate
job checkpointing and migration. In another work, Castelli et al. [19]
employed a different approach to failure prediction. In their approach, they
first predicted the resource exhaustion failure proactively and then conducted
software rejuvenation. To maximise system throughput, Oliner et al. [20] used
the coordinative checkpointing strategy that optimistically skips a checkpoint
when no failure prediction exists in the near future. Chakravorty et al. [21]
proposed software-based prediction of failure which basically migrates a task
before the failure actually occurs.

###  II-C Failure handling in Grid

Hwang and Kesselman [22] proposed a flexible failure handling framework for
the grid which is comprised of two phases: failure detection and recovery
phases. In the failure detection phase, an event notification mechanism
reports failures. A failure handler deals with the failures at two levels: the
task level and the workflow level. Task level failures are handled by
retrying, checkpointing and replication. At the workflow level, they are
managed by alternative task and redundancy. Jin et al. [23] proposed the Fault
Tolerant Grid Platform (FTGP) approach from the perspective of grid users,
taking the nature of grid faults into account.

Lee et al. [24] proposed a resource manager for optimal resource selection.
The proposed resource manager automatically selects a set of optimal resources
from candidate resources which achieve optimal performance using a genetic
algorithm with a fault tolerance service that satisfies QoS requirements. Lee
et al. [24] implemented a fault detector and a fault manager which will handle
failure by job migration, using a checkpoint. Kandaswamy et al. [25] proposed
a fault-tolerance technique using over-provisioning and migration for
computational grids. Khoo and Veeravalli [26] proposed a failure handling
mechanism based on pro-active failure handling strategies for grid
environments.

###  II-D Failure handling in cloud computing

Much research on handling failures in the cloud environment has been
undertaken to provide a failure-prone environment. Two review works [6, 7], in
which all kinds of failures were categorised into reactive and proactive
failure methods, extensively evaluated failure handling mechanisms in the
cloud. Reactive failure mechanisms were further divided into three sub-
categories: checkpointing, replication and logging. While Virtual Machine (VM)
migration was considered as proactive failure management, Gill and Buyya [6]
suggested continuous monitoring of resource allocation to manage failures in
the cloud environment during operation. Sharma et al. [7] point out that
predicting resource behaviour is critical in the cloud environment.

Sharma et al. [27] proposed a failure-aware VM consolidation technique based
on exponential smoothing. They employed checkpointing and migration of VM in
their proposed method. Luo et al. [28] proposed a Markov-based model to
examine failures in large-scale cloud computing systems. They employed
reliability-aware resource scheduling to improve fault tolerance. Although
cloud computing is a mature technology, it still lacks service reliability.
Hence, Buyya et al. [29] suggested investigating failure-aware provisioning
and reliability-aware service management mechanisms for the cloud computing
environment.

###  II-E Failure handling in Fog computing

Existing failure handling methods in P2P, distributed and cloud computing
mainly scale infrastructure to utilise extra resources to cover failure but in
Fog computing, fault tolerance is challenging due to some unfavourable
factors, such as resource constraints and multiple procedures [30]. Most of
those methods considered only one failure handling method (for example,
checkpointing or replication or resubmission) for fault tolerance [31]. Also,
they did not consider any time sensitivity of the user request [31]. Hence,
some researchers proposed new methods for failure handling in the Fog
computing environment [31, 32].

A Fault-Tolerant Scheduling Method (FTSM) was proposed by Alarifi et al. [31]
for the Fog-Cloud environment. In their approach, the system submits time-
tolerant requests to the cloud and time-sensitive requests to the edge
devices. FTSM finds the checkpoint interval based on the operation time
between failures for the devices. However, Alarifi et al. [31] did not
consider any prediction of the failure for devices based on the fluctuating
availability of computation resources in the devices. Tajiki et al. [32]
proposed the Heuristic Fast Failure Recovery (HFFR) algorithm for software-
defined service function chaining for Fog computing with failure
consideration. The main idea of their proposed method is to find failure
probability based on the predefined threshold. Similar to FTSM, HFFR did not
consider the dynamic changes in the available resources. In addition, neither
of the works considered real failure traces for evaluating their proposed
methods. Battula et al. [33] proposed an efficient resource monitoring service
for Fog computing which suggested failure handling is essential for efficient
resource management in the Fog environment.

In summary, existing failure handling methods in Fog computing did not take
into account fully the dynamic availability of Fog resources. In this paper,
we propose a combined approach of proactive and reactive failure handling with
task replication to tackle highly dynamic behaviour of Fog resources. Thus,
this research was carried out to propose a composite solution of utilising
proactive, reactive and replication failure handling methods with dynamic
changes of the resources in the Fog devices. The bivalent proposition of the
Fuzzy logic technique motived us to employ this approach for failure handling.

##  III Failure Issues and Scenario

In this section we describe the application scenario and the research problem.
We also discuss the reasons for resource failure and some possible solutions
for handling failures in the Fog environment.

###  III-A Application Scenario

To demonstrate the problem solved in this paper, an application scenario is
presented in this section. Let us assume that an emergency vehicle is using a
smart transportation application and moving from point A to point B. The
vehicle has to choose the shortest route to the destination. To fulfil this
requirement the system needs to process data generated or stored in a dash
cam, surveillance camera and sensors. Based on the traffic conditions, the
following actions need to be taken: (i) inform other vehicles ahead that an
emergency vehicle is approaching; (ii) override signals if there are multiple
road junctions along the way; (iii) do the relevant processing in the Fog
devices, and (iv) take action following the processing. The overall scenario
and system architecture is presented in Figure 1.

Figure 1: Application scenario and system architecture.

Other incidents might also occur while the emergency vehicle is enroute. The
system should act promptly to minimise the delay in reaching the destination.
Here, the system needs to process data from sensors, as well as video data
from dashcams and surveillance cameras. All of the processing for the above
application scenarios is done in Fog devices to comply with the need for time
sensitivity. Therefore, the utilisation of processing power and on-time
processing are important. It is possible to ensure time sensitivity of the
application by distributing the application workload among Fog devices . But
the issue is what will happen if the Fog node has failed? We need to ensure
that the outcome of the application should meet time-sensitive requirements in
which the robustness of the scheduling approach will be assured.

Robustness is a feature of the scheduling process in which application
execution will be successful by ensuring time sensitivity, even if the
resource has failed, any errors have occurred in the system components or any
erroneous input has taken place. In our application scenario, the application
always requests the completion of the processing by defining a deadline.
However, our concern is how to deal with the failure of the resources during
operation. We are specifically focused on minimising the impact of the failure
on the applications, due to resource failure, by handling the situations in
which Fog device resources have failed.

###  III-B Problem Definition

This research was carried out to solve the following problem: How to meet user
requirements for applications in the Fog environment, with consideration of
device failure, in order to satisfy any time-sensitive requirements of the
application, while available resources in the devices are changing
dynamically?

Scheduling all related tasks to Fog devices is not such a complicated task if
we can assume that all devices are up and running, and there are no chances of
their failure. But, in reality, the chance of failure in the Fog environment
is very high since the devices are not dedicated to running Fog applications.
On the other hand, most of the devices in the Fog depend on wireless
connectivity. Also, the devices are mobile and are moving frequently from one
cluster to another. Next, most of the Fog devices are not stationary, meaning
that the devices have limited battery power. Furthermore, the application
might be interrupted by the owner of the devices (for example, the owner turns
off the device for some reason; the owner does not want to participate at that
moment or the owner wants to run another application which requires some
resources to be freed up). Due to all of the above reasons, the chances of
failure of the computation resources are very much higher than in any other
distributed system. To ensure the robustness of the scheduling algorithm, we
need to deal with resource failures in a way that the application user would
not affected.

###  III-C Resource Failure and Counter-measures

The resources could fail in the Fog environment for many reasons. The reasons
for failure can be categorised, such as the termination of the application to
run the native application, network failure, the device being moved to another
cluster, power outage, human interruption, software and hardware failure, and
network attacks. Due to the mobility and dynamicity of the available resources
in the devices, we can categorise all types of failure into two basic types:
(i) unpredicted/immediate failure and (ii) predicted failure.

We can handle failures in two different ways. Firstly, we can manage the
resource failure after it took place; this is referred to as reactive failure.
Secondly, it is possible to have countermeasures before the occurrence of the
resource failure; this is known as proactive failure handling. Both types of
failure handling mechanism have different approaches to manage resource
failures.

In a reactive failure handling mechanism, we can employ checkpointing and
replication. In application checkpointing the state of the application is
stored in reliable storage and, if the application has failed, it does not
need to rerun the application from the beginning. It will start the
application from the point where the latest state has been saved. There are
two types of checkpointing: i) coordinated or periodic checkpointing and ii)
uncoordinated or random checkpointing. In coordinated checkpointing, the
checkpoint should be consistent for the processes. In uncoordinated
checkpointing, each process checkpoints its state. The other type of reactive
failure handling mechanism is replication which always run replicas of the
running processes in different devices.

The basic way to solve immediate failure is re-running the whole application
but this is not the optimum way to solve the problem. For example, if a
certain percentage of processing is completed, there is no point in processing
the same portion of the application. Hence, the only solution for immediate
failure is checkpointing. Some researchers have argued that checkpointing is
not a good solution for the Fog environment because the Fog is a highly
dynamic environment [3, 34]. Yi et al. [3] suggested that replications are
more suitable for the Fog but multiple Fog nodes would need to be working
together. Madsen et al. [35] suggested using checkpointing for the Fog which
would save computation time for the faulty tasks. Some researchers used
checkpointing in the Fog as a fault-tolerant technique [36, 37]. We needed to
ascertain if there were any way to accommodate checkpointing in the Fog
environment. To do that we needed to evaluate our solution in simulation and
also in a real environment. We evaluated our proposed method in a simulated
environment with real failure traces.

In a proactive failure handling process, we can employ the migration process
before the resource failed. Since the Fog is for time-sensitive applications,
we were required to migrate the application without disconnecting devices.
Hence, we needed to employ live migration for this process. Two basic types of
migration are i) pre-copy migration and ii) post-copy migration [7]. In post-
copy migration, application migration needs to be initiated by suspending the
application at the source which will increase down-time. To minimise downtime,
pre-copy migration needed to have been employed. To resolve the predicted
failure, we could have employed pre-copy live migration. Once we could predict
that an application was going to fail then we could migrate the application to
another Fog device. But again, the question is raised: how to decide when and
where to migrate? However, this research only dealt with when to migrate, not
where to migrate to. To ensure the robustness of the scheduling algorithm, we
needed to handle both predicted and unpredicted failures which would minimise
their impact.

##  IV Fuzzy logic-based failure handling mechanism

To handle predicted and unpredicted failure we employed the fuzzy logic-based
solution. Classical logic usually has a bivalent proposition, which may be
true or false in principle. On the other hand, fuzzy logic can represent
actual membership of both true and false for a function. Some propositions
might be true and false to a certain degree, rather than being true or false
only. For example, for a Fog device, mobility, response time and power
availability might cause the failure of a device. However, the chances of
failure completely depend on the membership of each parameter (for example,
mobility, response time and power availability). To represent the exact degree
of membership of each parameter, a fuzzy logic-based approach was undertaken.
If the unpredicted failure for a Fog device were high then the Fog device
would be flagged as unreliable. To handle failure for unreliable Fog devices,
replication was used to ensure the robustness of the scheduling algorithm.

A predicted failure handling mechanism basically acts before the resource
failure takes place. However, due to decentralised management of the Fog
devices, an application might have failed but this was beyond our prediction.
Thus, an unpredicted failures handling mechanism allows seamless application
processing. Frequent unpredicted failures caused by a Fog device will trigger
replication to ensure successful application execution. Therefore, to ensure a
reliable application processing environment, all three approaches (predicted
failure, unpredicted failure and replication) need to be considered. Figure 2
shows what action will be taken after calculating the failure score.

Figure 2: Proposed failure handling mechanism.

Over utilisation of resources always causes failure. Suleiman and Venugopal
[38] modelled elasticity rules for the cloud when the resource has been
scaled, when utilisation is either 75% or 80%. This indicated that the chances
of failure was high when the utilisation was more than 80%. Hence, we assumed
that 80% to 100% utilisation was unsafe and service migration needed to have
been triggered. In another work Liu et al. [39] mentioned that the chances of
server crash were high when utilisation was more than 60%. Therefore, they
have chosen a workload threshold of 50% to 70%. Al-Haidari et al. [40]
revealed that the upper threshold for cloud resources utilisation should be
70% to 90%. Based on these studies [38, 39, 40] we assumed that less than 50%
utilisation was safe and it was necessary to checkpoint in case of failure if
the utilisation were 50% to 80%. A user could change these thresholds while
they were being implemented in a real environment through the proposed
algorithm.

###  IV-A MRP score calculation for unpredicted failure

To find an unpredicted failure, the system always calculates the degree of
failure by calculating membership of the following parameters: (i) device
mobility, (ii) device response time and (iii) device power availability.

Based on the degree of failure, the system will decide how frequently
checkpointing needs to be undertaken. Based on the percentage of the device
movement, we defined how readily the device could be completely moved to
another network. Device mobility can be represented as $D_{m}$ which could be
0% to 100%. Device response time always maps with required response time to
meet the application time sensitivity. For example, to complete an application
request, the device response time should be 2ms but the device is responding
in 1m; therefore, the degree of failure is within the group of 0%. On the
other hand, if the device response time suddenly changed to 2.5ms then the
degree of failure is within the group of 100% since it is not meeting the
application time-sensitive requirements. Device response time can be
represented as $D_{r}$ which could be 0% to 100%. Similarly, the power
available score can be calculated based on the power that is required to
complete the submitted application. All the parameters of device
characteristics are transformed into a normalised range [0 to 1] during
fuzzification. Fuzzy logic usually includes three phases: fuzzification, fuzzy
inference and defuzzification. The fuzzy sets for the above parameters are as
follows:

  * •

Device mobility: $D_{m}\in\\{Low,Normal,High\\}$

  * •

Device response time: $D_{r}\in\\{Fast,Normal,Slow\\}$

  * •

Device power: $D_{p}\in\\{Rich,Standard,Poor\\}$

Using Equation 1, the value can be normalised to fall in the interval [0 to
1].

$\overline{D_{x}}=\frac{D_{x}-\alpha_{x}}{\beta_{x}-\alpha_{x}}$ (1)

In the Equation 1, $D_{x}$ is the numerical value of $x$ where $x$ is either
mobility, response time or power. The value of $x$ is within the range of
$\alpha_{x}$ to $\beta_{x}$. The normalised value of the parameters’ mobility,
response time and power were calculated for further operation. The degree of
membership of each parameter is shown in Figure 3.

(a) Mobility

(b) Response time

(c) Power availability

Figure 3: Membership of different parameters for unpredicted failure. Figure
4: Membership for mrp score.

The mobility parameter of 0% to 50% is considered as low mobility; 30% to 90%
is normal mobility and 70% to 100% is considered to be high mobility. Until
30% mobility membership, we considered that the system was in safe zone.
However, at the point of 30%, the mobility membership was low and was
decreasing, and normal mobility membership was increasing. At the point of
50%, the low mobility membership was 0 and normal mobility membership was 1.
However, at the point of 70% normal mobility, membership decreased and became
0 at 90%. On the other hand, a 70% high mobility score, which started to
increase and reach 1 at 90%, meant that the device was about to fail. A
similar approach was employed for response time and membership of the power
availability parameters. Based on the membership of each parameter,
fuzzification was completed in the Fuzzy Interference System (FIS). To develop
FIS we used the jfuzzylogic toolbox [41]. The membership function for low,
normal and high mobility is shown in Equations 2, 3 and 4. A similar equation
is used for response time and power parameters.

$\mu_{mL}(x)=\begin{cases}0,&x>d\\\ \frac{d-x}{d-c},&c\leq x\leq d\\\
1,&x<c\end{cases}$ (2)

$\mu_{mN}(x)=\begin{cases}0,&(x<a)\ or\ (x>d)\\\ \frac{x-a}{b-a},&a\leq x\leq
b\\\ 1,&b\leq x\leq c\\\ \frac{d-x}{d-c},&c\leq x\leq d\end{cases}$ (3)

$\mu_{mH}(x)=\begin{cases}0,&x<a\\\ \frac{x-a}{b-a},&a\leq x\leq b\\\
1,&x>b\end{cases}$ (4)

We used max function as an accumulation method by which the fuzzy outcome of a
particular application is represented as $X_{i}$
Fuzzy rules: Based on the behaviour of the system fuzzy, rules were generated.
If any of the parameters were high, the system would not have been capable of
running any application. More clearly, if a system were highly mobile, there
was a high chance of resource failure in that device. In the same way, if
response time or power membership were high, then resource failure in that
particular device was also high. For this particular instance the rule should
be as follows:

  * •

If $D_{m}$ is high or $D_{r}$ is slow or $D_{p}$ is poor then $UF_{{mrp}_{m}}$
is high

In the above rule, $UF_{{mrp}_{m}}$ represents an unpredicted failure score
for application m. In order to consider some devices as being in a safe zone,
all scores of all parameters should have safe zone scores with a 0% to 50%
variation. For this particular instance, the rule is as follows:

  * •

If $D_{m}$ is low and $D_{r}$ is fast and $D_{p}$ is rich then
$UF_{{mrp}_{m}}$ is low

To define device membership in the checkpoint zone, mobility should be low or
normal, response time should be fast or normal, and power availability should
be rich or standard. The mobility membership should not be high; response time
should not be slow and power should not be poor, to be in the checkpointing
zone. In addition, mobility should not be low, response time should not be
fast and power should not be rich at the same time. To represent the
situations described above, we defined seven different rules. An example of
such a rule is given as follows:

  * •

If $D_{m}$ is low and $D_{r}$ is fast and $D_{p}$ is standard then
$UF_{{mrp}_{m}}$ is normal

Fuzzy inference and defuzzification: To generate an mrp score we used 0% 50%
as a low score, 50% to 80% as a normal score and 80% to 100% as a high score
(See Figure 3). A Center of Gravity (CoG) defuzzification method was used for
calculating the mrp score. The equation for CoG is shown in equation 5.

$UF_{{mrp}_{x}}=\frac{\sum_{i=1}^{n}X_{i}\times\mu_{i}}{\sum_{i=1}^{n}X_{i}}$
(5)

In the above equation $n$ is the number of rules needing to be triggered.
$\mu_{i}$ is the singleton value which refers to the maximum score for a
particular parameter. The defuzzification value for an application was used to
make decisions about application failure handling ($mrp$ score).

###  IV-B CPMNR score calculation for predicted failure

Some failures can be predicted based on the following criteria:

  * •

Effect on processing based on the current CPU utilisation

  * •

Effect on processing based on available power in the device

  * •

Effect on processing based on device mobility

  * •

Effect on processing based on network communication (Device is capable of
completing the request but network communication might be the cause of not
meeting time-sensitive requirements)

  * •

Effect on processing based on device response time

All device behaviour parameters were transformed into a normalised range [0 to
1] during fuzzification. The fuzzy sets for the above parameters are as
follows:

  * •

CPU utilisation: $D_{mc}\in\\{Low,Normal,High\\}$

  * •

Device power: $D_{mp}\in\\{Rich,Standard,Poor\\}$

  * •

Device mobility: $D_{mm}\in\\{Low,Normal,High\\}$

  * •

Network communication: $D_{mn}\in\\{Fast,Medium,Slow\\}$

  * •

Response time $D_{mr}\in\\{Fast,Normal,Slow\\}$

Using Equation 6, the value can be normalised to fall into the interval [0 to
1].

$\overline{D_{mx}}=\frac{D_{mx}-\alpha_{mx}}{\beta_{mx}-\alpha_{mx}}$ (6)

In the Equation 6, $D_{mx}$ is the numerical value of $mx$ where $mx$ is
either CPU utilisation, power, mobility, network communication or response
time. The value of $mx$ was within the range of $\alpha_{mx}$ to $\beta_{mx}$.
The normalised value of the parameters’ CPU utilisation, power, mobility,
network communication and response time was calculated for further operation.
The degree of membership of each parameter is shown in Figures 5.

(a) CPU utilisation

(b) Power availability

(c) Mobility

(d) Network communication

(e) Response time

(f) cpmnr score

Figure 5: Membership of different parameters for predicted failure and cpmnr
score.

The CPU utilisation parameter 0% to 50% was considered to be low CPU
utilisation; 30% to 90% was normal CPU utilisation and 70% to 100% was
considered to be high CPU utilisation. Until 30% CPU utilisation membership,
we considered that the system was in safe zone. However, at the point of 30%,
low CPU utilisation membership decreased and normal CPU utilisation membership
increased. At the point of 50%, low CPU utilisation membership was 0 and
normal CPU utilisation membership was 1. However, at the point of 70%, normal
CPU utilisation membership started to decrease and became 0 at 90%. On the
other hand, a 70% high CPU utilisation score starting to increase and reaching
1 at 90% meant that the device was about to fail due to the over utilisation
of the CPU. A similar approach was employed for power availability, mobility,
network communication and response time parameters. Based on the membership of
each parameter, fuzzification was undertaken in the FIS system. Similar to the
calculation of the MRP score, we used Equations 2, 3 and 4 for the membership
function of low, normal and high for CPU utilisation, power availability,
mobility, network communication and response time parameters.

Similar to the MRP score calculation we used the max function as an
accumulation method by which the fuzzy outcome of a particular application is
represented as $X_{i}$.

Fuzzy rules:  Based on the behaviour of the system, fuzzy rules have been
generated. If any of the parameters are high the system will not be capable of
running any application. More clearly, if a system has high CPU utilisation,
there is a high chance of application failure in that device. In the same way,
if power, mobility, network communication and response time membership are
high, then application failure in that particular device will be high as well.
For this particular instance the rule should be as follows:

  * •

If $D_{mc}$ is high or $D_{mp}$ is poor or $D_{mm}$ is high or $D_{mn}$ is
slow or $D_{mr}$ is slow then $PF_{{cpmnr}_{m}}$ is high

In the above rule, $PF_{{cpmnr}_{m}}$ represents the unpredicted failure score
for application $m$. In order to consider some devices as being in a safe
zone, all scores of all parameters should have safe zone scores which are
within 0% to 50% variation. For this particular instance the rule is as
follows:

  * •

If $D_{mc}$ is low and $D_{mp}$ is rich and $D_{mm}$ is low and $D_{mn}$ is
fast and $D_{mr}$ is fast then $PF_{{cpmnr}_{m}}$ is low

To define device membership in a checkpoint zone, CPU utilisation should be
low or normal, power availability should be rich or standard, mobility should
be low or normal, network communication should be fast or medium and response
time should be fast or normal. The CPU utilisation membership should not be
high, power should not be poor, mobility membership should not be high,
network communication membership should not be slow and response time should
not be slow to arrive in the checkpoint zone. Also, CPU utilisation should not
be low, power should not be rich, mobility should not be low, network
communication should not be fast, and response time should not be fast at the
same time. To represent the situations described above, we need to defined 31
different rules. An example of such a rule is given as follows:

  * •

If $D_{mc}$ is low and $D_{mp}$ is rich and $D_{mm}$ is low and $D_{mn}$ is
fast and $D_{mr}$ is normal then $PF_{{cpmnr}_{m}}$ is normal

Fuzzy inference and defuzzification: To generate the cpmnr score we used 0%
50% as a low score, 50% to 80% as a normal score and 80% to 100% as a high
score (See Figure 5(f)). The Centre of Gravity (CoG) defuzzification method
was used for calculating the cpmnr score. The equation for CoG is shown in
Equation 7.

$PF_{{cpmnr}_{x}}=\frac{\sum_{i=1}^{n}X_{i}\times\mu_{i}}{\sum_{i=1}^{n}X_{i}}$
(7)

In the above equation $n$ is the number of rules needing to be triggered.
$\mu_{i}$ is the singleton value which refers to the maximum score for a
particular parameter. The defuzzification value for an application was used
for making decisions about the predicted application failure handling (cpmnr
score).

###  IV-C Replication

Replication of the application only applies if the rate of unpredicted
(immediate) failure is high. The failure rate cannot be calculated within the
execution of a few application attempts. Due to this we considered at least 10
application executions before deciding whether replication was required or
not. The overall process of the failure handling process is presented in
Figure 6.

Figure 6: Failure handling process in the proposed method. Algorithm 1 Fuzzy-
logic-based failure handling (FLBFH).

Input:
$App[id,D_{m},D_{r},D_{p},D_{mc},D_{mp},D_{mm},D_{mn},D_{mr},SD_{ft},A_{c}]$
Output:$Ac_{tr}[App_{id},Actions]$

for all $App[id]$ do

Calculate degree of changes in mobility

Calculate degree of response time changes

Calculate degree of power profile changes

Calculate degree of CPU utilization changes

Calculate degree of changes in network comm

Calculate degree of failure ($d_{f}$)

if $d_{f}\geq 50$ and $d_{f}\leq 80$ then

$Ac_{tr}.INSERT[App_{id},Checkpoint]$

else if $d_{f}\geq 80$ and $d_{f}<100$ then

$Ac_{tr}.INSERT[App_{id},Migrate]$

else if $d_{f}\geq 100$ then

$Ac_{tr}.INSERT[App_{id},CheckpointRecover]$

end if

$ASD_{f}$ = ($SD_{ft}$ \+ $d_{f}$)/$A_{c}$

if $ASD_{f}\geq 50$ and $A_{c}>10$ then

$Ac_{tr}.INSERT[App_{id},Replicate]$

end if

end for

return $Ac_{tr}[]$

###  IV-D Mapping

If the mrp score for unpredicted failure is in the unsafe zone, then the
system will migrate the application to other available Fog devices. It is
obvious that the cpmnr score will also be in the unsafe zone, if the mrp score
is in the unsafe zone. However, the cpmnr score also considers CPU utilisation
and network communication for making more accurate decisions about
checkpointing and migration. If either of the two scores is in the
checkpointing zone, then the application checkpointing will be triggered.
However, if any of these two scores are in the failed zone, then the system
will see if any replicated application is running or not. If so, the system
will interact with one of the replicated applications. In the case of there
being no running replicated application, the system will check if there are
any checkpoints there or not. If there are any checkpoints, then the
application will recover from that checkpoint. In the case of no checkpoint
and no replicated application, $n$, then the system will rerun the whole
application which is a worse case scenario. A proposed Fuzzy-Logic-based
Failure Handling (FLBFH) algorithm is presented in Algorithm 1.

In Algorithm 1, $SD_{f}$ is the score for degree of failure, $A_{c}$ is the
app count (The total number of times a task for an application is running),
$SD_{ft}$ is the total score for degree of failure and $ASD_{f}$ is the
average score for degree of failure.

##  V Experimental Setup and Evaluation Technique

###  V-A Failure Modelling

Since no failure traces are available for the Fog, we used failure traces from
the Failure Trace Archive (FTA) [42]. There are 27 real failure traces
available in FTA. Most of those traces have two events: failed or not failed
(available). Among them, only Los Alamos National Laboratory (LANL) [43] has
failure traces with reasons such as CPU failure, power failure or network
failure. Therefore, we selected LANL failure traces to model failure in the
Fog environment. LANL has failure traces for nine years (1996 to 2005) which
consist of 4750 nodes that form 22 High-Performance Computing (HPC) systems
[43]. This trace has the records for every failure that takes place within the
system and which needs administrator attention. We selected those devices from
LANL failure traces which had comparatively high failure rates compared with
other devices. Those selected devices did not have failure traces for the year
1996 and 2005. Due to that, we used failure traces from 1997 to 2004. The Fog
environment consists of numerous nodes, each HPC nodes being considered as a
single Fog node. The LANL failure traces only have the information as to
whether the resource failed or not. By keeping the Fog device characteristics
intact, we utilised the failure information of the Fog node during simulation-
based experiments. Hence, it is logical to use LANL failure traces in our
experimental scenario.

###  V-B Experimental Setup

In order to control over the experimental environment, we chose simulation to
evaluate the proposed method. We adopted a simulation environment and
performance parameters from our previous works [44] [45]. In addition, we
modelled a realistic Fog environment by extending the CloudSim [46] toolkit,
similar to our previous work. All submitted tasks followed deadlines which
varied dynamically from 10% to 80%, similar to our previous work [45].
Successful execution of application by maintaining deadlines indicated
successful processing.

###  V-C Performance Metrics

All the performance metrics were adopted from our previous works [44, 45].

Delay: We considered the delay between the user to the Fog resources. Delay is
the time between task submission and the starting of task execution. It can be
calculated as follows:

$\begin{split}\color[rgb]{0,0,0}d_{t}^{x}=E_{st}^{x}-U_{S}\end{split}$ (8)

In Equation 8, $d_{t}^{x}$ denotes the delay for the $x$ Fog device which is
involved in task execution. $E_{st}$ is the task start time and $x-U_{S}$ is
the time when the user requested the execution of the task.

Processing time: Processing time is the required time to process a task. It is
the time between the task processing start time $p_{st}$ and the task
processing end time $p_{en}$ which can be calculated by using the Equation 10.

$\begin{split}\color[rgb]{0,0,0}Pt_{t}^{x}=p_{en}^{x}-p_{st}^{x}\end{split}$
(9)

In the above equation, $x$ is the Fog device which is involved in task
execution, and $Pt_{t}$ is the processing time for task $t$.

Processing Cost: We considered connectivity and messaging costs for processing
costs. These costs are based on the AWS IoT pricing model. Cost is from $1 to
$1.65 per million messages for messaging and from $0.08 to $0.132 for
connectivity cost for per million minutes for various regions. We considered
the price that has been allocated for the Sydney region. Processing cost can
be calculated as follows:

$\begin{split}\color[rgb]{0,0,0}Pc_{t}=\sum_{k=a}^{n}(M_{c}+C_{c})\end{split}$
(10)

In the above Equation, $M_{c}$ is the messaging cost and $C_{c}$ is the
connectivity cost and $Pc_{t}$ is the total processing cost. We calculated
cost for Fog device $a$ to Fog device $n$.

###  V-D Evaluation Technique

We compared the proposed FLBFH with two recent works HFFR [32] and FTSM [31].
Since those two works were implemented in a different simulation environment
and did not consider real failure traces, we adopted the key idea of both
proposed methods to fit with our simulation environment and failure traces. We
compared both methods with our proposed method in the results and discussion
section to show the improvement of the FLBFH failure handling method over
previously proposed methods.

##  VI Results and Discussion

We took eight years of failure traces to perform simulations and simulate each
year’s failure traces separately for HFFR, FTSM and the proposed FLBFH
methods. Performance comparison of each metric is presented below in different
sub-sections.

###  VI-A Delay

We measured average, maximum and minimum delays for each task, as shown in
Figure 7, 8 and 9. The average delay for the proposed FLBFH method was
improved by around 52% and 58% for HFFR and FTSM respectively, on an average
for all failure traces (Figure 7).

Figure 7: Average delay for different failure traces.

For the failure traces of the year 2000, 2001 and 2003, the improvement was
around 51% for HFFR compared with the proposed method. The maximum improvement
was found for the 2004 failure traces which was 54%. Delay improvement for the
rest of the failure traces was between 52% to 53%. On the other hand, compared
with FTSM, the maximum improvement was 60% for the 2003 failure traces in the
proposed method. The minimum delay improvement found for the 2001 failure
traces compared with the FTSM, was 55%. However, the improvement was 59% for
1998, 2000 and 2002 failure traces, and 56%, 57% and 58% respectively for
1997, 1999 and 2004 failure traces. The delay improvement was different
because of the difference failure handling technique. However, our proposed
FLBFH method performed better over both HFFR and FTSM methods.

The maximum delay for the proposed FLBFH method was improved by around 50% and
56% for HFFR and FTSM respectively (Figure 8).

Figure 8: Maximum delay for different failure traces.

For all failure traces, the maximum delay was improved 49% to 50% in the
proposed method, compared with the HFFR method. On the other hand, the
improvement was in between of 55% and 56% in the proposed method, compared
with the FTSM method. Maximum improvement was found over FTSM method for
average delay and the same trend was found for maximum delay.

The minimum delay was more in FLBFH for most of the cases, as compared with
HFFR and FTSM (Figure 9). Compared with HFFR, it was 19% more, while it was
13% more for FRSM on an average, for all failure traces. However, for 1997,
1998 and 2001, the failure traces minimum delay improved compared with FTSM,
the improvement being 17% to 20%. Since the average delay was improved for the
proposed algorithm, the minimum delay will not have much effect on application
processing.

Figure 9: Minimum delay for different failure traces.

###  VI-B Processing time

There is no significant difference in the average processing time for HFFR and
FTSM, compared with the proposed FLBFH method (Figure 10). However, the number
of failed tasks was less in the proposed FLBFH method. Since the proposed
method used a Fuzzy-logic based approach for failure handling and prediction,
it was able to handle failure more efficiently, with a resulting improvement
in the total processing time.

Figure 10: Average processing time for different failure traces.

On average, the total processing time improved by 51% and 45% for the FLBFH
method, compared with HFFR and FTSM respectively as shown in Figure 11.
Compared with HFFR, the improvement was around 50% to 51% and compared with
FTSM, it was around 44% to 46%. Total processing time improved in the proposed
method because the number of failed tasks in the proposed method was fewer
which provided better failure handling and robust scheduling.

Figure 11: Improvement in processing time for different failure traces with
FLBFH. Figure 12: Processing cost for different failure traces.

###  VI-C Cost

The total processing cost was less for the proposed FLBFH method, compared
with HFFR and FTSM, as shown in Figure 12. HFFR had around 77% higher cost on
average for all failure traces. On the other hand, FTSM had around 44% higher
cost compared with FLBFH. This indicates that the number of failed tasks was
higher in HFFR and FTSM, compared with the proposed FLBFH method.

##  VII Conclusion

The Fog computing environment is highly dynamic in terms of available
resources in the devices and the chances of failure are very high. This
research contributes to minimising the total number of application failures
due to the failure of the resources; it helps to improve delay and processing
time by proposing a Fuzzy-logic-based failure handling method. The proposed
failure handling method was evaluated using real failure traces from LANL.
Compared with the existing failure handling approaches, we found an
improvement in average delay and total processing time which were 56% and 48%
respectively on average. For future work, we will consider the implementation
and evaluation of the proposed method in the real Fog computing environment,
as well as power-aware resource allocation. The proposed method can be
improved further by selecting more appropriate Fog devices which have less
chance of failure.

## References

  * [1] R. K. Naha, S. Garg, D. Georgakopoulos, P. P. Jayaraman, L. Gao, Y. Xiang, and R. Ranjan, “Fog computing: survey of trends, architectures, requirements, and research directions,” _IEEE access_ , vol. 6, pp. 47 980–48 009, 2018\.
  * [2] S. K. Battula, S. Garg, R. K. Naha, P. Thulasiraman, and R. Thulasiram, “A micro-level compensation-based cost model for resource allocation in a fog environment,” _Sensors_ , vol. 19, no. 13, p. 2954, 2019.
  * [3] S. Yi, C. Li, and Q. Li, “A survey of fog computing: concepts, applications and issues,” in _Proceedings of the 2015 workshop on mobile big data_. ACM, 2015, pp. 37–42.
  * [4] D. Bermbach, F. Pallas, D. G. Pérez, P. Plebani, M. Anderson, R. Kat, and S. Tai, “A research perspective on fog computing,” in _International Conference on Service-Oriented Computing_. Springer, 2017, pp. 198–210.
  * [5] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg, and I. Brandic, “Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing as the 5th utility,” _Future Generation computer systems_ , vol. 25, no. 6, pp. 599–616, 2009.
  * [6] S. S. Gill and R. Buyya, “Failure management for reliable cloud computing: A taxonomy, model and future directions,” _Computing in Science & Engineering_, pp. 1–10, 2018.
  * [7] Y. Sharma, B. Javadi, W. Si, and D. Sun, “Reliability and energy efficiency in cloud computing systems: Survey and taxonomy,” _Journal of Network and Computer Applications_ , vol. 74, pp. 66–85, 2016.
  * [8] K. Samant and S. Bhattacharyya, “Topology, search, and fault tolerance in unstructured p2p networks,” in _37th Annual Hawaii International Conference on System Sciences, 2004. Proceedings of the_. IEEE, 2004, pp. 1–6.
  * [9] K. Vanthournout, G. Deconinck, and R. Belmans, “Building dependable peer-to-peer systems,” in _DSN 2004 Workshop on Architecting Dependable Systems_ , 2004, pp. 297–301.
  * [10] J.-W. Lin, M.-F. Yang, and J. Tsai, “Fault tolerance for super-peers of p2p systems,” in _13th Pacific Rim International Symposium on Dependable Computing (PRDC 2007)_. IEEE, 2007, pp. 107–114.
  * [11] A.-R. Mawlood-Yunis, M. Weiss, and N. Santoro, “From p2p to reliable semantic p2p systems,” _Peer-to-peer networking and applications_ , vol. 3, no. 4, pp. 363–381, 2010.
  * [12] Y. Li and Z. Lan, “Exploit failure prediction for adaptive fault-tolerance in cluster computing,” in _Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID’06)_ , vol. 1. IEEE, 2006, pp. 1–8.
  * [13] G. M. Weiss and H. Hirsh, “Learning to predict rare events in event sequences,” in _KDD_ , 1998, pp. 359–363.
  * [14] R. Vilalta and S. Ma, “Predicting rare events in temporal domains,” in _2002 IEEE International Conference on Data Mining, 2002. Proceedings._ IEEE, 2002, pp. 474–481.
  * [15] R. K. Sahoo, A. J. Oliner, I. Rish, M. Gupta, J. E. Moreira, S. Ma, R. Vilalta, and A. Sivasubramaniam, “Critical event prediction for proactive management in large-scale computer clusters,” in _Proceedings of the ninth ACM SIGKDD international conference on Knowledge discovery and data mining_. ACM, 2003, pp. 426–435.
  * [16] R. Vilalta and S. Ma, “Predicting rare events in temporal domains using associative classification rules,” _Technical Report_ , pp. 426–435, 2002\.
  * [17] G. A. Hoffmann, F. Salfner, and M. Malek, _Advanced Failure Prediction in Complex Software Systems_. Humboldt-Universität zu Berlin, Mathematisch-Naturwissenschaftliche Fakultät II, Institut für Informatik, 2011.
  * [18] C. Leangsuksun, T. Liu, T. Rao, S. Scott, and R. Libby, “A failure predictive and policy-based high availability strategy for linux high performance computing cluster,” in _The 5th LCI International Conference on Linux Clusters: The HPC Revolution_. Citeseer, 2004, pp. 18–20.
  * [19] V. Castelli, R. E. Harper, P. Heidelberger, S. W. Hunter, K. S. Trivedi, K. Vaidyanathan, and W. P. Zeggert, “Proactive management of software aging,” _IBM Journal of Research and Development_ , vol. 45, no. 2, pp. 311–332, 2001.
  * [20] A. J. Oliner, L. Rudolph, R. K. Sahoo, J. E. Moreira, and M. Gupta, “Probabilistic qos guarantees for supercomputing systems,” in _2005 International Conference on Dependable Systems and Networks (DSN’05)_. IEEE, 2005, pp. 634–643.
  * [21] S. Chakravorty, C. Mendes, and L. Kalé, “Proactive fault tolerance in large systems,” in _HPCRI Workshop in conjunction with HPCA_ , 2005, pp. 1–7.
  * [22] S. Hwang and C. Kesselman, “Grid workflow: a flexible failure handling framework for the grid,” in _High Performance Distributed Computing, 2003\. Proceedings. 12th IEEE International Symposium on_. IEEE, 2003, pp. 126–137.
  * [23] H. Jin, D. Zou, H. Chen, J. Sun, and S. Wu, “Fault-tolerant grid architecture and practice,” _Journal of Computer Science and Technology_ , vol. 18, no. 4, p. 423, 2003.
  * [24] H. Lee, K. Chung, S. Chin, J. Lee, D. Lee, S. Park, and H. Yu, “A resource management and fault tolerance services in grid computing,” _Journal of Parallel and Distributed Computing_ , vol. 65, no. 11, pp. 1305–1317, 2005.
  * [25] G. Kandaswamy, A. Mandal, and D. A. Reed, “Fault tolerance and recovery of scientific workflows on computational grids,” in _2008 Eighth IEEE International Symposium on Cluster Computing and the Grid (CCGRID)_. IEEE, 2008, pp. 777–782.
  * [26] B. B. Khoo and B. Veeravalli, “Pro-active failure handling mechanisms for scheduling in grid computing environments,” _Journal of Parallel and Distributed Computing_ , vol. 70, no. 3, pp. 189–200, 2010.
  * [27] Y. Sharma, W. Si, D. Sun, and B. Javadi, “Failure-aware energy-efficient vm consolidation in cloud computing systems,” _Future Generation Computer Systems_ , vol. 94, pp. 620–633, 2019.
  * [28] L. Luo, S. Meng, X. Qiu, and Y. Dai, “Improving failure tolerance in large-scale cloud computing systems,” _IEEE Transactions on Reliability_ , vol. 68, no. 2, pp. 620–632, 2019.
  * [29] R. Buyya, S. N. Srirama, G. Casale, R. Calheiros, Y. Simmhan, B. Varghese, E. Gelenbe, B. Javadi, L. M. Vaquero, M. A. Netto _et al._ , “A manifesto for future generation cloud computing: research directions for the next decade,” _ACM computing surveys (CSUR)_ , vol. 51, no. 5, p. 105, 2019\.
  * [30] Y. Liu, J. E. Fieldsend, and G. Min, “A framework of fog computing: Architecture, challenges, and optimization,” _IEEE Access_ , vol. 5, pp. 25 445–25 454, 2017.
  * [31] A. Alarifi, F. Abdelsamie, and M. Amoon, “A fault-tolerant aware scheduling method for fog-cloud environments,” _PLOS ONE_ , vol. 14, no. 10, pp. 1–24, 2019.
  * [32] M. M. Tajiki, M. Shojafar, B. Akbari, S. Salsano, and M. Conti, “Software defined service function chaining with failure consideration for fog computing,” _Concurrency and Computation: Practice and Experience_ , vol. 31, no. 8, pp. 1–14, 2019.
  * [33] S. K. Battula, S. Garg, J. Montgomery, and B. H. Kang, “An efficient resource monitoring service for fog computing environments,” _IEEE Transactions on Services Computing_ , 2019.
  * [34] K. Kai, W. Cong, and L. Tao, “Fog computing for vehicular ad-hoc networks: paradigms, scenarios, and issues,” _the journal of China Universities of Posts and Telecommunications_ , vol. 23, no. 2, pp. 56–96, 2016.
  * [35] H. Madsen, B. Burtschy, G. Albeanu, and F. Popentiu-Vladicescu, “Reliability in the utility computing era: Towards reliable fog computing,” in _2013 20th International Conference on Systems, Signals and Image Processing (IWSSIP)_. IEEE, 2013, pp. 43–46.
  * [36] J. P. de Araujo Neto, D. M. Pianto, and C. G. Ralha, “A fault-tolerant agent-based architecture for transient servers in fog computing,” in _2018 30th International Symposium on Computer Architecture and High Performance Computing (SBAC-PAD)_. IEEE, 2018, pp. 282–289.
  * [37] C. Puliafito, E. Mingozzi, C. Vallati, F. Longo, and G. Merlino, “Companion fog computing: Supporting things mobility through container migration at the edge,” in _2018 IEEE International Conference on Smart Computing (SMARTCOMP)_. IEEE, 2018, pp. 97–105.
  * [38] B. Suleiman and S. Venugopal, “Modeling performance of elasticity rules for cloud-based applications,” in _2013 17th IEEE International Enterprise Distributed Object Computing Conference_. IEEE, 2013, pp. 201–206.
  * [39] C. Liu, K. Li, J. Liang, and K. Li, “Service reliability in an hc: Considering from the perspective of scheduling with load-dependent machine reliability,” _IEEE Transactions on Reliability_ , vol. 68, no. 2, pp. 476–495, 2019.
  * [40] F. Al-Haidari, M. Sqalli, and K. Salah, “Impact of cpu utilization thresholds and scaling size on autoscaling cloud resources,” in _2013 IEEE 5th International Conference on Cloud Computing Technology and Science_ , vol. 2. IEEE, 2013, pp. 256–261.
  * [41] P. Cingolani and J. Alcalá-Fdez, “jfuzzylogic: a java library to design fuzzy logic controllers according to the standard for fuzzy control programming,” _International Journal of Computational Intelligence Systems_ , vol. 6, no. sup1, pp. 61–75, 2013.
  * [42] B. Javadi, D. Kondo, A. Iosup, and D. Epema, “The failure trace archive: Enabling the comparison of failure measurements and models of distributed systems,” _Journal of Parallel and Distributed Computing_ , vol. 73, no. 8, pp. 1208–1223, 2013.
  * [43] B. Schroeder and G. Gibson, “A large-scale study of failures in high-performance computing systems,” _IEEE transactions on Dependable and Secure Computing_ , vol. 7, no. 4, pp. 337–350, 2009.
  * [44] R. K. Naha, S. Garg, A. Chan, and S. K. Battula, “Deadline-based dynamic resource allocation and provisioning algorithms in fog-cloud environment,” _Future Generation Computer Systems_ , vol. 104, pp. 131–141, 2020.
  * [45] R. K. Naha and S. Garg, “Multi-criteria-based dynamic user behaviour aware resource allocation in fog computing,” _arXiv preprint_ , 2019.
  * [46] R. N. Calheiros, R. Ranjan, A. Beloglazov, C. A. De Rose, and R. Buyya, “Cloudsim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms,” _Software: Practice and experience_ , vol. 41, no. 1, pp. 23–50, 2011.

|  Ranesh Kumar Naha Ranesh Kumar Naha completed his Ph.D. studies on reliable
resource allocation and scheduling in the Fog computing environment with the
University of Tasmania, Australia. He has been awarded a Tasmania Graduate
Research Scholarship (TGRS) to support his studies. He received his Master of
Science (M.Sc.) degree from Universiti Putra Malaysia, in 2015. He has been
awarded a prestigious Commonwealth Scholarship provided by the Ministry of
Higher Education, Malaysia. His research interests include wired and wireless
networks, parallel and distributed computing, security, Blockchain, Cloud
computing, Internet of Things (IoT) and Fog/Edge computing.
---|---
|  Dr. Saurabh Garg is currently a Lecturer with the University of Tasmania,
Australia. He is one of the few Ph.D. students who completed in less than
three years from the University of Melbourne. He has authored over 40 papers
in highly cited journals and conferences. During his Ph.D., he has been
received various special scholarships for his Ph.D. candidature. His research
interests include resource management, scheduling, utility and grid computing,
Cloud computing, green computing, wireless networks, and ad hoc networks.
---|---
|  Dr. Muhammad Bilal Amin received the M.S. degree from DePaul University,
Chicago, IL, USA, in 2006, and the Ph.D. degree from Kyung Hee University,
South Korea, in 2015. He is currently a Korea Research Fellow and serving as a
Lecturer with the Department of ICT, University of Tasmania, Australia. He has
an experience of more than ten years in the software industry, working for
Fortune 500 companies in the USA. He is an author of more than 50
publications. His research interests include blockchain, distributed systems,
software engineering and architecture, and performance-based cloud
applications
---|---
|  Prof. Dr. Rajiv Ranjan (Senior Member, IEEE) is currently a chair and
professor of computing science and Internet of Things with Newcastle
University (from August 2018), United Kingdom. He is an internationally
established scientist with more than 300 scientific publications and expertise
in cloud computing, big data, and the Internet of Things. He has secured more
than $24 Million AUD in the form of competitive research grants from both
public and private agencies. He is an innovator with strong and sustained
academic and industrial impact and a globally recognized R&D leader with the
proven track record. His work has been extensively cited (17K+, Google
Scholar; 9K+ Scopus; 6K+ Web of Science). He serves on the editorial boards of
top-quality international journals including the IEEE Transactions on
Computers, IEEE Transactions on Cloud Computing, IEEE Cloud Computing, and
Future Generation Computer Systems.
---|---


* (60) P. De Lange, A. Maloney and E. Verlinde, _Monstrous Product CFTs in the Grand Canonical Ensemble_ , 1807.06200.
  * (61) R. Dijkgraaf, G. W. Moore, E. P. Verlinde and H. L. Verlinde, _Elliptic Genera of Symmetric Products and Second Quantized Strings_ , _Commun. Math. Phys._ 185 (1997) 197 [hep-th/9608096].
  * (62) J. M. Maldacena, G. W. Moore and A. Strominger, _Counting BPS Black Holes in Toroidal Type II String Theory_ , hep-th/9903163.
  * (63) A. Maloney and E. Witten, _Quantum Gravity Partition Functions in Three Dimensions_ , _JHEP_ 02 (2010) 029 [0712.0155].
  * (64) R. Dijkgraaf, J. M. Maldacena, G. W. Moore and E. P. Verlinde, _A Black Hole Farey Tail_ , hep-th/0005003.
  * (65) J. Manschot and G. W. Moore, _A Modern Farey Tail_ , _Commun. Num. Theor. Phys._ 4 (2010) 103 [0712.0573].
  * (66) C. A. Keller and A. Maloney, _Poincare Series, 3D Gravity and CFT Spectroscopy_ , _JHEP_ 02 (2015) 080 [1407.6008].
  * (67) J. Maldacena and L. Susskind, _Cool Horizons for Entangled Black Holes_ , _Fortsch. Phys._ 61 (2013) 781 [1306.0533].
  * (68) N. Engelhardt, S. Fischetti and A. Maloney, _Free Energy from Replica Wormholes_ , 2007.07444.
  * (69) N. Seiberg and E. Witten, _The ${\rm D}1$ / ${\rm D}5$ system and singular CFT_, _JHEP_ 04 (1999) 017 [hep-th/9903224].
  * (70) R. Gopakumar, _From Free Fields to AdS_ , _Phys. Rev. D_ 70 (2004) 025009 [hep-th/0308184].
  * (71) R. Gopakumar, _From Free Fields to AdS. 2._ , _Phys. Rev. D_ 70 (2004) 025010 [hep-th/0402063].
  * (72) R. Gopakumar, _From Free Fields to AdS: III_ , _Phys. Rev. D_ 72 (2005) 066008 [hep-th/0504229].
  * (73) S. S. Razamat, _On a Worldsheet Dual of the Gaussian Matrix Model_ , _JHEP_ 07 (2008) 026 [0803.2681].
  * (74) M. R. Gaberdiel, R. Gopakumar, B. Knighton and P. Maity, _From Symmetric Product CFTs to ${\rm AdS}_{3}$_, 2011.10038.
  * (75) H. Maxfield and G. J. Turiaci, _The Path Integral of 3D Gravity Near Extremality; Or, Jt Gravity with Defects as a Matrix Integral_ , 2006.11317.
  * (76) L. Susskind, _Some Speculations About Black Hole Entropy in String Theory_ , hep-th/9309145.
  * (77) G. T. Horowitz and J. Polchinski, _A Correspondence Principle for Black Holes and Strings_ , _Phys. Rev. D_ 55 (1997) 6189 [hep-th/9612146].
  * (78) A. Giveon, D. Kutasov, E. Rabinovici and A. Sever, _Phases of Quantum Gravity in $\mathrm{AdS}_{3}$ and Linear Dilaton Backgrounds_, _Nucl. Phys. B_ 719 (2005) 3 [hep-th/0503121].
  * (79) V. Balasubramanian, B. Craps, B. Czech and G. Sárosi, _Echoes of chaos from string theory black holes_ , _JHEP_ 03 (2017) 154 [1612.04334].
  * (80) A. Belin, _Permutation Orbifolds and Chaos_ , _JHEP_ 11 (2017) 131 [1705.08451].
  * (81) S. R. Coleman, _Black Holes as Red Herrings: Topological Fluctuations and the Loss of Quantum Coherence_ , _Nucl. Phys. B_ 307 (1988) 867.
  * (82) S. B. Giddings and A. Strominger, _Loss of Incoherence and Determination of Coupling Constants in Quantum Gravity_ , _Nucl. Phys. B_ 307 (1988) 854.
  * (83) S. B. Giddings and A. Strominger, _Baby Universes, Third Quantization and the Cosmological Constant_ , _Nucl. Phys. B_ 321 (1989) 481.
  * (84) O. Aharony, S. M. Chester and E. Y. Urbach, _A Derivation of AdS/CFT for Vector Models_ , 2011.06328.
  * (85) N. Berkovits and C. Vafa, _Towards a Worldsheet Derivation of the Maldacena Conjecture_ , _AIP Conf. Proc._ 1031 (2008) 21 [0711.1799].
  * (86) N. Berkovits, _Sketching a Proof of the Maldacena Conjecture at Small Radius_ , _JHEP_ 06 (2019) 111 [1903.08264].
  * (87) B. Sundborg, _Stringy gravity, interacting tensionless strings and massless higher spins_ , _Nucl. Phys. Proc. Suppl._ 102 (2001) 113 [hep-th/0103247].
  * (88) H. Maxfield, S. Ross and B. Way, _Holographic Partition Functions and Phases for Higher Genus Riemann Surfaces_ , _Class. Quant. Grav._ 33 (2016) 125018 [1601.00980].
  * (89) N. Hitchin, _Harmonic spinors_ , _Advances in Mathematics_ 14 (1974) 1 .
  * (90) L. Bers, _Simultaneous uniformization_ , _Bull. Amer. Math. Soc._ 66 (1960) 94.
  * (91) D. Gallo, M. Kapovich and A. Marden, _The monodromy groups of schwarzian equations on closed riemann surfaces_ , _Annals of Mathematics_ (2000) 625\.
  * (92) R. Mandelbaum, _Branched structures and affine and projective bundles on riemann surfaces_ , _Transactions of the American Mathematical Society_ 183 (1973) 37.
  * (93) A. Gerasimov, A. Morozov, M. Olshanetsky, A. Marshakov and S. L. Shatashvili, _Wess-Zumino-Witten Model as a Theory of Free Fields_ , _Int. J. Mod. Phys. A_ 5 (1990) 2495.
  * (94) R. Iengo and B. Ivanov, _Fermionization of chiral string determinants in factorizable metrics_ , _Physics Letters B_ 203 (1988) 89 .