2.1 Edge computing in IoT system

Recently, IoT data analytics play an important role in predicting the status of our surroundings by processing and computing collected from a huge number of IoT users [1, 2]. Use cases benefiting such IoT data analytics include smart city video analytics, smart manufacturing, health care, etc [2, 3]. Nevertheless, many IoT devices have limited computing resources and storage to cache diverse data and locally execute the heavy computation task. Therefore, cloud computing has been adopted to provide IoT users with sufficient storage and processing capability through data centers in the cloud. That is, a massive amount of multi-modal data collected from numerous heterogeneous IoT users have to be transferred to the cloud for storage, computation, and decision-making. However, the cloud platform is usually located physically far from the IoT users causing slow response times. Users can no longer tolerate such slow responses of cloud-based computing when using IoT applications such as self-driving cars, and voice recognition. More recently, therefore, edge computing, which brings resources close to the end-users, has been recognized as a solution to reduce the response time for IoT applications [4, 19, 20]. [20] shows that the edge paradigm will reduce the latency and distribute network traffic in computation offloading. [19] propose the smart-edge algorithm for the joint optimization of computation, caching, and communication to address the disadvantages of traditional cloud computing in terms of communication delay and network load.

2.2 Data caching in IoT-edge system

There have been some efforts aimed at reducing the total response time of the computation task for supporting a number of IoT applications via edge caching [6, 8, 21, 22]. Recent work has applied content caching to IoT-edge systems to reduce redundant computations, delay, and energy consumption. Especially, an edge node caches the output data of the task [9] and intermediate task results that may use for future task executions [21]. While previous studies show that the computation content caching can minimize the total response time, the fundamental assumption on reusing the same task input, output, or intermediate data may not hold for many IoT applications [6].

Program data caching, on the other hand, caches the library/program data for processing IoT applications. Caching program at edge nodes is an effective way to relieve the burden of the backhaul network and to reduce the delay caused by initializing necessary program data or task migration due to the absence of the program [5, 6]. There have been some research related to task offloading and the program caching [6, 23, 24]. [23] jointly considering the access network selection and program placement to improve the response time for edge applications. [6] minimize the computation delay and energy consumption of the edge node by jointly consider the program data caching placement, computation offloading decisions, and system resource allocation. The previous works have shown that the program data caching can reduce the total response time of the task. In particular, it can reduce the initialization of an application such as loading required libraries and initializing user-specific code. However, previous works [6, 23] did not consider the cooperative edge to overcome the limited storage and computing resources caching less diverse data in the system.

2.3 Cooperative caching

Compared to the cloud, the storage capacity at the edge is relatively limited [25]. Unfortunately, as the volume of content keeps increasing, the caching capacity at the edge nodes gets more limited [9]. Thus, there have been some studies on cooperative caching to efficiently utilize the storage resources as well as to improve the hit ratio and data retrieval time in the edge-enabled networks [8, 26]. [26] suggests a dynamic cache replacement algorithm which considers in the tree network topology. The strategy calculates the node access frequency to achieve better cache placement performance. [8, 9] suggest a spatially caching strategy to construct cooperative networks of edge servers. For maximizing the storage efficiency of edge servers, each edge server does not cache the data which have been cached by its nearest edge server. Despite their meaningful works in content caching, the fundamental assumption on reusing task input and intermediate data may not suitable for many IoT applications. Similar to content caching, there have been also many cooperative systems in program caching to improve the storage efficiency and the computing delay [14, 21, 26]. [14] proposes an online edge service caching algorithm to reduce the traffic sent to the cloud by utilizing the cooperative features of base stations in mobile edge cloud. In [21], the author studies how to edge servers cooperatively process the data of multiple applications via the heuristic greedy method and caching strategy.

2.4 Motivation

The previous works [8, 9, 26] have shown that cooperative caching is effective in managing the network traffic and storage of edge servers in the edge-enabled computing system. In particular, cooperative caching can increase the diversity of cached data, leading to a high hit ratio. However, these previous works did not consider the waiting time of the user requests for data because they focused on content caching, where no computation is needed but only sending the requested data. Although [9, 14, 15] suggested the cooperative caching algorithms in program data caching, they have not considered the waiting time of the requests in the cloudlet due to numerous task requests from the IoT users.

It is addressed in [12, 27] that the long waiting time can be caused by numerous task requests from IoT users. Specifically, since the program is required to execute the task in the cloudlet, the waiting time on a cloudlet can be increased if there is only one cloudlet that caches the high demanded program data and multiple IoT users send the task requests that require the same program data. Yet, in these works [12, 27], when a cloudlet receives a request and does not cache the related program data, it can forward its request only to the cloudlet that is directly connected to itself. As a result, the options of the cloudlets to which the requests can be forwarded are limited.

Therefore, in this study, we propose the cooperative edge caching strategy to handle a large number of computation tasks requested by IoT users, requiring the same program data. Specifically, in the proposed caching strategy, replicas of the high demanded program data are cached into the multiple cloudlets based on the number of requests and data popularity. Hence, if the cloudlet that received the task requests from IoT users does not cache the required program data, then the requests can be forwarded to the multiple cloudlets, leading to lower response times of the tasks.

3.1 Overall system architecture

The overall architecture of the IoT-Edge system is depicted in Fig 1. We consider a particular region that can be defined based on its features (e.g., residential district, business district) as IoT users will request the computing task related to these features [27, 28]. Each region consists of a Coordinator Server (CS), cloudlets, and IoT users. The role of each system element is defined as follows:

• Coordinator Server: CS is introduced to make a caching decision as a control server of our caching system. In each region, CS is installed as in [29, 30], while it may be replicated for different geographical regions. At the time when the CS is deployed, it retains the IP addresses of the cloudlets and RTT among the cloudlets in its region [27, 31].
  In the proposed system, CS mainly has the following two components:
  • Clustering Agent (CA): Since cloudlets are limited in the computing resources and caching space, CA forms clusters (referred to as ‘cooperative edge network’ in this paper) of cloudlets in edge networks [32]. Cloudlets in the same cooperative network can cache replicas of program data, so the tasks requiring the same program data can be distributed into multiple cloudlets. CS clusters the cloudlets when they are first deployed or later when a new cloudlet is additionally deployed in the region.
  • Caching Decision Agent (CDA): CDA is in charge of making a caching decision. CDA performs the caching decision when it receives the average number of task requests from the cloudlets of the region. After caching decision is finished, the CS sends the information of which cloudlet caches which program data as well as the estimated waiting time of each cloudlet to the cloudlets in its region. The waiting time refers to the time taken to finish executing task at the cloudlet. The process to calculate the waiting time of each cloudlet is explained in Section 5.
• Cloudlet: Cloudlet aims to bring computing capabilities and servers to the network edge and closer to users. Cloudlet is co-located with base station (BS) and deployed near IoT users to provide computing resources [28, 33]. In addition, cloudlets are usually deployed at some important sites, such as factories and schools [28, 32]. In these applications, it is necessary to optimize the task response delay of users. Recently, IoT applications such as augmented reality and natural language processing requires computation-intensive, resource-limited IoT users can send a task request to the cloudlets [28]. The main objective of using cloudlet is to process most of the data at the network edge and send less traffic toward the cloud, resulting in low data storage requirements and low total response time [33].
  If the cloudlet that receives a task from an IoT user does not cache the required program data for the task, the cloudlet can forward the task to another cloudlet in the same cooperative edge network. In the proposed system, each cloudlet has the following two components:
  • Reachability table: Each cloudlet contains the reachability table that has the waiting time and IP addresses of cloudlets in the same cooperative network, and the information of what program data each cloudlet has [27, 30]. The reachability table is updated after the caching decision is finished by the CS.
  • Monitoring Agent (MA): MA monitors the incoming task requests and stores the number of incoming requests for each program data during a certain period of time (e.g. a day) [34]. MA sends the stored information to CDA for caching decision.
• IoT users: IoT users are smart devices such as smart phones, wearable computing devices and self-driving cars [35]. To efficiently provision the real-time services for the applications, IoT users request the task with their collected data to one of near cloudlets.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 1. Cached-enabled IoT-edge system architecture.

https://doi.org/10.1371/journal.pone.0270183.g001

3.2 Procedure of processing task requests

In this subsection, we describe how IoT user sends the task to the cloudlet and gets back a result of that task. The process of requesting a task and getting the result corresponding to the task work as follow:

1. When the IoT user wants to send a computation request, it first sends a request to the BS. BS finds the nearest cloudlet using the agent discovery process and forwards the request to the found cloudlet [36].
2. The cloudlet that first received the request from the IoT user works as a proxy cloudlet. If the proxy server contains the required data for the task, it executes the task and returns the result to the IoT user.
3. Otherwise, using the reachability table in the proxy cloudlet, the proxy cloudlet selects the cloudlet with the lowest waiting time among the cloudlets that has the required data for the task. Then, the selected cloudlet will execute the task. After the cloudlet finished executing the task, the cloudlet record what program data is used for the task using MA.
4. If none of the cloudlets can execute the task due to the absence of required program data, the IoT user directly sends the task to the cloud.

4.1 System model

We denote by I the set of cloudlets in the region, i ∈ I. Let J and K be the sets of program data and IoT users, respectively. The program data j, j ∈ J, is required to process the computing tasks at the cloudlet.

We denote s_j as the size of the input data for the task requiring program j. For any program data j, x_ij is used to indicate whether the data is cached at the cloudlet i (1)

We denote n_ij as the number of incoming requests requiring program data j to the cloudlet i. MA measures n_ij during a certain period of time, and sends the measured value to CDA in CS. Using the received n_ij, CDA can obtain the popularity of each data p_j by calculating . Then, using the Exponential Weighted Moving Average (EWMA), CDA obtains the average popularity for data j at cloudlet i as [37]: (2) where σ ∈ [0, 1] is a weight and is the average popularity obtained in the previous period.

Using the average popularity, obtained from Eq 3 we can get the hit ratio of the system (denoted by h). The hit ratio is defined as the probability of finding the program required for the task in the cache of cloudlets. We then can express the hit ratio as: (3)

The above equation means the probability of finding of at least one cloudlet that caches the required program data in the IoT edge. The last part of Eq 3, ∏_{i ∈ I}(1 − x_ij) becomes zero if one of the cloudlets i ∈ I caches the program data j. The binary variable x_ij is decided by CDA in CS when it performs the caching decision. The details about the caching decision process will be explained in Section 5.2.

4.2 Transmission time between IoT user and cloudlet

If an IoT user transmits the task to an optimal cloudlet i, the transmission time between IoT users and the cloudlet i, t_ij can be expressed as: (4) where r_i is the average transmission rate at the cloudlet i and s_j is the size of input data of the task that requires the program j. Since the size of the result is usually very small, the delay to receive the result is negligible [15, 30]. Each IoT user k will be allocated to a bandwidth β for transmitting its task. We denote P_ik and c_ik as the transmit power of and channel gain from IoT user k to i, respectively. Let σ is Gaussian noise, the transmission rate beteen r_ik achieved at IoT user can be written as .

Then, we now can get the total transmission time including the cases of the task is executed in the cloudlet or the cloud, : (5) where T_miss is the sum of total transmission time and execution time between IoT user and the cloud when the task is executed in the cloud.

4.3 Waiting time

When the task requests arrive at the cloudlet, each cloudlet is supposed to process one task at a time. A large number of task requests are sent to the cloudlet and so the tasks must be queued [12]. We assume that the computation task requests are generated by IoT users in the region according to a Poisson process. The time required to process the task depends on the computing workload of the task and the computing power of each cloudlet i. The tasks have different computing workloads following the distribution of the general service rate. Hence, we model the waiting time of requests at the cloudlet as an M/G/1 queuing system [17].

The multiple arrivals of task requests requiring program j can be distributed into multiple cloudlets in our considered architecture. Hence, we can express the expected arrival rate of task request requiring j to the cloudlet i, λ_ij as: (6) where Y_j is the number of cloudlets that contain the data j in a cooperative network which is given by Y_j = ∑_{i ∈ I} x_ij. λ is the total arrival rate of task requests to the region (i.e λ = ∑_{i ∈ I}∑_{j ∈ J}λ_ij). We then define the service time to process a task requiring program j at i as (7) where c_j and f_i are the computational computing workload of request requiring program j and the computing power of cloudlet i, respectively.

Then we calculate the average number of task requests at i as: (8)

We use Pollaczek-Khinchine formula to get the average queue length and use Little’s law to obtain the average waiting time of the request at the cloudlet i as: (9)

5.1 Clustering process

To prevent the request is sent to a far cloudlet which can cause an unexpected long transmission time, CS groups the cloudlets into clusters based on the RTT among them. For collecting RTT among cloudlets, CS sends lists of IP addresses to its cloudlets. Using the lists, cloudlets measure the RTT (e.g. ping mechanism using IP) among themselves. Then cloudlets return the measured RTT to the CS.

In the clustering algorithm, we introduce a control parameter, t_cl to limit the size of the cluster (i.e., the intra-cluster delay). The larger size of the cluster results in a higher T^r, but a greater number of cloudlets. For the clustering process, CS performs the following process:

1. CS first finds a random cloudlet that is not included in any cluster, then makes this cloudlet as a start of a new cluster
2. CS finds the cloudlet i that is connected to the cluster by 1 hop. Cloudlet i can be included in m if it does not belong to any other cluster and if the RTT among cloudlet i and the other cloudlets in the cluster is less than t_cl. Otherwise, the cloudlet i cannot be assigned to the cluster.
3. CS keeps expanding the cluster until there is no cloudlet that can be added to the cluster.

CS repeats the above process until there is no cloudlet that does not belong to any cluster. The clustering algorithm occurs at a moment when a new cloudlet is deployed in the system. After the clustering process is completed, CS starts caching data into its cluster using our proposed caching algorithm.

Algorithm 1 Caching Algorithm

1: Input:

  I, J, X: matrix of x_ij

2: Initialize:

  Sort program data set of J in descending order based on p_j

3: for each j ∈ J do

4:  Obtain i that has the largest

5:  x_ij ← 1

6: end for

7: Calculate T^w using Eq 10

8:

9: while , in i ∈ I do

10:  for each i ∈ I do

11:   for each j ∈ J do

12:    if all i ∈ I is full then

13:     Terminate the Caching Algorithm

14:    else if then

15:     x_ij = 1

16:    end if

17:    Calculate using Eq 10

18:    if then

19:     

20:    else

21:     x_ij = 0

22:    end if

23:   end for

24:  end for

25:  if then

26:   Terminate the Caching Algorithm

27:  else

28:   

29:  end if

30: end while

5.2 Caching process

The 0–1 knapsack problem in Eq 12, can be solved using brute force, but the approach is not scalable as the number of data and cloudlets increases. Instead, the problem can be solved using the greedy algorithm by making a heuristic decision at each stage. Hence, we design the heuristic caching algorithm. Moreover, we introduce the control parameter θ which is an adjustable threshold to control the cache storage of cloudlets and the complexity of the algorithm. The algorithm is terminated when the reduction of waiting time during the caching process is less than θ. The larger value of θ may save the storage of cloudlets but caches less number of replicas may lead to more waiting time.

The CDA component in CS executes the following caching algorithm:

1. For each data j ∈ J, CS caches program data j into the cloudlet i which has the largest remaining storage () (Line 3–6).
2. CS calculates the current waiting time T^w using Eq 10. (i.e. ) (Line 7).
3. For each data j ∈ J and each cloudlet i ∈ I, CS calculates the expected waiting time of the cooperative network when additional data j is cached into the cloudlet i. Then CS selects x_ij that leads to lowest when x_ij set to 1. (Denoted as ). However, The selected x_ij has to satisfy constraint (Line 10–24).
4. The algorithm is terminated if none of cloudlet can cache the data j due to full of storage (Line 12–13).
5. If the decrements of the total response time after caching selected data j into the cloudlet i is less than θ (i.e., ), caching process is terminated (Line 25–26). Then the algorithm is repeated from Step 3.

After the caching decision is finished, CDA sends the information of which cloudlet caches which program data and the estimated waiting time of each cloudlet to the cloudlets in the region. The information is updated into the reachability table of each cloudlet and cloudlets use the reachability table to select the cloudlet that executes the task.

6.1 Simulation settings

We consider the scenario in which 100 cloudlets are randomly distributed. The topology of the cloudlets is generated randomly in each experiment using a random graph generator. Then the RTTs among the cloudlets are uniformly distributed from 0.5 to 1.2 ms [27].

There are 50 types of program data, with the popularity of each program follows a Zipf-distribution with a shape parameter α = 7 and the popularity weight factor σ is set to 0.125 to avoid high fluctuations in the estimation [22, 38, 39]. The transmission power of IoT user is set from 0.2W to 0.3W [40, 41]. The bandwidth between cloudlets from users is 500 Mbps. Since the task request has the input data and the computing workload to be completed, we set the input data and output data size s_j as an average of 2 MB [42]. Since the waiting time at the cloudlet is designed as M/G/1 queuing, the computing workload of the request c_j follows uniform distributions in [75 × 10⁶, 200 × 10⁶] cycles [43].

We set the cloud’s computation capability is set to 2 times of the cloudlet [24]. The delay from users to the cloud is 0.3 s [36]. We initially set t_cl as 0.015 s [24, 27, 36], which constructs average of ten clusters in the entire simulation area. We simulate the algorithm by varying the arrival rate from λ_i = 1 to 10 (requests/s) for each cloudlet assuming the IoT user requests a task per second. The capacity of each cloudlet is set to range from 20—40% of the total size of unique data in the system so that the storage capacity of the (e.g. when J = 50, each cloudlet can store a maximum of 10 to 20 data) [12].

We compared our proposed algorithm to the other two methods. The first algorithm is the cooperative caching algorithm where the popular data is cached into the one cloudlet for each cooperative network (denoted as general cooperative caching (CC)). The second algorithm caches one replica for the popular data in the cooperative network (denoted as replica caching (RC)).

6.2 Simulation results

In Fig 2, we show the effect of the arrival rate λ_i on the total response time for each algorithm with different Zipf parameters α: 0.3, 0.7, and 1.0. The proposed algorithm always outperforms the other two comparing algorithms for all the three values of α with respect to the total response time. The delay difference among the three algorithms gets larger when α is increased as shown in Fig 2, but the proposed algorithm relatively consistent because it adjusts the number of replicas depending on the popularity of the data. The smaller α implies the lower consistency of the user’s preference for the popular data. In other words, when α is high (e.g α = 1.0), the demand for tasks requests requiring popular data (i.e., the popularity is p_j) is higher than when α is low. Accordingly, the waiting time at the cloudlets that contain the popular data gets higher. We thus can say that the proposed algorithm can achieve a relatively lower delay on various values of α by caching multiple replicas of the data that have higher popularity and arrival rate in the cluster.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 2. Total response time varying λ_i when the Zipf distribution parameter α = 0.3, 0.7 and 1.0.

https://doi.org/10.1371/journal.pone.0270183.g002

We plot Fig 3 describing the total response time with the different values of β between IoT users and cloudlet i to examine how transmission rate affects the total response time. The average delay of the three algorithms decreased with the higher transmission rate due to less transmission delay between the. IoT user and cloudlet. We also observe that all the three algorithms achieve higher response time with larger λ_i because the waiting time is increased due to the increase in the number of requests. As shown in Fig 3, CC and RC are less tolerable to the higher arrival rate compared to the proposed algorithm. Especially, the total response time of the two comparing methods are highly increased when the arrival rate (λ_i) is bigger than 8. This is because CC and RC cache the one or two data for each program data in the cooperative network so that the requests requiring the same program data are concentrated to one or two cloudlets leading to the long waiting time at the cloudlet.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 3. Total response time varying λ_i when the bandwidth β = 300 and 500 Mbps.

https://doi.org/10.1371/journal.pone.0270183.g003

In Fig 4, we compare the total response time on the different computing workloads of the task. Our algorithm gets more effective when the task gets more complicated. We examined the three algorithms with different computational workloads of the task (c_j): 75 × 10⁶ and 200 × 10⁶ cycles. We see from Fig 4 that when c_j is 75 × 10⁶ cycles, the proposed algorithm still shows a better total response time for all the different arrival rates. As shown in Fig 4, the total response time of CC and RC is highly increased from λ_i = 7. When c_j is increased to 200 × 10⁶ cycles, our proposed algorithms shows average of 28% and 19% a better total delay than CC and RC when λ_i is relatively low(i.e. λ_i ≤ 7). Then the total response time of the proposed algorithm significantly increases when λ_i gets larger than 7. As shown in Fig 4, while our algorithm still has a stable delay on a larger request intensity, the delays of CC and RC are significantly increased.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 4. Total response time varying λ_i when the the computation workload of the task c_j = 75 and 200 cycles.

https://doi.org/10.1371/journal.pone.0270183.g004

In Fig 5 (Left), the graph shows the total response time depending on the size of input data s_j. The proposed algorithm shows an average of 25% and 20% better total response time than the CC and RC. The control of waiting time is also important to minimize the total response time. Fig 5 (Right) shows the ratio of waiting time to total response time for three algorithms. As shown in Fig 5, the ratio of waiting time is increased as λ_i increases since more requests are held in each cloudlet. The ratio difference between the three algorithms shows that the waiting time has a large effect on the total response time. The waiting time of the proposed algorithm is relatively smaller than CC and RC also indicating that the waiting time can be reduced by caching replicas into multiple cloudlets and distributing the task requests.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 5. Total response time varying (left) the size of task data s_j and (right) the ratio of waiting time in total response time varying λ_i.

https://doi.org/10.1371/journal.pone.0270183.g005

Fig 6 plots the total response time versus the number of cloudlets increasing from 30 to 150 when λ_i = 5, 7 and 10 requests per second. We set the number of clusters as 10. We observe that as the number of cloudlets increases, the total response time decreases for all the three methods, while the proposed algorithm outperforms the other two methods. This is because the proposed algorithm can cache more program data in the cooperative network when there are more cloudlets, resulting in the task requests being distributed to more cloudlets. As shown in Fig 6 the differences in total response time between the proposed methods and the other two methods gets smaller as the number of cloudlets increases, but the delay differences between the proposed algorithms and the other two methods get larger when the arrival rate increases.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 6. Total response time varying the number of cloudlets when λ_i = 5, 7 and 10.

https://doi.org/10.1371/journal.pone.0270183.g006

Fig 7 (Left) shows the total response time with the various number of clusters when the number of cloudlets is 100. The total response time decreases when the number of clusters increases from 1 to 10. When there are a fewer number of clusters, the size of each cluster gets bigger than when more number of clusters are formed. Hence, when there is one cluster, the task request is sent to the further cloudlet leading to a longer transmission time than when 5 and 10 clusters are formed. Interestingly, the total response time increases when the number of clusters increases from 10 to 20. Although the request is sent to the further cloudlet for the case of 10 clusters than for the case of 20 clusters, the difference in the number of cloudlets is less than when the number of clusters is increased from 1 to 10, as shown in Table 1. There are 10 cloudlets with the average of 1.34 replicas in each cloudlet when 10 clusters are formed, whereas only 5 cloudlets with an average of 1.08 replicas when 20 clusters are formed. Therefore, the task requests can be executed in a fewer number of cloudlets for the case of 20 clusters, compared to the case of 10 clusters, leading to a long waiting time. The proposed algorithm improves the total response time up to 7% and 4% than CC and RC, respectively.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 7. Total response time varying (left) the number of clusters and (right) the caching capacity of the cloudlet.

https://doi.org/10.1371/journal.pone.0270183.g007

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 1. The maximum number of cloudlets, the maximum and average number of replicas in each cluster for different number of clusters.

https://doi.org/10.1371/journal.pone.0270183.t001

Fig 7 (Right) shows the total response time with the various caching capacity of the cloudlet. As shown in Fig 7 (right), the difference in total response time between the proposed algorithm and the two comparing methods gets larger when the capacity increases. Since the proposed algorithm caches the replicas of the popular data, the total response time increases when the storage capacity of the cloudlet decreases. However, the other two comparing methods do not overcome the proposed method even if the storage capacity of the cloudlet is less than 20% of the total size of unique program data in the system.