1. Introduction
With the emergence of fifth generation (5G) mobile communication and Internet of Things, a variety of applications such as augmented reality, facial recognition, mobile game, smart city, and smart building, have been developed [
1,
2,
3,
4,
5,
6,
7,
8,
9,
10]. Many of these applications require high processing performance and low processing latency, and each task for these applications must be processed within an acceptable delay. However, it is difficult to process tasks for mobile applications within acceptable delays on mobile terminals [
11,
12,
13]. This is because the processing capability of mobile terminals is low, and it takes a long time to process the tasks on these terminals.
By using task offloading, tasks for mobile applications can be processed on cloud servers, which are external servers with higher processing performance than mobile terminals [
14]. The tasks can be processed on cloud servers in a short time [
15]; however, the transmission delay is large due to the large distance between the mobile terminal and cloud servers [
16]. Task offloading is a complex process and can be affected by a number of different factors [
17], and it requires application partitioning, offloading decision making and distributed task execution [
18].
Mobile edge computing (MEC) has attracted attention for processing tasks for applications that require low processing delay [
19,
20]. MEC was defined by the European Telecommunication Standards Institute [
21], and it is also recently called Multi-Access Edge Computing. MEC is classified into one of the edge computing, which can support several kinds of characteristics including mobility support, location awareness, low latency, and heterogeneity [
22,
23,
24]. In general, edge computing has more limited resources, limited computation and storage capabilities, and proximity to end devices than fog computing [
25].
In a MEC platform in which MEC servers can be used, tasks can be processed on the MEC servers using task offloading, and the transmission delay for the task processing can be significantly reduced compared with cloud servers. However, the amount of available computing resources in a MEC server is limited, and the processing performance of a MEC server is lower than that of cloud servers. Thus, the number of tasks processed on a MEC server affects the performance of the MEC server. To process each task within an acceptable delay, some tasks should not be processed on the MEC server to avoid reducing the processing performance.
In some MEC platforms, MEC servers and cloud servers can be utilized for processing tasks [
26]. MEC servers are classified into the following two groups based on the location and users: dedicated MEC servers and shared MEC servers. Dedicated MEC servers are utilized to process tasks that are sent from the closest access point, while shared MEC servers are utilized for tasks that are sent from any access point. Each task should be processed on an appropriate server among dedicated MEC servers, shared MEC servers, and cloud servers to satisfy the acceptable delay. Moreover, each task should be processed with low latency even if the acceptable delay is satisfied. Therefore, the total delay between sending a task and receiving a response for all tasks can be reduced by using MEC servers and cloud servers appropriately. However, the latency for each task is significantly affected by other task processes; therefore, it is difficult to perform task allocation for these servers. In addition, tasks transmitted from multiple access points are allocated to one of multiple MEC servers. Task allocation must be performed for tasks transmitted from multiple access points; however, it is difficult to consider the bottleneck node in an MEC platform. As far as the authors know, task allocation has not been studied in an MEC platform in which MEC servers and cloud servers are utilized from multiple access points and there is a bottleneck node.
In this paper, we propose a task allocation method for reducing the total latency in a MEC platform. In this platform, there are three types of servers: a dedicated MEC server, a shared MEC server, and a cloud server. For this platform, we first calculate the delay between sending a task and receiving a response for the dedicated MEC server, shared MEC server, and cloud server by considering the processing time and transmission delay. Here, the bottleneck node is modeled as an M/M/1 queueing model, and the transmission delay for the shared MEC server is derived using a queuing theory. Then, we formulate an optimization problem for task allocation to minimize the total latency for all tasks. By solving this optimization problem, tasks can be allocated to the MEC servers and cloud server appropriately. However, the calculation time is very large even if a meta-heuristic algorithm, such as the genetic algorithm [
27], is used. Therefore, we also propose a heuristic algorithm to obtain the approximate optimal solution in a shorter time. This heuristic algorithm consists of four algorithms: a main algorithm and three additional algorithms. In this algorithm, tasks are divided into two groups, and task allocation is executed for each group. We compare the performance of our proposed heuristic algorithm with the solution obtained by the genetic algorithm and other methods and investigate the effectiveness of our algorithm.
Various studies have been conducted on task allocation methods for the MEC platform [
20,
26,
28,
29,
30,
31,
32,
33,
34,
35,
36,
37,
38,
39,
40,
41,
42,
43,
44,
45,
46,
47,
48,
49,
50,
51,
52,
53,
54,
55,
56,
57,
58,
59], which are described in
Section 2. In comparison with these studies, we offer the following contributions and benefits:
This paper considers task allocation for a MEC platform in which two types of MEC servers and a cloud server can be utilized.
Three different equations are formulated to calculate the latency for each server.
Our proposed heuristic algorithm can quickly derive the approximate optimal solution for the optimization problem in a situation in which three different servers are utilized.
Our proposed heuristic algorithm can be implemented in a MEC platform and a mobile application, such as our developed application and system [
60,
61], because this algorithm is not complex for implementation.
Task allocation may fall into the local minimum when our proposed heuristic algorithm is used because task allocation processes are simple so that it can be implemented in a MEC platform. However, we will avoid falling into the local minimum by adding random search technique (ARSET) and heuristic random optimization (HRO) [
62]. It should be noted that this paper is an extension of our previous work [
63].
The remainder of this paper is organized as follows.
Section 2 presents related work on task allocation in a MEC platform.
Section 3 describes our system model, and
Section 4 formulates an optimization problem to reduce the total latency in the MEC platform.
Section 5 proposes a heuristic algorithm for solving the optimization problem, and
Section 6 calculates computational complexity of the heuristic algorithm.
Section 7 presents numerical examples, and
Section 8 concludes the paper.
2. Related Work
In this section, we introduce related work on task allocation in a MEC platform. In [
20], an offloading algorithm was proposed for multiple users to perform the computation offloading in a MEC environment. In this environment, multi-channel radio interference was utilized for offloading, and the algorithm used game theory for task offloading. In [
26], the authors studied resource allocation for a multi-user MEC offloading system based on time-division multiple access and orthogonal frequency-division multiple access. In [
28], the authors proposed a task allocation in a hybrid non-orthogonal multiple access (NOMA) MEC system to reduce the processing delay and save the energy consumption. The proposed method formulates an optimization problem and utilizes a matching algorithm to obtain a better solution. In [
29], the authors proposed a cooperative task allocation method to minimize the power consumption of mobile terminals in an environment with a MEC server and cloud server. In this environment, task processing can be performed on the MEC server near the base station via wireless communication. This method can also use cloud servers via optical line terminals or the Internet.
In [
30], the authors defined a mathematical model of a MEC environment in which traffic flows can be managed. The proposed permissive underestimation system, which selects the destination server with the lowest latency, provides an effective solution for a MEC platform. In addition, in [
31], the authors discussed how a MEC server can be used to realize serverless edge computing. Following the European Telecommunications Standards Institute (ETSI) MEC standard, two alternative design approaches were proposed to handle rapid changes in mobility and load conditions. Using numerical examples, it was demonstrated that the proposed approaches were effective in accommodating system changes in response time.
In [
32], the authors proposed an optimization framework for computation offloading and resource allocation for a MEC environment with multiple servers. This framework can be used to minimize the total computational overhead. The individual computation decisions, transmit power of the users, and computation resources were optimized. MEC servers were utilized in this environment; however, cloud servers were not. In addition, this paper adopted a suboptimal approach by splitting the original problem into a computation offloading decision problem and a joint resource allocation problem.
In [
33], the authors investigated a two-tier offloading method for multiple MEC servers in heterogeneous networks. In this method, the total computation overhead was minimized by solving a formulated optimization problem that was a mixed-integer nonlinear program problem. The original problem was also divided into a resource allocation problem and a computation offloading problem. In [
34], the authors focused on a MEC platform in which there were two types of MEC serves: a near server and far server. In this platform, delay-sensitive tasks were allocated to the near server while computationally intensive tasks were allocated to the far server. However, this task allocation did consider the utilization of cloud servers. In [
35], a resource management technique based on game theory was proposed in a MEC platform and small-scale data centers. This technique can minimize energy consumption and costs while ensuring applications’ performance using a semi-co-operative game.
In [
36], the authors proposed a heuristic offloading algorithm to maximize the reliability performance of computation offloading. The method can be used in an Internet of Vehicle environment in which fixed edge computing node and MEC nodes are used, but cloud servers are not used. For a similar Internet of Vehicle environment, in [
37], the authors modeled the data redundancy and proposed the collaborative task computing scheme. The proposed scheme can reduce the redundant data and utilize the idle resources in nearby MEC servers. In [
38], the authors proposed an optimization framework of offloading from a single mobile device to multiple edge devices. This framework is based on a semi-definite relaxation (SDR), and tasks are allocated considering central process unit (CPU) to improve energy consumption and processing latency. In [
39], for the industrial Internet of Things, the authors proposed a MEC-enabled architecture considering the task’s priority constraints. This architecture can minimize the response time using a task allocation strategy using a Bayesian network based evolutionary algorithm. In [
40], for the latency and reliability sensitive computing tasks processed in swarm of drones, the authors proposed a task allocation based on an optimization problem. In the swarm of drones, nearby drones are used as MEC server for processing the tasks. This algorithm can minimize the energy consumption of the swarm of drones when the latency and reliability requirements are satisfied.
For cloud computing environments without MEC servers, in [
41,
42], the authors proposed resource management methods for cloud computing environments and cloud data centers. These methods can manage resources to improve energy consumption, service performance, and costs. In [
43], the authors studied the combination of two virtualization technologies: virtual machine and containers. The authors presented the advantages of running containers on virtual machines.
For a environment where MEC servers and cloud servers are available, [
44,
45] proposed an algorithm that allocates tasks to a MEC server or cloud servers to minimize the total latency. Optimization problems were formulated for latency reduction and were solved using a genetic algorithm. In both problems, there was only one MEC server, and heuristic algorithms were not proposed. In [
46] a task allocation to increase user satisfaction was proposed. The minimization of power consumption was also considered [
47,
48,
49,
50,
51].
MEC is significantly expected to be utilized by future Internet applications. Therefore, various uses of MEC have been proposed [
52,
53,
54,
55]. Especially, machine learning and artificial intelligence are effective in a MEC platform [
56,
57,
58,
59]. For utilizing machine learning and artificial intelligence, a large number of data sets obtained from the real environment and a long training time to determine an appropriate task allocation.
4. Optimization Problem Formulation for Total Latency Reduction
In this section, we formulate an optimization problem for allocating tasks to three servers to minimize the total latency for the system model described in
Section 3. For this optimization problem, we define the following variables for task
:
The above variables indicate the server where is processed. For example, indicates that is allocated to .
When the acceptable latency for
is
, we formulate the following optimization problem for minimizing the total latency for all
tasks:
In this optimization problem, the objective function (
5) signifies that tasks are allocated to servers to minimize the total latency. The constraint condition (
6) indicates that the latency for each task must be equal to or lower than
. Moreover, (
7) signifies that each task is allocated to only one of three servers. This optimization problem can be solved simply using meta heuristic algorithms, such as the genetic algorithm.
5. Proposed Heuristic Algorithm
In this section, we propose a heuristic algorithm for solving the formulated optimization problem. Our proposed heuristic algorithm consists of four algorithms that are denoted as Algorithms 1–4. Algorithm 1 is the main algorithm, while the remaining algorithms are used as a function in the main algorithm.
Figure 4 presents an overview of our proposed heuristic algorithm. In our algorithm, the allocation of a task whose acceptable latency is low is preferentially performed to satisfy the acceptable latency of all tasks. In Algorithm 1, first, all tasks are divided into two sets in line 1. This process is performed based on the acceptable latency in Algorithm 2.
Algorithm 1 Main algorithm. |
Input:
All parameters for our optimization problem Output: , , 1: Task division (, ) /*Algorithm 2*/
2: MEC allocation /*Algorithm 3*/ 3: MEC cloud allocation /*Algorithm 4*/ |
In Algorithm 2, tasks are divided into two sets, and . includes tasks that can be processed on S, while includes tasks that are never processed on S. If the acceptable latency of task is smaller than , is never processed on S and is included in in lines 3 and 4. Otherwise, is included in in lines 5 and 6.
Then, each task in
is allocated to
or
in line 2 of Algorithm 1, and this allocation is performed in Algorithm 3. In Algorithm 3, let
and
be the latency when
is assumed to be processed on
and
, respectively. Furthermore,
and
are the minimum values of the acceptable latency
of a task allocated to
and
, respectively. As explained in the previous paragraph, a task in
must be allocated to
or
because
is smaller than
. In addition, a task whose acceptable latency is low should be allocated to
because the transmission delay for
is zero. Therefore, the allocation of tasks in
is decided in ascending order of
, and
is sorted in ascending order of
in line 1. It should be noted that
is the minimum value while
is the maximum value after line 1. In this task allocation,
and
are compared with
and
in lines 6, 18, and 23. When all tasks satisfy the acceptable latency even if
is allocated to
and
in line 6,
is allocated to a server to reduce the latency by comparing
with
in lines 7 or 12 (
or
). After
is allocated to a server,
or
may be updated in line 10 or 15. When all tasks satisfy the acceptable latency if
is allocated to
but the acceptable latency is not satisfied for
in line 18,
is allocated to
(
). In addition, when all tasks satisfy the acceptable latency if
is allocated to
, but the acceptable latency is not satisfied for
in line 23,
is allocated to
(
). In both cases,
or
may be updated in line 21 or 26.
Algorithm 2 Task division function. |
Input: Output: Initialization: 1: LOOP Process: 2: whiledo 3: if then 4: 5: else 6: 7: end if 8: 9: end while |
Algorithm 3 MEC allocation function. |
Input: Output:, , for Initialization: 1: in is sorted in ascending order of 2: 3: 4: LOOP Process: 5: while do 6: if and then 7: if then 8: 9: if then 10: 11: end if 12: else 13: 14: if then 15: 16: end if 17: end if 18: else if and then 19: 20: if then 21: 22: end if 23: else 24: 25: if then 26: 27: end if 28: end if 29: end while |
In Algorithm 4, tasks are allocated to
,
, or
S because
can be allocated to the cloud server. Here, this task allocation can easily satisfy the acceptable latency for a task by allocating the task to
S. This is because the processing time for
and
does not change when the task is allocated to
S. Therefore, in this algorithm,
in
is sorted in descending order of
to reduce the total latency in line 1. It should be noted that
is the maximum value and
is the minimum value after line 1. Here, let
,
, and
be the total latency for
,
, and
S in the case in which
is assumed to be processed on
,
, and
S, respectively. In this task allocation,
and
are compared with
and
in lines 6, 20, 29, and 38. When all tasks satisfy the acceptable latency, even if
is allocated to
and
in line 6,
is allocated to a server so that the total latency becomes the smallest in lines 7, 12, or 17 (
,
, or
). After
is allocated to
or
,
or
may be updated in line 10 or 15. When all tasks satisfy the acceptable latency if
is allocated to
, but the acceptable latency is not satisfied for
in line 20,
is allocated to
or
S. In line 21 or 26,
is allocated to a server so that the total latency becomes the smallest (
or
). In addition, when all tasks satisfy the acceptable latency if
is allocated to
, but the acceptable latency is not satisfied for
in line 29,
is allocated to
or
S. In line 30 or 35,
is allocated to a server so that the total latency becomes the smallest (
or
). When no task can satisfy the acceptable latency if
is allocated to
and
,
is allocated to
S (
).
Algorithm 4 MEC cloud allocation function. |
Input: Output:, , for Initialization: 1: in is sorted in decreasing order of 2: 3: 4: LOOP Process: 5: while do 6: if and then 7: if and then 8: 9: if then 10: 11: end if 12: else if and then 13: 14: if then 15: 16: end if 17: else 18: 19: end if 20: else if and then 21: if then 22: 23: if then 24: 25: end if 26: else 27: 28: end if 29: else if and then 30: if then 31: 32: if then 33: 34: end if 35: else 36: 37: end if 38: else 39: 40: end if 41: 42: end while |
6. Computational Complexity
In order to investigate the scalability of our proposed algorithm, we derive computational complexity of our proposed heuristic algorithm. First, there is no loop process in Algorithm 1, which is the main algorithm; therefore, the computational complexity of this algorithm can be derived from Algorithm 2, Algorithm 3, or Algorithm 4.
In Algorithm 2, there is a loop process from line 2 to line 9, and the order of this loop process is , in which N is the number of tasks. In Algorithms 3 and 4, there is also a loop process from line 5 to line 29 and from line 5 to line 42, respectively. From line 5 of Algorithm 3, the order of this loop process is because is equal to or smaller than N. Moreover, from line 5 of Algorithm 4, the order of this loop process is also because is equal to or smaller than N.
As a result, the computational complexity of our proposed algorithm is . This signifies that the computational complexity of this algorithm does not depend on parameters of a MEC platform and is affected by only the number of tasks. Therefore, our proposed algorithm is scalable to a large-scale MEC platform.
7. Numerical Examples
In this section, we evaluate the performance of our proposed heuristic algorithm described in
Section 5 through comparison with other methods such as near-optimal task allocation with the genetic algorithm.
In the MEC platform for the performance evaluation, the number of tasks
is 10, 20, 30, 40, or 50, and the number of tasks
is equal to 20. The processing efficiency for
is
, and the processing efficiency for
is
. In addition, the transmission delay of tasks for
S is
, 0.2, 0.3, 0.4, or 0.5. For task
,
is determined according to a uniform distribution of
, and
is determined according to a uniform distribution of
. For the bottleneck node, we assume that
is equal to 1.25, 1.5, 1.75, 2.0, or 2.25, and
is equal to 100.
Table 1 presents a list of parameter settings in the simulation. These parameter settings were decided according to our MEC platform and application [
62].
For this MEC platform, we evaluate the performance of the proposed heuristic algorithm, denoted as Proposed, and the performance of near-optimal task allocation, denoted as GA. In near-optimal task allocation, the number of chromosomes in each generation is 1000 and the mutation probability is 0.005. GA algorithm stops if there is no improvement in the best objective value for 1000 generations. It should be noted that we determined that the result of GA is the same as the optimal value obtained by the CPLEX optimizer [
64] when the number of tasks is small. Therefore, the result of GA is used as the optimal one, and the performance of our proposed heuristic algorithm is investigated by comparing with the result of GA.
We also evaluate another heuristic algorithm where , , and are replaced by , , and in Algorithm 4. This signifies that the latency for is considered, but the total latency is not considered in Algorithm 4. The performance evaluation of this method is useful to investigate the validity of our proposed heuristic algorithm where the total latency can be considered, and the result is denoted as Comp. Finally, as one of the simplest methods, we evaluate the performance of a random method, this is denoted as Random, in which tasks are allocated to the three servers at random. We evaluate the performance of this method by deriving the average value from 10 simulations; the result is denoted as Random. By comparing Proposed with Random, the processing complexity of Proposed can be investigated.
In the following performance evaluation, there are four performance metrics:
Total latency: The solution of (
5).
Minimum latency: .
Maximum latency: .
Calculation time to perform task allocation by solving the optimization problem.
These metrics are derived by solving the optimization problem (
5) using the four methods.
7.1. Impact of Number of Tasks
First, we investigate the impact of the number of tasks
N on the performance of each method when the transmission delay
via the Internet is 0.2 and the arrival rate
is 2.0.
Figure 5 presents the total latency versus the number of tasks
N. This figure indicates that the total latency increases as the number of tasks increases for all methods. This is because the total number of CPU cycles required for processing tasks increases. Among the four methods, the total latency of GA is the lowest, as expected. Furthermore, the latency of Random is much higher than that of GA, which demonstrates that tasks should not be allocated to servers at random. For our proposed method (Proposed), the obtained latency is close to the near-optimal result of GA. This is because our proposed method is constructed to obtain appropriate solution for the optimization problem (
5)–(
7). Moreover, the latency of Comp is almost the same as that of GA when the number of tasks is small; however, the latency increases as the number of tasks increases. When the number of tasks is 50, the total latency of Comp is much higher than that of Random. Therefore,
Figure 5 demonstrates that our proposed heuristic algorithm can effectively reduce the total latency compared to Random and Comp.
Next, we evaluate the minimum latency and maximum latency for each task allocation in
Figure 6 and
Figure 7, respectively. In these figures, the number of tasks
N is 50,
is 0.2, and
is 2.0.
Figure 6 demonstrates that the minimum latency of Proposed is larger than that of GA. This indicates that the minimum latency can not be obtained using our proposed algorithm. This means that our proposed method cannot obtain the optimal solution for the optimization problem. However, the minimum latency of Proposed is much lower than that of Comp by using appropriate parameters in Algorithm 4. Here, the minimum latency of Random is the lowest among the four methods by ignoring the total latency reduction. In terms of the maximum latency,
Figure 7 demonstrates that the latency of Proposed is almost the same as that of GA. This result signifies that Proposed can allocate tasks to appropriate servers so as not to increase the maximum latency for the total latency reduction. Here, the maximum latency for GA, Proposed, and Random is 0.4 that is equal to
, and this is the latency for the task offloading to cloud servers. Therefore, GA, Proposed, and Random can utilizes MEC servers appropriately, but MEC servers are overused in Comp. These results indicate that our proposed heuristic algorithm is effective in solving the optimization problem to reduce the total latency.
Figure 8 and
Figure 9 illustrate how tasks are allocated to each server when
N is equal to 30 and 50, respectively. In both figures,
is 0.2 and
is 2.0. In these figures, almost the same number of tasks are allocated to each server for Random because the task allocation is determined at random. By comparing Random with other methods, we observe that a large number of tasks are allocated to cloud server
S. As a result, the minimum latency and maximum latency are low in
Figure 6 and
Figure 7; however, the total latency is high in
Figure 5. In our proposed method, the number of tasks for
is almost the same as that of GA, but the number of tasks for
and
S are somewhat different from that for GA. In our proposed method, the number of tasks offloaded to each server depends on the processing order that is predetermined at line 1 in Algorithms 3 and 4. Therefore, it is hard to obtain the optimal task offloading in our proposed method. In Comp, the number of tasks for
S is the smallest for both cases because the total latency cannot be considered in Algorithm 4.
7.2. Impact of Transmission Delay for Cloud Server
Next, we investigate the impact of the transmission delay
on the performance of each method.
Figure 10 presents the total latency versus
in the case of
and
. This figure indicates that the total latency increases as
increases for GA, Proposed, and Random. This is because the latency for tasks that are allocated to the cloud server
S increases. From this figure, we find that the total latency for Proposed is close to that for GA. This means that our heuristic algorithm is effective regardless of
. In contrast, the total latency of Comp does not increase when
is larger than 0.2. In Comp, many tasks are allocated to
S by considering only the latency for each task when
is small. However, the latency for each task allocated to
S increases as
increases. Therefore, the number of tasks for
S decreases and the total latency does not increase even if
increases.
We also evaluate the minimum latency and maximum latency for each task allocation versus
. In
Figure 11 and
Figure 12,
is set to 50 and
is set to
.
Figure 11 demonstrates that the minimum latency of Comp is the largest because many tasks are allocated to
S even if
and
are available. On the other hand, the minimum latency of Proposed is higher than that of GA and Random. The difference between Proposed and these two methods increases as
increases. This signifies that many tasks are allocated to MEC servers using our proposed method, and the minimum latency of our method increases. However, in
Figure 12, the maximum latency of Proposed is equal to that of GA in most cases. In contrast, the maximum latency of Comp is very different from that of other methods. This is because many tasks are allocated to MEC servers even if the processing time in these servers increases. Although the task allocation of Proposed is somewhat different from that of GA, our heuristic algorithm is more effective than Comp and Random.
7.3. Impact of Arrival Rate in a MEC Platform
In this subsection, we investigate the impact of the arrival rate on the performance of each method in the case of and . The change of arrival rate signifies that the change of the number of tasks, and the scalability of our heuristic algorithm and the heterogeneity of system model, can be investigated. It should be noted that there are no results of Random because the obtained random task allocation could not satisfy constraint conditions.
Figure 13 presents the total latency versus
. This figure indicates that the total latency increases as
increases for GA and Proposed. This is because the latency
increases from (
1) and (
3). In contrast, when
increases from 2.0 to 2.25, the total latency of Comp decreases. This is because many tasks are allocated to the cloud server
S and the processing time on MEC servers decreases.
Figure 13 demonstrates that our proposed heuristic algorithm can effectively reduce the total latency compared to Comp regardless of
.
In addition, we evaluate the minimum latency and maximum latency for each task allocation versus
.
Figure 14 demonstrates that the minimum latency of Proposed is higher than that of GA, but is lower than Comp. In
Figure 15, the maximum latency of Proposed is equal to that of GA regardless of
. These results present that our heuristic algorithm is more effective than Comp, although the task allocation of Proposed is somewhat different from that of GA. Here, the proposed method utilizes the total latency, which is given by
,
, or
, in our Algorithm 4, but Comp uses the latency for a server, which is given by
,
, or
. This means that our proposed algorithm is effective by considering the total latency instead of the latency for a server. This tendency can be shown in the previous subsection.
7.4. Calculation Time
Finally, we investigate the calculation time of our proposed method using a computer running macOS Mojave 10.14.6 with 2.3 GHz Intel Core i5, and 8 GB memory. It should be noted that the calculation time changes every time it is measured and it is not constant.
Table 2 presents the calculation time of GA, Proposed, and Comp in the case of
10, 20, 30, 40, and 50. Here,
is equal to 0.2 and
is equal to 2.0. This table indicates that the calculation time of our proposed method (Proposed) is much lower than that of near-optimal task allocation (GA). As the number of tasks increases, the difference between Proposed and GA becomes large. This is because meta-heuristic algorithms including GA take a longer processing time than heuristic algorithms as widely known. This means that the heuristic algorithm is effective for task allocation in real environments. GA is not appropriate to decide the task offloading in real time. Moreover, the calculation time of our proposed method is almost the same as that of another heuristic algorithm (Comp). This is because the two algorithms are almost identical, although our proposed algorithm is more effective. From these results, we can conclude that our proposed heuristic algorithm is effective for task allocation in a MEC platform with multiple types of MEC servers.
8. Conclusions and Future Work
For 5G and future Internet, in this paper, we proposed a task allocation method for reducing the total latency in a MEC platform with three types of servers: a dedicated MEC server, a shared MEC server, and a cloud server. The proposed method can perform approximate optimal task allocation in a shorter time than other meta heuristic algorithms. This heuristic algorithm consists of four algorithms: a main algorithm and three additional algorithms. In this algorithm, tasks are divided into two groups, and task allocation is executed for each group. Computational complexity of our proposed algorithm depends on only the number of tasks. We compared the performance of our proposed heuristic algorithm with the solution obtained by GA and evaluated the effectiveness of our algorithm. From numerical examples, we observed that the results of our proposed method were similar to the results of near-optimal task allocation with GA. When the number of tasks changed, the difference between our proposed method and GA did not change significantly. In addition, the proposed algorithm could reduce the total latency by comparing with other methods. In terms of the transmission delay, the effectiveness of the proposed method was much high even if the transmission delay increased. This is because our proposed method can utilize MEC servers as is the case with GA. On the other hand, as the arrival rate became large, the difference between the proposed method and GA increased. This is because the impact of incorrect task allocation became large as the arrival rate increased. Nevertheless, the proposed method was more effective than other methods. The calculation time of our proposed method was much lower than that of near-optimal task allocation with GA. This result signified that Proposed could allocate tasks to appropriate servers so as not to increase the maximum latency for the total latency reduction. These results indicated that our proposed heuristic algorithm was effective in solving the optimization problem to reduce the total latency. Our proposed heuristic algorithm was effective for task allocation in a MEC platform with multiple types of MEC servers.
For a large-scale MEC platform, our system model and proposed algorithm are utilized modeling multiple MEC servers and multiple access points as a shared MEC server and an access point group, respectively. If the impact of each MEC server and each access point should be evaluated, our proposed method must be extended. This extension is one of our future works. In addition, we have developed an open MEC platform and a mobile augmented reality application. In our future work, we will implement the proposed algorithm into our MEC platform and mobile application and experimentally evaluate the performance of the algorithm. Moreover, in order to improve the performance, a deep learning algorithm may be available in the future.