## 2 Motivation and Core Concepts  
Based on the continued development of IoT technology, a number of applications, such as health monitoring applications, are emerging that require feedback within a short time slot. These applications are difficult for mobile devices to handle; therefore, MEC technology has emerged as a solution. Figure 1 shows the task failure rate and processing time for three cases: (1) using only mobile devices, (2) using only edge devices, and (3) using a built MEC environment. The failed tasks represent the percentage of failed tasks out of the total tasks, and the processing time represents the average service time minus the average network delays. We divided failure into two causes. First, the CPU capacity of the user device and the edge cloud server is exceeded. Second, the task cannot be completed due to user mobility or network (WLAN/MAN/WAN) delay. For the sake of simplicity, we use the term \"failed task\" in the paper. The processing time is derived from the following formula: processing time + network delay = service time. If the operation is performed in Only_Mobile or Only_Edge, since no network delay occurs, the processing time and service time are the same. In the case of Mobile + Edge, the actual service time minu  
Figure 1: Task failure rate and processing time in the MEC (mobile edge computing) environment. (**a**) Percentage of failed tasks; (**b**) Processing time. processing time because the task is offloaded to the edge cloud server. If the task is offloaded to the central cloud server, the actual service time minus WAN delay becomes the processing time. Moreover, we operate the latency-tolerant tasks and latency-sensitivity tasks at a ratio of 5:5 in this experiment. The deployment and use of a MEC environment are advantageous in terms of task failure rate and processing time. From the analysis of the task failure rate, it is observed that task failures occur due to the lack of resources in the case where only mobiles are used. When using only edge devices, the task failures occur due to the frequent movement of mobile devices. In particular, when the number of users (devices) exceeds 1000, the performance of using only edge devices sharply deteriorates. The MEC environment complements these shortcomings, and the task failure rate is relatively low. However, the MEC environment uses offloading techniques to offload tasks, which may slow down the processing time compared to using mobile devices alone. When offloading occurs, the latency caused by sending a task to an edge cloud server and returning a response from the server can have strongly negative effects. In addition, if a task of such performance degradation is latency-sensitive, such as autonomous driving services, the damage suffered by the user would be profound. Therefore, we need a solution that can guarantee rapid processing for latency-sensitive tasks. We devised an approach to classify tasks and offload latency-tolerant tasks first to reduce the deadline violation incurred by offloading, as shown in Figure 2. Throughout this paper, we assume that each virtual machine (VM) has only one task. Once offloading is decided, the tasks of the applications on a user device are classified as latency-tolerant and latency-sensitive tasks. The proposed LCDA then decides which tasks to be offloaded. For Case A, in Figure 2, where a latency-tolerant task is selected for offloading, our offloading algorithm chooses the edge cloud server with the smallest number of latency-sensitive VMs. Offloading a latency-tolerant task minimizes any adverse effects on latency-sensitive tasks that are currently running on the edge cloud server. If there are many servers with the same number of latency-sensitive VMs, we consider CPU utilization and the distance to the user device as secondary metrics. For Case B, where a latency-sensitive task is selected for offloading, our offloading algorithm chooses the server with the lowest CPU utilization.