# Prediction-Based Resource Deployment and Task Scheduling in Edge-Cloud Collaborative Computing

Authors: Mingfeng Su; Guojun Wang; Kim-Kwang Raymond Choo
Journal: Wireless Communications and Mobile Computing
 (2022)

---

## Abstract

Edge computing is becoming increasingly commonplace, as consumer devices become more computationally capable and network connectivity improves (e.g., due to 5G). With the rapid development of edge computing and Internet of Things (IoT), the use of edge-cloud collaborative computing to provide service-oriented network application (i.e., task) in edge-cloud IoT has become an important research topic. In this paper, we present an edge-cloud collaborative computing framework and our resource deployment algorithm with task prediction (RDAP). Based on our paradigm, tasks in the cloud service center are predicted using the two-dimensional time series, and task classification aggregation and delay threshold determination are combined to optimize task resource deployment of edge servers. A task scheduling algorithm with Pareto improvement (TSAP) is also proposed. At the edge servers, the Pareto progressive comparison is conducted in two stages to obtain the tangent point or any intersection point of the two objective curves of user’s quality of service and effect of system service to optimize task scheduling. The experimental results show that for varying user task scales and different Zipf distributionα parameters, combining RDAP and TSAP (RDAP-TSAP) can improve the average user task hit rate. In addition, the average task completion time of users, the overall system service effect, and the total task delay rate of RDAP-TSAP are better than TSAP and the benchmark algorithms for task scheduling.


---

## Body

## 1. Introduction

As Internet of Things (IoT) and other related consumer devices (e.g., Internet of Vehicles and home/medical IoT) become more interconnected and pervasive in our digitally aware environment, there is a need for data analytics to be performed closer to the data sources [1–3]. Doing so allows us to improve users’ quality of service, minimize latency, achieve privacy (to some extent), etc. This partly motivates network computing modes such as fog computing [4], transparent computing [5], edge computing [6, 7], and mobile edge computing [8].In this paper, we focus on edge-cloud collaborative computing in edge-cloud IoT, to leverage the advantages of both cloud and edge computing for a range of services, such as data transmission, resources distribution, and service-oriented network application (i.e., task) offloading. By improving data collaborative processing of both cloud and edge servers, we can potentially minimize data processing delays, improve system scalability, achieve improved system services, etc. In addition, data may have spatiotemporal characteristics such as seasons [9–11], where there is periodic and trend information (explicit and implicit) in the spatiotemporal dimension. In other words, data changes or trends can be effectively predicted [12–14]. To implement edge-cloud collaborative computing in the edge-cloud IoT, cloud service center generally requires massive computing resources to perform data/predictive analytics, which can subsequently be used to guide the deployment of resources required for task operation of edge layer and promote efficient use of resources [15, 16]. At the edge layer, the edge server can balance the needs of users and service providers through task collaborative offloading, and optimize task scheduling with multiple objectives, so as to enhance user service experience and improve the overall performance.In edge-cloud IoT, the optimization of service caching (i.e., task resources) and task offloading (i.e., task scheduling) need to solve two problems. (1) The task load of different edge servers changes dynamically over time, and it is necessary to formulate a task resource push strategy according to task changes. (2) Task scheduling should not only consider the needs of users and shorten the task completion time, but also consider the interests of service providers and reduce the overall energy consumption of the system. Therefore, in edge-cloud IoT, we consider edge-cloud collaborative computing and introduce task prediction to study resource deployment and task scheduling optimization. The main contributions are as follows:(i)
A resource deployment algorithm with task prediction (RDAP) is proposed. In the cloud service center, task predictive analytics draw upon both horizontal and vertical time dimensions, and the deployment of resources required for the task operation of the edge servers is optimized to improve the average task hit rate (ATHR)(ii)
A task scheduling algorithm with Pareto improvement (TSAP) is proposed. At the edge server, considering the benefits of users and service providers, Pareto improvement is made to the two objectives of user’s quality of service (QoS) and effect of system service (ESS) to optimize task scheduling(iii)
An edge-cloud collaborative computing framework is proposed, and an experimental environment for edge-cloud collaborative computing is constructed. Considering the impact of different user scales and Zipf distributionα parameters, the task scheduling is evaluated and analyzed from the average task completion time (ATCT), overall system service effect (OSSE), and total task delay rate (TTDR).The rest of this paper is organized as follows. In Section2, we introduce the related work. We present our designed framework and model of edge-cloud collaborative computing in Section 3. Then, in Sections 4 and 5, we, respectively, describe the task prediction and the resource deployment and task scheduling. Our evaluation setup and findings are presented in Section 6. Finally, we conclude this paper in Section 7.


## 2. Related Work

Task sharing on demand is one common application in our digitalized society [17, 18], and one of the key challenges is how to improve the QoS by reducing the task completion time. For example, Mao et al. [19] used reinforcement learning and neural network to design scheduling algorithm according to specific workloads, to efficiently schedule data processing jobs, and minimize the average job completion time in distributed clusters. Jalaparti et al. [20] proposed a scheduling method combining data placement and computational optimization to reduce cross rack data transmission and decrease task completion time. Ren et al. [21] predicted the stragglers in the cluster center, by leveraging the copy mechanism. Their approach also considers data location, task execution time, and task interdependence to reduce task delay in centralized and decentralized scheduling. To achieve increased ESS, cloud computing servers could attempt to enhance resource utilization and reduce system costs [22–24]. For example, Andrew et al. [25] put forward a new cluster scheduler for public IaaS platforms. Their scheduler is designed to dynamically allocate virtual machine (VM) instances to improve resource utilization and reduce costs. Liu et al. [26] proposed a joint execution strategy based on an improved genetic algorithm to reduce the overall energy consumption of the system. Nishtala et al. [27] designed a scalable QoS aware task management method, which uses deep reinforcement learning to reduce contention of shared resources, and minimizes data center energy consumption while ensuring QoS. These studies centrally execute user tasks in the cloud computing center. When task requests increase, coupled with reasons such as long transmission distances and limited backhaul links, problems such as high delay and increased energy consumption are likely to occur. The traditional cloud computing model is facing new challenges.To mitigate some of the limitations associated with cloud computing, there have been attempts to utilize edge computing to offload all or part of the computationally intensive tasks to the edge servers and extend the computing power to the edge layer. Such an approach can potentially reduce data processing delays [28]. For example, Rodrigues et al. [29] proposed a method to minimize service delay, by offloading tasks that users cannot run to cloudlet servers at the edge network. They also attempt to reduce processing and transmission delays of tasks through VM migration and transmission power control. Mao et al. [30] presented a Lyapunov optimization-based dynamic computation offloading algorithm, which focuses on minimizing execution delay and execution cost of task failure, maximizing battery capacity of mobile devices, and gradually optimizing computationally intensive workloads to improve QoS and user’s quality of experience (QoE). Chen et al. [31] used a mixed-integer nonlinear programming method to optimize task dispatch and resource allocation, solve mobile edge computing ultra-dense network task offloading, and minimize delays under the premise of considering device battery life. He et al. [32] proposed an incentive mechanism for online auction, which offloads user tasks to neighboring mobile devices to meet low latency requirements. However, these studies mainly focus on user’s service needs and reduce the task completion time to optimize task offloading. Task offloading lacks consideration of system energy consumption optimization for service providers.To enhance both QoS and ESS, edge computing needs to think of task offloading, network load, resource allocation, and transmission delay [33–35]. Wang et al. [36] proposed a local optimization algorithm for the univariate search technology, which introduces dynamic voltage scaling technology in computational offloading, and uses variable replacement technology to find the optimal solution to minimize mobile energy consumption and application execution delay. Dinh et al. [37] put forward a task offloading framework from mobile devices to multiple edge devices, considering both fixed and flexible mobile device CPU frequencies based on the semi-definite relaxation approximation method to enhance task execution delay and device energy consumption. Zhang et al. [38] raised an energy-aware computing offloading scheme, which optimizes communication resources and computing resources allocation under limited energy and delay conditions, and finds out the hybrid nonlinear integer optimal solution of computing offloading and resource allocation through an iterative search algorithm. Wang et al. [39] came up with an optimal resource allocation scheme that combines AP energy transmission consumption, CPU processing frequency, user offloading file size, and user time allocation. The scheme thinks of computing and wireless power transmission to minimize the total AP energy consumption under the constraint of individual computing delay. Ding et al. [40] proposed a decentralized offloading strategy in a mobile edge computing environment with limited user equipment resources. The task execution location, CPU frequency, and transmission power are optimized based on code partition offloading to minimize application execution time and energy consumption. The above research work mainly considers task offloading. It is assumed that the edge server already has the relevant service cache required to execute the task, and service cache is also called task resource. When tasks are offloaded to edge servers, only the computing resource constraints are considered, but task resource constraints are not considered. However, in practical applications, the storage resources of edge servers are limited, and it is difficult to cache all task resources required for task execution [41]. It is necessary to dynamically formulate task resource deployment strategy according to the actual situation, and jointly optimize task resource and task offloading.Therefore, the cloud computing capability is extended to the edge servers in edge-cloud IoT, and the edge-cloud collaborative computing framework is proposed. The task prediction is introduced to study the resource deployment and task scheduling optimization in the edge-cloud collaborative computing environment, and improve both QoS and ESS for users and service providers.


## 3. Framework and Modeling of Edge-Cloud Collaborative Computing

In this section, we first design the edge-cloud collaborative computing framework, and then model the edge-cloud collaborative computing, including quantifying user’s quality of service and effect of system service. The main symbols and descriptions of this paper are shown in Table1.Table 1
Description of main symbols.
SymbolsDescriptionUSet of userJSet of taskESet of edge servercCloud service centerqujQoS’s coefficient of useru task jrujSystem service revenue coefficient of useru task jωu,ejProportion of task performed on receiving edge server for taskjωe,ejProportion of task assigned by the receiving edge server to other edge servers for taskjωe,cjProportion of task assigned by the receiving edge server to cloud service center for taskjfejBinary variable, 1/0 indicates whether the edge servere can execute the task j or notlujThe size of the taskj for the end user ukujBinary variable, 1/0 indicates whether the useru has the request task j or notDDistance coefficient between nodesdx,yDistance degree between nodesx and yμTask execution preference weight coefficientβRevenue indexδComputing resourcesεStorage resourcesΔTask type, binary variable, 1/0 refers to time-sensitive and time-insensitive tasks, respectivelyτTask execution time equivalent∂Average server energy consumption coefficientξTask delay occurrence threshold


### 3.1. Edge-Cloud Collaborative Computing Framework

The edge-cloud collaborative computing framework is divided into the cloud layer, edge layer, and sensor layer, which are interconnected through the Internet. As shown in Figure1, edge-cloud collaborative computing can be applied in scenarios such as smart transportation, telemedicine, and environmental monitoring. The cloud layer includes a cloud service center, which is composed of some hardware such as homogeneous or heterogeneous computing, storage, network, and other hardware. The cloud service center uses virtualization, software defined network, redundancy, and other technologies to supply high-performance, highly reliable, and scalable resources to support a wide range of on-demand services for users. Control flow (CF) is generated between the cloud layer and edge layer. The cloud service center predicts the user task, and pushes the task resources to the edge servers through the CF in advance according to the prediction result. Task resources include software and software-dependent data required for task operation. The cloud service center monitors the task processing and resource utilization of the edge servers in real-time, summarizes the task processing and resource utilization of each edge server, and then distributes them to other edge servers through the CF.Figure 1
Edge-cloud collaborative computing framework.The edge layer is composed of edge servers with limited resources, road side units (RSU), and sinks. The edge layer collects data from the sensor network in real-time. The edge server can aggregate and process data and provide users with real-time, fast, diverse, and flexible network applications. According to the current resource utilization and scheduling strategy, the edge server decides to execute the user tasks separately in the local edge servers, or subdivide and schedule the tasks to other edge servers and/or cloud service center for collaborative execution. Data flow (DF) is generated by executing tasks between edge-edge and edge-cloud. The edge server receives and loads the task resources from the cloud service center through the CF, and pre-start the environment required for task operation. The edge server uploads the task processing status and the resource usage status of computing, storage, and network to the cloud service center through the CF.The sensor layer includes a sensor network, which is composed of a large number of sensors of IoT. Sensors can be deployed in environments such as smart transportation, telemedicine, and environmental monitoring. The sensor collects various required data in real-time and masters the status information of the monitoring area (object). The data collected by the sensors are uploaded to the edge layer in time. The uploaded data at the sensor layer can be analyzed and processed by the edge layer and cloud layer.In edge-cloud IoT, users can initiate service-oriented task requests through mobile devices, computers, connected cars, and smart terminals, and send request data (RD) to the edge server. The requested task is executed by the local edge server alone or in collaboration with other edge servers and/or cloud service center, answer data (AD) will be returned to the client from the local edge server, other edge servers, and cloud service center. Take the application of edge-cloud collaborative computing in smart transportation as an example. Sensors in each area monitor passing vehicles and control traffic information, and upload the traffic information to the edge servers in each area in time. The edge server processes the data and uploads the summarized traffic information to the traffic command center (cloud service center). When a user initiates a task request, for example, the task is to obtain a regional traffic condition map. The edge server closest to the user receives the user’s request. The edge server can perform tasks by itself, or dispatch to other adjacent edge servers and/or cloud service center to perform tasks cooperatively. Finally, the traffic condition map of a certain area is obtained, and the task result is returned to the user. The execution of user tasks requires the cloud service center to predict user tasks and push the task resources required to perform tasks to the edge server in advance. Task resources include software (program for drawing traffic conditions) and software data dependency (basic map).


### 3.2. Edge-Cloud Collaborative Computing Modeling

(1)quj=lujμue·ωu,ej/Due+μee·ωe,ej/Du,ee+μec·ωe,cj/Du,ec.Definition 1.
Edge-cloud collaborative computing model (EC3M). EC3M is a six-tuple model, denoted asMEC3, MEC3=U,J,E,c,O,θ. U is the user set, which is composed of nu independent users, U=u0,u1,⋯,unu−1. Users do not interfere with each other, and the various tasks submitted by users have a time-series correlation, so the number and types of tasks can be predicted. J is the task set, which is composed of nj service-oriented network applications (i.e., tasks), J=j0,j1,⋯,jnj−1. The task j is expressed as j=δj,εj,Δj. δj is the computing resources required for task j execution, which is quantified as the CPU computing power required for each task, i.e., GHz/task. εj is the storage resources required for task j execution. Δj is the task type of task j. Δj=1 indicates that task j is a time-sensitive task, and Δj=0 indicates that task j is a time-insensitive task. Each task type includes a variety of different tasks to meet the needs of various users. The task can be subdivided into several subtasks. E is the edge server set, which contains ne geographically dispersed edge servers, E=e0,e1,⋯,ene−1. The edge server e=δe,εe has limited hardware resources. δe and εe represent the computing resources and storage resources of the edge server e, respectively. The edge server is limited by hardware resources and can only load task resources required for some tasks simultaneously. The edge servers can subdivide the tasks and execute tasks locally or dispatch them to remote execution based on scheduling decisions. c is the cloud service center, which has massive computing, storage, network, and other hardware resources, and can load and run task resources for all tasks. The cloud service center manages and monitors the edge servers, effectively predicts the user tasks, and pushes the appropriate task resources to the relevant edge servers. O is the optimization objective of edge-cloud collaborative computing, which is quantified by both QoS and ESS (denoted as Q and S), O=maxQ,maxS. θ is the optimization algorithm for resource deployment and task scheduling.Definition 2.
User’s quality of service (QoS). QoS mainly focuses on the service experience and quality of user in the edge-cloud collaborative computing environment. User tasks are executed locally in the edge servers that receive the tasks and the shorter the response time of user task requests, the higher the QoS. The latter’s coefficient is stated in (1).The QoS’s coefficient is related to the task size and task execution. The task size is quantified as task execution time.wu,ej, we,ej, and we,cj represent the proportion of task j executed locally by the receiving edge server, dispatched by the receiving edge server to other edge servers, and dispatched by the receiving edge server to cloud service center, respectively. Their corresponding task execution preference weight coefficients are μue, μee, μec, and there is μue>μee>μec>0, μue+μee+μec=1. The distance coefficient between nodes considers the sending and receiving of tasks and it is related to the distance degree between nodes. Due is the distance coefficient between nodes that the task locally executed at the receiving edge server, Due=du,e+de,u. Du,ee is the distance coefficient between nodes that the task is dispatched by the local edge server to other edge servers, Du,ee=du,e+de,e+de,u. Du,ec is the distance coefficient between nodes that the task is dispatched by the local edge server to the cloud service center, Du,ec=du,e+de,c+dc,u. The distance degree dx,y is related to the minimum bandwidth, cumulative delay, and reliability of the links between nodes x and y. The value of distance degree is equal to the cumulative delay divided by product of reliability and minimum bandwidth. If the minimum bandwidth is larger, the cumulative delay is smaller, and the reliability is higher, then the distance degree value is smaller. The objective function of QoS is described in (2).
(2)Q=∑u=0un−1∑j=0jn−1kujfej·quj+1−fej·μ0·luj·DucmaxQs.t.fej=0,1,∀e∈E,j∈Jkuj=0,1,∀u∈U,j∈J.kuj=1 indicates that user u has a request for task j. fej=1 implies that the edge server e has the task resources required for task j to run. Duc is the distance coefficient between nodes of the task submitted by the user to the cloud service center, Duc=du,c+dc,u. μ0 is the non-preference weight coefficient, μ0=−μe. It can be seen from (2) that the edge servers have the resources required for the task operation and the larger the proportion of tasks executed locally, the larger the Q value, that is, the higher the user service quality of edge-cloud collaborative computing.
(3)ruj=lujμue·ωu,ej·βue+μee·ωe,ej·βee+μec·ωe,cj·βec.Definition 3.
Effect of system service (ESS). ESS mainly concentrates on the system service revenue and system service consumption of service providers in the edge-cloud collaborative computing. The system service revenue coefficient is stated in (3).The system service revenue coefficient is associated with the task size and task revenue.βue is the revenue index of the tasks performed on the local edge servers. βee is the revenue index of the edge servers dispatching the received tasks to the neighbor edge servers. βec is the revenue index of the edge servers dispatching the received tasks to the cloud service center. The objective function of ESS is shown in (4).
(4)S=∑u=0un−1∑j=0jn−1kujfej·ruj+1−fejμ0·luj·βec−τc·∂c+∑i=0en−1τei·∂eimaxSs.t.fej=0,1,∀e∈E,j∈Jkuj=0,1,∀u∈U,j∈J.In (4), the system service consumption in the statistical period is the product of task execution time equivalent and average service energy consumption coefficient (denoted as τ and ∂). τc and τe represent the task execution time equivalent of the cloud service center and edge servers, respectively. ∂c and ∂e represent the average service energy consumption coefficient of cloud service center and edge servers, respectively. The energy consumption coefficient depends on the hardware/software costs, and the system operation and maintenance costs. The former includes the hardware/software purchase costs and the depreciation costs. The latter gets involved in the power consumption of equipment, the energy consumption of air conditioning and refrigeration, and the management and service costs. From the comparative analysis of single quantity, ∂c is much larger than ∂e. The higher the system service revenue and the lower the system service consumption, the larger the S value, that is, the higher the system service effect of edge-cloud collaborative computing.In the edge-cloud collaborative computing model, the objective optimization of QoS and ESS is involved in resource deployment and task scheduling. (1) It needs to foretell the type and quantity of user tasks, reasonably push the task resources to the edge servers, and efficiently use the computing, storage, network, and other resources of the edge servers. (2) It also should optimize task scheduling, improve the QoS, and strengthen the ESS through the task collaborative processing of local edge servers, other edge servers, and cloud service center.


## 3.1. Edge-Cloud Collaborative Computing Framework

The edge-cloud collaborative computing framework is divided into the cloud layer, edge layer, and sensor layer, which are interconnected through the Internet. As shown in Figure1, edge-cloud collaborative computing can be applied in scenarios such as smart transportation, telemedicine, and environmental monitoring. The cloud layer includes a cloud service center, which is composed of some hardware such as homogeneous or heterogeneous computing, storage, network, and other hardware. The cloud service center uses virtualization, software defined network, redundancy, and other technologies to supply high-performance, highly reliable, and scalable resources to support a wide range of on-demand services for users. Control flow (CF) is generated between the cloud layer and edge layer. The cloud service center predicts the user task, and pushes the task resources to the edge servers through the CF in advance according to the prediction result. Task resources include software and software-dependent data required for task operation. The cloud service center monitors the task processing and resource utilization of the edge servers in real-time, summarizes the task processing and resource utilization of each edge server, and then distributes them to other edge servers through the CF.Figure 1
Edge-cloud collaborative computing framework.The edge layer is composed of edge servers with limited resources, road side units (RSU), and sinks. The edge layer collects data from the sensor network in real-time. The edge server can aggregate and process data and provide users with real-time, fast, diverse, and flexible network applications. According to the current resource utilization and scheduling strategy, the edge server decides to execute the user tasks separately in the local edge servers, or subdivide and schedule the tasks to other edge servers and/or cloud service center for collaborative execution. Data flow (DF) is generated by executing tasks between edge-edge and edge-cloud. The edge server receives and loads the task resources from the cloud service center through the CF, and pre-start the environment required for task operation. The edge server uploads the task processing status and the resource usage status of computing, storage, and network to the cloud service center through the CF.The sensor layer includes a sensor network, which is composed of a large number of sensors of IoT. Sensors can be deployed in environments such as smart transportation, telemedicine, and environmental monitoring. The sensor collects various required data in real-time and masters the status information of the monitoring area (object). The data collected by the sensors are uploaded to the edge layer in time. The uploaded data at the sensor layer can be analyzed and processed by the edge layer and cloud layer.In edge-cloud IoT, users can initiate service-oriented task requests through mobile devices, computers, connected cars, and smart terminals, and send request data (RD) to the edge server. The requested task is executed by the local edge server alone or in collaboration with other edge servers and/or cloud service center, answer data (AD) will be returned to the client from the local edge server, other edge servers, and cloud service center. Take the application of edge-cloud collaborative computing in smart transportation as an example. Sensors in each area monitor passing vehicles and control traffic information, and upload the traffic information to the edge servers in each area in time. The edge server processes the data and uploads the summarized traffic information to the traffic command center (cloud service center). When a user initiates a task request, for example, the task is to obtain a regional traffic condition map. The edge server closest to the user receives the user’s request. The edge server can perform tasks by itself, or dispatch to other adjacent edge servers and/or cloud service center to perform tasks cooperatively. Finally, the traffic condition map of a certain area is obtained, and the task result is returned to the user. The execution of user tasks requires the cloud service center to predict user tasks and push the task resources required to perform tasks to the edge server in advance. Task resources include software (program for drawing traffic conditions) and software data dependency (basic map).


## 3.2. Edge-Cloud Collaborative Computing Modeling

(1)quj=lujμue·ωu,ej/Due+μee·ωe,ej/Du,ee+μec·ωe,cj/Du,ec.Definition 1.
Edge-cloud collaborative computing model (EC3M). EC3M is a six-tuple model, denoted asMEC3, MEC3=U,J,E,c,O,θ. U is the user set, which is composed of nu independent users, U=u0,u1,⋯,unu−1. Users do not interfere with each other, and the various tasks submitted by users have a time-series correlation, so the number and types of tasks can be predicted. J is the task set, which is composed of nj service-oriented network applications (i.e., tasks), J=j0,j1,⋯,jnj−1. The task j is expressed as j=δj,εj,Δj. δj is the computing resources required for task j execution, which is quantified as the CPU computing power required for each task, i.e., GHz/task. εj is the storage resources required for task j execution. Δj is the task type of task j. Δj=1 indicates that task j is a time-sensitive task, and Δj=0 indicates that task j is a time-insensitive task. Each task type includes a variety of different tasks to meet the needs of various users. The task can be subdivided into several subtasks. E is the edge server set, which contains ne geographically dispersed edge servers, E=e0,e1,⋯,ene−1. The edge server e=δe,εe has limited hardware resources. δe and εe represent the computing resources and storage resources of the edge server e, respectively. The edge server is limited by hardware resources and can only load task resources required for some tasks simultaneously. The edge servers can subdivide the tasks and execute tasks locally or dispatch them to remote execution based on scheduling decisions. c is the cloud service center, which has massive computing, storage, network, and other hardware resources, and can load and run task resources for all tasks. The cloud service center manages and monitors the edge servers, effectively predicts the user tasks, and pushes the appropriate task resources to the relevant edge servers. O is the optimization objective of edge-cloud collaborative computing, which is quantified by both QoS and ESS (denoted as Q and S), O=maxQ,maxS. θ is the optimization algorithm for resource deployment and task scheduling.Definition 2.
User’s quality of service (QoS). QoS mainly focuses on the service experience and quality of user in the edge-cloud collaborative computing environment. User tasks are executed locally in the edge servers that receive the tasks and the shorter the response time of user task requests, the higher the QoS. The latter’s coefficient is stated in (1).The QoS’s coefficient is related to the task size and task execution. The task size is quantified as task execution time.wu,ej, we,ej, and we,cj represent the proportion of task j executed locally by the receiving edge server, dispatched by the receiving edge server to other edge servers, and dispatched by the receiving edge server to cloud service center, respectively. Their corresponding task execution preference weight coefficients are μue, μee, μec, and there is μue>μee>μec>0, μue+μee+μec=1. The distance coefficient between nodes considers the sending and receiving of tasks and it is related to the distance degree between nodes. Due is the distance coefficient between nodes that the task locally executed at the receiving edge server, Due=du,e+de,u. Du,ee is the distance coefficient between nodes that the task is dispatched by the local edge server to other edge servers, Du,ee=du,e+de,e+de,u. Du,ec is the distance coefficient between nodes that the task is dispatched by the local edge server to the cloud service center, Du,ec=du,e+de,c+dc,u. The distance degree dx,y is related to the minimum bandwidth, cumulative delay, and reliability of the links between nodes x and y. The value of distance degree is equal to the cumulative delay divided by product of reliability and minimum bandwidth. If the minimum bandwidth is larger, the cumulative delay is smaller, and the reliability is higher, then the distance degree value is smaller. The objective function of QoS is described in (2).
(2)Q=∑u=0un−1∑j=0jn−1kujfej·quj+1−fej·μ0·luj·DucmaxQs.t.fej=0,1,∀e∈E,j∈Jkuj=0,1,∀u∈U,j∈J.kuj=1 indicates that user u has a request for task j. fej=1 implies that the edge server e has the task resources required for task j to run. Duc is the distance coefficient between nodes of the task submitted by the user to the cloud service center, Duc=du,c+dc,u. μ0 is the non-preference weight coefficient, μ0=−μe. It can be seen from (2) that the edge servers have the resources required for the task operation and the larger the proportion of tasks executed locally, the larger the Q value, that is, the higher the user service quality of edge-cloud collaborative computing.
(3)ruj=lujμue·ωu,ej·βue+μee·ωe,ej·βee+μec·ωe,cj·βec.Definition 3.
Effect of system service (ESS). ESS mainly concentrates on the system service revenue and system service consumption of service providers in the edge-cloud collaborative computing. The system service revenue coefficient is stated in (3).The system service revenue coefficient is associated with the task size and task revenue.βue is the revenue index of the tasks performed on the local edge servers. βee is the revenue index of the edge servers dispatching the received tasks to the neighbor edge servers. βec is the revenue index of the edge servers dispatching the received tasks to the cloud service center. The objective function of ESS is shown in (4).
(4)S=∑u=0un−1∑j=0jn−1kujfej·ruj+1−fejμ0·luj·βec−τc·∂c+∑i=0en−1τei·∂eimaxSs.t.fej=0,1,∀e∈E,j∈Jkuj=0,1,∀u∈U,j∈J.In (4), the system service consumption in the statistical period is the product of task execution time equivalent and average service energy consumption coefficient (denoted as τ and ∂). τc and τe represent the task execution time equivalent of the cloud service center and edge servers, respectively. ∂c and ∂e represent the average service energy consumption coefficient of cloud service center and edge servers, respectively. The energy consumption coefficient depends on the hardware/software costs, and the system operation and maintenance costs. The former includes the hardware/software purchase costs and the depreciation costs. The latter gets involved in the power consumption of equipment, the energy consumption of air conditioning and refrigeration, and the management and service costs. From the comparative analysis of single quantity, ∂c is much larger than ∂e. The higher the system service revenue and the lower the system service consumption, the larger the S value, that is, the higher the system service effect of edge-cloud collaborative computing.In the edge-cloud collaborative computing model, the objective optimization of QoS and ESS is involved in resource deployment and task scheduling. (1) It needs to foretell the type and quantity of user tasks, reasonably push the task resources to the edge servers, and efficiently use the computing, storage, network, and other resources of the edge servers. (2) It also should optimize task scheduling, improve the QoS, and strengthen the ESS through the task collaborative processing of local edge servers, other edge servers, and cloud service center.


## 4. Task Prediction

Through long-term monitoring of user tasks, from a local perspective, the change of user tasks is a dynamic and random process, and a trend of change can be seen explicitly or implicitly. The task change and time have a strong correlation. From a global perspective, user tasks are autocorrelated with time such as days, weeks, months, and years. Based on the task change rules of the horizontal and vertical time dimensions, the task changing trend can be found through prediction. Figure2(a) shows the task request statistics chart of the network external network interface of a university’s data center. Figure 2(b) shows the statistics of the number of tasks executed in the cluster server of an e-commerce platform. Both figures use hours as the statistical unit, and the number of tasks changes with time. By observing the number of tasks listed in Figure 2(a) for 3 consecutive days and Figure 2(b) for 7 consecutive days, it is found that the changing trend of daily tasks in the same period is similar, and the overall shows the regular periodic fluctuations. This provides a reference basis for user task prediction in edge-cloud IoT.Figure 2
Task request statistics.
(a)
External network interface of university data center(b)
Cluster server of e-commerce companyAccording to the overlapping trend of strong periodicity, medium trend, and weak randomness of user tasks in edge-cloud collaborative computing, the user tasks can be comprehensively predicted from the horizontal and vertical time dimensions in the cloud service center. Through statistics and analysis of the past time-series data, the change of tasks can be inferred. The prediction model based on the two-dimensional time series is indicated in (5).
(5)pt=λνt+1−ληt+zt.pt is the task prediction result of the next time series. νt shows the current time series value of the vertical time dimension, which is the periodic statistics part, specifically the mean value of the same time series in different periods. νt is the mean value of the same time series in different periods. ηt is the current time series value of the horizontal time dimension, which is the trend prediction part. zt is the random noise part. λ represents the adjustment factor of two-dimensional time series, and its value is between 0 and 1.Theorem 4.
The task of trend prediction based on the horizontal time dimension in edge-cloud collaborative computing isηt=ηt−1+ηt−2+⋯+ηt−n/n+n+1/2φ.Proof.
According to the statistical analysis of practical data, the number of tasks increases or decreases linearly from a local perspective. The change in the number of tasks at timet can be expressed by a linear equation, as shown in (6). Thus, the number of tasks with time t−n can be obtained, as shown in (7).
(6)ηt=φχt+a,(7)ηt−n=φχt−n+a.
According to the moving average prediction method, the number of tasks at timet is related to the number of tasks in the previous n time slots, as shown in (8).
(8)ηt¯¯=ηt−1+ηt−2+⋯+ηt−nn.
Combining formula (7), and calculating ηt¯¯ to obtain (9).
(9)ηt¯¯=φχt−1+a+φχt−2+a+⋯+φχt−n+an=φχt−1+χt−2+⋯+χt−n+nan=φnχt−nn+1/2+nan=φχt−φn+1/2+a=φχt+a−φn+1/2.
According to formula (6), the number of tasks ηt=φχt+a at time t is substituted into formula (9), and (10) is obtained.
(10)ηt¯¯=ηt−φn+1/2.
There is a delay deviation ofφn+1/2 between ηt¯¯ (the number of tasks predicted by the moving average method) and ηt (the actual number of tasks), which needs to be corrected. Therefore, the task of trend prediction based on the horizontal time dimension is ηt=ηt¯¯+φn+1/2, which is (11). The φ value can be calculated by a linear regression formula, φ=∑χi∑ηi−nχ¯η¯/∑χi2−nχ¯2. It should be pointed out that if the number of tasks is absolutely stationary in the statistical interval, its φ=0.
(11)ηt=ηt−1+ηt−2+⋯+ηt−nn+n+12φThus, the task prediction based on the two-dimensional time series is gotten, as stated in (12).
(12)pt=λνt+1−ληt−1+ηt−2+⋯+ηt−nn+η+12φ+zt.


## 5. Resource Deployment and Task Scheduling

In this section, we introduce the resource deployment and task scheduling optimization of edge-cloud collaborative computing. Firstly, the cloud service center pushes the task resources to the appropriate edge servers according to the task prediction result to improve the local execution rate of user tasks. Secondly, the edge servers optimize the task scheduling through Pareto improvement to enhance both QoS and ESS.


### 5.1. Resource Deployment Algorithm with Task Prediction (RDAP)

In the edge-cloud collaborative computing environment, the hardware resources of the edge servers are limited, and the tasks they perform are also limited. The cloud service center needs to monitor the task processing status of the edge layer in real-time, use task prediction based on two-dimensional time series to obtain the changing trend of task type and quantity, and push the task resources to the edge servers. Task running needs to occupy hardware resources, this paper mainly considers computing resources (δ) and storage resources (ε) [42]. The maximum available resource of the edge server e is he, he=δemax,εemax. The currently available resource of the edge server e is be, be=δecur,εecur. The resource consumption of task j is gj=δj,εj. Considering the limited number of tasks performed by the edge servers, the cloud service center needs to classify and aggregate the prediction tasks, and control the number of task resources pushed to the edge servers, keeping the task load of the edge servers in a reasonable range. The RDAP is shown in Algorithm 1.Algorithm 1: RDAP.
Input: E: edge server set; J: task set; H: edge server maximum available resource set; B: edgeserver current available resource set.Output:X: edge server task resource deployment set.1: classify allj into time-sensitive or time-insensitive task, ∃j∈J,Δj=1,0;2:for each e∈Edo3:  calculatehe and be, ∃he=δemax,εemax, be=δecur,εecur;4:  predictpt by formula (12);5:  sort, aggregate, and rank tasks forJ in descending order of frequency;6:for each j∈Jdo7:iffej=1∩Δj=1then8:ifminδecur−δj/δemax,εecur−εj/εemax>ξthen9:δecur⟵δecur−δj, εecur⟵εecur−εj;10:     updateX⟵Xej;11:end if12:end if13:end for14:ifminδecur/δemax,εecur/εemax>ξthen15:for each j∈Jdo16:iffej=1∩Δj=0then17:ifminδecur−δj/δemax,εecur−εj/εemax>ξthen18:δecur⟵δecur−δj, εecur⟵εecur−εj;19:      updateX⟵Xej;20:end if21:end if22:end for23:end if24:end for25:returnXThe resource deployment with task prediction is performed in the cloud service center. Tasksj∈J are classified into two types: time-sensitive task (Δj=1) and time-insensitive task (Δj=0) (Line 1). According to the monitoring data, the current and maximum available resources of each edge server are calculated (Lines 2-3). Formula (12) is used to predict tasks based on the two-dimensional time series (Line 4). The tasks of each edge server are classified and aggregated in line with the prediction result, arranging them in descending order by the occurrence frequency (Line 5). This can reduce the push quantity of task resources, decrease the resource occupation of the edge servers, and improve the hit rate of user tasks under the resource shortage. Based on the task classification and aggregation result, the resource deployment of time-sensitive tasks is first considered, and then the resource deployment of time-insensitive tasks is taken into account when the edge servers have surplus resources available, which is conducive to ensuring the user’s quality of service (Lines 6-23). After obtaining the task resources deployed by each edge server, the currently available resources of each edge server are updated. To decrease the task delay, the delay threshold is determined to make sure that the proportion of available resources (including computing resources and storage resources) of the edge servers is higher than the task delay occurrence threshold ξ, so as to control the number of task resources pushed to the edge servers. Finally, the edge server task resource deployment set X is returned, and the cloud service center pushes the task resources to the edge servers (Line 25). The time complexity of the RDAP is One×njlbnj+1.


### 5.2. Task Scheduling Algorithm with Pareto Improvement (TSAP)

The task scheduling of the edge-cloud collaborative computing should be oriented to users and service providers, and the QoS and ESS ought to be considered comprehensively. The single objective optimization of task scheduling cannot ensure that the other objective is also optimal. It is necessary to weigh two objectives for comprehensive optimization. For example, task scheduling to nodes with strong computing capabilities can reduce the response time of tasks and improve QoS, but it is easy to increase system service consumption and reduce ESS. It is necessary to consider the interests of users and service operators to weigh QoS and ESS. Therefore, the Pareto improvement in the field of economics is introduced, and the task scheduling scheme of edge-cloud collaborative computing is obtained by seeking Pareto improvement for both QoS and ESS. The TSAP is described in Algorithm2.Algorithm 2: TSAP.
Input: E: edge server set; J: task set; c: cloud service center; μue, μee, μec; βue, βee, βec; ∂c, ∂e.Output:Y: task scheduling scheme set.1: newj received2:J⟵J+j;3:end if4:if count(J)≠∅then5:  sortJ in ascending order;6:end if7:for each j∈Jdo8:for each E∪Cdo9:iffej=1,∃j∈J,e∈Ethen10:    calculateQ according to formula (2);11:    selectYj1m⊆Y1,Yj1m≻maxQ;12:end if13:end for14:for each E∪Cdo15:iffej=1,∃j∈J,e∈Ethen16:    calculateE according to formula (4);17:    selectYj2m⊆Y2,Yj2m≻maxS;18:end if19:end for20:Y⟵Yj1m∩Yj2m;21:end for22:returnYThe task scheduling with Pareto improvement is performed in the edge servers. New tasks are received and added to the task setJ. If multiple users initiate task requests at the same time period, the tasks are sorted in ascending order (Lines 1-6). Pareto improvement of task scheduling is involved two stages (Lines 7-21). The first stage is the objective optimization of the QoS (Lines 8-13). The m-group of task scheduling schemes in the first stage is solved based on the random greedy approximation algorithm. Formula (2) is used to calculate the Q value in each group, and select the scheduling scheme with the highest Q value in each group. The objective curve of QoS can be obtained from these schemes set. The second stage is the objective optimization of the ESS (Lines 14-19). Based on the random greedy approximation algorithm, the m-group task scheduling schemes in the second stage are solved. The S value in each group is calculated by using formula (4), and the scheduling scheme with the highest S value in each group is selected. The objective curve of ESS can be obtained by these schemes set. The task scheduling schemes obtained in two stages are gradually compared by Pareto improvement, and the tangent point or any intersection point corresponding to the QoS and ESS objective curves are selected. The tangent point is the only optimal scheme for the two objectives, and the intersection point is any co-optimal scheme for the two objectives, so as to obtain the optimal scheduling scheme for each task (Line 20). Finally, the task scheduling scheme set Y is returned (Line 22). The time complexity of the TSAP is Onj×lbnj+ne+1×m.


## 5.1. Resource Deployment Algorithm with Task Prediction (RDAP)

In the edge-cloud collaborative computing environment, the hardware resources of the edge servers are limited, and the tasks they perform are also limited. The cloud service center needs to monitor the task processing status of the edge layer in real-time, use task prediction based on two-dimensional time series to obtain the changing trend of task type and quantity, and push the task resources to the edge servers. Task running needs to occupy hardware resources, this paper mainly considers computing resources (δ) and storage resources (ε) [42]. The maximum available resource of the edge server e is he, he=δemax,εemax. The currently available resource of the edge server e is be, be=δecur,εecur. The resource consumption of task j is gj=δj,εj. Considering the limited number of tasks performed by the edge servers, the cloud service center needs to classify and aggregate the prediction tasks, and control the number of task resources pushed to the edge servers, keeping the task load of the edge servers in a reasonable range. The RDAP is shown in Algorithm 1.Algorithm 1: RDAP.
Input: E: edge server set; J: task set; H: edge server maximum available resource set; B: edgeserver current available resource set.Output:X: edge server task resource deployment set.1: classify allj into time-sensitive or time-insensitive task, ∃j∈J,Δj=1,0;2:for each e∈Edo3:  calculatehe and be, ∃he=δemax,εemax, be=δecur,εecur;4:  predictpt by formula (12);5:  sort, aggregate, and rank tasks forJ in descending order of frequency;6:for each j∈Jdo7:iffej=1∩Δj=1then8:ifminδecur−δj/δemax,εecur−εj/εemax>ξthen9:δecur⟵δecur−δj, εecur⟵εecur−εj;10:     updateX⟵Xej;11:end if12:end if13:end for14:ifminδecur/δemax,εecur/εemax>ξthen15:for each j∈Jdo16:iffej=1∩Δj=0then17:ifminδecur−δj/δemax,εecur−εj/εemax>ξthen18:δecur⟵δecur−δj, εecur⟵εecur−εj;19:      updateX⟵Xej;20:end if21:end if22:end for23:end if24:end for25:returnXThe resource deployment with task prediction is performed in the cloud service center. Tasksj∈J are classified into two types: time-sensitive task (Δj=1) and time-insensitive task (Δj=0) (Line 1). According to the monitoring data, the current and maximum available resources of each edge server are calculated (Lines 2-3). Formula (12) is used to predict tasks based on the two-dimensional time series (Line 4). The tasks of each edge server are classified and aggregated in line with the prediction result, arranging them in descending order by the occurrence frequency (Line 5). This can reduce the push quantity of task resources, decrease the resource occupation of the edge servers, and improve the hit rate of user tasks under the resource shortage. Based on the task classification and aggregation result, the resource deployment of time-sensitive tasks is first considered, and then the resource deployment of time-insensitive tasks is taken into account when the edge servers have surplus resources available, which is conducive to ensuring the user’s quality of service (Lines 6-23). After obtaining the task resources deployed by each edge server, the currently available resources of each edge server are updated. To decrease the task delay, the delay threshold is determined to make sure that the proportion of available resources (including computing resources and storage resources) of the edge servers is higher than the task delay occurrence threshold ξ, so as to control the number of task resources pushed to the edge servers. Finally, the edge server task resource deployment set X is returned, and the cloud service center pushes the task resources to the edge servers (Line 25). The time complexity of the RDAP is One×njlbnj+1.


## 5.2. Task Scheduling Algorithm with Pareto Improvement (TSAP)

The task scheduling of the edge-cloud collaborative computing should be oriented to users and service providers, and the QoS and ESS ought to be considered comprehensively. The single objective optimization of task scheduling cannot ensure that the other objective is also optimal. It is necessary to weigh two objectives for comprehensive optimization. For example, task scheduling to nodes with strong computing capabilities can reduce the response time of tasks and improve QoS, but it is easy to increase system service consumption and reduce ESS. It is necessary to consider the interests of users and service operators to weigh QoS and ESS. Therefore, the Pareto improvement in the field of economics is introduced, and the task scheduling scheme of edge-cloud collaborative computing is obtained by seeking Pareto improvement for both QoS and ESS. The TSAP is described in Algorithm2.Algorithm 2: TSAP.
Input: E: edge server set; J: task set; c: cloud service center; μue, μee, μec; βue, βee, βec; ∂c, ∂e.Output:Y: task scheduling scheme set.1: newj received2:J⟵J+j;3:end if4:if count(J)≠∅then5:  sortJ in ascending order;6:end if7:for each j∈Jdo8:for each E∪Cdo9:iffej=1,∃j∈J,e∈Ethen10:    calculateQ according to formula (2);11:    selectYj1m⊆Y1,Yj1m≻maxQ;12:end if13:end for14:for each E∪Cdo15:iffej=1,∃j∈J,e∈Ethen16:    calculateE according to formula (4);17:    selectYj2m⊆Y2,Yj2m≻maxS;18:end if19:end for20:Y⟵Yj1m∩Yj2m;21:end for22:returnYThe task scheduling with Pareto improvement is performed in the edge servers. New tasks are received and added to the task setJ. If multiple users initiate task requests at the same time period, the tasks are sorted in ascending order (Lines 1-6). Pareto improvement of task scheduling is involved two stages (Lines 7-21). The first stage is the objective optimization of the QoS (Lines 8-13). The m-group of task scheduling schemes in the first stage is solved based on the random greedy approximation algorithm. Formula (2) is used to calculate the Q value in each group, and select the scheduling scheme with the highest Q value in each group. The objective curve of QoS can be obtained from these schemes set. The second stage is the objective optimization of the ESS (Lines 14-19). Based on the random greedy approximation algorithm, the m-group task scheduling schemes in the second stage are solved. The S value in each group is calculated by using formula (4), and the scheduling scheme with the highest S value in each group is selected. The objective curve of ESS can be obtained by these schemes set. The task scheduling schemes obtained in two stages are gradually compared by Pareto improvement, and the tangent point or any intersection point corresponding to the QoS and ESS objective curves are selected. The tangent point is the only optimal scheme for the two objectives, and the intersection point is any co-optimal scheme for the two objectives, so as to obtain the optimal scheduling scheme for each task (Line 20). Finally, the task scheduling scheme set Y is returned (Line 22). The time complexity of the TSAP is Onj×lbnj+ne+1×m.


## 6. Experimental Evaluation

In this section, we build an edge-cloud collaborative computing experimental environment, set experimental parameters, determine evaluation indexes, and comprehensively evaluate resource deployment and task scheduling.


### 6.1. Experimental Environment and Parameters

The hardware platform of the edge-cloud collaborative computing experiment is an x86 server with Intel e5-2620v4 CPU, 64GB ECC RAM, and 3×2TB STA hard disk. The software platform relies on the CentOS 8.0 x86_64 operating system, and uses python 3.8 to build an edge-cloud collaborative computing simulation environment. In addition, OriginPro 2017 software is used for data analysis and post drawing. The parameters of the experimental environment are shown in Table 2. In the edge-cloud collaborative computing environment, the user task type, task execution time, CPU resource utilization, and RAM resource utilization are set by referring to the data set published by Alibaba Cloud [42–44]. User tasks have time series correlation, and the overall distribution is Zipf [45–47]. The frequency of tasks is inversely proportional to the rank of task popularity. In the experiment, the default value of Zipf distribution α parameter is 1.0 [48, 49]. The maximum available resources of the cloud service center are 10 K PE CPU, 10 TB RAM, and 10 PB disk. The hardware resource parameters of the edge servers are shown in Table 3. The benchmark algorithms for task scheduling include BAO (the benchmark task scheduling algorithm with OREO) [50] and BAF (the benchmark task scheduling algorithm with FIFO) [51, 52]. Task scheduling evaluation metrics include ATCT, OSSE, and TTDR.Table 2
Experimental environment parameters.
ParametersValueTypes of tasks300Number of edge servers15δj/GHz[0.1-0.3]εj/MB[20-80]δe/GHz[2.5-3.6]μue, μee, μec0.48, 0.31, 0.21βue, βee, βec0.39, 0.36, 0.25ξ0.20Table 3
Hardware resource parameters of edge servers.
Edge server numberCPU/PERAM/GBDisk/GBE01-E032~44~8500E04-E064~64~8500E07-E094~68~161000E10-E124~88~161000E13-E156~1616~321000


### 6.2. Experimental Results and Discussion

#### 6.2.1. Resource Deployment

In the edge-cloud collaborative computing environment, resource deployment with task prediction is evaluated and analyzed. The day is taken as the statistical cycle, each cycle is divided into 24 time periods, and each time period is 0.5 hours. In the experiment, the cloud service center predicts the tasks of the edge servers based on the two-dimensional time series, and the value of time slotn is 10. According to the experimental data of previous task prediction, the adjustment factor λ of the two-dimensional time series is set up to 0.27, and the random noise is ignored. The predicted result is compared with the actual number of tasks processed by the edge servers. As shown in Figure 3, the actual value of user tasks changes greatly, and the predicted value of tasks changes relatively gently. In general, the task prediction based on the two-dimensional time series is close to the actual value, the deviation of the average task number is less than 5%, and the accuracy of task prediction is high. The result can guide the cloud service center to optimize the task resource deployment of the edge servers.Figure 3
Prediction of user tasks.The average task hit rate (ATHR) is used to evaluate the effect of resource deployment with task prediction. ATHR refers to the average value of the local execution proportion of tasks of each edge server. The proportion of local task execution of the edge server is the ratio of the edge server receiving user task requests and executing tasks locally (because it has the task resources required for task operation). The high ATHR value indicates that the cloud service center has a high accuracy rate of pushing the task resources based on the predicted result. The high rate of local execution of tasks in the edge servers is conducive to improving both QoS and ESS. In the edge-cloud collaborative computing environment, the cloud service center can effectively predict user tasks based on the two-dimensional time series, classify and aggregate them according to the prediction result, and optimize the task resources pushed to each edge server. It can improve the local execution rate of user tasks on the edge servers, and reduce the passive application of task resources to the cloud service center because the edge servers do not have the resources required for task operation. Through 15 consecutive days of experiments, using task prediction based on the two-dimensional time series to deploy the task resources required by the edge servers, the average task hit rate of the edge servers is very high. As shown in Figure4, its ATHR value reaches 85.79%~92.39%, which is much higher than the average task hit rate of less than 50% for resource deployment without task prediction.Figure 4
Average task hit rate of edge servers.


#### 6.2.2. Task Scheduling

We evaluate and analyze the task scheduling performance of the TSAP, RDAP-TSAP (combining RDAP and TSAP, as shown in Figure5), BAO, and BAF from the three aspects of ATCT, OSSE, and TTDR. In the edge-cloud collaborative computing environment, to compare different task scheduling performances, the m-group task scheduling schemes of TSAP consider the values of 3, 5, 7, and 9, respectively.Figure 5
RDAP-TSAP.(1) Average Task Completion Time (ATCT). The ATCT is the ratio of the total completion time of all user tasks to the number of user tasks during the statistical period. The ATCT mainly considers the user service experience. The smaller the ATCT value, the shorter the average completion time of all tasks and the higher the quality of user experience. In the edge-cloud collaborative computing environment, the Zipf distribution α parameter of the user task is set to the default value, and the ATCT of the TSAP, RDAP-TSAP, BAO, and BAF algorithms are compared and analyzed by changing the task scale. As shown in Figure 6, with the increase of the number of user tasks, the ATCT values of the four algorithms increase and show an approximately linear trend. The ATCT values of RDAP-TSAP, BAO, and TSAP algorithms are significantly lower than that of BAF algorithm. The TSAP algorithm effectively reduces the ATCT by Pareto improvement on the two objectives of QoS and ESS, and its ATCT value is reduced by 29.69% on average compared with the BAF algorithm. The BAO algorithm jointly optimizes task caching and task offloading, and its ATCT value is reduced by 35.68% on average compared with the BAF algorithm. The RDAP-TSAP algorithm predicts the number of user task types, improves the accuracy of resources required by the cloud service center to push tasks to edge servers, and further reduces the ATCT by Pareto improvement of QoS and ESS. The ATCT value of RDAP-TSAP algorithm is 42.07% lower than the BAF algorithm, and 9.94% lower than the BAO algorithm. In addition, the TSAP and RDAP-TSAP algorithms have the best ATCT values when m =5. It shows that the smaller m value leads to the single task scheduling scheme, and the higher m value will increase the calculation cost of task scheduling itself, which will improve the ATCT.Figure 6
Average task completion time under different tasks.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9Considering the influence of task Zipf distributionα parameter, the ATCT of the TSAP, RDAP-TSAP, BAO, and BAF algorithms will be further evaluated under certain user tasks. The number of user tasks is set up to 5k in the edge-cloud collaborative computing environment. As shown in Figure 7, as the value of the Zipf distribution α parameter increases, user tasks become more and more concentrated in the popular task types, and the ATCT values of the four scheduling algorithms decrease in varying degrees. Moreover, the TSAP and RDAP-TSAP algorithms have the best ATCT value when the m-group of task scheduling schemes is 5. Overall analysis, the RDAP-TSAP algorithm predicts the type and number of tasks, improves the accuracy of task resources push, increases the average task hit rate; and then integrates both QoS and ESS for Pareto improvement to optimize task scheduling. Its ATCT value is the best, with an average overall reduction of 34.94% compared with the BAF algorithm and 6.22% compared with the BAO algorithm. The TSAP algorithm benefits from two-stage Pareto improvement of QoS and ESS. In the absence of task prediction to optimize resource deployment, its ATCT value is overall reduced by 23.23% on average compared with the BAF algorithm.Figure 7
Average task completion time under different Zipf distributionα parameters.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9(2) Overall System Service Effect (OSSE). The OSSE is the difference between system service revenue and system service consumption of the cloud service center and edge servers in the statistical period, which is the ESS value of normalization. The OSSE mainly considers the interests of service providers. The higher the system service revenue of providers and the lower their system service consumption, the higher its OSSE value. In the edge-cloud collaborative computing environment, the user tasks are Zipf distribution with default α parameter. The OSSE of the TSAP, RDAP-TSAP, BAO, and BAF algorithms are evaluated by gradually increasing the number of user tasks. As shown in Figure 8, the OSSE values of the four algorithms increase with the number of user tasks, showing an approximate logarithmic growth. Compared with the BA algorithm, the OSSE values of the RDAP-TSAP, BAO, and TSAP algorithms are significantly higher. Among them, the TSAP algorithm optimizes task scheduling through Pareto improvement of both QoS and ESS objectives, and improves the overall service effectiveness of the cloud service center and edge servers. Its OSSE value overall increases by 24.69% on average. The BAO algorithm jointly optimizes task caching and task offloading, and its OSSE value increases by 36.78% on average. The RDAP-TSAP algorithm predicts based on the type and number of tasks in the cloud service center, effectively pushes the task resources, improves the average task hit rate, and optimizes task scheduling based on the objectives of QoS and ESS at the edge servers to further increase the OSSE value. Its OSSE value overall increases by 49.55% on average. In addition, compared with the BAO algorithm, the OSSE value of the RDAP-TSAP algorithm has an overall increase of 10.43% on average. Moreover, similar to the previous ATCT analysis, the OSSE values of the TSAP and RDAP-TSAP algorithms are optimal when m=5. It indicates that a small value of m leads to a single task scheduling scheme and is under-optimized, and a large value of m increases the computational overhead of task scheduling, which will reduce the OSSE.Figure 8
Overall system service effect under different tasks.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9Considering the influence of task Zipf distributionα parameter, the OSSE of the TSAP, RDAP-TSAP, BAO, and BAF algorithms will be further evaluated under certain user tasks. In Figure 9, the number of user tasks is 5k in the edge-cloud collaborative computing environment. As the value of the Zipf distribution α parameter increases, the user tasks gradually tend to be more popular task types and decrease the number of task resources required by edge servers, and the OSSE values of the four algorithms are greatly improved. And similar to the previous ATCT analysis, the OSSE values of the TSAP and RDAP-TSAP algorithms are optimal when the value of the m-group task scheduling schemes is 5. In general, the RDAP-TSAP algorithm predicts the tasks, improves the accuracy of task resources required to push edge servers, and increases the average task hit rate. Moreover, through the two-stage comprehensive optimization considering the QoS and ESS, the OSSE value of RDAP-TSAP algorithm is the best. Its OSSE value is 39.54% higher than the BAF algorithm, and 11.91% higher than the BAO algorithm. In the absence of task prediction, the TSAP algorithm uses Pareto optimization of the QoS and ESS, and its OSSE value is overall increased by 22.62% on average compared to the BAF algorithm.Figure 9
Overall system service effect under different Zipf distributionα parameters.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9(3) Total Task Delay Rate (TTDR). The TTDR is the proportion of tasks whose task response time exceeds 3 times the average response time of similar tasks in the statistical time period. The TTDR affects the user’s quality of service and the effect of system service [53–55]. The low TTDR value can help reduce the average task completion time of users and enhance the QoS, and also help reduce the system energy consumption and improve the ESS. In the edge-cloud collaborative computing environment, user tasks are Zipf distribution with default α parameter, and the value of the m-group task scheduling schemes is 5. The TTDR of the TSAP, RDAP-TSAP, BAO, and BAF algorithms are evaluated by gradually increasing the number of user tasks. As shown in Figure 10, with the number of user tasks increasing, the TTDR values of the four algorithms increase. In general, the RDAP-TSAP algorithm is the best, the BAO and TSAP algorithm is the second, and the BAF algorithm is the worst. The RDAP-TSAP algorithm predicts tasks, classifies and aggregates tasks to reduce the number of task resources pushed to the edge servers, determines the delay threshold during resource deployment, and considers the available resources of the edge servers to reduce the probability of task delay. As the number of tasks increases, the total task delay rate increases slowly, and the TTDR value is controlled between 0.12% and 4.17%. The BAF, TSAP, and BAO algorithms lack task prediction in task scheduling and do not handle possible task delays. Their TTDR values are high, and the total task delay rate increases linearly with the increase of tasks. The BAF algorithm has the highest TTDR value, ranging from 8.37% to 37.12%. Because the TSAP algorithm performs Pareto improvement for task scheduling by integrating the objectives of QoS and ESS, it can reduce the average service completion time of tasks, and its TTDR value is relatively low, ranging from 3.67% to 34.39%. The BAO algorithm jointly optimizes task caching and task offloading, and its TTDR value is 2.17% to 21.19%.Figure 10
Total task delay rate under different tasks.Considering the influence of task Zipf distributionα parameter, the TTDR of the TSAP, RDAP-TSAP, BAO, and BAF algorithms is further evaluated under the condition of unchanged user tasks. In the edge-cloud collaborative computing environment, the number of user tasks is set up to 5k, and the value of the m-group task scheduling schemes is 5. The changes in their TTDR are shown in Figure 11. As the value of Zipf distribution α parameter increases, user tasks are more and more concentrated on task types with high popularity, and the task resource types required by edge servers are reduced. In general, the TTDR of the TSAP, RDAP-TSAP, BAO, and BAF algorithms has decreased to varying degrees. The RDAP-TSAP algorithm predicts, classifies, and aggregates user tasks to reduce the task resources required to push to the edge servers. During resource deployment, the delay threshold is judged to effectively reduce the occurrence of task delays, and then the Pareto optimizes task scheduling to make its TTDR always at a low level, with values ranging from 0.15% to 4.17%, which is an average reduction of 19.05% compared to the BAF algorithm, and an average reduction of 10.29% compared to the BAO algorithm. The TSAP algorithm lacks user task prediction and does not optimize task resource deployment of edge servers. However, it integrates the QoS and ESS for Pareto improvement during user task scheduling, and its TTDR value is relatively high, ranging from 11.22% to 22.71%, which is 4.28% lower than the BAF algorithm on average. The BAO algorithm jointly optimizes task caching and task offloading, and its TTDR value is 7.29% to 18.61%, which is an average reduction of 8.76% compared to the BAF algorithm. The TTDR value of the BAF algorithm is the highest, ranging from 15.31% to 28.51%, with an average value of 20.47%.Figure 11
Total task delay rate under different Zipf distributionα parameters.


## 6.1. Experimental Environment and Parameters

The hardware platform of the edge-cloud collaborative computing experiment is an x86 server with Intel e5-2620v4 CPU, 64GB ECC RAM, and 3×2TB STA hard disk. The software platform relies on the CentOS 8.0 x86_64 operating system, and uses python 3.8 to build an edge-cloud collaborative computing simulation environment. In addition, OriginPro 2017 software is used for data analysis and post drawing. The parameters of the experimental environment are shown in Table 2. In the edge-cloud collaborative computing environment, the user task type, task execution time, CPU resource utilization, and RAM resource utilization are set by referring to the data set published by Alibaba Cloud [42–44]. User tasks have time series correlation, and the overall distribution is Zipf [45–47]. The frequency of tasks is inversely proportional to the rank of task popularity. In the experiment, the default value of Zipf distribution α parameter is 1.0 [48, 49]. The maximum available resources of the cloud service center are 10 K PE CPU, 10 TB RAM, and 10 PB disk. The hardware resource parameters of the edge servers are shown in Table 3. The benchmark algorithms for task scheduling include BAO (the benchmark task scheduling algorithm with OREO) [50] and BAF (the benchmark task scheduling algorithm with FIFO) [51, 52]. Task scheduling evaluation metrics include ATCT, OSSE, and TTDR.Table 2
Experimental environment parameters.
ParametersValueTypes of tasks300Number of edge servers15δj/GHz[0.1-0.3]εj/MB[20-80]δe/GHz[2.5-3.6]μue, μee, μec0.48, 0.31, 0.21βue, βee, βec0.39, 0.36, 0.25ξ0.20Table 3
Hardware resource parameters of edge servers.
Edge server numberCPU/PERAM/GBDisk/GBE01-E032~44~8500E04-E064~64~8500E07-E094~68~161000E10-E124~88~161000E13-E156~1616~321000


## 6.2. Experimental Results and Discussion

### 6.2.1. Resource Deployment

In the edge-cloud collaborative computing environment, resource deployment with task prediction is evaluated and analyzed. The day is taken as the statistical cycle, each cycle is divided into 24 time periods, and each time period is 0.5 hours. In the experiment, the cloud service center predicts the tasks of the edge servers based on the two-dimensional time series, and the value of time slotn is 10. According to the experimental data of previous task prediction, the adjustment factor λ of the two-dimensional time series is set up to 0.27, and the random noise is ignored. The predicted result is compared with the actual number of tasks processed by the edge servers. As shown in Figure 3, the actual value of user tasks changes greatly, and the predicted value of tasks changes relatively gently. In general, the task prediction based on the two-dimensional time series is close to the actual value, the deviation of the average task number is less than 5%, and the accuracy of task prediction is high. The result can guide the cloud service center to optimize the task resource deployment of the edge servers.Figure 3
Prediction of user tasks.The average task hit rate (ATHR) is used to evaluate the effect of resource deployment with task prediction. ATHR refers to the average value of the local execution proportion of tasks of each edge server. The proportion of local task execution of the edge server is the ratio of the edge server receiving user task requests and executing tasks locally (because it has the task resources required for task operation). The high ATHR value indicates that the cloud service center has a high accuracy rate of pushing the task resources based on the predicted result. The high rate of local execution of tasks in the edge servers is conducive to improving both QoS and ESS. In the edge-cloud collaborative computing environment, the cloud service center can effectively predict user tasks based on the two-dimensional time series, classify and aggregate them according to the prediction result, and optimize the task resources pushed to each edge server. It can improve the local execution rate of user tasks on the edge servers, and reduce the passive application of task resources to the cloud service center because the edge servers do not have the resources required for task operation. Through 15 consecutive days of experiments, using task prediction based on the two-dimensional time series to deploy the task resources required by the edge servers, the average task hit rate of the edge servers is very high. As shown in Figure4, its ATHR value reaches 85.79%~92.39%, which is much higher than the average task hit rate of less than 50% for resource deployment without task prediction.Figure 4
Average task hit rate of edge servers.


### 6.2.2. Task Scheduling

We evaluate and analyze the task scheduling performance of the TSAP, RDAP-TSAP (combining RDAP and TSAP, as shown in Figure5), BAO, and BAF from the three aspects of ATCT, OSSE, and TTDR. In the edge-cloud collaborative computing environment, to compare different task scheduling performances, the m-group task scheduling schemes of TSAP consider the values of 3, 5, 7, and 9, respectively.Figure 5
RDAP-TSAP.(1) Average Task Completion Time (ATCT). The ATCT is the ratio of the total completion time of all user tasks to the number of user tasks during the statistical period. The ATCT mainly considers the user service experience. The smaller the ATCT value, the shorter the average completion time of all tasks and the higher the quality of user experience. In the edge-cloud collaborative computing environment, the Zipf distribution α parameter of the user task is set to the default value, and the ATCT of the TSAP, RDAP-TSAP, BAO, and BAF algorithms are compared and analyzed by changing the task scale. As shown in Figure 6, with the increase of the number of user tasks, the ATCT values of the four algorithms increase and show an approximately linear trend. The ATCT values of RDAP-TSAP, BAO, and TSAP algorithms are significantly lower than that of BAF algorithm. The TSAP algorithm effectively reduces the ATCT by Pareto improvement on the two objectives of QoS and ESS, and its ATCT value is reduced by 29.69% on average compared with the BAF algorithm. The BAO algorithm jointly optimizes task caching and task offloading, and its ATCT value is reduced by 35.68% on average compared with the BAF algorithm. The RDAP-TSAP algorithm predicts the number of user task types, improves the accuracy of resources required by the cloud service center to push tasks to edge servers, and further reduces the ATCT by Pareto improvement of QoS and ESS. The ATCT value of RDAP-TSAP algorithm is 42.07% lower than the BAF algorithm, and 9.94% lower than the BAO algorithm. In addition, the TSAP and RDAP-TSAP algorithms have the best ATCT values when m =5. It shows that the smaller m value leads to the single task scheduling scheme, and the higher m value will increase the calculation cost of task scheduling itself, which will improve the ATCT.Figure 6
Average task completion time under different tasks.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9Considering the influence of task Zipf distributionα parameter, the ATCT of the TSAP, RDAP-TSAP, BAO, and BAF algorithms will be further evaluated under certain user tasks. The number of user tasks is set up to 5k in the edge-cloud collaborative computing environment. As shown in Figure 7, as the value of the Zipf distribution α parameter increases, user tasks become more and more concentrated in the popular task types, and the ATCT values of the four scheduling algorithms decrease in varying degrees. Moreover, the TSAP and RDAP-TSAP algorithms have the best ATCT value when the m-group of task scheduling schemes is 5. Overall analysis, the RDAP-TSAP algorithm predicts the type and number of tasks, improves the accuracy of task resources push, increases the average task hit rate; and then integrates both QoS and ESS for Pareto improvement to optimize task scheduling. Its ATCT value is the best, with an average overall reduction of 34.94% compared with the BAF algorithm and 6.22% compared with the BAO algorithm. The TSAP algorithm benefits from two-stage Pareto improvement of QoS and ESS. In the absence of task prediction to optimize resource deployment, its ATCT value is overall reduced by 23.23% on average compared with the BAF algorithm.Figure 7
Average task completion time under different Zipf distributionα parameters.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9(2) Overall System Service Effect (OSSE). The OSSE is the difference between system service revenue and system service consumption of the cloud service center and edge servers in the statistical period, which is the ESS value of normalization. The OSSE mainly considers the interests of service providers. The higher the system service revenue of providers and the lower their system service consumption, the higher its OSSE value. In the edge-cloud collaborative computing environment, the user tasks are Zipf distribution with default α parameter. The OSSE of the TSAP, RDAP-TSAP, BAO, and BAF algorithms are evaluated by gradually increasing the number of user tasks. As shown in Figure 8, the OSSE values of the four algorithms increase with the number of user tasks, showing an approximate logarithmic growth. Compared with the BA algorithm, the OSSE values of the RDAP-TSAP, BAO, and TSAP algorithms are significantly higher. Among them, the TSAP algorithm optimizes task scheduling through Pareto improvement of both QoS and ESS objectives, and improves the overall service effectiveness of the cloud service center and edge servers. Its OSSE value overall increases by 24.69% on average. The BAO algorithm jointly optimizes task caching and task offloading, and its OSSE value increases by 36.78% on average. The RDAP-TSAP algorithm predicts based on the type and number of tasks in the cloud service center, effectively pushes the task resources, improves the average task hit rate, and optimizes task scheduling based on the objectives of QoS and ESS at the edge servers to further increase the OSSE value. Its OSSE value overall increases by 49.55% on average. In addition, compared with the BAO algorithm, the OSSE value of the RDAP-TSAP algorithm has an overall increase of 10.43% on average. Moreover, similar to the previous ATCT analysis, the OSSE values of the TSAP and RDAP-TSAP algorithms are optimal when m=5. It indicates that a small value of m leads to a single task scheduling scheme and is under-optimized, and a large value of m increases the computational overhead of task scheduling, which will reduce the OSSE.Figure 8
Overall system service effect under different tasks.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9Considering the influence of task Zipf distributionα parameter, the OSSE of the TSAP, RDAP-TSAP, BAO, and BAF algorithms will be further evaluated under certain user tasks. In Figure 9, the number of user tasks is 5k in the edge-cloud collaborative computing environment. As the value of the Zipf distribution α parameter increases, the user tasks gradually tend to be more popular task types and decrease the number of task resources required by edge servers, and the OSSE values of the four algorithms are greatly improved. And similar to the previous ATCT analysis, the OSSE values of the TSAP and RDAP-TSAP algorithms are optimal when the value of the m-group task scheduling schemes is 5. In general, the RDAP-TSAP algorithm predicts the tasks, improves the accuracy of task resources required to push edge servers, and increases the average task hit rate. Moreover, through the two-stage comprehensive optimization considering the QoS and ESS, the OSSE value of RDAP-TSAP algorithm is the best. Its OSSE value is 39.54% higher than the BAF algorithm, and 11.91% higher than the BAO algorithm. In the absence of task prediction, the TSAP algorithm uses Pareto optimization of the QoS and ESS, and its OSSE value is overall increased by 22.62% on average compared to the BAF algorithm.Figure 9
Overall system service effect under different Zipf distributionα parameters.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9(3) Total Task Delay Rate (TTDR). The TTDR is the proportion of tasks whose task response time exceeds 3 times the average response time of similar tasks in the statistical time period. The TTDR affects the user’s quality of service and the effect of system service [53–55]. The low TTDR value can help reduce the average task completion time of users and enhance the QoS, and also help reduce the system energy consumption and improve the ESS. In the edge-cloud collaborative computing environment, user tasks are Zipf distribution with default α parameter, and the value of the m-group task scheduling schemes is 5. The TTDR of the TSAP, RDAP-TSAP, BAO, and BAF algorithms are evaluated by gradually increasing the number of user tasks. As shown in Figure 10, with the number of user tasks increasing, the TTDR values of the four algorithms increase. In general, the RDAP-TSAP algorithm is the best, the BAO and TSAP algorithm is the second, and the BAF algorithm is the worst. The RDAP-TSAP algorithm predicts tasks, classifies and aggregates tasks to reduce the number of task resources pushed to the edge servers, determines the delay threshold during resource deployment, and considers the available resources of the edge servers to reduce the probability of task delay. As the number of tasks increases, the total task delay rate increases slowly, and the TTDR value is controlled between 0.12% and 4.17%. The BAF, TSAP, and BAO algorithms lack task prediction in task scheduling and do not handle possible task delays. Their TTDR values are high, and the total task delay rate increases linearly with the increase of tasks. The BAF algorithm has the highest TTDR value, ranging from 8.37% to 37.12%. Because the TSAP algorithm performs Pareto improvement for task scheduling by integrating the objectives of QoS and ESS, it can reduce the average service completion time of tasks, and its TTDR value is relatively low, ranging from 3.67% to 34.39%. The BAO algorithm jointly optimizes task caching and task offloading, and its TTDR value is 2.17% to 21.19%.Figure 10
Total task delay rate under different tasks.Considering the influence of task Zipf distributionα parameter, the TTDR of the TSAP, RDAP-TSAP, BAO, and BAF algorithms is further evaluated under the condition of unchanged user tasks. In the edge-cloud collaborative computing environment, the number of user tasks is set up to 5k, and the value of the m-group task scheduling schemes is 5. The changes in their TTDR are shown in Figure 11. As the value of Zipf distribution α parameter increases, user tasks are more and more concentrated on task types with high popularity, and the task resource types required by edge servers are reduced. In general, the TTDR of the TSAP, RDAP-TSAP, BAO, and BAF algorithms has decreased to varying degrees. The RDAP-TSAP algorithm predicts, classifies, and aggregates user tasks to reduce the task resources required to push to the edge servers. During resource deployment, the delay threshold is judged to effectively reduce the occurrence of task delays, and then the Pareto optimizes task scheduling to make its TTDR always at a low level, with values ranging from 0.15% to 4.17%, which is an average reduction of 19.05% compared to the BAF algorithm, and an average reduction of 10.29% compared to the BAO algorithm. The TSAP algorithm lacks user task prediction and does not optimize task resource deployment of edge servers. However, it integrates the QoS and ESS for Pareto improvement during user task scheduling, and its TTDR value is relatively high, ranging from 11.22% to 22.71%, which is 4.28% lower than the BAF algorithm on average. The BAO algorithm jointly optimizes task caching and task offloading, and its TTDR value is 7.29% to 18.61%, which is an average reduction of 8.76% compared to the BAF algorithm. The TTDR value of the BAF algorithm is the highest, ranging from 15.31% to 28.51%, with an average value of 20.47%.Figure 11
Total task delay rate under different Zipf distributionα parameters.


## 6.2.1. Resource Deployment

In the edge-cloud collaborative computing environment, resource deployment with task prediction is evaluated and analyzed. The day is taken as the statistical cycle, each cycle is divided into 24 time periods, and each time period is 0.5 hours. In the experiment, the cloud service center predicts the tasks of the edge servers based on the two-dimensional time series, and the value of time slotn is 10. According to the experimental data of previous task prediction, the adjustment factor λ of the two-dimensional time series is set up to 0.27, and the random noise is ignored. The predicted result is compared with the actual number of tasks processed by the edge servers. As shown in Figure 3, the actual value of user tasks changes greatly, and the predicted value of tasks changes relatively gently. In general, the task prediction based on the two-dimensional time series is close to the actual value, the deviation of the average task number is less than 5%, and the accuracy of task prediction is high. The result can guide the cloud service center to optimize the task resource deployment of the edge servers.Figure 3
Prediction of user tasks.The average task hit rate (ATHR) is used to evaluate the effect of resource deployment with task prediction. ATHR refers to the average value of the local execution proportion of tasks of each edge server. The proportion of local task execution of the edge server is the ratio of the edge server receiving user task requests and executing tasks locally (because it has the task resources required for task operation). The high ATHR value indicates that the cloud service center has a high accuracy rate of pushing the task resources based on the predicted result. The high rate of local execution of tasks in the edge servers is conducive to improving both QoS and ESS. In the edge-cloud collaborative computing environment, the cloud service center can effectively predict user tasks based on the two-dimensional time series, classify and aggregate them according to the prediction result, and optimize the task resources pushed to each edge server. It can improve the local execution rate of user tasks on the edge servers, and reduce the passive application of task resources to the cloud service center because the edge servers do not have the resources required for task operation. Through 15 consecutive days of experiments, using task prediction based on the two-dimensional time series to deploy the task resources required by the edge servers, the average task hit rate of the edge servers is very high. As shown in Figure4, its ATHR value reaches 85.79%~92.39%, which is much higher than the average task hit rate of less than 50% for resource deployment without task prediction.Figure 4
Average task hit rate of edge servers.


## 6.2.2. Task Scheduling

We evaluate and analyze the task scheduling performance of the TSAP, RDAP-TSAP (combining RDAP and TSAP, as shown in Figure5), BAO, and BAF from the three aspects of ATCT, OSSE, and TTDR. In the edge-cloud collaborative computing environment, to compare different task scheduling performances, the m-group task scheduling schemes of TSAP consider the values of 3, 5, 7, and 9, respectively.Figure 5
RDAP-TSAP.(1) Average Task Completion Time (ATCT). The ATCT is the ratio of the total completion time of all user tasks to the number of user tasks during the statistical period. The ATCT mainly considers the user service experience. The smaller the ATCT value, the shorter the average completion time of all tasks and the higher the quality of user experience. In the edge-cloud collaborative computing environment, the Zipf distribution α parameter of the user task is set to the default value, and the ATCT of the TSAP, RDAP-TSAP, BAO, and BAF algorithms are compared and analyzed by changing the task scale. As shown in Figure 6, with the increase of the number of user tasks, the ATCT values of the four algorithms increase and show an approximately linear trend. The ATCT values of RDAP-TSAP, BAO, and TSAP algorithms are significantly lower than that of BAF algorithm. The TSAP algorithm effectively reduces the ATCT by Pareto improvement on the two objectives of QoS and ESS, and its ATCT value is reduced by 29.69% on average compared with the BAF algorithm. The BAO algorithm jointly optimizes task caching and task offloading, and its ATCT value is reduced by 35.68% on average compared with the BAF algorithm. The RDAP-TSAP algorithm predicts the number of user task types, improves the accuracy of resources required by the cloud service center to push tasks to edge servers, and further reduces the ATCT by Pareto improvement of QoS and ESS. The ATCT value of RDAP-TSAP algorithm is 42.07% lower than the BAF algorithm, and 9.94% lower than the BAO algorithm. In addition, the TSAP and RDAP-TSAP algorithms have the best ATCT values when m =5. It shows that the smaller m value leads to the single task scheduling scheme, and the higher m value will increase the calculation cost of task scheduling itself, which will improve the ATCT.Figure 6
Average task completion time under different tasks.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9Considering the influence of task Zipf distributionα parameter, the ATCT of the TSAP, RDAP-TSAP, BAO, and BAF algorithms will be further evaluated under certain user tasks. The number of user tasks is set up to 5k in the edge-cloud collaborative computing environment. As shown in Figure 7, as the value of the Zipf distribution α parameter increases, user tasks become more and more concentrated in the popular task types, and the ATCT values of the four scheduling algorithms decrease in varying degrees. Moreover, the TSAP and RDAP-TSAP algorithms have the best ATCT value when the m-group of task scheduling schemes is 5. Overall analysis, the RDAP-TSAP algorithm predicts the type and number of tasks, improves the accuracy of task resources push, increases the average task hit rate; and then integrates both QoS and ESS for Pareto improvement to optimize task scheduling. Its ATCT value is the best, with an average overall reduction of 34.94% compared with the BAF algorithm and 6.22% compared with the BAO algorithm. The TSAP algorithm benefits from two-stage Pareto improvement of QoS and ESS. In the absence of task prediction to optimize resource deployment, its ATCT value is overall reduced by 23.23% on average compared with the BAF algorithm.Figure 7
Average task completion time under different Zipf distributionα parameters.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9(2) Overall System Service Effect (OSSE). The OSSE is the difference between system service revenue and system service consumption of the cloud service center and edge servers in the statistical period, which is the ESS value of normalization. The OSSE mainly considers the interests of service providers. The higher the system service revenue of providers and the lower their system service consumption, the higher its OSSE value. In the edge-cloud collaborative computing environment, the user tasks are Zipf distribution with default α parameter. The OSSE of the TSAP, RDAP-TSAP, BAO, and BAF algorithms are evaluated by gradually increasing the number of user tasks. As shown in Figure 8, the OSSE values of the four algorithms increase with the number of user tasks, showing an approximate logarithmic growth. Compared with the BA algorithm, the OSSE values of the RDAP-TSAP, BAO, and TSAP algorithms are significantly higher. Among them, the TSAP algorithm optimizes task scheduling through Pareto improvement of both QoS and ESS objectives, and improves the overall service effectiveness of the cloud service center and edge servers. Its OSSE value overall increases by 24.69% on average. The BAO algorithm jointly optimizes task caching and task offloading, and its OSSE value increases by 36.78% on average. The RDAP-TSAP algorithm predicts based on the type and number of tasks in the cloud service center, effectively pushes the task resources, improves the average task hit rate, and optimizes task scheduling based on the objectives of QoS and ESS at the edge servers to further increase the OSSE value. Its OSSE value overall increases by 49.55% on average. In addition, compared with the BAO algorithm, the OSSE value of the RDAP-TSAP algorithm has an overall increase of 10.43% on average. Moreover, similar to the previous ATCT analysis, the OSSE values of the TSAP and RDAP-TSAP algorithms are optimal when m=5. It indicates that a small value of m leads to a single task scheduling scheme and is under-optimized, and a large value of m increases the computational overhead of task scheduling, which will reduce the OSSE.Figure 8
Overall system service effect under different tasks.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9Considering the influence of task Zipf distributionα parameter, the OSSE of the TSAP, RDAP-TSAP, BAO, and BAF algorithms will be further evaluated under certain user tasks. In Figure 9, the number of user tasks is 5k in the edge-cloud collaborative computing environment. As the value of the Zipf distribution α parameter increases, the user tasks gradually tend to be more popular task types and decrease the number of task resources required by edge servers, and the OSSE values of the four algorithms are greatly improved. And similar to the previous ATCT analysis, the OSSE values of the TSAP and RDAP-TSAP algorithms are optimal when the value of the m-group task scheduling schemes is 5. In general, the RDAP-TSAP algorithm predicts the tasks, improves the accuracy of task resources required to push edge servers, and increases the average task hit rate. Moreover, through the two-stage comprehensive optimization considering the QoS and ESS, the OSSE value of RDAP-TSAP algorithm is the best. Its OSSE value is 39.54% higher than the BAF algorithm, and 11.91% higher than the BAO algorithm. In the absence of task prediction, the TSAP algorithm uses Pareto optimization of the QoS and ESS, and its OSSE value is overall increased by 22.62% on average compared to the BAF algorithm.Figure 9
Overall system service effect under different Zipf distributionα parameters.
(a)
m=3(b)
m=5(c)
m=7(d)
m=9(3) Total Task Delay Rate (TTDR). The TTDR is the proportion of tasks whose task response time exceeds 3 times the average response time of similar tasks in the statistical time period. The TTDR affects the user’s quality of service and the effect of system service [53–55]. The low TTDR value can help reduce the average task completion time of users and enhance the QoS, and also help reduce the system energy consumption and improve the ESS. In the edge-cloud collaborative computing environment, user tasks are Zipf distribution with default α parameter, and the value of the m-group task scheduling schemes is 5. The TTDR of the TSAP, RDAP-TSAP, BAO, and BAF algorithms are evaluated by gradually increasing the number of user tasks. As shown in Figure 10, with the number of user tasks increasing, the TTDR values of the four algorithms increase. In general, the RDAP-TSAP algorithm is the best, the BAO and TSAP algorithm is the second, and the BAF algorithm is the worst. The RDAP-TSAP algorithm predicts tasks, classifies and aggregates tasks to reduce the number of task resources pushed to the edge servers, determines the delay threshold during resource deployment, and considers the available resources of the edge servers to reduce the probability of task delay. As the number of tasks increases, the total task delay rate increases slowly, and the TTDR value is controlled between 0.12% and 4.17%. The BAF, TSAP, and BAO algorithms lack task prediction in task scheduling and do not handle possible task delays. Their TTDR values are high, and the total task delay rate increases linearly with the increase of tasks. The BAF algorithm has the highest TTDR value, ranging from 8.37% to 37.12%. Because the TSAP algorithm performs Pareto improvement for task scheduling by integrating the objectives of QoS and ESS, it can reduce the average service completion time of tasks, and its TTDR value is relatively low, ranging from 3.67% to 34.39%. The BAO algorithm jointly optimizes task caching and task offloading, and its TTDR value is 2.17% to 21.19%.Figure 10
Total task delay rate under different tasks.Considering the influence of task Zipf distributionα parameter, the TTDR of the TSAP, RDAP-TSAP, BAO, and BAF algorithms is further evaluated under the condition of unchanged user tasks. In the edge-cloud collaborative computing environment, the number of user tasks is set up to 5k, and the value of the m-group task scheduling schemes is 5. The changes in their TTDR are shown in Figure 11. As the value of Zipf distribution α parameter increases, user tasks are more and more concentrated on task types with high popularity, and the task resource types required by edge servers are reduced. In general, the TTDR of the TSAP, RDAP-TSAP, BAO, and BAF algorithms has decreased to varying degrees. The RDAP-TSAP algorithm predicts, classifies, and aggregates user tasks to reduce the task resources required to push to the edge servers. During resource deployment, the delay threshold is judged to effectively reduce the occurrence of task delays, and then the Pareto optimizes task scheduling to make its TTDR always at a low level, with values ranging from 0.15% to 4.17%, which is an average reduction of 19.05% compared to the BAF algorithm, and an average reduction of 10.29% compared to the BAO algorithm. The TSAP algorithm lacks user task prediction and does not optimize task resource deployment of edge servers. However, it integrates the QoS and ESS for Pareto improvement during user task scheduling, and its TTDR value is relatively high, ranging from 11.22% to 22.71%, which is 4.28% lower than the BAF algorithm on average. The BAO algorithm jointly optimizes task caching and task offloading, and its TTDR value is 7.29% to 18.61%, which is an average reduction of 8.76% compared to the BAF algorithm. The TTDR value of the BAF algorithm is the highest, ranging from 15.31% to 28.51%, with an average value of 20.47%.Figure 11
Total task delay rate under different Zipf distributionα parameters.


## 7. Conclusion

In this paper, we focused on resource deployment and task scheduling optimization using task prediction in edge-cloud collaborative computing for users and service providers. We presented an edge-cloud collaborative computing framework for edge-cloud IoT, and an approach for task prediction based on the two-dimensional time series. Then, for service-oriented tasks, we described our proposed RDAP. Using our approach, user tasks can be predicted based on the two-dimensional time series in the cloud service center, user tasks classified and aggregated, and the resources required for task operation pushed to the edge servers to improve average task hit rate and reduce server resource overhead. We also described our designed TSAP. In our approach, at the edge servers, the random greedy approximation algorithm is used to make Pareto improvement to both QoS and ESS, and the tangent point or intersection point of the two objective curves is used to optimize the task scheduling. Finally, the experimental evaluation shows that the RDAP-TSAP algorithm combining RDAP and TSAP realizes the comprehensive optimization of user’s quality of service and effect of system service. Based on improving the average user task hit rate, the RDAP-TSAP algorithm has better ATCT, OSSE, and TTDR values than the TSAP, BAF, and BAO algorithms.



---

*Source: 2568503-2022-04-04.xml*