## 3 Efficient Caching Rate-Control for Edge Computing
### A Framework for EDCrammer  
The framework for EDCrammer controls the data distribution rate using an enhanced PID controller by communication with the SDC dynamically, which has minimum functions. In the framework, a distributed Message Queuing Telemetry Transport (DMQTT) supports communication among EDCrammer, the SDC manager, and a cloud service. Communication by MQTT is performed by the central message broker. If the message broker is located in the cloud, it can lead to long latency between MQTT clients on the edge node and load congestion on the central cloud. Therefore, by a message broker deployed on an edge node, latency and load congestion can be mitigated. In this environment, EDCrammer only requires the current cache utilization from SDC in edge nodes. When receiving the current cache utilization, EDCrammer calculates the error which is a difference between the desired cache utilization and the current cache utilization, and then estimates the next amount of data by computation of the PID controller, and finally transmits data to SDC in edge nodes. Therefore, EDCrammer remotely controls cache utilization in edge nodes  
Although rate-control between the cloud and the edge is certainly important, an awareness of how data consumption affects the cache and then coping with user's data consumption as soon as possible is even more important. A conventional cache provides passive read/write storage, making it difficult to dynamically check data production and consumption. The SDC can efficiently monitor all cache operations: creating, reading, updating, and deleting. The SDC can also produce data from EDCrammer and provide it to a service on an edge node or a user device. On the other hand, when a cache is provided as a service in cloud computing, the pay-as-you-go pricing policy must be  
Figure 2: A concept of efficient edge caching between a cloud and edge nodes for live video streaming. considered. If a CSC uses a certain cache capacity, the CSC would get a stable cache hit ratio and pay a little extra cost. For this reason, optimizing cache capacity is important because it allows CSCs to save money and CSPs to save storage resources. Figure 3 shows the communication among EDCrammer, the SDC manager, the SDC, and a cloud service or application. IP depletion makes it difficult to assign a public IP to all participating entities and establish Peer-to-Peer (P2P) communication. For this reason, MQTT, which performs publish/subscribe-based communications through an MQTT broker, has become the de facto messaging protocol for IoT. We deploy MQTT brokers on both the cloud and edge nodes, in a distributed fashion. Deploying the message broker on the edge node and on the central cloud, our DMQTT can distribute and minimize the traffic load concentrated on the central cloud node as well as reduce the latency among MQTT clients on the edge node. Then, a cloud service or application can use RESTful APIs to get and use data. Figure 4 illustrates the overall flows within the framework based on the communication diagram shown in Figure 3. The flows can be divided into the data caching part between the cloud and edge nodes and the data usage part between the edge nodes and user devices. The caching part uses the following steps. (1) First, the SDC manager informs EDCrammer about the cache capacity, the desired cache utilization, and the current cache status. The cache utilization is usually zero at the beginning. (2) An advanced PID controller calculates and predicts the data distribution required to reach the desired cache utilization. The advanced PID controller is described below. (3) The output from the advanced PID controller is checked to prevent over-utilization of the cache capacity and control the rate for caching. (4) EDCrammer splits the data based on the output and (5) distributes it to the SDC manager. (6) The SDC manager identifies the state of the SDC, and (7) stores the data in the SDC. (8) Then, the SDC manager checks the cache utilization and notifies EDCrammer, which initiates a repeat of Steps (1)-(8).