Keywords

1 Introduction

With multicore household PCs and smartphones being widespread in recent years, the types of applications covered by them became diverse. For instance, applications dealing with image processing, face recognition, and more heavy loaded ones can be handled by parallel processing schemes. Though cloud computing is based on the virtualization of computational resources such as CPU, RAM, and storage to achieve overcommitment, effectively utilizing them for various objectives is still a challenging issue. For instance, there is a problem regarding data communication overhead if the data size between a cloud system and a client can be a bottleneck. In such a case, an edge infrastructure [1], which takes the role of a bridge between them, is deployed. Furthermore, a large amount of data can be stored at the edge for data caching. In particular, storing data from mobile terminals such as smartphones or executing tasks of mobile terminals at the edge can save energy at mobile terminals. In such an offloading scheme [2,3,4,5,6,7,8], how to minimize the schedule length along with reducing energy consumption at the mobile terminal is a challenging task.

As for the job to be executed at a mobile terminal, a general representation can be expressed as a directed acyclic graph, or workflow [6,7,8], where each task has data dependencies with others as the precedence constraint. This job model is called as a mobile workflow job, and how to schedule tasks in a mobile workflow job is called an NP-complete problem.

In this paper, we propose a task scheduling algorithm with task offloading, called priority-based continuous task selection for offloading (PCTSO), for mobile workflow in an edge cloud environment. The PCTSO algorithm tries to check whether each task should be executed at the mobile terminal. If not, the task is offloaded to the edge cloud with generating the new communication between the mobile terminal and the edge cloud. The proposed algorithm is based on a list-scheduling scheme and the objective is to minimize the schedule length along with satisfying the energy consumption constraint. Experimental results of the simulation demonstrate that PCTSO outperforms other algorithms in terms of the schedule length along with satisfying the energy constraint.

The remainder of this paper is organized as follows. Section 3 describes the assumptions and the basics for understanding the proposed algorithm. Section 4 presents and explains the details of the proposed algorithm. Section 5 presents the experimental results. Section 2 shows the related work in terms of task offloading. Finally, Sect. 6 concludes this paper.

2 Related Work

Literature [2] proposes a task offloading algorithm for minimizing the total energy consumption at a mobile client with satisfying the deadline for task execution. Literature [3] proposes a task offloading algorithm by checking each time slot whether a task should be locally executed or offloaded. This approach aims to minimize the total delay for whole task execution with satisfying the energy constraint with linear programming. Literature [5] assumes multi-user environment with weighting both the response time and the energy consumption depending on each user’s requirement.

As for task offloading for a workflow, literature [6,7,8] have been proposed. Task offloading can be applied for fault tolerance purpose in order to resume the task execution in a cloud [6], or load balancing among a cloud and a mobile client [8]. In literature [7], each task is offloaded to a cloudlet to minimize both the execution delay and the energy consumption at a mobile client. If one task is accepted for offloading to a cloudlet, successor tasks of the task are checked if they can be offloaded the same cloudlet or not. If both the execution delay and the energy consumption are reduced by offloading them, they are assigned to the cloudlet.

Above mentioned algorithms check each task for offloading in one-by-one basis. As a result, offloaded tasks and locally executed tasks may exist on a path in a workflow. This characteristics can lead to the fact that many tasks cannot be offloaded and therefore the energy consumption at a mobile client cannot be reduced so much. In PCTSO algorithm, the set of tasks in a path are selected for offloading. Thus, more tasks can be offloaded than conventional algorithms, thereby the reduction of the energy consumption is achieved.

Fig. 1.
figure 1

Assumed situation

Full size image
Table 1. Notations for objective function.
Full size table

3 System Model

In this section, we describe the assumed system, jobs to be handled in the system, and the objective function. Table 1 shows whole definitions used in this section.

3.1 Assumed System

In an edge cloud system, we assume there is an edge cloud server having multiple VM instances, where the set of available vCPUs (virtual CPUs) is defined as \({C_{vcpu}}\) and \({C_{vm}}\) as the set of VM instances (i.e., \({|C_{vm}| \le |C_{vcpu}|}\)). The i-th VM instance is defined as \({v_i}\), and the j-th vCPU in the i-th VM instance is defined as \({c_{i,j} \in C_{vcpu}}\). We suppose that an edge cloud server has the fixed number of VM instances, i.e., \({|C_{vm}|}\) is the fixed value and no more VM instances cannot be launched.

Since each VM instance can have one or more vCPUs, let the number of vCPUs in \({v_i}\) is defined as \({N_{vcpu}^i \ge 1}\). Let the processing speed for each vCPU be the same as \({\alpha _{vm}}\). The set of mobile clients is defined as M, and each mobile clients as \({m_i \in M}\). The processing speed at i-th mobile client is defined as \({\alpha _i}\).

3.2 Assumed Job Model

As for a workflow job, it is known as an abstraction of a job, in which each task has data dependencies with others. Each task corresponds to a set of instructions, i.e., one executable file or one execution unit. In this paper, we rename a workflow job as “workflow”. Each mobile client has one workflow to be executed. Let the number of workflows be M, i.e., the number of mobile clients. Each workflow is expressed as \({W_k=G_k(V_k, E_k)}\), and the set of workflows is defined as W. However, for simplicity of notation of workflows, each workflow job is supposed to be combined into a larger workflow as W for scheduling, where \({W=G(V,E)}\) and each task and edge are defined as \({t_i \in V}\) and \({e_{i,j}\in E}\), respectively. The pseudo START task \({t_{pstart}}\) and the pseudo END task \({t_{pend}}\) are added to generate the “merged workflow” by connecting them to every workflow, where \({w_{pstart}=w_{pend}=0}\). By generating such a merged workflow, every task can be simultaneously taken into account for prioritizing of scheduling [15].

In a workflow, let \({pred(t_i)}\) be the set of predecessor tasks of \({t_i}\), and let \({suc(t_i)}\) be the set of successor tasks of \({t_i}\). If \({pred(t_i) = \emptyset }\), \({t_i}\) is called the START task, and if \({suc(t_i) = \emptyset }\), \({t_i}\) is called the END task.

Figure 1 describes how each workflow is merged into W and how each task is assigned. In this figure, three workflows, i.e., \({W_1, W_2, }\) and \({W_3}\) are merged into W. In W, the pseudo START task and the pseudo END task are added as the new START task and the END task. Without loss of generality, both their workloads, the communication time from the pseudo START task, and the communication time to the pseudo START are set to zero. In this assumption, several tasks in W is assigned to vCPUs on the edge cloud server.

3.3 Cost Model

The workload of \({t_i}\) is \({w_i}\) and the resultant data size of \({t_i}\), i.e., that must be sent from \({t_i}\) to \({t_j}\) is defined as \({d_{i,j}}\). As for the pseudo START task and the pseudo END task, we assume \({w_{pstart}=w_{pend}=0}\) and \({d_{pstart, i}=d_{j,pend}=0}\) for \({\forall t_i, t_j \in V}\). The processing time of \({t_i}\) on \({m_k}\) is defined as

$$\begin{aligned} T_p(t_i, m_k) =\frac{w_i}{\alpha _k}, \end{aligned}$$
(1)

and the communication time of \({d_{i,j}}\) over the wireless link between \({m_k}\) and the edge cloud server is defined as

(2)

where \({A(t_i)}\) is the assignment target of \({t_i}\), and \({A(t_i) \in C_{vcpu}}\) means that \({t_i}\) is executed on a vCPU in the cloud. \({r_k}\) is the data rate of wireless communication between the edge cloud server and \({m_k}\), which is defined by Shannon’s theorem as follows:

$$\begin{aligned} r_k = \beta _k \log _2{\left( 1+\dfrac{p_kg_k}{\omega + \sum _{i\ne k, CN_i =CN_k}{p_i g_i}}\right) }, \end{aligned}$$
(3)

where \({\beta _k}\) is the communication bandwidth of \({m_k}\), \({p_k}\) is the transmission power and receiving power of \({m_k}\), \({g_k}\) is the channel gain between \({m_k}\) and a base station, \({\omega }\) is the background noise power, and \({CN_k}\) is the communication channel used by \({m_k}\). It is obvious that \({r_k}\) becomes smaller if more mobile terminals use the same channel as \({m_k}\).

As for the energy consumption for executing \({t_i}\) on \({m_k}\), it is defined as \({E_{exec}(t_i, m_k)}\), and for transmitting \({e_{i,j}}\) from the edge cloud server to \({m_k}\), or \({m_k}\) to the edge cloud is defined as \({E_{in}(e_{i,j}, m_k)}\) or \({E_{out}(e_{i,j}, m_k)}\), respectively. They are defined as follows:

$$\begin{aligned} E_{exec}(t_i, m_k)= & {} \tau _k w_i, \end{aligned}$$
(4)

where \({\tau _k}\) is the coefficient determined for each \({m_k \in M}\) in terms of the energy consumption per cycle; that is, we assume \({w_i \varpropto E_{exec}(t_i, m_k)}\) for \({\forall m_k \in M, \forall t_i \in V}\). As for the energy consumption related to sending the data to a mobile client and the edge cloud server, we define

$$\begin{aligned} E_{in}(e_{i,j}, m_k)= & {} p_k T_c(d_{i,j},r_k), A(t_i) \in C_{vcpu},\nonumber \\ E_{out}(e_{i,j}, m_k)= & {} p_kT_c(d_{i,j},r_k), A(t_j) \in C_{vcpu}. \end{aligned}$$
(5)

3.4 Schedule Length

In this section, we present how the start time of each task \({t_i}\) on \({A(t_i)}\), i.e., \({T_s(t_i, A(t_i))}\) is determined when scheduling tasks and how the schedule length is derived. At first, we define several notations for deriving both \({T_s(t_i,A(t_i))}\) and the schedule length. Suppose the finish time of \({t_i}\) is defined as \({T_f(t_i, A(t_i))}\), then we have

$$\begin{aligned} T_f(t_i, A(t_i)) = T_s(t_i, A(t_i))+T_p(t_i, A(t_i)), \end{aligned}$$
(6)

where \({A(t_i) \in M \cup C_{vcpu}}\). The set of free tasks is defined as fList; that is, the set of tasks whose predecessor tasks have been scheduled. For each task in fList, the data ready time can be derived. Data ready time (DRT) is the maximum data arrival time from all predecessor tasks. Note that DRT is the earliest start time for each task and the actual start time can be later than DRT. This is because \({t_j}\) cannot start execution when a task \({t_h\notin pred(t_j)}\) such that \({A(t_h) = A(t_j)}\) is scheduled before \({t_j}\). DRT of \({t_j}\) at \({m_k}\) is derived as follows:

$$\begin{aligned} T_{dr}(t_j)= & {} \mathop {\max }\limits _{\scriptstyle t_i \in pred(t_j )} \left\{ {T_f (t_i, A(t_i)) + T_c(d_{i,j}, r_k)} \right\} , \end{aligned}$$
(7)

where \({T_c(d_{i,j}, r_k)=0}\) if \({A(t_j) \in C_{vcpu}}\) and \({A(t_i) \in C_{vcpu}}\), or both \({t_i}\) and \({t_j}\) are assigned to \({m_k}\) by the definition given by (2). Then we can derive the start time, i.e., \({T_s(t_j,A(t_j))}\) with DRT as follows:

$$\begin{aligned} T_s (t_j,A(t_j))= & {} \max \left\{ {\mathop {\max }\limits _{\scriptstyle t_i \notin pred(t_j ), \atop \scriptstyle A(t_i ) = A(t_j ) } \left\{ {T_f (t_i, A(t_i))} \right\} ,T_{dr} (t_j )} \right\} . \end{aligned}$$
(8)

The schedule length is the finish time of the END task and is defined as follows:

$$\begin{aligned} T_f(t_{end}, A(t_{end}))=T_s(t_{end}, A(T_{end}))+T_p(t_{end},A(t_{end})), \end{aligned}$$
(9)

3.5 Objective Function

The original energy consumption of \({W_i}\) at \({m_l}\) is \({\sum _{t_k \in V_i}{E_{exec}(t_k,m_l)}}\). With aforementioned definitions, the objective function is defined as follows:

Objective Function 1

Minimize \({T_f(t_{end}, A(t_{end}))}\)

subject to :

$$\begin{aligned}&\sum _{A(t_i)=m_k}{E_{exec}(t_i,m_k)}+\sum _{A(t_i)\in C_{vcpu}, \atop A(t_j)=m_k}{E_{in}(e_{i,j},m_k)}+\sum _{A(t_i)=m_k, \atop A(t_j) \in C_{vcpu}}{E_{out}(e_{i,j},m_k)}\nonumber \\&\le \sum _{t_j \in V_i}{E_{exec}(t_j,m_k)} for \ \forall m_k \in M, \ and \nonumber \\&T_f(t_{end}^i) \le \sum _{t_j^i \in V_i}{T_{p}(t_j^i,m_k)}\ for \ \forall m_k \in M. \end{aligned}$$
(10)

4 PCTSO Algorithm

4.1 Overall Procedures

As defined in Sect. 3.2, each workflow job is supposed to be merged into a larger one, i.e., \({W=G(V, E)}\). From (10), each mobile client’s energy consumption for the task scheduling algorithm must be lower or equal to the original execution.

Initially, each mobile client \({m_k}\) has its own workflow \({W_k=G_k(V_k, E_k)}\). The initial schedule length \({SL_{init}(W_k)}\) and the initial energy consumption \({E_{init}(m_k)}\) are defined as follows:

$$\begin{aligned} SL_{init}(W_k)= \sum _{t_i \in V_k}{\dfrac{w_i}{\alpha _k}}, E_{init}(m_k) = \sum _{t_i \in V_k}{E_{exec}(t_i, m_k)} = \tau _k \sum _{t_i \in V_k}{w_i}. \end{aligned}$$
(11)

From the objective function in Sect. 3.5, the PCTSO algorithm tries to achieve \({T_f(t_{end},A(t_{end})) \le SL_{init}(W_k)}\) and \({E_{init}(m_k) }\) must be made smaller for each \({m_k \in M}\).

Algorithm 1 presents the entire procedure of the PCTSO algorithm. From lines 2 to 14, PCTSO iterates procedures to output the schedule during \({UEX \ne \emptyset }\). At line 3, \({t_{pivot}}\), having the maximum level value in fList is selected, where fList is the free task list. A task is called “free” if and only if all its predecessor tasks have been scheduled. Then, at line 4, the set of continuous tasks \({S_{free}}\), starting from \({t_{pivot}}\), is generated by calling CTSO as Algorithm 2. Then, for each task in \({S_{free}}\), it is assigned to the idle time slot of a vCPU to start execution as early as possible. Then PCTSO updates both UEX and fList by tracing suc(t), where \({t \in S_{free}}\) (lines 9–10 or 12 to 14). When all tasks have been traced, i.e., \({UEX = \emptyset }\), PCTSO finishes.

figure a
figure b

In the following sections, we present (i) the criterion for selecting a pivot task from fList and (ii) the criterion on how the set of tasks is selected for offloading to the edge cloud server or the mobile client.

4.2 Pivot Task Selection Policy

We provide details regarding the task selection policy from the free task list (fList). The remaining time duration from \({t_i}\) to the END task on \({m_k}\) is defined as

$$\begin{aligned} rlevel(t_i)= & {} \mathop {\max }\limits _{t_j \in suc(t_i )} \left\{ {T_c (d_{i,j} ,r_k ) + T_p (t_j ,A(t_j )) + rlevel(t_j )} \right\} . \end{aligned}$$
(12)

As the start time of \({t_i}\) can be derived by (8) by assuming that \({t_i}\) is executed on \({m_k}\). Then, the priority for the task selection i.e., \({level(t_i)}\) is defined as

$$\begin{aligned} level(t_i)= & {} T_s(t_i, A(t_i)) + T_p(t_i,m_k)+rlevel(t_i), \end{aligned}$$
(13)

where \({T_s(t_i, A(t_i)) }\) is the start time when \({t_i}\) is executed on \({m_k}\). \({level(t_i)}\) is the dominant path for the schedule length if every task that can be executed after \({t_i}\) is allocated to respective cloud, provided that \({r_k}\) dominates the bandwidth. PCTSO algorithm tries to minimize the schedule length by minimizing the start time of a task in the dominant path. For each task \({\in fList}\), the task satisfying the following condition is selected for scheduling.

$$\begin{aligned} \mathop {\max }\limits _{\scriptstyle t_i \in fList} \left\{ level(t_i) \right\} . \end{aligned}$$
(14)
Fig. 2.
figure 2

Example of continuous task selection for offloading

Full size image

4.3 Continuous Task Selection for Offloading

There is no guarantee that both the schedule length and the energy consumption at the mobile client \({m_k}\) are made smaller by assigning a task to a vCPU. Thus, assigning a task to a vCPU is accepted if both the schedule length and the energy consumption are made smaller by inserting an idle time slot of the vCPU. Here, we model how the schedule length is reduced as follows. First, suppose that the selected task is \({t_i \in fList}\) and \({t_i}\) is supposed to be offloaded to a vCPU \({c_{p,q}}\) from \({m_k}\). Then, we have the time difference generated by offloading \({t_i}\) as follows:

$$\begin{aligned} \varDelta T_p(t_i) = T_p(t_i, c_{p,q})-T_p(t_i, m_k), \end{aligned}$$
(15)
$$\begin{aligned} \varDelta T_s(t_i) = T_s(t_i, c_{p,q})-T_s(t_i, m_k), \end{aligned}$$
(16)

and \({T_c(d_{i,j},r_k)}\) is newly generated, where \({t_j \in suc(t_i)}\) and \({t_j}\) is placed at \({m_k}\). Thus, one condition to reduce the schedule length by offloading \({t_i}\) is

$$\begin{aligned} \varDelta SL(t_i) = T_c(d_{i,j},r_k)+\varDelta T_p(t_i) +\varDelta T_s(t_i, A(t_i)) \le 0, \end{aligned}$$
(17)

where \({\varDelta SL(t_i)}\) is the increment of the schedule length in case that no data waiting time is generated for all tasks that are scheduled after \({t_i}\). Even if \({\varDelta SL(t_i)>0}\) by offloading \({t_i}\), there is one possibility for \({\varDelta SL(t_i \cup t_j) \le 0}\) by offloading \({t_i}\) and \({t_j}\), where \({t_j \in suc(t_i)}\) when \({T_c(d_{i,j}, r_k)}\) is much larger than \({T_p(t_j, A(t_j))}\) because \({T_c(d_{i,j}, r_k)}\) is localized among VMs in a cloud. Thus, offloading several tasks, having dependencies on each other, can lead to the reduction of both schedule length and energy consumption at a mobile client. Here, suppose that \({t_i}\) is selected from fList as a candidate for offloading and we assume that \({t_{i+1} \in suc(t_i), t_{i+2} \in suc(t_{i+1}), \dots , t_{i+r} \in suc(t_{i+r-1})}\). At \({t_{i+j} \in suc(t_{i+j-1})}\), suppose that tasks in \({pred(t_{i+j})}\) have already scheduled, except for \({t_{i+j-1}}\). We define such tasks as being put into \({S_{free}}\); that is, tasks satisfying the following condition are put into \({S_{free}}\).

$$\begin{aligned} \varDelta SL(S_{free})= & {} T_c(d_{i+r,s},r_k) + \sum _{t_i \in S_{free}}{\varDelta T_p(t_i)}+\varDelta T_s(t_i) \le 0, \end{aligned}$$
(18)

where \({t_s}\) is supposed to be placed on \({m_k}\). Figure 2 shows an example of how \({S_{free}}\) is generated, provided that \({t_i}\) is selected from fList. This figure assumes that \({\varDelta SL(S_{free}) >0}\) for \({S_{free}=\{t_i\}}\) such as (b), while \({\varDelta SL(S_{free}) <0}\) if more tasks are added to \({S_{free}}\) such as (c) and (d). From Fig. 2(b), (c), and (d), we observe that the main factor for \({\varDelta SL(S_{free})>0}\) is the communication time between a vCPU in \({C_{vcpu}}\) and the mobile client \({m_k}\), which occurs at the output data communication of the last task in \({S_{free}}\). If such a communication time is small with compared to the sum of the task execution times of \({S_{free}}\), i.e., \({\varDelta T_p(S_{free})}\), we can have \({\varDelta SL(S_{free}) <0}\). Thus, even if we have \({\varDelta SL(t_i) >0}\), \({\varDelta SL(S_{free}) <0}\) is possible depending on the relationship between the newly generated communication time and the sum of the processing times in \({S_{free}}\).

As for the energy constraint, for all tasks \({\in V_k}\), the following condition must be satisfied to schedule the selected task.

$$\begin{aligned}&\sum _{A(t_i)=m_p}{E_{exec}(t_i,m_p)}+\sum _{A(t_i)\in C_{vcpu}, \atop A(t_j)=m_p}{E_{in}(e_{i,j},m_p)}+\sum _{A(t_i)=m_p, \atop A(t_j) \in C_{vcpu}}{E_{out}(e_{i,j},m_p)} \nonumber \\&< \sum _{t_j \in V_i}{E_{exec}(t_j,m_p)}. \end{aligned}$$
(19)

If both (18) and (19) are satisfied, each task in \({S_{free}}\) is selected for scheduling and is inserted into an idle time slot of a vCPU s.t, \({T_f(t_k, c_p)}\) is minimized, where \({t_k \in S_{free}}\).

The detailed algorithm to derive \({S_{free}}\) is shown in Algorithm 2, called continuous task selection for offloading (CTSO). During lines 4 to 16, CTSO tries to construct \({S_{free}}\) by tracing successor tasks of \({t_{pred}}\) in \({S_{free}}\). At line 8, if \({\varDelta SL(S_{free})}\) takes the minimum value and \({SL(S_{free})\le 0}\), \({S_{free}}\) is updated by adding the task t as \({t_{min}}\). Otherwise, \({S_{free}}\) is not varied as line 13 and 15. As procedures in lines 4 to 16 assume that \({S_{free}}\) has two or more entries, at line 17, CTSO checks the case of \({S_{free}=\{t_i\}}\). Then, CTSO returns \({S_{free}}\). The condition for offloading \({t_i}\) is accepted is \({\varDelta SL \le 0}\); that is, during that each task is added to \({S_{free}}\), the algorithm finds \({S_{free}}\) such that \({\varDelta SL(S_{free})}\) is minimized and \({\varDelta SL(S_{free}) \le 0}\). As \({\varDelta T_s(t_i, A(t_i))}\) is not varied during each task is added to \({S_{free}}\), we have only to see the behaviors of \({T_c(d_{i+r, s},r_k)}\) and \({\sum _{t_i \in S_{free}}{\varDelta T_p(t_i)}}\).

5 Experimental Results

5.1 Objective and Method

We conducted preliminary experimental comparisons by a simulation and confirmed advantages of PCTSO algorithm in terms of:

  • The schedule length obtained by PCTSO is smaller than conventional algorithms [7, 8] with satisfying the energy constraint.

  • The energy consumption is reduced in an acceptable level or not.

Conventional algorithms other than [7, 8] cannot be compared in the simulation because the objective function, the assumed situation such as the deadline is imposed or not for the schedule length, and the assumed job model are different from PCTSO.

The simulation was developed on CloudSim [11] with incorporating WorkflowSim [12]. The development and running platform are jdk1.7.0.51, and the CPU is a Intel(R) Core i7-5600U 2.6 GHz with 8-GB memory. Table 2 shows the simulation parameters. shows simulation parameters. We used randomly generated workflows and Montage [14], which is used for creating a custom mosaics from images, similar to image processing on mobile phones.

In other comparison targets described in Sects. 5.2 and 5.3, we compared the schedule length of PCTSO with the algorithm having one-by-one task checking basis; that is, if the schedule length or the energy consumption is made larger if one task is offloaded, the task is assigned to the mobile client, not taking its successor tasks into account. We name this case as “Non-PCTSO”. Also we compared PCTSO with algorithms [7, 8], named as “Cloudlet” [7] and “LB” [8] in this paper, respectively. The objective of “Cloudlet” is to minimize both the schedule length and the energy consumption, while that of “LB” is the balance the assigned workload among the cloud and a mobile user.

As a comparison metric, we use schedule length ratio (SLR)[9].

$$\begin{aligned} SLR= & {} \frac{SL}{\sum _{t_k \in CP_w}{T_p(t_k, c_{i,j})}}, \end{aligned}$$
(20)

where \({CP_w}\) is the critical path of W in terms of the total execution time on a path; that is, only the workload of each task on a path is considered and the data size for each edge on the path is not. SL in (20) is the schedule length of W. As we assume every vCPU to have the same frequency, \({c_{i,j}}\) in (20) takes the same value among vCPUs.

Table 2. Setup parameters for the simulation
Full size table

5.2 Comparison by Single Workflow

We conducted comparisons for single random workflow and Montage workflow. Both the schedule length and the energy consumption are averaged by 100 tries with varying CCR [10], the number of tasks. Figure 3 shows the comparison results in terms of the SLR for those workflows. For Fig. 3(a) and (b), we observe that the schedule length by PCTSO has the smallest in the all CCR cases. In particular, the difference of SLR between that of PCTSO and that of Non-PCTSO gets larger in cases of CCR = 7.0 and 10.0. This is because that only tasks having small outgoing data are offloaded in Non-PCTSO and a few number of tasks are offloaded. In PCTSO, more tasks are executed in the edge cloud and energy consumption is reduced with compared to other algorithms. Table 3 shows the comparison results of the energy consumption by single workflow, i.e., random workflow and Montage workflow. Values in the table is the reduction ratio to the original execution, i.e., all tasks are executed at the mobile client. PCTSO only guarantees that the energy consumption with PCTSO is lower than that of original execution, and it does not try to minimize it. However, since the number of offloaded tasks in PCTSO is larger than that of Non-CTSO, the energy consumption by PCTSO is better than Non-CTSO, Cloudlet and LB in all CCR cases. From these results we can conclude that continuously assigning dependent tasks can lead to the effective energy reduction.

Fig. 3.
figure 3

Comparison of SLR by single workflow.

Full size image
Table 3. Comparison of energy saving in single workflow.
Full size table

5.3 Comparison by Multiple Workflows

The schedule length in the multiple workflow case is the maximum makespan among multiple workflows, and we averaged the schedule length in 100 tries for each case of multiple workflows, i.e., 5, 10, 20, 30, 50 workflows. Figure 4 shows the results of SLR in multiple workflows. From Fig. 4(a) (b), it can be seen that PCTSO outperforms other algorithms in terms of SLR in every case, which is similar to the single workflow case.

As for the energy consumption, we derived the reduction ratio in mobile clients, and Table 4 shows the averaged reduction ratio for each number of workflows. In every case, the energy consumption by PCTSO is the highest, while the energy consumption ratio by Non-CTSO is lower than that of Cloudlet and LB. From this results, continuous task selection in multiple workflows can lead to the reduction of both the schedule length and the energy consumption.

Fig. 4.
figure 4

Comparison of SLR by multiple workflow.

Full size image
Table 4. Comparison of energy saving in multiple workflows.
Full size table

6 Conclusion

In this paper, we proposed a task scheduling algorithm with offloading tasks to an edge cloud, called PCTSO. PCTSO is based on offloading tasks and priority based scheduling algorithm. PCTSO tries to continuously select dependent tasks for offloading in order to minimize the schedule length under the energy constraint. From experimental results, we conclude that PCTSO can be applied to the case that multiple workflows must be finished as early as possible, with reducing the energy consumption for each mobile client.

As a future work, we take the mobility of each client into account, and we will implement PCTSO as a realistic software.