Edge-Cloud Collaborative Optimization Scheduling with Micro-Service Architecture

The architecture of edge-cloud cooperation is proposed as a compromising solution that combines the advantage of MEC and central cloud. In this paper we investigated the problem of how to reduce the average delay of MEC application by collaborative task scheduling. The collaborative task scheduling is modeled as a constrained shortest path problem over an acyclic graph. By characterizing the optimal solution, the constrained optimization problem is simplified according to one-climb theory and enumeration algorithm. Generally, the edge-cloud collaborative task scheduling scheme performance better than independent scheme in reducing average delay. In heavy workload scenario, high blocking probability and retransmission delay at MEC is the key factor for average delay. Hence, more task executed on central cloud with abundant resource is the optimal scheme. Otherwise, transmission delay is inevitable compared with execution delay. MEC configured with higher priority and deployed close to terminals obtain more performance gain.


Introduction
As digital applications proliferate, 5G network is deeply integrated with enhanced mobile broadband (eMBB), ultra reliable low latency communications (uRLLC), and massive machine type communication (mMTC) services, such as virtual reality/augmented reality, 4K/8K live video, artificial intelligence decision and big data analysis [1] [2] [3] [4]. Multiple access edge computing (MEC) is a promise technology which allows various access mode, high bandwidth, low la-tency services executed locally by deploying multiple access edge cloud at the edge of the network [5] [6]. As a simplified version of central cloud, MEC executes the cloud computing task locally by deep data inspection, which can reduce the transmission delay and avoid the flow storm towards backhaul and core network [7] [8] [9]. More and more broadband and low latency services are applied with the assistant of MEC instead of centralized cloud. However, MEC is deployed at the edge of network with limited resources including computing, storage, cache, even physical space, air-conditioning environment and energy consumption. Compared with MEC, central cloud is assumed to offers virtually unlimited computing capacity, massive storage and abundant cache in core data center (DC). Hence, the architecture of edge-cloud cooperation is proposed as a compromising solution that combines the advantage of MEC and central cloud [10] [11]. In the cooperation scenario, it is critical to utilize the limited resource efficiently and balance the workload between edge and cloud by offloading mechanism and resource management schemes.
Offloading mechanism has been studied extensively in mobile edge computing scenario [12]- [19]. Generally, there are three kinds of offloading policies aiming at minimal delay, minimal energy and balance between delay and energy. Liu adopt a Markov decision process approach to handle the delay and optimal computation offloading policy, incorporating different timescales in the task execution process [12] [13] [14]. Several strategies are proposed to minimize the energy consumption with predefined delay constrains [15] [16] [17] [18]. Kamoun suggested continuous optimization algorithms preconfigured offline and based on network status online [15] [16]. Resource allocation is considered in a MEC offloading system comprising multiple users sharing the same edge cloud [17] [18]. Furthermore, some offloading proposals are considered for energy efficiency in latency constrained [19] [20]. However, most of the literatures are assumed to solve the optimal cooperation between the mobile terminal and MEC platform with fading channels. In fact, the cooperation between MEC and central cloud is also significant in task scheduling [21]. In this scenario, not only backhaul bandwidth but also transmission delay with various MEC deployment positions are the critical factors.
In this research, we investigate problem of how to reduce the average delay of MEC application with cloud assistant in a more generally scenario. Compared with one dimension linear or parallel task execution topology, the realistic MEC platform allows both serial and parallel computation tasks executed. The parallel computation task execution is designed to support micro-service application. Nevertheless, most tasks cannot be divided into parallel elements completely. Some elements are executed with others' output as input. Hence, we build a grid topology model to describe the task generally. The model is consists of two dimensions topology. The micro-service sets are executed serially and the micro services are executed in parallel in each set. Then, we characterize the optimal solution to the optimization problem by one-climb theory and enumeration algorithm [20].
The rest of this paper is organized as follows. System model and problem formulation is presented in Section 2. Section 3 provides the characterization of the optimal solution to the optimization problem. In Section 4, some simulation results are listed to compare the performance gain in average delay. Finally, the conclusions of this paper and suggestions for future work are given in Section 5.

System Model and Problem Formulation
In this section, we present the model for tasks with micro-service architecture collaborated between MEC and cloud. Generally, an application task is a hybrid of services executed sequentially and in parallel.

1) Micro-Service Task Model
We assume that an application task Φ is presented by a sequence of micro-service sets with a linear topology. Each micro-service set consists of micro-services which can be executed in parallel. Figure 1 illustrates the micro-service task model in a grid topology. S 0 and D are the initiator and destination of the application task, respectively. There are n sequentially executed micro-service sets {S 1 , S 2 , •••, S n } in the task, which can be modeled as a Poisson process. We denote the output of S i as i is the computing workload of the jth micro service in the micro-service set S i . However, micro-service set S i (0 < i ≤ n) is executed based on the output of previous set S i−1 (0 < i ≤ n). Hence, notice that i α (0 ≤ i ≤ n) is a non-zero matrix. Generally, there are three kinds of edge-cloud collaborative policy: local execution, partial offload and all offload.
Hence, ξ is defined as the ratio of micro-service set that offloaded to MEC platform.

2) Execution Model
In this paper, we focus on the collaborative task execution between MEC and cloud. Specially, each micro service in the grid topology can be executed on the local MEC platform or offload to the cloud. In this configuration, we establish atomic modules involved during the collaboration between MEC and cloud.
MEC execution. If the jth micro service in the micro-service set S i (0 < i ≤ n) is executed on the MEC platform, the completion time is given by (1) and the energy consumption of MEC platform is given by where MEC f is the computation power function related with CPU frequency, ij κ is a constant related to the hardware architecture, and MEC p is the energy consumption model proportional to 3 MEC f . Therefore, the completion time of MEC platform for micro-service S i (0 < i ≤ n) with m i micro services executed in parallel is given by Edge-cloud transmission. MEC transmits necessary input i α for micro-service set S i+1 when its buffer is full. The transmission bandwidth for MEC is defined as a constant B. L EC is the transmission distance from MEC to cloud.
Generally, the typical transmission delay of backhaul is a constant related with distance, e.g. 5us per kilometer. Then the loop transmission delay of output data i α (0 ≤ i ≤ n) between MEC and cloud is given by where t 0 is the transmission delay per kilometer and B is the transmission rate of backhaul between MEC and central cloud.
The energy consumption of output data i α (0 ≤ i ≤ n) transmission between MEC and cloud is given by Cloud execution. Similarly, if the jth micro service in the micro-service set S i−1 (0 < i ≤ n) is executed on the cloud, the completion time is given by and the energy consumption of cloud is given by where C f is the computation power function related with central CPU frequency, ij κ is a constant related to the hardware architecture, and C p is the energy consumption model proportional to 3 C f . Generally, cloud is more powerful and efficient than MEC with higher C f . Therefore, the completion time of cloud for micro-service S i (0 < i ≤ n) with m i micro services executed in parallel is given by

3) Markov Process
The collaborative task execution between MEC and cloud can be modeled by a directed acyclic graph G = (V, A), with the finite node set V and arc set A, as shown in Figure 2. We denote the number of nodes and arcs as |V| and |A|, re-Q. Y. Liu et al. spectively. Node i represents that the ith micro-service set S i is executed on MEC platform and node i' represents that the ith micro-service set S i is executed on cloud. We can find that |V| = 2n + 2 and |A| = 4n. However, cloud can complete the micro-service sets in advance without prior information from the output of MEC. Hence, the application task collaborated between MEC and cloud can be divided into two parts, as shown in Figure 3. The previous i − 1 nodes on cloud are independent from special MEC platform service. Hence, non-time limited and services independent task can be executed on cloud previously, such as pre-configuration and model training in machine leaning. The collaborative task execution between and cloud model is modified as the latter part, from node i + 1 or i + 1' to node n or n' in Figure 3. Hence, the number of nodes |V| and arcs |A| can be modified as |V| = 2n − i + 2 and |A| = 4n − 3i. State (i, j) represents the state where the current number of requests at MEC is i and at cloud is j. Let p ij be the stationary probability of state (i, j).
Unlike cloud, computing and cache resource are limited at MEC. The subsequence service has to be transmitted to the cloud if its request buffer is full. Hence, the micro-service sets executed on the MEC platform can be expressed as a modified M/M/c/K queue with cache capacity K 1 . And the arrival rate λ 1 and the response completion time obey negative exponential distribution with parameter as μ 1 .
where [ ]  is the average operator. Then, the micro-service sets executed on cloud can be modeled as a modified M/M/c/K queue with cache capacity K 2 . And the arrival rate λ 2 and the response completion time obeys negative exponential distribution with parameter as μ 2 .

Characterization of Optimal Solution to Task Scheduling Policy
The arc of the adjacent modes, i and j, is associated with the nonnegative delay t i,j for a corresponding service. Under this framework, we can transform the edge-cloud collaborative scheduling problem to the shortest distance route problem between node i and D, subject to the constraint that the expected completion time of that path should be less than or equal to the energy ceiling. A path p is feasible if the expected energy consumption satisfies the energy constraint. A feasible path p* with the minimum time delay is the optimal solution among all the feasible paths. Mathematically, it can be formulated as a constrained shortest path problem, where  is the set of all possible paths from node i to D and E max is the maximal energy consumption of the entire application. Since each micro service can be executed by offloading to MEC or on cloud, there are 2 n-i possible options for the solution. This constrained optimization problem is shown to be NP-complete. Based on the optimality of the one-climb policy, the minimal delay optimal execution only migrates once from MEC to the cloud after node i. Then, we design an efficient algorithm for task scheduling. We can enumerate all the paths under the one-climb policy rather than all the 2 n-i paths [20]. We define ′  as the set of all the paths under one-climb policy. There are ( )( ) ( ) 1 / 2 1 n i n i − + − + paths in ′  , thus the optimal solution is available by reformulating T into a series of linear programming problems with non-convex T.
The probability flows from the previous level to the current level are captured by the matrix 0 A with fixed ξ , for queue length from 0 to K 1 , and by the matrix 0 λξ = − A I for the other levels.
where I is the identity matrix. The queue length keeps the same with expression and where 1 ′ A and * 1 A are matrix for state (0, 0) and (K, K).
Finally, the matrix from the next state to the current state is given by Then the average delay are given by Searching space of the one-climb policy is much smaller than that of the brute-force search. Detailed procedures for solving minimal delay T are summarized as follows.

Performance Evaluation
In this section, we evaluated the performance of the proposed edge-cloud collaborative task scheduling scheme with independent task scheduling scheme. In this simulation, it is assumed that the input data packet obeys Poisson process.
Compared with the independent scheme, the workload ratio ξ is adaptive to obtain the minimal delay. Figure 4 illustrated the average delay comparison of cooperative and independent schemes with ARQ (Automatic Repeat-Request). Generally, edge-cloud collaborative scheme performs better than the independent scheme. The average delay gap is reduced as the workload increases with higher task density λ and less buffer size. In heavy workload scenario, high blocking probability with intensive retransmission is the most significant factor in average delay. Hence, the heavy workload case is a resource limited case. There is no extremely obvious difference whether MEC is configured with higher priority or not. Otherwise, high and inevitable transmission delay is a more critical factor in sparse task scenario. In this resource sufficient case, more task is executed at MEC platform until its buffer is full. Cooperative task scheduling obtains more performance gain than the independent scheme. Figure 5 illustrated the average delay comparison between different task scheduling policies with MEC deployed in edge DC and local DC. Compared with execution delay, transmission delay is a more significant factor in edge-cloud collaborative task scheduling with MEC deployed in different DC. Hence, the average delay is increased extensively with MEC deployed on a higher layer, especially with insufficient buffer size.

Conclusions
In this paper we investigated the problem of how to reduce the average delay of MEC application by collaborative task scheduling. The collaborative task scheduling is modeled as a constrained shortest path problem over a acyclic graph. By characterizing the optimal solution, the constrained optimization problem is simplified according to one-climb theory and enumeration algorithm. Generally, the edge-cloud collaborative task scheduling scheme performs better than independent scheme in reducing average delay. In heavy workload scenario, high blocking probability and retransmission delay at MEC is the key factor for average delay. Hence, more task executed on central cloud with abundant resource is the optimal scheme. Otherwise, transmission delay is inevitable compared with execution delay. MEC configured with higher priority and deployed close to terminals obtain more performance gain. For future work, we will consider various extensions of this work. First, more mathematical models of practical details in cloud computing are necessary to be considered in edge-cloud collaborative execution. Second, power saving on MEC and cloud platform is also important. In addition, the task workflow topology can be extended into more general modes.
neering Project of Ministry of Industry and Information Technology.

Funding
This work was support by Key R & D Program (Z91170GZX03011) grant from the Ministry of Science and Technology, Innovation and Development of Engineering Project of Ministry of Industry and Information Technology.