1.1 Research statement

Computation offloading, the manner in which resource-intensive tasks are migrated from a resource-constrained device to a resource-rich infrastructure, is a crucial design issue in CEE systems [8]. In this paper, we are devoted to developing efficient CEE offloading strategies that are aware of load balance. More specifically, we consider the following problem:

1. Load balance -aware offloading (LBAO) problem: Consider a CEE system composed of a cloud center, multiple edge servers, and multiple end-device collections. Suppose the task producing rate of each end-device collection is known or predictable. Suppose load balance is available in the CEE system. Then, for a finite time horizon, how to collaboratively and dynamically determine the cloud offloading rates of edge servers and the many-to-many edge offloading proportions between end-device collections and edge servers, such that the total task latency is minimized?

1.2 Contribution

To address the LBAO problem, our contributions are as follows.

• On mathematical modeling, we propose a load evolution model to characterize the influences of different CEE offloading strategies on a CEE system, establish a latency model as the performance criterion of CEE offloading strategies, and reduce the LBAO problem to an optimal control model.
• On problem solving, we analyze the feasibility of typical optimal control numerical methods in solving the LBAO problem. Then, based on the framework of genetic algorithm (GA) [9], we develop a numerical algorithm called the LBAO algorithm to solve the LBAO problem, and make a rough analysis of the time complexity of the LBAO algorithm.
• On simulations, we perform a series of numerical experiments to verify the proposed LBAO algorithm. First, we discuss the parameter setting of our experiments. Second, we investigate the optimal configuration of the LBAO algorithm. Third, by comparing the LBAO algorithm with other commonly used methods, we examine the performance of the LBAO algorithm. Finally, we give insight into the influence of load balance in CEE collaborative offloading.

The remainder of this paper is organized in the following manner. Section 2 reviews the related work. Section 3 presents the mathematical modeling of the LBAO problem. Section 4 discusses the solution to the LBAO problem. Section 5 shows numerical experiments. Finally, this paper is closed by Section 6.

3.1 Basic terms and notations

Let us consider a CEE system composed of a remote cloud center, M edge servers, and N collections of end devices, as illustrated in Fig 3. Denote the set of the M edge servers by S = {s₁, …, s_M} and the set of the N end-device collections by D = {d₁, …, d_N}.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 3. Illustration of notations.

https://doi.org/10.1371/journal.pone.0296897.g003

Consider a finite time horizon [0, T]. At any time t ∈ [0, T], denote α_i(t) as the task producing rate of the end-device collection d_i. Denote x_ij(t) as the proportion of tasks offloaded from the end-device collection d_i to the edge server s_j at time t. By definition, holds for all i and t. We refer to the function x(t) = [x_ij(t)]_N×M, 0 ≤ t ≤ T, as the edge offloading strategy. At time t, denote l_j(t) as the load (i.e., the length of the task queue) of the edge server s_j and l₀(t) as the load of the cloud center. Then, we refer to the function l(t) = (l₀(t), l₁(t), …, l_M(t)), 0 ≤ t ≤ T, as the load evolution trajectory.

Once tasks have arrived at the queue of an edge server, they will be processed locally, migrated to other edge servers through a load balance scheme, or further offloaded to the cloud center for remote assistance. Suppose at any time, the task executing speed of a server is relatively stable. Thus, denote β_j as the average task processing rate of the edge server s_j and β₀ as that of the cloud center. Also, denote the load balance scheme by f such that at time t, the edge server s_i will migrate its own tasks to the edge server s_j at the rate of f(i, j, l(t), t). Because it is no need for an edge server to migrate its own tasks to itself, let f(i, i, l(t), t) = 0 for all i. Moreover, denote y_j(t) as the cloud offloading rate of the edge server s_j at time t. Then, we refer to the function y(t) = (y₁(t), …, y_M(t)), 0 ≤ t ≤ T, as the cloud offloading strategy. Denote y_max as the common maximum of cloud offloading rates.

Based on the above discussions, we combine together the edge offloading strategy x and cloud offloading strategy y, and refer to the function pair (x(t), y(t)), 0 ≤ t ≤ T, as the CEE offloading strategy. Clearly, the feasible set of CEE offloading strategies is (1)

Remark 1 In this paper, the user mobility in edge computing is presented by the time-varying task producing rates α_i(t). To explain that, let us introduce a numerical example as follows. Denote as the average task producing rate of an end device at any time. Suppose there are n_i and n_j devices within the collections d_i and d_j at time t, respectively. Then, the task producing rates at time t are and . If there are Δn devices moving from d_i to d_j during the time interval [t, t + Δt], then the task producing rates at time t + Δt will be and . A diagram illustrating the above scenario is shown in Fig 4.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 4. Illustration of user mobility.

https://doi.org/10.1371/journal.pone.0296897.g004

3.2 Load evolution model

Next, let us investigate the relationship between the CEE offloading strategy (x, y) and the load evolution trajectory l.

Suppose each server has a task queue of infinite length. In this paper, we refer to the term “load dynamics” as the trajectories of load changes on all servers in a CEE system. Below, we analyze the load dynamics of a CEE system.

According to the discussions in the previous subsection, the load of an edge server is determined by the following four aspects. Firstly, if the queue of the server is not empty, the load of the server will constantly decrease because tasks on the queue are being processed by the server. Secondly, the load of the server will increase because the server is receiving tasks from end devices. Thirdly, due to the load balance scheme, the server will migrate its own tasks to other servers or receive tasks from other servers. Finally, due to cloud offloading, the load will reduce if not empty.

Different from the case of edge servers, the load of the cloud center is only determined by the following two aspects. Firstly, if the queue of the cloud center is not empty, the load of the cloud center will decrease because of task executing. Secondly, because of cloud offloading, the load of the cloud center will increase.

Based on the above analysis, we derive a dynamical system in Theorem 1 to characterize the load dynamics of edge servers and the cloud center.

Theorem 1 Denote the initial load distribution of the CEE system by L₀. Then, the load evolution trajectory l under the control of the CEE offloading strategy (x, y) satisfies the dynamical system (2). (2) where Γ(0) = 0, Γ(x) = 1, ∀x > 0.

Proof 1 Let Δt be a variation of time. Consider the tiny time interval [t, t + Δt]. In this time interval, the load of the cloud center will increase by because of cloud offloading and meanwhile decrease by Γ(l₀(t))β₀Δt because of task processing. Thus, the load of the cloud center at time t + Δt will be (3) Because (4) the first equation in the dynamical system (2) is obtained by direction calculation.

Similarly, during the time interval [t, t + Δt], the load of the edge server s_j will increase by due to edge offloading, decrease by Γ(l_j(t))β_jΔt and Γ(l_j(t))y_j(t)Δt due to task consumption and cloud offloading, respectively, and change by due to load balance. Because (5) and (6) the remaining equations in the dynamical system (2) are obtained from direct calculation. The proof is complete.

The dynamical system (2) reveals the relationship between the CEE offloading strategy (x, y) and the load evolution trajectory l, with which we can predict the load dynamics of the CEE system under an arbitrary CEE offloading strategy. Thus, we refer to this dynamical system as the load evolution model.

To help understand the proposed load evolution model, we provide a simple numerical example as follows. Consider a tiny CEE system composed of only a cloud center, two edge servers and two device collections, as shown in Fig 5. Let a second be a unit time. Suppose the task executing rates are β₀ = β₁ = β₂ = 10 tasks per second (tps). Suppose the tasks producing rates are α₁(t) = α₂(t) ≡ 100 tps. Suppose the initial load distribution is L₀ = (l₀(0), l₁(0), l₂(0)) = (100, 200, 300) tasks. Suppose the edge offloading strategy is x₁₁(t) = x₂₁(t) ≡ 0.2, x₁₂(t) = x₂₂(t) ≡ 0.8. Suppose the cloud offloading strategy is y₁(t) ≡ 10, y₂(t) ≡ 0 tps. Suppose the maximum of task migration rate is f_max = 10 tps, and the load balance scheme is presented by the function (7)

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 5. Simple numerical example for load evolution model.

https://doi.org/10.1371/journal.pone.0296897.g005

Then, during the time interval [0, 1], there are α₁(0)x₁₁(0) = 20 tasks offloaded from the device d₁ to the edge server s₁, α₁(0)x₁₂(0) = 80 tasks from d₁ to s₂, α₂(0)x₂₁(0) = 20 tasks from d₂ to s₁, and α₂(0)x₂₂(0) = 80 tasks from d₂ to s₂. Meanwhile, because the edge server s₂ has higher load than s₁, i.e., l₂(0) > l₁(0), there are f(2, 1, l(0), 0) = 10 tasks migrated from s₂ to s₁ for load balance. Besides, there are y₁(0) = 10 tasks offloaded from the edge server s₁ to the cloud center. In addition, there are β₁ = 10 tasks processed by the edge server s₁, β₂ = 10 tasks by s₂.

As a consequence, during the time interval [0, 1], the load of the edge server s₁ will change by (8) the load of the edge server s₂ will change by (9) and the load of the cloud center will change by (10)

3.3 Latency model

Next, we need to establish a performance model to evaluate different CEE offloading strategies, so that we can have a criterion to select the optimal strategy from its feasible set.

In this paper, we consider the overall latency of the CEE system as a performance metric of CEE offloading strategies, as low latency is the most important feature of edge computing [30]. Specifically, we consider the following two types of latency: (i) task queuing latency occurred at edge servers and the cloud center; (ii) task propagation latency caused by edge offloading, cloud offloading, and the task migration for load balance.

To achieve that, let us consider the simplified communication model shown in Fig 6. Suppose each (cloud or edge) server contains a task queue and a business model responsible for handling tasks. Tasks arriving at a server will firstly be restored on the task queue and then be processed by the business model. Suppose the time interval [0, T] is short enough such that the network environment in this period is relatively stable. Denote D^d as the average propagation delay for offloading one task from an end device to an edge server through the access network, i.e., the time within which a task is transmitted from an end device to the task queue of an edge server. Denote as the average propagation delay for migrating one task from the edge server s_i to the edge server s_j through the core network, i.e., the time within which a task is transmitted from the task queue of the server s_i to the task queue of the server s_j. Denote as the average propagation delay for offloading one task from the edge server s_j to the cloud center through the Internet, i.e., the time within which a task is transmitted from the task queue of the server s_j to the task queue of the cloud server. Then, the overall latency of the CEE system is calculated in Theorem 2.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 6. Simplified communication model of CEE systems.

https://doi.org/10.1371/journal.pone.0296897.g006

Theorem 2 Given a CEE offloading strategy (x, y), the overall latency of the CEE system is (11)

Proof 2 Firstly, we quantify the task queuing latency. It is known that at time t, the queue length of the edge server s_j is l_j(t) and that of the cloud center is l₀(t). Thus, during the time horizon [0, T], the total time of all tasks staying in the queue of the server s_j is and that of the cloud center is . Therefore, the overall queuing latency of the CEE system in [0, T] is (12)

Secondly, we quantify the task propagation latency. At time t, tasks are offloaded from end devices to edge servers at the total rate of . Therefore, during the time interval [0, T], the total latency of edge offloading is (13)

Also, at time t, tasks are offloaded from the edge server s_j to the cloud center at the rate of Γ(l_j(t))y_j(t). Hence, in the time interval [0, T], the total latency of cloud offloading is (14)

In addition, at time t, tasks in the edge server s_i are migrated to the server s_j at the rate of f(i, j, l(t), t). Accordingly, in the time interval [0, T], the total latency of task migration is (15)

Combining the above discussions, we obtain the result by directly calculating (16)

The proof is complete.

We refer to Eq (11) as the latency model. A better CEE offloading strategy should result in less latency.

3.4 Optimal control problem

Now, we are ready to formulate an optimization model to describe the LBAO problem, with the CEE offloading strategy as the decision variable, the latency model (11) as the objective functional, and the load evolution model (2) as a constraint. (17)

The above optimization problem is a continuous-time optimal control problem [31]. After solving it, we will attain the CEE offloading strategy that minimizes the overall latency of the CEE system.

4.1 Analysis of feasible numerical methods

Recall that the problem (17) is a continuous-time optimal control model. As the survey [32] reports, numerical methods to solve a continuous-time optimal control problem can be divided into two categories: indirect methods and direct methods. In an indirect method, a set of necessary conditions of optimality will be derived and then the oringinal optimal control problem will be equivalently transformed to a multi-point boundary value (MPBV) problem [33]. On this basis, a proper iterative algorithm will be developed to solve the MPBV problem, and a candidate optimal solution satisfying all the known necessary conditions of optimality will be attained. When the original optimal control problem is extremely simple, indirect methods can perform well with regard to solution accuracy and algorithm complexity. However, if the original optimal control problem is high-dimensional and complex, it would be very difficult to guess a proper initial solution for iteratively solving the MPBV problem. Thus, indirect methods are less common than direct methods [34].

Contrary to indirect methods, direct methods suggest treating optimal control problems as nonlinear optimization problems. In a direct method, time-varying decision variables will be represented (or approximated) by some kind of static parameters, and then the original optimal control problem will be addressed by using well-known optimization techniques. Compared with indirect methods, direct methods do not rely on the optimality necessary conditions of the original optimal control problem and is therefore more versatile in practical applications. Thus, in this paper, we intend to address the optimal control model (17) through a direct method.

The survey [32] also points out that direct methods can be further classified into two categories: nonlinear programming (NLP) -based methods and heuristic-based methods. For simple optimal control models or the cases where the control and state variables are low dimensional, NLP-based methods can achieve good performance. However, NLP-based methods may not be suitable to solve the optimal control model (17) due to the heavy dependence on function approximation. Specifically, with regard to the optimal control model (17), NLP-based methods require using four interpolation polynomials to approximate the strategies x(t) and y(t), the differential equations of the load evolution trajectory l(t), and the definite integration of the latency model J. Because polynomial interpolation will inevitably produce errors, the solution of the approximate problem would deviate from the solution of the original optimal control problem (17). Thus, an appropriate method should reduce the dependence on function approximation as much as possible.

Fortunately, heuristic-based methods, which require only the approximation for the decision functions x(t) and y(t), provide a promising way to solve the LBAO problem. Therefore, in this paper we solve the optimal control model (17) through a heuristic-based method. GA [9] is a commonly used meta-heuristic method to find satisfactory solutions to a complex optimization problem. As the performance of GA has been widely proven, in the subsequent subsections, we apply GA to solve the optimal control problem (17). Specifically, we proceed into the following four steps. First, design an encoding scheme to represent CEE offloading strategies by chromosomes (i.e., a set of parameters), and design a decoding scheme to safely map chromosomes to their corresponding CEE offloading strategies, so as to ensure the resulting CEE offloading strategies must satisfy the feasible set (1). Second, design an initialization scheme to generate random feasible chromosomes. Third, design a fitness evaluation scheme to select high-quality chromosomes. Finally, design a crossover-mutation operator to produce better chromosomes from the existing ones. The details are as follows.

4.2 Encoding and decoding

An encoding scheme is responsible for transferring a CEE offloading strategy to a set of controllable parameters called a chromosome. In this paper, we use the widely adopted Legendre-Gauss (LG) method [35], which has been proven to be an accurate and efficient discretization technique. Specifically, we proceed into the following three steps.

First, we map the time interval t ∈ [0, T] to τ ∈ [−1, 1] by (18)

Second, we determine an integer n and select n collocation points [35] by solving the roots of the equation P_n(τ) = 0, where P_n(τ) is the Legendre polynomial [36]. Denote the resulting n collocation points by (τ₁, …, τ_n).

Third, we approximate the CEE offloading strategy (x, y) by (19) where L_k(τ) are the Lagrange polynomials [37] (20)

It follows from observation that x_ij(τ) = X_ij(τ) and y_j(τ) = Y_j(τ) hold true for all the collocation points τ = τ₁, …, τ_n. This way, the approximate CEE offloading strategy (X, Y) is determined by all the fixed points x_ij(τ_k) and y_j(τ_k), where i = 1, …, N, j = 1, …, M, k = 1, …, n.

Therefore, we define a chromosome as an [(N + 1) × (M × n)]-dim matrix (21)

After designing the encoding scheme, we need a decoding scheme to map a chromosome to its corresponding CEE offloading strategy. As the encoding scheme is an approximate mapping, a challenge in decoding is to ensure the resulting CEE offloading strategy must satisfy the feasible set (1). To this end, a heuristic decoding scheme is shown in Algorithm 1. The main idea of this heuristic algorithm is straightforward. First, we forcefully make the parts of x and y that exceed their upper and lower bounds become their upper and lower bounds. Second, for the parts of x that do not satisfy the conditions , we modify these parts through normalization.

Algorithm 1 Decoding

Input: A chromosome c.

Output: A CEE offloading strategy (x, y).

1: // Below, calculate the approximate functions.

2: Calculate (X, Y) with the chromosome c from Eqs (19) and (21).

3: // Below, ensure the conditions 0 ≤ x_ij(t) ≤ 1, ∀i, j.

4: for i ← 1: N

5:  for j ← 1: M

6:   .

7: // Below, ensure the conditions , for alli.

8: for i ← 1: N

9:  if

10:   for j ← 1: M

11:    .

12:  else

13:   for j ← 1: M do

14:    .

15: // Below, ensure the conditions 0 ≤ y_j(t) ≤ y_max, for allj.

16: for j ← 1: M do

17:  y_j(t) ← min{y_max, max{0, Y_j(t)}}, 0 ≤ t ≤ T.

18: // This way, (x, y) must satisfy the feasible set (1). Thus, return it as a result.

19: return (x, y).

4.3 Initialization

An initialization scheme is responsible for generating random chromosomes. As [38] points out, what is the most important in this step is to maintain good diversity of the generated chromosomes to prevent premature convergence. Thus, it is needed to make the generated chromosomes uniformly distributed throughout their feasible set. To this end, an initialization scheme is displayed in Algorithm 2.

Algorithm 2 Initialization

Input: Not applicable.

Output: A random chromosome c.

1: // Below, consider the expression of c in Eq (21).

2: for k ← 1: n do

3:  for i ← 1: N do

4:   Generate a M-dim random vector from [0, 1]^M. Denote it by r.

5:   for j ← 1: M

6:    .

7:  Generate a M-dim random vector from [0, y_max]^M. Denote it by r.

8:  for j ← M

9:   y_j(τ_k) ← r_j.

10: return c.

4.4 Fitness evaluation

A fitness evaluation scheme aims to measure the quality of different chromosomes. The higher the fitness, the better the chromosome. In this paper, we simply define the fitness of a chromosome by the negative number of the latency it causes. The detail of the fitness evaluation scheme is given in Algorithm 3, whose main idea is straightforward.

Algorithm 3 Fitness

Input: A chromosome c.

Output: The fitness value of the input chromosome.

1: (x, y) ← Decoding(c).

2: Calculate l with (x, y) based on the load evolution model (2).

3: Calculate the latency J(x, y) by the latency model (11).

4: return −J(x, y).

4.5 Crossover and mutation

A crossover-mutation operator is responsible for producing chromosomes with higher quality from the existing ones. In this paper, we adopt the standard uniform crossover method [39] and the standard uniform mutation method [39]. A pseudo-code for this step is given in Algorithm 4.

Algorithm 4 Evolution

Input: A pair of chromosomes (c⁽¹⁾, c⁽²⁾), crossover probability p_c, and mutation probability p_m.

Output: Two new chromosomes.

1: for i ← 1: (N + 1) do

2:  for j ← 1: (M × n) do

3:   // Crossover

4:   Generate a random number r from [0, 1].

5:   if r < p_c

6:    Swap and .

7:   // Mutation.

8:   for q ← 1: 2

9:    Generate a random number r from [0, 1].

10:    if r < p_m

11:     if i = N + 1

12:      Set by a random value from [0, y_max].

13:     else

14:      Set by a random value from [0, 1].

15: // Check if . If not, modify the related elements.

16: for q ← 1: 2 do

17:  for i ← 1: N do

18:   for k ← 1: n do

19:    if

20:     for j ← 1: M

21:      .

22: return (c⁽¹⁾, c⁽²⁾)

4.6 Overview of LBAO algorithm

According to the above discussions, a overall procedure of our GA-based method is presented in Algorithm 5. We refer to it as the LBAO algorithm. Also, a flow chart illustrating the LBAO algorithm is shown in Fig 7. In addition, the source codes of the LBAO algorithm have been uploaded to GITHUB, whose link is [40]. Through the LBAO algorithm, we can obtain a satisfactory CEE offloading strategy.

Algorithm 5 LBAO

Input: Population size N_P, crossover probability p_c, mutation probability p_m, and maximal iteration step Q.

Output: A satisfactory CEE offloading strategy (x*, y*).

1: // Population initialization and fitness evaluation

2: for i ← 1: N_P do

3:  c⁽ⁱ⁾ ← Initialization().

4:  F(c⁽ⁱ⁾) ← Fitness(c⁽ⁱ⁾).

5: // Population evolution

6: for q ← 1: Q do

7:  // Select chromosomes using the standard roulette-wheel operator [39].

8:   ← RouletteWheel(F₁, …, F_NP).

9:  // Crossover and mutation

10:  for i ← 1: 2: N_P do

11:   (c⁽ⁱ⁾, c⁽ⁱ⁺¹⁾) ← Evolution(c⁽ⁱ⁾, c⁽ⁱ⁺¹⁾, p_c, p_m).

12: // Fitness evaluation for the new generation of population.

13:  for i ← 1: N_P do

14:   F(c⁽ⁱ⁾) ← Fitness(c⁽ⁱ⁾).

15: // Find the best chromosome from the population, and return its strategy

16: .

17: (x*, y*) ← Decoding(c*).

18: return(x*, y*)

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 7. Flow chart of LBAO algorithm.

https://doi.org/10.1371/journal.pone.0296897.g007

4.7 Time complexity of LBAO algorithm

Next, let us make a rough analysis of the time complexity of the proposed LBAO algorithm. Denote the average time consumption of the initialization, fitness evaluation, and evolution operators by C_I, C_F, and C_E, respectively. Then, by directly observing the LBAO algorithm shown in Algorithm 5, we can obtain that the total time consumption is approximately equal to (22)

In practice, the initialization, fitness evaluation, and evolution operators are all implemented by matrix-based operations (e.g., matrix multiplication). Thus, we define matrix-based operations as basic operations and denote by C the average time consumption of a basic operation. Then, by direct observation, we can obtain that C_I ≈ C, C_E ≈ 2C. Next, let us estimate the time consumption of the fitness evaluation operator. As shown in Algorithm 3, it mainly contains the calculation of the load evolution model (2) and latency model (11), which are essentially differential equations and a function integration, respectively. In this paper, we use the Euler method [41] (an efficient numerical algorithm to solve differential equations and function integration) to calculate the load evolution model and latency model. When the Euler method is applied, the total time horizon [0, T] is uniformly divided into N_T small time intervals, and for each time interval, the derivative of every function is calculated through only one matrix-based operation. Because the load evolution model contains (M + 1) functions l_j and the latency model contains just one function J, the time consumption of the fitness evaluation operator is C_F = [(M + 1) + 1]N_TC.

Combining the above discussions, it follows that (23)

From Eq (23), we can see that the time consumption of the LBAO algorithm is determined by the population size N_P, the maximum iteration step Q, and the discrete precision N_T, provided that the number of edge servers M is given by reality conditions. In practice, the population size N_P and maximum iteration step Q will affect the optimality of the GA-based LBAO algorithm, whereas the discrete precision N_T will affect the precision of the Euler-based numerical result. Thus, if we intend to obtain an offloading strategy with better quality, we may set the parameters N_P, Q, N_T by large values but the total time consumption of running the LBAO algorithm will increase. Otherwise, if we intend to apply the LBAO algorithm to real-time scenarios, we may set the parameters N_P, Q, N_T by small values such that the time consumption is low enough (though doing so may lead to some sacrifices in the quality of the results).

5.1 Parameter setting

In our numerical experiments, we consider a CEE system composed of a remote cloud server, two edge servers, and three end-device collections. Thus, let M = 2, N = 3. Let T = 6 seconds. As the propagation delay between end devices and edge servers can range from 30 milliseconds (ms) to 40 ms [42], we set D^d = 35 ms by the average value. In addition, as the propagation delay between edge servers can range from 0.1 ms [43] to 5 ms [44], we set each randomly within the range [0.1, 5]. Besides, we assume that the propagation delay between edge servers and cloud centers can range from 100 ms to 500 ms (without network congestion), and we set each randomly within the range [100, 500].

Next, we suppose the load balance scheme is supported by the Round Robin (RR) algorithm [45], one of the most widely used load balance algorithms. In the RR scheme, tasks from an edge server are equally dispatched to all the idle servers. Suppose the maximum of task migration rate is f_max = 200 tasks per second (tps). Following [25], the load balance function f can be defined as (24)

Moreover, we suppose the task processing rate of each edge server can range from 2000 to 3000 tps, and that of the cloud center is 3000 tps. Thus, we set β₀ = 3000 and set each β_j, j = 1, …, M, randomly within the range [2000, 3000]. To present a case of flash crowd (i.e., the network congestion which occurs when a huge number of end devices request an edge server simultaneously), we set the edge offloading rates by α_i(t) = 6000i tps. Besides, let the maximum cloud offloading rate be y_max = 200 tps.

5.2 Optimal configuration of LBAO algorithm

Having described the parameters used in our experiments, let us investigate the optimal configuration of the LBAO algorithm. Because the LBAO algorithm is based on the GA framework, there are three crucial parameters that can affect the quality of the resulting solution: the population size N_P, the crossover probability p_c, and the mutation probability p_m. Below, we determine these three parameters by setting them by different values and examining their resulting algorithm performance.

Let N_P ∈ {120, 240, 360}, p_c ∈ {0.05, 0.10, …, 0.50}, p_m ∈ {0.025, 0.050, …, 0.100}. Then, we run the LBAO algorithm for each parameter combination with the same iteration steps and compare the results. Denote J* as the optimal latency yielded from the LBAO algorithm. Then, Tables 1–3 display the algorithm performance under different parameter combinations with regard to N_P = 120, N_P = 240, and N_P = 360, respectively. From these three tables, it is seen that when N_P = 360, p_c = 0.50, p_m = 0.075, the LBAO algorithm can achieve the best performance as the optimal latency is J* = 182.839 thousands seconds. Thus, we recommend N_P = 360, p_c = 0.50, p_m = 0.075 as the optimal configuration of the LBAO algorithm with respect to the case we examine.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 1. Optimal latency under different crossover and mutation probabilities when N_P = 120.

https://doi.org/10.1371/journal.pone.0296897.t001

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 2. Optimal latency under different crossover and mutation probabilities when N_P = 240.

https://doi.org/10.1371/journal.pone.0296897.t002

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 3. Optimal latency under different crossover and mutation probabilities when N_P = 360.

https://doi.org/10.1371/journal.pone.0296897.t003

5.3 Effectiveness of LBAO algorithm

Though the GA framework is considered effective in tackling most optimization problems [39], there is still a need to verify if the solution obtained from the GA-based LBAO algorithm achieves a satisfactory performance. To this end, we intend to compare the LBAO solution with a large number of randomly generated CEE offloading strategies and verify if the performance of the LBAO solution is better than the best performance among all the random CEE offloading strategies. The reason for this experiment approach is straightforward. According to the Monte Carlo theory [46], with the increase of the number of randomly generated CEE offloading strategies, the best performance among all the random strategies will gradually approach the global optimal value. Thus, when the number of random strategies is large enough and the LBAO solution is better than all the random strategies, it is reasonable to recommend the LBAO solution as a satisfactory result.

Let N_R denote the number of randomly generated CEE offloading strategies. Then, a comparison between the LBAO algorithm and the Monte Carlo method is shown in Table 4. From this table, it is seen that the optimal latency of random CEE offloading strategies decreases with the increase of the number of random CEE offloading strategies, which satisfies the statement of the Monte Carlo theory. However, even though the number of random strategies is as large as N_R = 10, 000, 000, the optimal latency of random strategies is much higher than that of the LBAO solution. Besides, all the numerical experiments are conducted on the same PC machine with an AMD 5800X CPU and 32 GB memory, and it is seen that the LBAO algorithm is much more efficient than the Monte Carlo method as the runtime of the LBAO algorithm is far less than that of the Monte Carlo method. Thus, the LBAO algorithm is effective.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 4. Comparison between LBAO algorithm and Monte Carlo (MC) method.

https://doi.org/10.1371/journal.pone.0296897.t004

In addition, we compare the LBAO algorithm with other methods, including but not limited to those applied to industrial IoT scenarios. Let us introduce several baseline methods as follows.

• Cloud Horizon (ClHo) scheme [6]. At any time, each end device selects a random edge server to offload all computational tasks and each edge server always performs the cloud offloading with the maximum capability. With respect to our load evolution model, the offloading strategy is configured by , ∀i, j, y_j(t) ≡ y_max, ∀j.
• First Come First Service (FCFS) scheme [19]. At any time, each task produced by end devices is offloaded to edge servers in sequence, following the first come first service principle. Similarly, each task on the queue of an edge server is offloaded to the cloud center in sequence, following the first come first service principle. With regard to our load evolution model, the offloading strategy is configured by , ∀i, j, , ∀j.
• Edge Processing Only (EPS) scheme [47]. At any time, each end device can only select a random edge server to offload all computational tasks and the cloud offloading is invalid. With respect to our load evolution model, the offloading strategy is configured by , ∀i, j, y_j(t) ≡ 0, ∀j.

A performance comparison of the ClHo, FCFS, EPS, MC, LBAO methods is shown in Table 5, from which it is seen that the proposed LBAO algorithm is better than the four baseline methods in terms of task total latency. In addition, denote the load evolution trajectories under the ClHo, FCFS, EPS schemes by l^ClHo, l^FCFS, l^EPS, respectively. Then, the load evolution trajectories under the LBAO algorithm and the ClHo, FCFS, EPS methods are compared in Fig 8. From this figure, it is seen that the cloud load under the LBAO algorithm is much lower than those under the baseline methods. This result implies that in the current network environment, the propagation delay for cloud offloading may be relatively high. Thus, the LBAO strategy does not recommend the excessive use of cloud offloading, but rather suggests fully utilizing the potential capability brought by the load balance between edge servers.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 5. Comparison of different methods in terms of total latency.

https://doi.org/10.1371/journal.pone.0296897.t005

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 8. Comparison between the load evolution trajectories l^ClHo, l^FCFS, l^EPS and l*.

https://doi.org/10.1371/journal.pone.0296897.g008

Next, let us investigate the relationship between the time consumption and result quality of the LBAO algorithm. Recall that the time complexity of the LBAO algorithm is mainly determined by the population size N_P, the maximum iteration step Q and the discrete precision N_T. Let Q = 100, N_P ∈ {40, 80, 120}, N_T ∈ {20, 40, 60, 80, 100}. Then, we run the LBAO algorithm for each parameter combination and record the corresponding total time consumption and task latency. The results are shown in Fig 9, from which the following two observations can be attained:

• With the increase of the discrete precision N_T, the total time consumption of the LBAO algorithm increases in a roughly linear manner, whereas the total latency decreases slower and slower. This observation implies that it seems not a cost-efficient way to blindly increase the precision N_T because the resulting improvement in algorithm quality would be very limited. For example, when N_P = 120, if the precision N_T is enlarged from 20 to 100, the quality improvement would be just only , while the time consumption would increase by . On the contrary, if the precision is reduced, the algorithm time consumption will decrease quickly and the LBAO algorithm can be applied to real-time scenarios with just litter quality reduction.
• With the increase of the population size N_P, the total time consumption of the LBAO algorithm increases dramatically while the total latency just changes slightly. This observation also suggests us not to blindly increase the population size N_P for better algorithm quality. Thus, we recommend setting the population size N_P by a small value in practical applications.
• From the above two observations and analyses, we should understand that setting the population size N_P and discrete precision N_T by small values is a cost-effective way to solve the LBAO problem. Also, from Fig 9, it is seen that when these two parameters are as small as N_P = 40, N_T = 20, the result quality is acceptable and the time consumption is just nearly one second, which is much less than the considered time horizon T = 6 seconds. Thus, it is reasonable to consider that the LBAO algorithm has the potential to be applied to real-time applications.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 9. Relationship between time consumption and result quality of LBAO algorithm.

https://doi.org/10.1371/journal.pone.0296897.g009

5.4 Influence of load balance in CEE offloading

Finally, let us investigate the influence of load balance in CEE collaborative offloading. To achieve that, we perform the following four experiment steps:

1. Under the actual load balance scheme f shown in (24), calculate the optimal strategy (x*, y*) through the LBAO algorithm and denote the corresponding load evolution trajectory by l*. The strategy (x*, y*) is the optimal decision that is aware of load balance.
2. Let the load balance scheme be f(i, j, l(t), t) ≡ 0. Calculate the optimal strategy through the LBAO algorithm. This strategy means the erroneous optimal decision that ignores the effect of load balance.
3. Under the actual load balance scheme f shown in (24), calculate the actual load evolution trajectory for the erroneous strategy .
4. Compare the load evolution trajectories l* and . The result is shown in Fig 10.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 10. Comparison between the load evolution trajectories under the correct and erroneous optimal strategies.

https://doi.org/10.1371/journal.pone.0296897.g010

From Fig 10, it is seen that the influence of load balance on the optimal decision of CEE offloading strategies is non-negligible. More specifically, it follows from Fig 10A that the erroneous optimal strategy tends to adopt higher cloud offloading rates because it ignores the influence of load balance and underestimates the capacity of edge servers, leading to higher load in the cloud center; on the contrary, the correct optimal strategy (x*, y*), which has accounted for the load balance scheme, tends to adopt lower cloud offloading rates because it perceives that the edge servers are able to accommodate more tasks through load balance. In addition, Fig 10B and 10C show that the load balance scheme can effectively reduce the load difference between the two edge servers. Thus, load balance is a crucial factor in determining a proper CEE offloading strategy.