QoS-aware Task Allocation and Scheduling in Cloud-Fog-Edge Architecture

ed
with Proactive Migration Strategy

Nikita Joshia , Sanjay Srivastavaa

iew
a
ICT department, Dhirubhai Ambani Institute of Information and Communication
Technology, Gandhinagar, 382007, Gujarat, India

Abstract

ev
The vision of the Internet of Things (IoT) is made possible by advancements in sensor technologies,
smart devices, wearable gadgets, and communication paradigms. IoT Service Providers (IoSPs)
provide IoT services such as smart cities, virtual and augmented reality and pervasive healthcare.
These services produce a significant amount of time-sensitive data to be processed. IoT devices

r
can not process these data due to resource and energy constraints. Therefore it generates requests
as tasks to process these data to remote servers.
Cloud-Fog-Edge architecture is used to allocate the resources to execute such tasks. In this

er
architecture, Cloud Service Provider (CSP) can offload the task request received from IoSP to Fog
Service Providers (FSPs) to decrease the service delay. The allocation of resources to these tasks
in a commercial three-tier architecture is a complex problem since the Quality of Service (QoS)
pe
requirements of IoT applications and competition among IoSPs and FSPs for the price of the
resources must be considered. The perishable nature of cloud-fog resources, online task requests,
service delay variation, and resource unavailability at the cloud-fog level make allocation more
challenging.
A multi-attribute double auction-based QoS-aware Task Allocation and Scheduling (QoTAS)
is proposed in our work to account for both QoS requirements of tasks and monetary competition
ot

between IoSPs and FSPs. QoTAS has three modules. First is QoTAS-B, which allocates tasks in
batch mode. The second is QoTAS-O, which allocates tasks online, and the third is QoTAS-M,
which handles task migration-related decisions. The remote patient monitoring system is used as a
case study to verify the performance of QoTAS. We consider the tasks performed in remote patient
tn

monitoring systems with their resource and QoS requirements. The Internet behavior is simulated
in Netsim to get network delay between FSP-IoSP and FSP-FSP. We compare QoTAS with existing
work, which shows that QoTAS outperforms the existing work.
Keywords: Internet of Things, Cloud Computing, Task allocation, Perishable resources, Double
rin

auction, Virtual auction, Fog computing, Task migration, Service delay variation, VM failure

1. Introduction
ep

IoT Service Providers (IoSPs) are the entities that offer IoT services like remote patient mon-
itoring, smart homes, and smart parking systems. These service providers collect data from IoT
devices. IoSPs generate task requests to process these data. These tasks can be generated pe-
riodically [1] or sporadically [2]. Because sporadic tasks are created in emergencies, they have
Pr

stringent deadlines; if they are not completed on time, adverse effects may result. IoT devices
may occasionally operate as edge computing devices with limited processing power that can do low
computation-intensive tasks. However, they cannot execute tasks that are highly computationally

Preprint submitted to Pervasive and Mobile Computing July 5, 2023

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 intensive or require a global database. As a result, they request Cloud Service Provider (CSP) to

ed
execute these tasks.
CSP is a remote server that has extensive computational and storage capabilities. CSP can
hold global datasets from various sensors and all historical data. As a result, CSP can process any
tasks generated by IoSPs. However, IoT tasks may be delay sensitive, such as identifying stroke
attacks [2], which must be handled in real-time. These tasks should not be processed on the cloud

iew
since the latency of sending data to the cloud and receiving processed results back exceeds the
task’s deadline, which must be met to have an efficient IoT system.
Fog devices are local servers that provide lower latency from IoT devices than cloud servers [3].
CSPs can have their local servers, which can act as fog devices. However, this architecture is not
scalable since CSP needs to install fog devices everywhere to provide service. Many Fog service
providers (FSPs) are available in the market, such as vXchange [4] and EdgeConneX [5], which

ev
have set up data centers around the world to provide fog computing services. CSPs can directly
use their services and satisfy their clients to complete tasks on time. FSPs are not co-located,
meaning they are scattered across several regions, yet they may be linked. This architecture is
called three-tier Cloud-Fog-Edge architecture.

r
IoSPs have tasks to complete, FSPs have resources to rent, and CSP is a bridge between them
that acts as a broker to match buyers (IoSPs) and sellers (FSPs). IoSPs pay CSPs for providing

er
service, and CSPs pay FSPs. In this architecture, FSPs must register with CSP to rent their
resources. Additionally, IoSPs who wish to utilize the service should register with CSP and submit
requests to CSP to carry out tasks. CSP interacts with FSPs and assigns the most eligible FSP for
the task.
pe
Two pricing schemes are available in the literature on computing technologies [6]: Static and
dynamic pricing. In static pricing, all customers must pay the same fixed price per unit of time
[7]. Using the static price, service providers, as well as customers, cannot get the benefit of the
demand-supply ratio of the market. Dynamic pricing allows a provider to decide the price of the
resources based on the demand and supply in the market [8]. With multiple service providers,
customers can also benefit from competition among service providers. Deciding on a fair price is
ot

difficult in a dynamic pricing scheme for customers and service providers.

In this competitive setting, IoSPs attempt to execute tasks at the lowest possible cost, while
FSPs and CSPs want to maximize their profits through IoSP. In addition to satisfying monetary
tn

competition, IoT applications include quality of service requirements such as deadlines that must be
met during task allocation. It is an optimization problem in which each agent (IoSP, FSP or CSP)
seeks to maximize utility. A multi-attribute double auction mechanism can tackle this optimization
problem in which QoS requirements and prices are considered while matching IoSPs and FSPs [9].
Following task assignment to the most eligible FSP, IoSP may move to another location, the
rin

VM may fail on the server, or the delay between the allocated FSP and the IoSP may vary due to
variations in server queuing delay or network delay due to bit error of link or link down scenario.
In all of these cases, the task must be migrated to another FSP to prevent being penalized by IoSP
if it is not completed after allocation.
ep

In this work, we propose a QoS-aware Task Allocation and Scheduling (QoTAS) that considers
QoS requirements of tasks, competition among IoSPs and FSPs, perishable nature of cloud-fog
resources, online task generation by IoT applications, service delay variation and VM failure at
cloud-fog.
Pr

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 2. Related work

ed
Task allocation and scheduling for three-tier Cloud-Fog-Edge architecture is a classic problem
in which FSP is found that meets the QoS requirements, such as the deadline and priority of a
particular IoT application. Shi et al. [10], and Mihailescu et al. [8] have studied batch task
allocation in three-tier architectures, targeting IoT requirements such as deadline, priority, energy

iew
minimization, and delay minimization. Non-commercial architecture, where a single entity owns
all resources at the fog and cloud levels, was considered in this study. As a result, the price is
not considered while allocating tasks. In contrast, we are considering distributed architecture in
which ownership of resources is distributed. Therefore, while considering QoS requirements for task
allocation, monetary cost also must be considered.
Pham et al. [11] and Nguyen et al. [12] have used a game theory-based approach for task

ev
allocation, which considers price during allocation. However, price discovery is not discussed in
these studies. Stackelberg game-based studies [13] discover the price of resources based on demand
only. Users’ budget or maintenance cost of the seller is not considered while discovering that price
which may lead to negative utility.

r
In a distributed Cloud-Fog-Edge architecture that we are considering, IoSPs, FSPs, and CSPs
share resources by purchasing them from one another. Each has its utility function based on the
cost and payment received. They are all looking to maximize their utility. Moreover, on the other

er
hand, application requirements must also be satisfied. It means there is a trade-off between money
and performance parameters. We need to find a balance between them. Auction is a popular way
to provide fair resource allocation and price discovery in a competitive environment.
Y. Zu. et al. [14], A. Bandyopadhyay et al. [15] and Y. Zhang et al. [16] have used forward
pe
auction for task allocation. Buyers compete to obtain the resources in this scenario. The forward
auction is appropriate when there are many competing buyers but only one seller or when there
is no competition among sellers. In our scenario, however, multiple sellers compete to sell their
resources for the highest possible profit.
In contrast, to a forward auction, multiple sellers compete with each other to offer resources to a
ot

buyer in a reverse auction. Y. Guo et al. [17] and Agrawal et al. [18] suggest reverse auction-based
resource allocation, which satisfies the QoS criteria in IoT applications. This technique only allows
service providers to submit bids.
Both sellers and buyers bid in a double auction. It is a matching problem. According to
tn

the literature, the auctioneer is a separate entity in the double auction. Z. Gao et al. [19], R.
Besharati et al. [20], F. Zhang et al. [21], Peng et al. [9] have proposed a double auction-based
task allocation in a three-tier architecture. Thus, a considerable amount of work is done in task
allocation in three-tier architecture, but all have limitations, as discussed below.
rin

1. Task scheduling:
All of the studies discussed thus far allocate all the resources required by the task in a single
round, resulting in a scarcity of resources in that round, which can only satisfy a limited
number of tasks. Demand may be lower in the next round, and thus some resources will go
ep

unused.

2. Perishable nature of resources:

Furthermore, none have considered the perishable nature of resources when allocating re-
sources. Resources at fog and cloud levels are perishable since their valuation becomes zero
Pr

if it is not allocated. Miyashita et al. [22] and Maria B. et al. [23] have proposed bidding
strategies for sellers and buyers in which buyers lower their bid in the next round if they win
in the current round, and sellers lower their bid as the round nears its end. The allocation

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 algorithm in both works lacks a unique allocation technique for allocating maximum resources

ed
to avoid loss due to perishability.

3. Online task allocation:

Agrawal et al. [18] propose to reverse auction-based task allocation for the IoT fog, which
also meets the requirements for QoS in IoT applications. Only service providers are permitted

iew
to bid in this reverse auction mechanism. Therefore, the budget of users is not considered
during allocation.
In online allocation with the double auction, the main problem we observe in the literature
is finding the price to be paid by the user. Since there is only one user at a time in online
allocation, we do not have anything to compare that bid and decide whether the request
should be accepted.

ev
4. Migration strategies:
Recent studies [24] have considered user or service provider mobility as a reason for delay
variation. They have assumed that due to the mobility of the user or service provider, the

r
distance between the user and the service provider varies, which causes variation in delay.
However, on the internet, the delay is not only dependent on distance but also on the network’s
bandwidth.

er
Network bandwidth may vary due to various reasons such as packet loss, link failure and
congestion in network [25]. Instead of focusing on migration based on the mobility of users or
service providers, in QoTAS-M, we have considered migrations due to delay variation between
pe
users and service providers that can be because of any reason.
Saurez et al. [26] have proposed a proactive migration strategy. However, before deciding to
migrate, we need to check how many portions of the task are completed, the cost of migration,
and the loss if migration is not performed. These parameters are not considered in [26]. Also,
this work uses non-commercial architecture. Therefore, price is not considered for selecting a
new service provider.
ot

In our previous work [27], we proposed an algorithm for batch allocation. However, it performs
only task allocation; task scheduling is not done, so resources are not allocated efficiently. Also, it
tn

used the VCG (Vickrey-Clerk-Grove) price determination mechanism, which sometimes generates
the negative utility of CSP. After that, in [28], we discussed QoTAS-B, which considers QoS re-
quirements, competition among IoSPs and FSPs and the perishable nature of cloud-fog resources.
We extend that work in this paper by adding online allocation, migration strategy and adaptive
delay estimation strategy for allocation. We gave the idea of virtual bidding for online allocation in
rin

[29]. We extend that work for the QoTAS-O module of this work by adding a competitive bidding
strategy for virtual auctions.
The paper is organized as follows: The Problem statement is explained in Section 3. QoTAS is
explained in Section 4. Finally, Section 5 discusses the simulation results, and Section 6 concludes
ep

the results with future scope.

3. Problem statement

We consider a three-tier architecture, as shown in Figure 1. This architecture comprises three

Pr

layers: the Cloud layer, the Fog layer, and the Edge layer. In the Edge layer, N IoSPs and M FSPs
in the Fog layer, where M ≤ N . The resources are modeled as Virtual Machines (VMs) containing
fixed CPU, memory, and network bandwidth. In Figure 1, the data signal denotes delivering input

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 data for tasks and receiving results from the FSP, while the control signal denotes communication

ed
regarding allocation and payments.

iew
r ev
er
Figure 1: Cloud-Fog-Edge architecture

We define each agent’s (IoSP, FSP or CSP) utility function based on the cost of service each
agent charges and the payment received. IoSPs offer services to users of IoT applications. As a
pe
result, IoSPs earn money from those users in order to complete each task. This revenue is the task
valuation for IoSP. Task valuation of k th task of ith IoSP is represented by P Vi,k . Each IoT task
requires V Ri,k VMs, sending Si,k bytes of input data to execute the task. IoSP must pay CSP,
represented by P Ui,k . P Ui,k is decided by CSP based on bid submitted by IoSP BUi,k and auction
mechanism used by CSP. In addition, IoT tasks are real-time tasks. If they are not completed by
the deadline Di,k , IoSPs charges a penalty P Pi,k from CSP based on criticality Ci,k of task [28].
ot

The total revenue generated by an IoSP is the sum of the valuation of all the allocated tasks.
Let τi,k,j be a binary variable that has value one if k th task of ith IoSP is allocated to j th FSP
else, it is zero. Payment to CSP is the sum of the price to be paid by IoSP for all purchased VMs
tn

minus the penalty charged by IoSP if the task is not completed on time. Utility of ith IoSP denoted
by U Ui is the total revenue generated from IoT customers minus the total payment to CSP for all
the allocated tasks. Which can be formulated as Eq. (1)
K X
M
rin

X
U Ui = τi,k,j (P Vi,k − (V Ri,k P Ui,k − P Pi,k )) (1)
k=1 j=1

CSP receives payment from IoSPs for each allocated task. Which can be formulated as CSP
pays to FSP P Fj , which is the price of one unit of VM at j th FSP, which CSP decides based on a
ep

bid of BFj,q and auction mechanism. CSP also charges α fraction of the penalty from FSP if the
task is not completed before the deadline. Payment to FSP is calculated by the total price paid
for VMs purchased minus the α fraction of the penalty charged if the task is not completed before
the deadline.
Pr

After allocation, if the task is migrated to another FSP m, CSP must also pay that FSP. Let
ϕi,k,j,m is binary variable which is equal to one if k th task of ith IoSP is migrate to mth FSP from
j th FSP. In our model, CSP is not charging any brokerage for task allocation, but it generates

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 revenue from the payment received from IoSPs minus payment to FSP and migration cost. Which

ed
is formulated as shown in equation (2):
N X
X K X
M
CU = τi,k,j (V Ri,k (P Ui,k − P Fj ) − (1 − α)P Pi,k − ϕi,k,j,m V Ri,k P Fm ) (2)
i=1 k=1 j=1

iew
FSPs receive payment from CSP for VMs allocated during task allocation and task migration
which is revenue for FSP. It incurs maintenance costs per VM P Cj whether VMs are used or not.
Let V Aj be available VMs at j th FSP. If the task is migrated to mth FSP, j th FSP needs to send
input data. Utility of j th FSP is defined as the total payment received from CSP after deducting
penalty for allocated VMs minus the maintenance cost of all VMs and migration cost. Which is
formulated in Eq. (3).

ev
N X
X K
F Uj = ((τi,k,j (V Ri,k (P Fj − αi P Pi,k ) − V Aj P Cj − ϕi,k,j,m Si,k νj,m )) + ϕi,k,m,j V Ri,k P Fj ) (3)
i=1 k=1

r
Where νj,m is the migration cost of one unit of data from j th FSP to mth FSP. All agents(IoSP,
FSP, or CSP) want to maximize their utility in this competitive environment.

er
IoSPs wish to maximize utility by adjusting the price to CSP P Ui,k , which a bidding strategy can
control. Constraint (1.1) indicates that the task must be completed before the deadline. Constraint
(1.2) states that each task can only be assigned to one FSP, implying that the task cannot be divided
pe
into multiple sub-tasks. (1.3) denotes that each IoSP pays less than its valuation, resulting in a
positive utility.

Subproblem-1: Maximization of IoSP utility

PN
arg max i=1 U Ui (1.0)
P Ui,k
ot

Subject to T Ai,k ≤ Di,k , ∀i, k (1.1)

τi,k,j ∈ {0, 1} (1.2)
P Ui,k < P Vi,k , ∀i, k (1.3)
tn

Each FSP seeks to maximize utility by varying the allocated VMs V A∗j and the price P Fj ,
which its bid can control. Constraint (2.1) states that FSP may not allocate V A∗j more VMs than
are available V Aj since we are not overbooking VMs in our model. Constraint (2.2) states that the
rin

price per VM should be greater than its cost to have positive utility. Constraint (2.3) states that
a migration request should be generated if the penalty exceeds the migration cost.

Subproblem-2: Maximization of FSP utility

PM
arg max j=1 U Fj (2.0)
ep

P Fj ,V A∗j
Subject to V A∗j ≤ V Aj , ∀j (2.1)
P Fj > P Cj , ∀j (2.2)
PN PK
i=1 k=1 τi,k,j ϕi,k,j,m Si,k νj,m < αP Pi,k , ∀i, k, j (2.3)
Pr

CSP wants to maximize utility by matching IoSPs and FSPs, determining their prices, and
deciding whether to migrate tasks. The constraint (3.1) represents that IoSPs’ payments must

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 exceed the price paid to FSPs. Thus, its utility is positive. Constraint (3.2) states that each task

ed
can only be assigned to one FSP, implying that the task cannot be divided into multiple sub-tasks.
Constraint (3.3) states that total available VMs are lesser than total demand. Constraint (3.4)
states that migration should be performed only if the penalty imposed by IoSP is greater than the
migration cost.

iew
Subproblem-3: Maximization of CSP utility
arg max CU (3.0)
τi,k,j ,P Ui,k ,P Fj ,ϕi,k,j,m
PN PK PM
Subject to i=1 k=1 P Ui,k ≥ j=1 P Fj (3.1)
τi,k,j ∈ {0, 1} (3.2)
PM
V Aj < N
P PK
V Ri,k (3.3)
PN PK PMi=1 k=1
i=j

ev
i=1 k=1 j=1 τi,k,j P Pi,k > ϕi,k,j,m V Ri,k P Fm (3.3)

These subproblems are interdependent. IoSPs want to maximize their utility by lowering the

r
price to be paid. However, because of this, it may not receive any resources. Furthermore, the
utility of CSP and FSP may decrease as they receive less payment from IoSP. FSP wishes to
maximize its utility by charging higher fees, which may reduce its allocated resources and IoSP

er
and CSP utility. Thus this problem is an example of a joint optimization problem. It is NP-hard
to maximize the utility of all three nodes simultaneously [30]. Furthermore, the online nature of
tasks, service delay variation and the perishable nature of cloud-fog resources make this problem
pe
more difficult. We propose a heuristic-based solution to solve this problem.

4. QoS-aware task allocation and scheduling

This section proposes a QoS-aware Task Allocation and Scheduling (QoTAS) method, which
consists of three modules: QoTAS-B for batch allocation, QoTAS-O for online allocation, and
ot

QoTAS-M for task migration. As illustrated in Figure 2, CSP bridges IoSPs and FSPs. It stores
the four datasets—IoSP, FSP data, Critical bid and Active tasks. The IoSP dataset contains infor-
mation about IoSPs, such as their location and contextual data. It also keeps track of bandwidth
tn

between the IoSP and each FSP.

The FSP dataset covers FSP-specific information such as location, available VMs, maintenance
costs, VM execution time and bandwidth to other FSPs. The virtual auction generates the critical
bid dataset and contains IoSP and FSP critical bids for various scenarios that may be generated
during the virtual auction procedure. It is utilized in online task allocation. The active tasks
rin

dataset stores information about current active tasks, such as the IoSP id which generated the
task, the id of the assigned FSP, the expected service rate, the current service rate and the eligible
list of FSPs for migration. It is used in the migration module.
The system operates in four different phases. First is the Setup phase; it is performed once
when the system starts up and repeats whenever a new IoSP or FSP joins or leaves. It consists
ep

of two processes, namely registration and virtual auction. During the registration procedure, IoSP
sends I reg info (Message 1.1), which contains location and contextual information about IoSP. CSP
stores all of these details in the IoSP dataset. We assume that FSP provides service for different QoS
guarantee levels. FSP charges differently for different QoS-level services. FSP transmits F reg info
Pr

(Message 1.2), which comprises available VMs V Aj at FSP, the cost of maintaining a VMs P Cj ,
and FSP’s bid for a VM for each q th QoS level BFj,q during registration. All these details are
stored in FSP data.

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 ed
iew
r ev
er

Figure 2: System model

pe
ot
tn
rin
ep
Pr

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 During the virtual auction procedure, IoSPs place virtual bids for different scenarios (Message

ed
2) that may be generated during the actual auction procedure. CSP determines the final price for
IoSPs and FSPs and saves it in the critical bid dataset.
In the allocation phase, IoSP sends task requirements to CSP whenever it wants to execute a
task (Message 3). We assume that an IoSP can generate more than one task, the maximum it can
generate K tasks. Task requirement of ith IoSP for k th task contains [Ri,k , Di,k , Si,k , Ci,k , BUi,k ]

iew
where Ri,k is required resources, Di,k is deadline,Si,k is input datasize, Ci,k is time criticality and
BUi,k is bid of IoSP. When a task request arrives at CSP, its remaining time T Ri,k is calculated by
Equation 4.

T Ri,k = Di,k − max(T Pi,k,j ) (4)

ev
Here, max(T Pi,k,j ) is the maximum predicted service delay by considering the service delay of
all the FSPs to execute this task. If the next batch allocation round starts after T Ri,k unit of time,
the task is allocated online using QoTAS-O. Else, the task is added to the queue (χ) that maintains
task requests for batch allocation.
During the execution phase, IoSPs send input data to the assigned FSP for task execution

r
(Message 5). While the FSP executes the task, the CSP runs the QoTAS-M module to determine
the trigger for migration. Also, if the FSP discovers a migration trigger, it sends it to the CSP

er
(Message 6), and CSP locates a new FSP to migrate the task (Message 7). The FSP transfers
control to the new FSP by delivering all data to the new FSP (Message 8). The task output is
forwarded to IoSP after completing the task(Message 9).
During the Payment phase, the IoSP sends a QoS report containing the actual service delay to
pe
complete the task (Message 10). CSP calculates the penalty based on that report. CSP delivers
the bill to IoSP (Message 11) and payment to FSP using a price established by allocation algorithm
and penalty assessed (Message 12). The dashed arrows in Figure 2 indicates read or write operation
from the datasets.
ot

4.1. QoS-aware Task Allocation and Scheduling-Batch mode (QoTAS-B)

All task requests in queue χ are considered in batch mode allocation. We modify the Allocation
and scheduling algorithm proposed in [28] as discussed below to increase the TCR and utility of
CSP. After calculating candidate FSP according to [28], we calculate the estimated gain P Gi,k of
tn

CSP from IoSP by the total revenue it may be received from IoSP minus the possible penalty that
may be charged. It is formulated in Eq. (5).

P Gi,k = P Ri,k BUi,k − F Pi,k P Pi,k (5)

rin

Here, F Pi,k is the probability that the task may fail. This can be calculated based on the history
of IoSP and the task deadline. P Pi,k is a penalty if this task can not be completed on the deadline.
Tasks are prioritized using estimated gain, unlike [28], which considers the highest penalty task
as the highest prioritized task. In this work, the greater the estimated gain, the more important
ep

that task. As a result, the descending order of P Gi,k is used for all the tasks. If there is a tie
among tasks during sorting, we consider the priority of IoSP assigned during IoSP registration to
break the tie. For example, in a remote patient monitoring system, the criticality of the patient
can be used as the priority of IoSP. We use algorithms proposed in [28] for scheduling tasks, price
determination, and allocation of remaining resources.
Pr

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 4.2. QoS-aware Task Allocation and Scheduling-Online mode (QoTAS-O)

ed
We conduct a virtual auction in the setup phase of the system. Using a virtual auction, we may
obtain a critical price that can be compared to the task’s bid. The virtual auction generates bids
for different scenarios using the competitive bidding (CompBid) strategy proposed in [28]. The
final pricing for IoSP and FSP is calculated for each scenario using batch allocation(QoTAS-B) and

iew
is stored in a table. Let a range of possible normalized load be denoted by L and a range of QoS
level denoted by Q. As shown in Algorithm 1, virtual bids are generated For each normalized load,
nl and QoS level q by IoSPs using CompBid strategy and the price to be paid by IoSP P Unl,q c and
c
payment to FSP P Fnl,q is determined using QoTAS-B and stored in critical bid dataset.

Algorithm 1: Virtual auction

ev
1: for Each Normalized load in L do
2: for Each QoS level in Q do
3: Generate bid using CompBid strategy
4: Perform QoTAS-B
c ,PFc ]

r
5: Save critical prices [P Unl,q nl,q

er
When an online task arrives for allocation, we must extract two factors: normalized load and
QoS level. The demand-supply ratio from the previous round of batch mode allocation is used to
calculate normalized load, and the task’s criticality Ci,k value is used to determine the QoS level.
Once we have these two parameters, we attempt to use a regression model to discover the critical
pe
c , P F c ] from the critical bid dataset. The task is accepted if the online task’s bid
prices [P Unl,q nl,q
c . FSP is found for that task, which has allocated minimum VMs in
exceeds the critical bid P Unl,q
batch allocation and can satisfy the task before the deadline. IoSP must pay IoSP’s critical bid,
c , and FSP receives FSP’s critical bid, P F c . Algorithm 2 shows the working of QoTAS-O.
P Unl,q nl,q

Algorithm 2: QoTAS-O
ot

1: Find normalized load nl for previous batch allocation

2: Find QoS level of task byCi,k
c ,PFc ]
3: Find critical price[P Unl,q
tn

nl,q
c
4: if BUi,k ≥ P Unl,q then
5: Sort Fj s based on V Rj after batch allocation
6: for Each FSP in Fj do
7: if V Aj ≥ V Ri,k and T Pi,k,j ≤ Di,k then
rin

8: Set τi,k,j = 1
9: c
Set P Ui,k = P Unl,q
10: c
Set P Fj = P Fnl,q
11: Break
12: else
ep

13: Reject task request

4.3. QoS-aware Task Allocation and Scheduling- Migration (QoTAS-M)

Pr

The service delay may vary after task assignment to FSP due to IoSP mobility, network delay
and computation delay variability, and VM failure. CSP maintains details of current active tasks in
the active task dataset, available VMs at each FSP, and current network speed between each FSP

10

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 and all other FSPs in the FSP dataset. CSP uses this information to perform proactive migration

ed
before the task’s deadline.
As shown in Algorithm 3, CSP keeps these data up to date for all active tasks and FSPs. This
algorithm takes active tasks and the fog dataset as input and returns a list of eligible FSPs for each
active task. It is assumed that CSP has the most up-to-date information on network speed between
each FSP and all FSPs in the network. For each active task, k of IoSP i is currently allocated at

iew
FSP j; when we perform the migration, all the input data must be transferred to the new FSP.
CSP calculates migration delay to all possible FSPs m, j ̸= m denoted by T Mi,k,m using Equation
6.
Si,k
T Mi,k,m = (6)
Θj,m
Where, Θj,m is network speed between j th FSP and mth FSP. After that, CSP calculates the

ev
maximum migration delay accepted by the task denoted by migration threshold T M ˆ i,k to other
FSP by Equation 7. The task should be migrated only if, after migration, there is at least one
round of execution time available to complete a task before the deadline.

r
T ˆM i,k = Di,k − ct − γ (7)
Here, ct is the current time. Any FSP is called eligible for a task if FSP has required VMs

Algorithm 3: Find migration eligible FSP

Input: Active task data, Fog data
er
available and the migration delay is less than the migration threshold.
pe
Output: List of eligible FSPs for migration
1: for Each active task i, k do
2: Calculate migration threshold T ˆM i,k using Eq. 7
3: for Each FSP m do
4: Calculate migration delay T Mi,k,m using Eq. 6
ot

5: if T Mi,k,m < T ˆM i,k and V Aj ≥ V Ri,k then

6: Add mth FSP into migration eligible list of task
tn

There are three scenarios in which migration may be required. In each scenario, first, we try to
allocate more virtual machines to reduce processing delay. Based on the scenario, extra required
VMs are calculated as follows:
1. Decrement in network speed during input data transfer: While transferring input data to
rin

FSP, the network speed between the IoSP sending the data and the FSP executing the task
is measured. To complete the task before the deadline, the network delay must be less than
Di,k −T Ei,k . T Ei,k is decided by allocation and scheduling algorithm. The following equation
is used to calculate the expected network speed.
ep

Si,k
Θ̂i,j = (8)
Di,k − T Ei,k
A migration trigger is generated if the actual network speed Θi,j exceeds the expected network
speed. In this situation, extra VMs required P R ˆ i,k is the number of VMs that can compensate
Pr

for the difference in a service delay. New network delay TˆN i,k,j can be calculated by
Si,k
TˆN i,k,j = (9)
Θi,j

11

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 We need P Ri,k VMs to achieve execution delay T Ei,k = Di,k − T Ni,k . However, now, since

ed
network delay is updated TˆN i,k,j , which is greater than T Ni,k , we need to allocate more VMs
that compensate for these delay differences. The total number of extra VMs needed for this
network delay is
ˆ
PRˆ i,k = P Ri,k (Di,k − T N i,k,j ) − P Ri,k (10)

iew
Di,k − T Ni,k,j

2. VM failure: If the allocated VM fails after receiving input data and starting task execution,
a migration trigger is generated by FSP. In this case, the same number of VMs is needed
ˆ i,k = P Ri,k
PR (11)

ev
3. Increment in processing delay: CSP keeps track of the average service delay for each type of
completed task. If the task execution time exceeds the average execution time, a migration
trigger is generated. In this case, we need to allocate VMs to complete the task in the next
round since we are already running late than the average service delay. Since we need P Ri,k

r
VMs to complete the task in T Ei,k time, to complete the task in γ unit of time, we need
PR ˆ i,k VMs which is calculated by Eq. (12).

ˆ i,k =
PR
er
P Ri,k γ
(Di,k − T Ni,k )
− P Ri,k

As shown in Algorithm 4, for each of these scenarios, first, we try to find extra VMs required to
(12)
pe
compensate delay difference; if it is not available, then a new eligible FSP is selected, and the
migration cost is less than the penalty charged on the current FSP, then migration is performed.
Here Migration cost includes the payment to the new FSP and data transmission cost from the
current FSP to the new FSP.

Algorithm 4: QoTAS-M
ot

Input: Active task list, Fog info

Output: List of tasks to be migrated
1: for Each currently running task do
tn

2: required VMs=0
3: Calculate expected network speed using Eq. 8
4: if If actual network speed≤expected network speed for ∆ time then
5: Calculate required VMs using Eq. 10
rin

6: else if Current VM fails then

7: Calculate required VMs using Eq. 11
8: else if Current service delay exceeds average delay and task criticality is high then
9: Calculate required VMs using Eq. 10
10: if required VMs!=0 then
ep

11: if required VMs are available at current FSP then

12: Allocate extra FSP
13: else
14: Find new eligible FSP
if Cost of migration ≤ penalty on current FSP then
Pr

15:
16: Migrate to new FSP

12

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 5. Simulation setup and results

ed
For this simulation, we consider using remote patient monitoring task requirements and patient
categories defined in [28]. We implement a scenario with 30 patients, 6 FSPs, and one CSP. Table
1 represents the VM requirement of the
1 displays the simulation parameters. In this case, V Ri,k
2
preprocessing task, and V Ri,k represents the VM requirement of the abnormality detection task.

iew
Table 1: Simulation parameters

Parameter Value
Available VMs at each FSP(V Aj ) 30
Maintainance cost of each VM (P Cj ) N(250,50)

ev
Valuation of each VM by IoSP (P Vi,k ) N(500,100)
1 )
VM requirement of the preprocessing task (V Ri,k 4
2 )
VM requirement of the abnormality detection task (V Ri,k 5
Input data size(Si,k ) N(1000,100)KB
Bandwidth (Θi,j ) N(2,0.5)MBPS

r
Distance (di,j ) N(40,10) m
Propagation speed (θi,j ) 3 × 105 km/s

er
Duration of one round of execution of VM (γ) 10s

The network delay between each node (FSP or IoSP) to all other nodes (FSP or IoSP) can be
calculated using the bandwidth, input data size, distance, and propagation speed values. However,
pe
in a wireless/wired network, the delay can be affected by factors such as background traffic, bit
error rate, link-down situation, etc. We use NetSim to simulate the behavior of a wireless/wired
network. We randomly select a scenario from the above scenarios for the network link between
each IoSPs and all FSPs to get its network behavior.
After this setup, we compare the following parameters in the allocation mechanism:
ot

1. Task Completion Ratio (TCR): The ratio of tasks completed before the deadline to the total
number of requested tasks.

2. Resource Utilization (RU): The ratio of total virtual machines allocated to total virtual ma-
tn

chines available.

3. Average User Utility(UU): The average utility IoSPs calculated using Eq. (1). per task
normalized by the task’s valuation.
rin

4. Average Fog utility (FU): The average utility of FSPs calculated using Eq. (3) per VM
normalized by fog maintenance cost.

5. Cloud utility: It is the utility of the cloud calculated by Eq. (2) normalized by the user’s task
valuation.
ep

6. System Utility (SU): It is the average of Fog utility and Cloud utility.

5.1. Performance of QoTAS-BO

We allocate all the tasks in batch mode only in QoTAS-B. In this experiment, we first divide
Pr

tasks into batch and online tasks. QoTAS-B is used in batch allocation, and QoTAS-O is used for
online allocation. In order to conduct a virtual auction, we create a task set of patients representing
four QoS levels, with the total requirement calculated by the normalized load. Normalized load

13

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 is varied from 0.0 to 1.0 in 0.1-step increments. After creating the task, QoTAS-B algorithm is

ed
executed and saved the QoS level-specific IoSP and FSP prices as critical prices for each normalized
load.
After that, the probability of each IoSP generating a sporadic task, known as sporadic proba-
bility, is varied. The sporadic probability varies from 0 to 1 with a 0.1 step size. The deadline for
sporadic tasks is only 10 seconds. Moreover, batch allocation occurs every 30 seconds. As a result,

iew
all sporadic tasks must be assigned online only; otherwise, the deadline will be over, and the task
will be removed from the batch queue.
Four task allocation algorithms listed below are compared:
1. Batch mode allocation algorithm (QoTAS-B): This maintains a queue of all tasks received
between two allocation periods and performs batch allocation of all tasks in the queue at

ev
periodic intervals.

2. Reverse auction-based online allocation (RAOA): In this method, we implement the reverse
auction-based online allocation proposed in [18], which allocates the task as soon as the
request is received. Buyers are expected to pay, and sellers receive the lowest bid seller.

r
IoSPs are buyers in our case, while FSPs are sellers. As a result, IoSPs must pay the lowest
bid of the FSP. Here, the FSP bid remains constant.

er
3. PreBid: This method assigns tasks as soon as they are received. Payment is decided based
on the price discovery of the previous batch allocation round.

4. QoTAS-BO: In this method, periodic tasks are assigned using QoTAS-B, while sporadic tasks
pe
are assigned using QoTAS-O, with the price determined by virtual auction.
Three scenarios are generated based on the demand for VMs by periodic tasks assigned in batch
mode.

5.1.1. Low load scenario

ot

In this scenario, periodic tasks have taken up 20% of all VMs during batch allocation. As a
result, we also have enough VMs to handle sporadic tasks. When the sporadic probability reaches
one, all users’ generated sporadic tasks use 40% of the total VMs. So, in this circumstance, a lack
tn

of VM is not the cause of task allocation failure.

Figure 3(a) shows that the TCR of QoTAS-B decreases as sporadic probability increases because
as sporadic probability increases, more sporadic tasks are generated. However, QoTAS-B can only
complete periodic tasks because the deadline for sporadic tasks expires before the next batch
allocation round begins. RAOA always assigns tasks and completes them before the deadline
rin

because it assigns tasks as soon as they arrive. As a result, its TCR is the highest. QoTAS-
BO allocates all periodic tasks in batch mode and sporadic tasks online, ensuring that tasks are
completed on time. As a result, it has a TCR of one, just like RAOA. PreBid allocates tasks as soon
as they arrive, but IoSPs bid equal to the previous round’s closing price; after batch allocation, the
ep

demand-supply ratio may differ depending on sporadic tasks generated, resulting in many IoSPs
not being allotted VMs because they bid lower than the current round price from the market. As a
result, its TCR is lower than that of RAOA and QoTAS-BO. Also, as sporadic probability increases,
the TCR decreases because more sporadic task requests arrive, but PreBid cannot allocate most of
them due to IoSP’s lower bid.
Pr

Figure 3(b) demonstrates that QoTAS-B has constant RU since it can only allocate periodic
tasks. Both RAOA and QoTAS-BO distribute all sporadic tasks. Thus, they have equal RU, which
is the maximum. Moreover, as the probability of sporadic tasks increases, more tasks are generated

14

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 ed
iew
(a) Task completion ratio vs. Sporadic probability (b) Resource utilization vs. Sporadic probability

r ev
(c) User utility vs. Sporadic probability
er (d) System utility vs. Sporadic probability
pe
Figure 3: Performance of QoTAS-BO in Low load scenario

and allocated, increasing RU. PreBid can allocate fewer tasks than RAOA and QoTAS-BO; hence,
RU is lower.
During the utility analysis, it is discovered that because QoTAS-B only allocates periodic tasks
ot

and in batch allocation algorithm bid of the IoSP and FSP and price determination depends on the
normalized load and normalized load is constant here which is 0.2, it can be seen from the Figure
3(c) and (d) that UU and SU are both constant here. Also, because PreBid uses the previous batch
tn

round’s bid, it has constant bidding, which means it has constant utilities and is nearly identical
to QoTAS-B.
In contrast, an RAOA IoSP is expected to pay the lowest bid of the FSP. The maintenance cost
determines the FSP bid, which is constant. As a result, regardless of sporadic probability, IoSP is
assumed to pay a constant price for each task. Also, because the FSP bid is lower than the IoSP
rin

valuation, the IoSP has more UU than QoTAS-B and PreBid, where IoSPs were supposed to pay
in proportion to their valuation. As a result of the FSP’s constant bid and the fact that the cloud
utility, in this case, is zero, the SU is likewise constant.
In QoTAS-BO, periodic tasks are assigned in batch mode, whereas sporadic tasks are assigned
ep

here in online mode, which reduces the penalty that would apply if sporadic tasks were assigned
in batch mode and could not be completed before the deadline. As a result, QoTAS-BO has more
system and user utilities than QoTAS-B. Furthermore, in QoTAS-BO, IoSP bids more as sporadic
probability increases, whereas they are supposed to pay based on critical bids generated during the
virtual auction, as opposed to PreBid, where IoSP payment depends on IoSP bids. This critical
Pr

bid also increases as sporadic probability increases, but it is lower than the bids of IoSPs. As a
result, more tasks can be assigned as sporadic probability increases and UU increases. Similarly,
FSPs receive a payment equal to the critical price determined by the virtual auction, which rises

15

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 as the sporadic probability rises. As a result, SU rises as sporadic probability rises.

ed
In conclusion, the task completion rate and RU of QoTAS-BO are equal to those of RAOA;
however, due to its pricing mechanism, QoTAS-BO has 26% more UU and 23% more SU than
RAOA. Compared to PreBid, QoTAS-BO has a TCR that is 18% higher and RU that is 49% more
user- and 35% more SU. QoTAS-BO outperforms QoTAS-B in terms of UU (34%), RU (37%), UU
(51%), and SU (35%).

iew
5.1.2. Medium load scenario
In this case, batch allocation resulted in periodic tasks occupying 50% of all VMs. As a result,
we have 50% more resources to handle sporadic tasks. When the sporadic probability reaches one,
all users’ generated sporadic tasks will use 100% of the available resources. As a result, in this case,
a lack of VM is not the cause of task allocation failure. As illustrated in the figure, the behavior

r ev
er
pe
(a) Task completion ratio vs. Sporadic probability (b) Resource utilization vs. Sporadic probability
ot
tn

(c) User utility vs. Sporadic probability (d) System utility vs. Sporadic probability

Figure 4: Performance of QoTAS-BO in Medium load scenario

rin

of QoTAS-B and PreBid is the same as in the low-load scenario. In this scenario, RAOA allocates
the most tasks because it allocates tasks as soon as they arrive without first checking the IoSP bid.
As a result, its task allocation ratio and resource utilization are the highest. Its TCR decreases as
ep

sporadic probability increases because as sporadic probability increases, more VMs are occupied,
causing service delay variability at FSP and some tasks not being completed on time. QoTAS-BO,
on the other hand, allocates fewer tasks than RAOA because the FSP bid is higher at medium than
low load. Even with this, IoSP bid higher in medium load scenarios than in low load scenarios.
However, IoSP frequently fails to match FSP’s bid. As a result, its TCR and RU are lower than
Pr

RAOA’s.
The figure shows that the UU and SU of RAOA are the same as low load because, in that
method, the price is determined by the FSP bid, which is almost constant here. The UU and SU

16

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 trends of QoTAS-B, PreBid, and QoTAS-BO are similar to low load. However, the absolute value

ed
of UU is reduced because higher loads require them to pay more, and there are more chances of
tasks failing, which causes penalties and reduces UU. Similarly, SU is lower than under low load
due to the penalty imposed by task failure.
In conclusion, compared to RAOA, QoTAS-BO has a 7% lower TCR and a 9% lower RU.
Moreover, compared to RAOA, QoTAS-BO has 7% more excellent SU and 3% less UU. Comparing

iew
QoTAS-BO and PreBid reveals that the latter has 11% higher TCR and RU, as well as 42% higher
user and 25% higher SU. QoTAS-BO has 26% higher UU, 27% higher RU, 39% higher UU, and
21% higher SU compared to QoTAS-B.

5.1.3. High load scenario

In this case, batch allocation resulted in periodic tasks occupying 90% of all VMs. As a result,

ev
we have 10% more resources to handle sporadic tasks. As a result, in this case, a lack of VM is the
main cause of task allocation failure. The results show that QoTAS-B, PreBid, and QoTAS-BO

r
er
pe
(a) Task completion ratio vs. Sporadic probability (b) Resource utilization vs. Sporadic probability
ot
tn
rin

(c) User utility vs. Sporadic probability (d) System utility vs. Sporadic probability

Figure 5: Performance of QoTAS-BO in High load scenario

cannot allocate sporadic tasks because, in this high-load scenario, the FSP bid is exceptionally
ep

high, and IoSPs cannot match them. As a result, it can be observed from Figure 5 that the TCR,
RU, and utilities of all three algorithms are the same. RAOA allocation, on the other hand, is
determined by the FSP bid, which is constant. As a result, it behaves the same in low, medium,
and high load scenarios. As a result, RAOA performs better in this scenario than the other three
algorithms. However, as sporadic probability increases due to a lack of VMs, the TCR of all four
Pr

methods decreases.
QoTAS-B, QoTAS-BO, and PreBid all perform equally well under high load conditions, but aa
RAOA beats them by having a 14% higher TCR, a 14% higher RU, a 25% higher UU, and a 14%

17

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 higher SU.

ed
5.2. Performance of QoTAS-BM
In this experiment, the virtual machine failure situation is simulated. The virtual machine
failure probability (fail prob) varies by 0.01 to 0.1 with 0.01 stepsize. This means maximum it can
have 10% of VM failure, which is the practical scenario. We simulate three scenarios high load

iew
(NL=0.9), medium load (NL=0.5) and low load (NL=0.2). From the results, we observe that in
low and medium load scenarios, extra VMs are available on the same FSP; therefore, migration is
not performed. Therefore we analyze the high-load scenario in detail.

r ev
(a) Task failure fraction in high load

er
pe
ot

(b) User utility in high load (c) System utility in high load

Figure 6: Performance of QoTAS-BM

tn

We compare QoTAS-B, which does not perform the migration, QoTAS-BM with a medium
deadline and QoTAS-BM with a strict deadline. The task failure fraction is the one minus the TCR.
As shown in Figure 6(a), as the failure probability increases, the task failure fraction increases for
all three approaches. QoTAS-B has the highest task failure fraction since it does not perform the
migration. QoTAS-BM, with a medium deadline, has more time to perform migration than the
rin

strict deadline. Therefore, it performs more migration, leading to a lesser task failure fraction than
QoTAS-BM with strict deadlines.
As shown in Figure 6(b), QoTAS-BM with the medium deadline has a maximum UU than
the other two since it performs more migration compared to the other two and more tasks can be
ep

completed. Also, QoTAS-B has the minimum UU since it does not perform the migration. It is also
observed that UU decreases as fail prob increases since fewer migrations are performed compared
to VM failure.
As shown in Figure 6(c), QoTAS-BM with the medium deadline has a maximum SU than the
other two since it performs maximum migration compared to the other two, which causes a lesser
Pr

penalty. Also, QoTAS-B has the least SU since it performs the least migration, which causes a
maximum penalty. It is also observed that SU decreases as fail prob increases since fewer migrations
are performed than VM failure, which causes more penalties and reduces SU.

18

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 6. Conclusion and Future work

ed
QoS-aware task allocation and scheduling in distributed Cloud-Fog-Edge architecture is a chal-
lenging problem due to the problem of finding equilibrium in the competition of service providers
and IoSPs with ensuring this equilibrium solution satisfies the QoS requirements of tasks. The
online nature of tasks, perishable nature of resources, dynamic nature of the network, variability of

iew
service rate at cloud-fog and scarcity of cloud-fog resources make this problem more challenging.
We solve this problem by solving three sub-problems. First, QoTAS-B does efficient batch
allocation and considers QoS requirements and monetary competition among service providers and
IoSPs. Second, QoTAS-O is an algorithm for online task allocation using virtual bidding, which
maximizes the utility of service providers and TCR. Third, QoTAS-M migrates tasks to another
FSP or allocates more VMs to the same FSP if the delay of the currently active task is increased

ev
more than expected.
The remote patient monitoring system is used as a case study to verify the performance of
QoTAS. We compare QoTAS-BO, which does batch allocation using QoTAS-B and online allocation
using QoTAS-O, with the RAOA algorithm used in [18], QoTAS-B and PreBid. In the low load

r
scenario, results indicate that the TCR and RU of QoTAS-BO are equal to those of RAOA; however,
due to its pricing mechanism, QoTAS-BO has 26% more UU and 23% more SU than RAOA.
Compared to PreBid, QoTAS-BO has a TCR of 18% higher and RU of 49% more UU- and 35%

(35%). er
more SU. QoTAS-BO outperforms QoTAS-B in terms of UU (34%), RU (37%), UU (51%), and SU

In the medium load scenario, the results indicate that compared to RAOA, QoTAS-BO has
pe
a 7% lower TCR and a 9% lower RU. Moreover, compared to RAOA, QoTAS-BO has 7% more
excellent SU and 3% less UU. Comparing QoTAS-BO and PreBid reveals that the latter has 11%
higher job completion rates and RU, as well as 42% higher user and 25% higher SU. QoTAS-BO
has 26% higher UU, 27% higher RU, 39% higher UU, and 21% higher SU compared to QoTAS-B.
In the high-load scenario, the results indicate that QoTAS-B, QoTAS-BO, and PreBid perform
the same. However, RAOA beats them by having a 14% higher TCR, a 14% higher RU, a 25%
ot

higher UU, and a 14% higher SU. Also, we compare QoTAS-BM with QOTAS-B, and results show
that the migration strategy reduces task failure fraction and increases user and SU.
QoTAS-B allocates resources to all the tasks in batch mode. Some of them are periodic tasks
that are repeated at a fixed interval. In future work, contract-based allocation can be done for such
tn

periodic tasks with reservation of resources. Also, a different pricing scheme for such contracts can
be proposed, which includes discount schemes for more extended contracts or more quantities of
resources. A virtual bidding-based online task allocation model is proposed in this work, which
performs an online auction. In the future, we can use a machine learning algorithm to decide the
rin

price of the VM in different situations using historical data instead of doing a static virtual auction
once when system starts.

References
ep

[1] P. Verma, S. K. Sood, Fog assisted-iot enabled patient health monitoring in smart homes,
IEEE Internet of Things Journal (2018).

[2] Y. Cao, S. Chen, P. Hou, D. Brown, Fast: A fog computing assisted distributed analytics
system to monitor fall for stroke mitigation, in: 2015 IEEE International Conference on Net-
Pr

working, Architecture and Storage (NAS), IEEE, 2015, pp. 2–11.

19

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 [3] K. Bilal, O. Khalid, A. Erbad, S. U. Khan, Potentials, trends, and prospects in edge tech-

ed
nologies: Fog, cloudlet, mobile edge, and micro data centers, Computer Networks 130 (2018)
94–120.

[4] vXchange, https://gcnsolutions.com/our-technology-partners/vxchange, [Online; ac-

cessed 27-12-2022] (2022).

iew
[5] edgeConneX, https://www.edgeconnex.com/, [Online; accessed 27-12-2022] (2022).

[6] G. Baranwal, D. Kumar, Z. Raza, D. P. Vidyarthi, Auction based resource provisioning in

cloud computing, Springer, 2018.

[7] S. Chaisiri, B.-S. Lee, D. Niyato, Optimization of resource provisioning cost in cloud comput-

ev
ing, IEEE transactions on services Computing 5 (2) (2011) 164–177.

[8] H. A. Alameddine, S. Sharafeddine, S. Sebbah, S. Ayoubi, C. Assi, Dynamic task offloading

and scheduling for low-latency iot services in multi-access edge computing, IEEE Journal on
Selected Areas in Communications 37 (3) (2019) 668–682.

r
[9] X. Peng, K. Ota, M. Dong, Multiattribute-based double auction toward resource allocation in
vehicular fog computing, IEEE Internet of Things Journal 7 (4) (2020) 3094–3103.

er
[10] Y. Shi, S. Chen, X. Xu, Maga: A mobility-aware computation offloading decision for dis-
tributed mobile cloud computing, IEEE Internet of Things Journal 5 (1) (2017) 164–174.
pe
[11] X.-Q. Pham, T.-D. Nguyen, V. Nguyen, E.-N. Huh, Joint node selection and resource allocation
for task offloading in scalable vehicle-assisted multi-access edge computing, Symmetry 11 (1)
(2019) 58.

[12] D. T. Nguyen, L. B. Le, V. Bhargava, Edge computing resource procurement: An online

optimization approach, in: 2018 IEEE 4th World Forum on Internet of Things (WF-IoT),
ot

IEEE, 2018, pp. 807–812.

[13] N. Joshi, S. Srivastava, Task allocation in three tier fog iot architecture for patient monitoring
system using stackelberg game and matching algorithm, in: 2019 IEEE International Con-
tn

ference on Advanced Networks and Telecommunications Systems (ANTS), IEEE, 2019, pp.
1–6.

[14] Y. Zu, F. Shen, F. Yan, Y. Yang, Y. Zhang, Z. Bu, L. Shen, An auction-based mechanism
rin

for task offloading in fog networks, in: 2019 IEEE 30th Annual International Symposium on
Personal, Indoor and Mobile Radio Communications (PIMRC), IEEE, 2019, pp. 1–6.

[15] A. Bandyopadhyay, T. S. Roy, V. Sarkar, S. Mallik, Combinatorial auction-based fog service

allocation mechanism for iot applications, in: 2020 10th International Conference on Cloud
ep

Computing, Data Science & Engineering (Confluence), IEEE, 2020, pp. 518–524.

[16] Y. Zhang, C.-Y. Wang, H.-Y. Wei, Parking reservation auction for parked vehicle assistance in
vehicular fog computing, IEEE Transactions on Vehicular Technology 68 (4) (2019) 3126–3139.

[17] Y. Guo, T. Saito, R. Oma, S. Nakamura, T. Enokido, M. Takizawa, Distributed approach to

Pr

fog computing with auction method, in: International Conference on Advanced Information
Networking and Applications, Springer, 2020, pp. 268–275.

20

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500
 [18] A. Aggarwal, N. Kumar, D. P. Vidyarthi, R. Buyya, Fog-integrated cloud architecture enabled

ed
multi-attribute combinatorial reverse auctioning framework, Simulation Modelling Practice
and Theory 109 (2021) 102307.

[19] Z. Gao, C. Yao, K. Xiao, Z. Mo, Q. Wang, Y. Yang, A real-time task offloading strategy based
on double auction for optimal resource allocation in edge computing, in: 2019 7th International

iew
Conference on Future Internet of Things and Cloud (FiCloud), IEEE, 2019, pp. 9–16.

[20] R. Besharati, M. H. Rezvani, A prototype auction-based mechanism for computation offload-

ing in fog-cloud environments, in: 2019 5th conference on knowledge based engineering and
innovation (KBEI), IEEE, 2019, pp. 542–547.

[21] F. Zhang, Z. Tang, M. Chen, X. Zhou, W. Jia, A dynamic resource overbooking mechanism

ev
in fog computing, in: 2018 IEEE 15th International Conference on Mobile Ad Hoc and Sensor
Systems (MASS), IEEE, 2018, pp. 89–97.

[22] K. Miyashita, Online double auction mechanism for perishable goods, Electronic Commerce

r
Research and Applications 13 (5) (2014) 355–367.

[23] M. B. Safianowska, R. Gdowski, C. Huang, Preventing market collapse in auctions for perish-

(2017) 1550147717743693. er
able internet of things resources, International Journal of Distributed Sensor Networks 13 (11)

[24] D. Gonçalves, K. Velasquez, M. Curado, L. Bittencourt, E. Madeira, Proactive virtual machine

pe
migration in fog environments, in: 2018 IEEE Symposium on Computers and Communications
(ISCC), IEEE, 2018, pp. 00742–00745.

[25] B.-J. Chang, S.-Y. Lin, J.-Y. Jin, Liad: Adaptive bandwidth prediction based logarithmic
increase adaptive decrease for tcp congestion control in heterogeneous wireless networks, Com-
puter Networks 53 (14) (2009) 2566–2585.
ot

[26] E. Saurez, K. Hong, D. Lillethun, U. Ramachandran, B. Ottenwälder, Incremental deployment

and migration of geo-distributed situation awareness applications in the fog, in: Proceedings
of the 10th ACM International Conference on Distributed and Event-based Systems, 2016, pp.
tn

258–269.

[27] N. Joshi, S. Srivastava, Auction-based deadline and priority enabled resource allocation in
fog-iot architecture, in: 2020 Futuristic Trends in Network and Communication Technolo-
gies(FTNCT), Springer, 2020.
rin

[28] N. Joshi., S. Srivastava., Qos-aware task allocation and scheduling in three-tier cloud-fog-iot
architecture using double auction, in: Proceedings of the 13th International Conference on
Cloud Computing and Services Science - CLOSER, INSTICC, SciTePress, 2023, pp. 253–260.
doi:10.5220/0011967400003488.
ep

[29] N. Joshi, S. Srivastava, Online task allocation and scheduling in fog iot using virtual bidding,
IEEE Region 10 Humanitarian Technology Conference (2022).

[30] H. Zhang, Y. Xiao, S. Bu, D. Niyato, F. R. Yu, Z. Han, Computing resource allocation in
Pr

three-tier iot fog networks: A joint optimization approach combining stackelberg game and
matching, IEEE Internet of Things Journal 4 (5) (2017) 1204–1215.

21

This preprint research paper has not been peer reviewed. Electronic copy available at: https://ssrn.com/abstract=4515500