Federated Learning-Based Service Caching in Multi-Access Edge Computing System

Abstract

Multi-access edge computing (MEC) brings computations closer to mobile users, thereby decreasing service latency and providing location-aware services. Nevertheless, given the constrained resources of the MEC server, it is crucial to provide a limited number of services that properly fulfill the demands of users. Several static service caching approaches have been proposed. However, the effectiveness of these strategies is constrained by the dynamic nature of the system states and user demand patterns. To mitigate this problem, several investigations have been conducted on dynamic service caching techniques that can be categorized as centralized and distributed. However, centralized approaches typically require gathering comprehensive data from the entire system. This increases the burden on resources and raises concerns regarding data security and privacy. By contrast, distributed strategies require the formulation of complicated optimization problems without leveraging the inherent characteristics of the data. This paper proposes a distributed service caching strategy based on federated learning (SCFL) that works efficiently in a distributed system with user mobility. An autoencoder model is utilized to extract features regarding the service request distribution of individual MEC servers. The global model is then generated using federated learning, which is utilized to make service-caching decisions. Extensive experiments are conducted to demonstrate that the performance of the proposed method is superior to that of other methods.

1. Introduction

Mobile networks have become integral to modern society, connecting people and devices to the internet anytime and anywhere. With the increasing popularity of resource-intensive applications such as virtual and augmented reality, voice control, video streaming, 3D modeling, and interactive games [1,2,3], mobile networks generate a tremendous amount of data traffic. Cloud computing is an ideal approach for managing these tasks owing to its extensive computational and storage resources. Nevertheless, this approach has significant disadvantages, including high delay, low scalability, and risk of network congestion. To address this challenge, Multi-access Edge Computing (MEC) [4] has emerged as a promising solution in response to these limitations. By transferring computational tasks closer to data sources at the network edge, MEC reduces latency, improves data throughput, and enables a more efficient utilization of network resources.

However, the MEC system suffers from several problems arising from the inherent characteristics of the MEC environment. It is important to note that the computational resources available to MEC servers, which are embedded in base stations or access points, are much more constrained than those of cloud servers. Therefore, each MEC server deploys only a certain number of applications. The caching of appropriate services, commonly referred to as service caching, is an essential challenge in ensuring system performance. To address this issue, a static service caching approach was proposed by [5] to minimize the service response time. A fixed optimal decision is made without considering the dynamics of the user requests. Nevertheless, the ever-changing characteristics of MEC systems could result in a substantial influence on cache performance. Under real-life scenarios, such as in Rome, Italy [6], which is used as an experimental scenario, the geographical location of each user changes continuously over time. Consequently, each MEC server provides services to a different group of users at every time slot. These fluctuations lead to variations in the request patterns on each MEC server, leading to inconsistencies in the services that are requested and cached [7]. The caching service has to rapidly adapt to meet different request patterns. Moreover, the constantly changing workloads of services and resource-constrained MEC servers need effective caching solutions to reduce delay and enhance the overall quality of the user experience with available resources. Hence, employing a dynamic and adaptable approach to determine appropriate services is crucial, considering user demands and the geographical context.

Several dynamic service caching techniques have been proposed to facilitate the adaptive configuration of MEC services [8,9,10,11]. These approaches can be categorized into two types: centralized and distributed. In a centralized service caching system, a single central entity is responsible for making optimal decisions for the entire system. The central server collects data on user requests, resources available on MEC servers, and the transmission state. The data are then utilized as inputs for the optimal service caching decision-making procedure. In [8], the central server gathers information on the arrival of data and the conditions of the channel to dynamically allocate services.

Nevertheless, this approach is constrained by the inherent limits of centralized systems. Initially, the process of gathering data on the condition of system resources and user request data is resource-intensive [12]. The system is negatively affected by the high amount of information, ongoing transmission process, and reliance on a single centralized point, resulting in challenges such as network congestion and connection interruptions. Moreover, the scalability of centralized methods is a significant concern [13]. The number of MEC servers in the system exhibits a direct correlation with the complexity of the optimization problem. Consequently, centralized decision-making strategies become insufficient as the scale of the system increases, particularly considering the constrained resources and latency-sensitive nature of the applications. In addition, the centralized caching strategy leads to concerns about security and privacy problems [14]. The centralization of all user data, including sensitive information such as location and service requests, might potentially serve as the primary goal of a cyberattack.

Distributed service caching approaches have been proposed to address these issues. In distributed systems, the decision-making process of each MEC server is independent. It relies only on its state to determine appropriate services. This mitigates the stress on system resources and alleviates concerns about security vulnerabilities. Nevertheless, the efficiency of distributed techniques is compromised because of the constraints associated with local data. Specifically, owing to the dynamic nature of the system, using only local data at each MEC server to make decisions becomes ineffective. To address this issue, existing distributed service caching requires formulating complex optimization models. A previous study [15] adapted a system delay optimization model to the Markov decision process and proposed a deep Q-network for optimal decision making. Similarly, ref. [16] formulated a nonlinear mixed-integer optimization problem and solved it using a meta-heuristic algorithm.

However, existing distributed approaches face several challenges. Optimization problems are thoroughly formulated to represent the real-world environment. Reinforcement Learning (RL) algorithms often need a significant amount of interaction with the environment in order to acquire an efficient policy [17]. This inefficiency may pose a constraint, particularly in situations involving expensive or time-consuming data collection. Moreover, the state and action spaces are high dimensional, posing challenges for algorithms to efficiently explore and acquire information [17]. The curse of dimensionality may result in delayed learning and increased computational demands. Moreover, using these techniques in a distributed approach increases the complexity of the training process while simultaneously raising challenges in terms of convergence and stability [18].

In order to overcome these issues, we propose a distributed Service Caching Federated Learning-based framework (SCFL) with the objective of optimizing MEC system performance. SCFL utilizes a distributed strategy by storing and using data locally on MEC servers rather than gathering all data on a centralized server. This solution not only addresses the issue of optimizing system resources, but also mitigates problems related to security vulnerabilities. On the other hand, SCFL employs an autoencoder-based model for the purpose of acquiring data characteristics. The simplicity and efficiency of the proposed method not only guarantee optimal system performance, but also addresses the drawbacks associated with the complexity of existing distributed approaches. Specifically, the Adversarial Autoencoder (AAE) [19] model is utilized by MEC servers to capture complex data distributions based on local data. The Federated Learning (FL) [14] architecture is used to aggregate the local knowledge of MEC servers at a central server. This approach enables the system to acquire global knowledge about user request patterns without necessitating the sharing of the original data. Subsequently, the global model is sent to all MEC servers and is retrained using a limited quantity of local data before being utilized. This process enables the model to include global knowledge and adapt to the individual request patterns of each MEC server. Thus, the proposed method efficiently addresses the challenge arising from the dynamic nature of MEC systems. Based on mixing knowledge, each MEC server can make optimal cache service decisions independently. The cache replacement mechanism of SCFL also incorporates available resources into the service selection process, which further contributes to the reduction in system service latency. The main contributions of this study are as follows:

• We propose a FL framework system enabling MEC servers to determine, independently, service caching. Specifically, each MEC server utilizes its user data locally rather than sharing it with others. In addition, using FL enables each MEC server to acquire data characteristics corresponding to the entire system.
• We adopt the AAE for the distributed service caching problem. In particular, AAE efficiently extracts complicated distributions of distributed user data within the FL framework. The proposed method efficiently addresses the challenge of the dynamic nature of MEC systems by using both local and global knowledge.
• We conduct extensive experiments to determine the effectiveness of the model. Experiments that use both simulated and real-world mobility data are examined across multiple scenarios. The service hit ratio and service delay are used as key metrics to evaluate the performance of the service caching framework. The experimental results show that the proposed model increases the service hit ratio from $1.25$ to 5 times, while service latency is reduced by 15–$50\%$ compared to its counterparts.

The remainder of this paper is organized as follows. Section 2 presents the recent studies on service caching in the MEC system. We then describe the system architecture in Section 3. Details of the SCFL framework are presented in Section 4. Section 5 presents the simulation results. Finally, Section 6 concludes the paper.

2. Related Work

The emergence of MEC offers significant advantages in reducing the network burden and latency, and service caching has gained increasing attention in recent years. These methods can be classified into two categories: centralized and distributed. A central server is required in centralized approaches to gather information and make decisions for the entire system. In contrast, each MEC server makes individual decisions based on its own local perspective when employing distributed methods.

2.1. Centralized Service Caching

Service caching, data admission, and resource allocation problems of the MEC system were jointly investigated [8]. This study aimed to optimize the average service throughput of servers within the limitations imposed by bandwidth and memory restrictions. The central server gathered information regarding the arrival of data and channels. It transformed the data into a two-dimensional knapsack problem. Finally, this issue was resolved using dynamic programming to make optimal decisions.

Ref. [9] solved the problem of optimizing service caching by modeling four types of costs in an entire edge network system. The ITerative Expansion Moves (ITEM) method was proposed to address this problem. In each iteration, the ITEM transformed the optimization problem into a graph-cut problem and then solved it using the max-flow method.

Ref. [10] considered minimizing the load on a centralized cloud server in an MEC system. The simultaneous modeling of service caching and request routing problems was conducted considering practical constraints. The proposed method was based on a randomized rounding algorithm shown to approach optimal performance asymptotically. Moreover, this approach demonstrated adaptability in efficiently addressing changes in customer demand profiles.

The study [20] addressed the problem of optimizing service caching inside an MEC system comprising a single base station (BS) and multiple users. Specifically, the central BS determined the caching of services, whereas system users determined the offloading of tasks. The formulation of the optimization problem took the form of a Stackelberg game. Subsequently, a heuristic algorithm optimized the service caching decision at the BS.

In [21], the authors examined problems with service caching and request distribution inside the MEC systems. The system had a central cloud center that was interconnected with many BSs via the core network. A multi-objective optimization problem was formulated to minimize response time deadline violations. The authors proposed a genetic algorithm that proved close to the Pareto optimal front.

Centralized cache replacement systems use a central server that collects information and performs calculations for all MEC servers in the system. The central server uses heuristic algorithms, or RL-based models, to make optimal decisions for the entire system. As mentioned in Section 1, this not only imposes pressure on the system [12,13], but also raises issues about security and privacy [14]. In contrast to these methodologies, the proposed strategy is constructed in a distributed manner. MEC servers have the capability to independently use data and make individual decisions. This approach not only evenly distributes the workload throughout the system, but also reduces the resources required for system operation due to the compactness of the model weights in comparison to the original data. Moreover, the proposed approach also tackles the security concerns of the system.

2.2. Distributed Service Caching

Ref. [16] studied the performance optimization of a 3-layer MEC system, including users, access points, and a cloud server. The objective of the proposed approach was to reduce the delay in the system while considering the limitations imposed by the energy boundaries. The concurrent optimization of service caching and task offloading was defined as a nonlinear mixed-integer problem. The proposed model used Lyapunov optimization and Gibbs sampling techniques to enable access points to make optimal service caching decisions.

The authors of [12] studied the service caching problem in pervasive edge computing systems. The long-term optimization problem was deconstructed into a series of online sub-problems and then presented as Markov approximation problems. In addition, a distributed Markov chain was established to determine the most suitable services. Dynamic storAge-Stable Service caching (DASS) was proposed to maximize system utility.

Another study [15] was conducted to reduce the service latency of the MEC systems. This investigation included several service delays, including switching, serving, and offloading delays. An optimization problem was transformed into a Markov decision process and handled using the Deep Q Network algorithm. The proposed framework facilitated individual base stations to make independent decisions regarding service caching based on local conditions.

The authors of [11] introduced online service caching algorithms that do not rely on any assumptions regarding the patterns of user requests. The system under consideration has three distinct levels: user, edge server, and distant cloud layers. In addition, when a user requested a service unavailable on the edge server, the query would be sent to the remote cloud, or the service would be downloaded.

In systems using distributed cache replacement, MEC servers are able to make optimal decisions based on local information at each server. These solutions are typically complexly designed to address the limits imposed by data constraints and the dynamic nature of the MEC system [17]. This imposes significant pressure on MEC server resources and makes its practical implementation unfeasible [17,18]. In contrast to the current distributed techniques, the proposed strategy enables MEC servers to make independent decisions by using local data at each server and aggregated global knowledge. The FL architecture enables each MEC server to acquire information from the entire network without the need to share the raw data [14]. By incorporating local and global data characteristics, MEC servers are capable of making independent cache decisions efficiently. In addition, the AAE model used has a notably less complex structure compared to the RL models. This not only diminishes the resources required, but also enhances the practical applicability and guarantees model convergence.

3. System Model

In this section, the proposed system model is introduced. Specifically, the architecture of the three-tier network is described in detail. The fundamental operation of service caching within an MEC system is explained. Finally, the problem of service caching optimization is analyzed.

3.1. System Architecture

In this study, we consider the MEC system shown in Figure 1. This system comprises three distinct layers: a cloud server, MEC servers, and mobile users. In the top layer, the cloud server is assumed to possess massive computing and storage resources. Consequently, a comprehensive set of all $S_{all}$ services is implemented on a cloud server. In addition, the cloud server is interconnected with all MEC servers over the backhaul network.

The system comprises of a set of MEC servers $\mathcal{M}=\{1,2,\dots ,M\}$ ideally positioned inside an urban area. Despite the constraints imposed by limited resources, these servers provide significant advantages to the system because of their close proximity to the users. The distribution of computations over several geographical locations alleviates the computational pressure on the cloud server and mitigates delays resulting from data transmission. Due to resource constraints, each MEC server can only cache a limited number of distinct services $\mathcal{S}=\{1,2,\dots ,S\}$. Note that these MEC servers do not have direct connections or share information with each other.

The bottom layer includes a set of $\mathcal{U}=\{1,2,\dots ,U\}$ mobile users. It is assumed that each user is located inside the coverage area of a single MEC server, referred to as a local MEC server. User requests are transmitted via wireless connections to the corresponding local MEC server. The local server responds to a request if the requested service is available; otherwise, the request is forwarded to the cloud server.

The temporal scale inside the system can be categorized into two distinct types: user time slot $t_u$ and operation time slot $t_m$. The variable $t_u$ is used for actions that are related to the user, whereas $t_m$ reflects the temporal aspect involved in server operations, particularly in the case of service cache replacement. It is important to note that $t_m\gg t_u$ guarantees system stability.

Users move between the coverage areas involving multiple MEC servers during each user time slot. It is assumed that each user sends only one request to a local MEC server for each $t_u$. The request of user u in time step $t_u$ is denoted by the tuple $r_u\left(t_u\right)$ below.

$$r_u\left(t_u\right)=(u,s_u(t_u),d_u\left(t_u\right)),$$

(1)

where u, $s_u\left(t_u\right)$, and $d_u\left(t_u\right)$ are the user index, type of requested service, and data size of request, respectively.

On the other hand, the service demanded by all users during the user time slots follows to a Zipf distribution [22]. Specifically, $p_i$ denotes the probability of the ith most popular service of the system, which is determined as follows

$$p_i={\displaystyle \frac{{\displaystyle \frac{1}{i^{\gamma }}}}{{\sum }_{s=1}^{S_{all}}{\displaystyle \frac{1}{s^{\gamma }}}}}$$

(2)

where $\gamma$ denotes the skewness parameter. It can be seen that ${\sum }_{i=1}^{S_{all}}{p}_i=1$.

In contrast to the user time slot, $t_m$ represents the operations of both MEC and cloud servers. In each operation time slot, the MEC servers gather and analyze the statistical data related to the system. Service cache replacement is conducted at the end of each operating time slot to guarantee optimal system functionality. As stated, the MEC servers refrain from sharing statistical data involving users to guarantee privacy concerns. Thus, individual MEC servers are responsible for determining optimal caching services. The cloud server receives and responds to requests for caching these services. Finally, the chosen services are stored in the cache of each MEC server and continue to function throughout the subsequent operating time slot.

3.2. Problem Formulation

To optimize the utilization of MEC servers and mitigate system overload, it is essential to provide a service cache replacement mechanism that intelligently selects suitable services for deployment on MEC servers. In contrast to content caching, optimizing service caching necessitates investigating the computational resources inside the system. Thus, optimal decision making becomes more challenging.

${\xi }_s^m\left(t_m\right)$ represents the likelihood that service s is requested at MEC server m during the time interval $t_m$. To optimize the system performance, cache replacement aims to maximize the likelihood of requests for the selected services. Hence, the problem can be formulated as follows:

$${\displaystyle \underset{\mathcal{S}}{max}}{\displaystyle \sum _{t_u\in t_m}}{\displaystyle \sum _{m=1}^M}{\displaystyle \sum _{s=1}^S}{\xi }_s^m\left(t_m\right),$$

(3)

$$s.t.{\displaystyle \sum _{s=1}^S}{c}_s^m\le C_m,\forall m\in \mathcal{M},$$

(4)

where $c_s^m$ and $C_m$ denote the computational resources required for service s in MEC server m and the computational capacity of MEC server m, respectively. Equation (3) aims to maximize the likelihood of requests being served by the service caches of all MEC servers throughout each operation time slot. Constraint (4) guarantees that the total number of requested computational resources does not exceed that of the MEC server.

According to (3), determining the likelihood of each requested service is crucial for decision making regarding selecting optimal services. In an environment with limited information exchange, individual MEC servers can use local data obtained from user requests to estimate the probability of certain requested services. Nevertheless, user mobility leads to instability in the distribution of requests observed by each MEC server. Therefore, an efficient FL-based service caching framework for MEC systems is proposed in the following section.

4. Proposed Service Caching Framework

In this section, the proposed service caching framework is introduced. First, the system workflow is outlined. The process of calculating the popularity scores using AAE and FL is then described in detail. Finally, an algorithm for service cache replacement based on popularity scores is presented.

4.1. Overview

To enhance the efficiency of service caching within a system, we propose a framework that enables distributed service cache replacement. The mechanism is illustrated in Figure 2. Specifically, an FL-based method is proposed to determine the popularity score corresponding to each service. MEC servers can effectively gain knowledge of the distribution of service requests throughout the entire system while maintaining user data privacy. Additionally, a scoring system for service caching that considers both popularity and resource limitations is presented to evaluate the effectiveness of the services. Individual MEC servers can autonomously select optimal services based on the service caching score. The workflow of the proposed framework consists of the following steps.

• The individual MEC servers accept user requests and consolidate them into local data. It should be noted that the local data are not shared with any other server.
• The popularity score of each service is determined by each MEC server using its local data and knowledge acquired from FL.
• Each MEC server calculates the caching score for each service based on its popularity score and the availability of resources. The caching scores are ranked to identify the most ideal services.
• The decision-making process of each MEC server determines the replacement of service caches. Redundant services are eliminated, while underemployed services are replicated from the cloud server.

4.2. FL-Based Service Popularity Score

This section introduces the FL structure used to calculate the popularity scores for each service. Determining the popularity scores of services consists of two distinct stages: distributed training and inference. The raw data provided by the user requires preprocessing to be appropriately used as input for both phases. After the training process, each MEC server has its own trained popularity prediction model. During the distributed inference phase, individual MEC servers use locally processed user data as inputs to the trained model to obtain the popularity scores for the services.

4.2.1. Distributed Training Phase

The training process for each operational round is shown in Figure 3. The system performs five steps to train the model effectively. These steps include data preprocessing, local model training, transmission of the local model to the cloud server, aggregation of the global model, and sending the global model to the MEC servers.

(1) Data Preprocessing: Initially, the servers of the MEC system gather data on service requests from all users involved within their coverage area during each operation time slot. The dataset comprises unique user identification numbers, geographical coordinates, and specific services requested by the users.

As stated in the previous section, $S_{all}$ denotes the total number of services the system offers. During each user time slot, individual users initiate requests for multiple types of services. Hence, the query data of the user u at $t_u$ can be denoted by a one-dimensional matrix in the following format:

$$R_u\left(t_u\right)=[r_1\left(t_u\right),r_2\left(t_u\right),\dots ,r_{S_{all}}\left(t_u\right)],$$

(5)

where the binary variables $r_i\left(t_u\right)\in [0,1]$ indicate whether user u has requested service i in time slot $u_t$. The data are gathered during each operation time slot of the training or inference phase. Hence, it is necessary to aggregate the user-request data throughout the whole duration of each operation time slot. Note that $t_m\gg t_u$ indicates that each user can make multiple requests during each $t_m$ period. $R_u$ represents the request data of user u during operation time slot $t_m$. Thus, $R_u\in {\mathbb{R}}^{1\times S_{all}}$ can be determined as follows:

$$R_u\left(t_m\right)=\{\sum _{t_u\in t_m}{r}_i(t_u),1\le i\le S_{all}\},$$

(6)

The request data of all the users is merged into a 2-dimensional matrix using each MEC server. The matrix $Q_m\left(t_m\right)=[R_1\left(t_m\right),\dots ,R_U\left(t_m\right)]\in {\mathbb{R}}^{U\times S_{all}}$ denotes the processed request data of MEC server m in $t_m$. This matrix reflects the request characteristics of all users on each MEC server in each operation time slot. Hence, it can be efficiently used as an input during the training phase of deep learning neural networks. Figure 4 illustrates the data-preparation process.

(2) Local Model Training: Following the data preprocessing, the MEC servers begin with the training of the local model. The structure of the AAE is shown in Figure 5. AAE comprises a typical AE component and a discriminator component inspired by Generative Adversarial Networks (GAN) [23]. Hence, in addition to the reconstruction loss inherited from AE, AAE also aims to minimize the regularization loss of GAN. Regularization loss reduction facilitates matching the latent representation $\mathbf{z}$ with the prior distribution. Simultaneously, minimizing reconstruction helps the data generated from the latent space $\mathbf{z}$, which is mapped to a prior distribution, to accurately reflect the characteristics of the input data.

The data $Q_m\left(t_m\right)\in {\mathbb{R}}^{U\times S_{all}}$ serve as the dataset for the AAE model. Specifically, data samples $R_u\left(t_m\right)\in {\mathbb{R}}^{1\times S_{all}}$ are used as the input layer of the network, and the latent space $\mathbf{z}\in {\mathbb{R}}^{1\times d_z}$ is the middle layer, where $d_z$ is the dimension of the latent space. ${\mathbf{q}}_{\varphi }\left(\mathbf{z}\right|R_u\left(t_m\right))$ and ${\mathbf{p}}_{\theta }({\widehat{R}}_u\left(t_m\right)|\mathbf{z})$ are the probabilistic encoder and decoder of the AE model, respectively. The training phase of the AE guarantees that the conditional distribution ${\mathbf{q}}_{\varphi }\left(\mathbf{z}\right|R_u\left(t_m\right))$ effectively transforms the input data into the distribution $\mathbf{p}\left(\mathbf{z}\right)$ of the latent space. In addition, ${\mathbf{p}}_{\theta }({\widehat{R}}_u\left(t_m\right)|\mathbf{z})$ denotes the probability of a reconstructed value ${\widehat{R}}_u\left(t_m\right)$ given the latent representation $\mathbf{z}$. Hence, the reconstruction loss can be calculated as follows:

$${\mathcal{L}}_{res}\left(R_u\right(t_m),{\widehat{R}}_u(t_m),\varphi ,\theta )=-{\mathbb{E}}_{{\mathbf{q}}_{\varphi }(\mathbf{z}|R_u\left(t_m\right))}log\left({\mathbf{p}}_{\theta }\left({\widehat{R}}_u\left(t_m\right)\right|\mathbf{z})\right).$$

(7)

The AAE employs an adversarial training approach to match the posterior distributions of the latent space $\mathbf{z}$ with a given distribution $\mathbf{p}\left({\mathbf{z}}_{pri}\right)$. The GAN-based model has one generator and one discriminator. The discriminator is used to differentiate between data that derives from the generator and target distribution $\mathbf{p}\left({\mathbf{z}}_{pri}\right)$. Conversely, the generator attempts to produce data that the discriminator classifies incorrectly. It is evident that after finishing the training phase, the generator can produce data samples that closely match those created from the target distribution. The encoder sub-network ${\mathbf{q}}_{\varphi }\left(\mathbf{z}\right|R_u\left(t_m\right))$ of the AE is utilized as the generator in the AAE architecture. ${\mathbf{d}}_{\psi }$ denotes the discriminative network. Thus, the optimization problem for adversaries can be expressed as follows:

$$\underset{{\mathbf{q}}_{\varphi }\left(\mathbf{z}\right|R_u\left(t_m\right))}{min}\underset{{\mathbf{d}}_{\psi }}{max}{\mathbb{E}}_{{\mathbf{z}}_{pri}\sim \mathbf{p}\left({\mathbf{z}}_{pri}\right)}log\left({\mathbf{d}}_{\psi }\left({\mathbf{z}}_{pri}\right)\right)+{\mathbb{E}}_{\mathbf{z}\sim \mathbf{p}\left(\mathbf{z}\right)}log(1-{\mathbf{d}}_{\psi }\left(\mathbf{z}\right)).$$

(8)

The optimization issue can be addressed using a two-stage regularization process, including the training of both the discriminative network ${\mathbf{d}}_{\psi }$ and the generative network ${\mathbf{q}}_{\varphi }\left(\mathbf{z}\right|R_u\left(t_m\right))$. The discriminator is trained to distinguish between samples generated by the latent variable $\mathbf{z}\in {\mathbb{R}}^{1\times d_z}$ (negative samples) and samples created from prior distribution ${\mathbf{z}}_{pri}\in {\mathbb{R}}^{1\times d_z}$ (positive samples) by using the following loss function:

$${\mathcal{L}}_{dis}\left(R_u\right(t_m),\mathbf{z},\varphi ,\psi )={\mathbb{E}}_{{\mathbf{z}}_{pri}\sim \mathbf{p}\left({\mathbf{z}}_{pri}\right)}log\left({\mathbf{d}}_{\psi }\left({\mathbf{z}}_{pri}\right)\right)+{\mathbb{E}}_{\mathbf{z}\sim \mathbf{p}\left(\mathbf{z}\right)}log(1-{\mathbf{d}}_{\psi }\left(\mathbf{z}\right)).$$

(9)

On the other hand, the generator is trained with the objective of fooling the discriminator by optimizing the following loss function:

$${\mathcal{L}}_{gen}\left(R_u\right(t_m),\mathbf{z},\varphi ,\psi )=-{\mathbb{E}}_{\mathbf{z}\sim \mathbf{p}\left(\mathbf{z}\right)}log(1-{\mathbf{d}}_{\psi }\left(\mathbf{z}\right)).$$

(10)

After adversarial training, the samples generated by ${\mathbf{q}}_{\varphi }\left(\mathbf{z}\right|R_u\left(t_m\right))$ cannot be distinguished from those generated by $\mathbf{p}\left({\mathbf{z}}_{pri}\right)$. In this study, the prior distribution $\mathbf{p}\left({\mathbf{z}}_{pri}\right)$ is set as a normal distribution $\mathcal{N}(0,1)$ [24].

After completing the local training process, each MEC server is provided with trained weights for the AAE model. Let $w_m\left(t_m\right)$ be the weight of the local model trained by MEC server m in time slot $t_m$. It is important to note that $w_m\left(t_m\right)$ comprises the weights of both the generator and discriminator sub-networks in the AAE model.

(3) Sending Local Model to Cloud Server: Once the training operation time slot $t_m$ is finished, the MEC servers send the local models $w_m\left(t_m\right)$ to the Cloud server, where $m\in \mathcal{M}$. The local models are trained using the data specific to each MEC server, including the distinct data characteristics associated with each MEC coverage area. In addition, the cloud server is given with information on the number of requests, denoted as $n_m\left(t_m\right)$, which are received by the MEC server m during the time slot $t_m$.

(4) Global Model Aggregation: In contrast to conventional approaches to model training, the Cloud server does not have the requisite data for conducting training. This enables FL to address the issues related to user data privacy and security. The cloud server aggregates the global model after obtaining the weight parameters from the local models. This study uses the FedAvg aggregation method, one of the most popular techniques [25]. The global model is determined as follows:

$$w_G\left(t_m\right)=\sum _{m=1}^M{\displaystyle \frac{n_m\left(t_m\right)}{{\sum }_{m=1}^M{n}_m\left(t_m\right)}}{w}_m\left(t_m\right),$$

(11)

where $w_G\left(t_m\right)$ denotes the weight of the global model in the operation time slot $t_m$.

(5) Sending Global Model to MEC Servers: Following the aggregation procedure, the global model $w_G\left(t_m\right)$ is sent to all MEC servers. The MEC server updates the local model after receiving the global model. The local model for each MEC server is updated as follows:

$$w_m(t_m+1)=w_G\left(t_m\right),$$

(12)

The update process enables the models at each MEC server to acquire knowledge about the global data distribution without requiring the data transmission between MEC servers.

These training periods are repeated until the completion of the training phase. By conducting iterative training using local data and generating a global model, the FL framework demonstrates its ability to efficiently extract data characteristics from the entire system while safeguarding user data privacy.

4.2.2. Distributed Inference Phase

Each MEC server has a trained global model $w_G$ at the end of the training phase. In addition to the underlying global data characteristics, it is noteworthy that each individual MEC server has its own data characteristics. Hence, to enable the model to efficiently adapt to the dynamic nature of the data, it is necessary to retrain the model using the most recent local data. Particularly, at the start of each operation time slot, local models are trained using the local data from the previous time slot for a duration of $ϵ$ epochs. Once the training process is finished, the resulting local model $w_m$ is used to choose the most suitable cache services.

The local model $w_m$ comprises trained sub-networks, namely ${\mathbf{q}}_{\varphi }$ and ${\mathbf{p}}_{\theta }$. Consequently, a new data sample ${\widehat{R}}_u\left(t_m\right)$ can easily be generated from the input data $R_u\left(t_m\right)$. The latent space can be derived from the input data $\mathbf{z}\sim {\mathbf{q}}_{\varphi }\left(\mathbf{z}\right|R_u\left(t_m\right))$. Additionally, new data samples can be obtained using ${\widehat{R}}_u\left(t_m\right)\sim {\mathbf{p}}_{\theta }\left({\widehat{R}}_u\left(t_m\right)\right|\mathbf{z})$.

The output matrix ${\widehat{Q}}_m\left(t_m\right)\in {\mathbb{R}}^{U\times S_{all}}$ is received by each MEC server from the trained model and input data $Q_m\left(t_m\right)$. The rows of the matrix ${\widehat{Q}}_m\left(t_m\right)$ represent individual users. In contrast, the columns represent all of the services available within the system. The values of the same service requested by all the users are accumulated. Consequently, the output matrix ${\widehat{Q}}_m\left(t_m\right)$ is transformed into a popularity score vector denoted by $D_m\left(t_m\right)\in {\mathbb{R}}^{1\times S_{all}}$. This vector is determined as follows:

$$D_m\left(t_m\right)=\left\{d_i^m\right(t_m),1\le i\le S_{all}\},$$

(13)

where $d_i^m\left(t_m\right)$ denotes the popularity score of service i on MEC server m in operation time slot $t_m$. Utilization of the popularity score of each service by each MEC server enables the determination of suitable services for each $t_m$.

4.3. Service Caching Policies

This section describes the cache strategy that provides optimal performance for distributed systems. Initially, a caching metric that considers the level of popularity is introduced. Subsequently, a cache replacement algorithm is presented to enhance system performance while considering the limitations imposed by the available resources.

(1) Caching Score: Despite the benefit of popularity scores in predicting service demand, several drawbacks are associated with using popularity as a sole criterion for evaluating services. Popularity does not consider the resources required by each service. The deployment of resource-intensive services may result in the allocation of resources to other services. Consequently, the number of services that can be maintained in the cache decreases, leading to a corresponding decline in the ability to satisfy user requests. Hence, the cache score is computed as follows:

$$C{S}_m\left(t_m\right)=\{{\displaystyle \frac{d_i^m\left(t_m\right)}{c_i^m}},1\le i\le S_{all}\},$$

(14)

where $c_i^m$ denotes the computational resources required for service i in MEC server m. Since the units of the operators in Equation (14) are distinct, they must be normalized to interval $(0,1)$ before being used to calculate the cache score. It can be seen that the service cache score is proportional to the popularity score to maximize the deployment of services that can satisfy the most user requests. By contrast, as the resource requirements of a service increase, its cache score decreases. This increases the number of services cached on each MEC server.

(2) Service Cache Replacement: After calculating the list of cache scores for all services, each MEC server executes Algorithm 1 to provide a list of the most optimal services for the subsequent time slot operation. Each MEC server has unique service lists owing to user data and resource status variations. The primary objective of the cache score is to optimize the likelihood of cache service requests, whereas Algorithm 1 guarantees the alignment of cache service resources with the capacity of the individual MEC servers.

In each operation time slot $t_m$, the MEC servers individually gather data and compute the cache scores $C{S}_m\left(t_m\right)$ by using Equation (14). To select the most appropriate services, the MEC server employs a selection process whereby services in $C{S}_m\left(t_m\right)$ are listed in decreasing order based on their cache score. Selecting services with the highest score facilitates properly solving Equation (3). The popularity score value can evaluate the suitability of services for each MEC server, thanks to distributed training and decision making. In addition, performing calculations and cache replacement at each operation time slot $t_m$ helps to consistently maintain cache performance. On the other hand, the MEC server concurrently computes and updates the current hardware state to align with the chosen services. This process satisfies Constraint (4) regarding system resources. Exclusively prioritizing cache performance optimization without considering current resources might result in the selection of services causing stress on the system. This not only leads to an inefficient allocation of resources, but also results in increased service latency. After completing the calculation process, each MEC server acquires a list denoted as $S_m(t_m+1)$ consisting of services with the highest cache score while simultaneously satisfying resource limitations. Services that are not implemented on the MEC server are fetched from the cloud server, and redundant service caches are removed.

Algorithm 1 Adaptive Service Cache Replacement

1: Input:   2: ${\mathcal{S}}_m\left(t_m\right)$: List of current cached services in MEC server m at $t_m$   3: $D_m\left(t_m\right)$: List of service popularity scores in MEC server m at $t_m$   4: $c_i^m$: Required resource for service i in MEC server m   5: $C_m$: Resource capacity of MEC server m   6: Output:${\mathcal{S}}_m(t_m+1)$: List of optimal cached services in MEC server m at $t_m+1$   7: Initialize available resource $C_a=C_m$   8: Initialize score list index $i=0$   9: Initialize need-to-download services ${\mathcal{S}}_d\left(t_m\right)=⌀$ 10: Initialize optimal cached services ${\mathcal{S}}_m(t_m+1)=⌀$ 11: Calculate list of service cache scores $C{S}_m\left(t_m\right)$ by Equation (14) 12: Sort $C{S}_m\left(t_m\right)$ in descending order 13: while$C_a\ge 0$do 14:     Set s is the ith service in $C{S}_m\left(t_m\right)$ 15:     if $c_s^m\le C_m$ then 16:         Push s to ${\mathcal{S}}_m(t_m+1)$ 17:         if $s\notin S_m\left(t_m\right)$ then 18:            Push s to ${\mathcal{S}}_d\left(t_m\right)$ 19:         end if 20:         Set $C_a=C_a-c_s^m$ 21:         Set $i=i+1$ 22:     end if 23: end while 24: Download services $s\in {\mathcal{S}}_d\left(t_m\right)$ from Cloud server. 25: Delete services $s\in {\mathcal{S}}_m\left(t_m\right)-{\mathcal{S}}_m(t_m+1)$. 26: Return ${\mathcal{S}}_m(t_m+1)$.

The summary of notations used in this work is shown in Abbreviations section.

5. Experiment and Evaluation

This section presents an in-depth description of the performance of the proposed model. The configuration of the simulation environment and real-world data used in the experiments are presented. Furthermore, the setup of the metrics for performance comparisons is also included. Finally, the results of the experiment provide a comparative analysis of the performance of the proposed model compared with other methods. The experimental results demonstrate that the proposed approach outperforms its counterparts in addressing service caching problems.

5.1. Experimental Setup

Extensive experiments are conducted to evaluate the performance of the proposed model. The simulation environment is an 8 km by 8 km residential area divided into 64 $(1\times 1)$ units [6]. A total of 64 MEC servers are randomly distributed within each unit in this area. The computational capacity of each MEC server is set to 36 GHz. A backhaul network connects all the MEC servers to the cloud server. The connection between the cloud and MEC server has a bandwidth of 150 Mbps [26]. Moreover, MEC and cloud servers provide a category of 500 distinct services. Without compromising the generality, these services are listed in descending order of popularity.

Within the simulation area, 300 users traverse the coverage areas of various MEC servers. The simulated user-position data are derived from the mobility traces of taxis in the central region of Rome, Italy, in 2014 [6]. This information contains the user ID, longitude, and latitude of each user in each time slot. The first ten days of mobility trace data are used to conduct the experiments. The user sends one request to the local MEC server during each 2-min time slot. The data size for each request is randomly generated following the uniform distribution in the range $[0.05,5]$ Mb. Furthermore, the required computational resources of the service are randomly generated in the range $[0.1,1]$ GHz. Notably, the distribution of requested service categories over the entire time slots follows a Zipf distribution, with an ordered list of 500 system-provided services. The parameter gamma for skewness is set to $0.8$ [27].

The neural network model used in this study is structured as follows. As stated in Section 4, the input and output dimensions of the autoencoder network are equivalent to the total number of services inside the system. Hence, the dimensions of both the input and output layers are set to 500. Based on the results mentioned in [28], it has been shown that the size of the latent layer is calculated using the equation $[1+\sqrt{{size}_{input}}]$, resulting in a value of 23. Thus, the first layer of discriminator is set to 23, whereas the final layer is 1. The sigmoid function facilitates the discriminator’s ability to classify incoming samples from the specified distribution and the latent space. The learning rate used in the model training process is set to ${10}^{-4}$. To enhance the efficiency of the model, the weights of the AE network are initialized according to the approach suggested by [29]. The ADAM optimization method [30] is used to train the model.

The dataset, which consists of mobility traces and service requests from all users, is partitioned into training and testing sets in a 7:3 ratio based on the duration of the data samples. Each MEC server systematically acquires the training dataset at regular intervals of 60 min, referred to as the operation time slots. Following the preparation, the data are trained using individual MEC servers acting as clients in the FL paradigm. The local models are sent to the cloud server for aggregation and broadcast to the MEC servers. The communication rounds continue until the completion of the training phase. The trained model is used to determine the service caching decisions for individual servers. The performance of the approach is evaluated using metrics based on the services deployed and those requested by users in the testing set. Subsequently, the system efficacy is evaluated using metrics. Details of the parameters settings are listed in

Table 1. Simulation parameters.

Parameter	Value
Number of MEC servers	64
Number of users	300
Number of all services	500
Computational capacity of MEC server	36 GHz
User time slot	2 min
Operation time slot	60 min
Backhaul network bandwidth	150 Mbps
Request data size	$[0.05,5]$ Mb
Required computational resource of service	$[0.1,1]$ GHz
Skewness parameter	$0.8$
Input layer of AE	500
Latent space of AE	23
Learning rate	${10}^{-4}$

.

5.2. Metric

Extensive experiments are conducted to evaluate the performance of the proposed model under multiple scenarios. Two metrics are used to comprehensively describe the performance comparison results: the service hit ratio and service delay.

The service hit ratio indicates the capacity to choose a service that aligns with user demands. A service hit is captured when the requested service is installed properly on the MEC server. Conversely, if a service is not deployed on an MEC server, it is classified as a service miss. $SH$ and $SM$ denote the total counts of service hits and misses, respectively, in the system. Hence, the service hit ratio $SHR$ is determined as follows:

$$SHR={\displaystyle \frac{SH}{SH+SM}}.$$

(15)

The primary objective of this study is to determine service location decisions using historical user request data. Hence, the delay serves as a measure to evaluate the performance of the proposed method rather than being utilized to formulate an optimization problem. In this study, we investigate delays resulting from the unavailability of requested services on a local MEC server. When the computation is offloaded to the cloud server, there is an increase in the duration required to transmit the request information as opposed to processing on the local MEC server.

The data transfer rate in a wired network between MEC and the cloud server corresponds to the link bandwidth. The uplinks from MEC to the cloud server are used to transmit the task data. L denotes the wired uplink transmission latency from MEC to the cloud server, calculated as follows:

$$L=\frac{d_u\left(t\right)}{W_u},$$

(16)

where $d_u\left(t\right)$ and $W_u$ denote the task data size and uplink channel bandwidths allocated to the wired link between MEC and the cloud server, respectively.

It is noteworthy that the testing phase is conducted using a certain number of operation time slots. Consequently, determining the service delay and service hit ratio involves computing the average value experienced by the entire system during each operation time slot.

5.3. Counterpart

To verify the effectiveness of the proposed framework, we evaluate SCFL and the following approaches.

• Random Caching (RC) [31]: This approach employs a random selection process for determining the service types deployed on the MEC server.
• Least Recently Used (LRU) [22]: The prioritization in service deployment on MEC servers is based on the recency of their requests.
• Least Frequently Used (LFU) [22]: This approach leverages historical statistical data from past time slots to replace the services that have received the lowest requests.
• Federated Learning with AE (FLAE): This method employs the traditional autoencoder model to extract data features that are then used to select the appropriate service.

5.4. Performance Evaluation

5.4.1. Comparison of Service Hit Ratio

Figure 6 illustrates the service hit ratio of the service caching approaches inside a system with a computational capacity of 12–72 GHz on individual MEC servers. The system has 64 MEC servers and serves 300 mobile users. The efficacy of these approaches improves with an increase in resource capacity. This is because increased computational power directly relates to the capacity to fulfill client requests. Nevertheless, a significant performance gap exists between deep learning-based approaches and other methods. Specifically, with the 12 GHz MEC server, the service hit ratios for SCFL and FLAE are $0.26$ and $0.2$, respectively. In contrast, the corresponding ratios for LFU, LRU, and RC are $0.13$, $0.1$, and $0.04$. When the computational resource reaches 72 GHz, SCFL has a service hit ratio of approximately $0.6$, whereas LFU, LRU, and RC exhibit ratios below $0.3$. Moreover, it is consistently shown that SCFL demonstrates superior performance compared to FLAE across all experimental settings. The results indicate that AAE can extract information about request data distribution more than the conventional AE model.

Experiments are conducted to evaluate the model’s performance with different numbers of users in the system. The MEC system has 64 MEC servers, each with a computational capacity of 36 GHz, while the number of users varies from 50 to 250. The experimental results are presented in Figure 7. When the system has only 50 users, SCFL and FLAE reach service hit ratios of $0.28$ and $0.2$, respectively, whereas LRU and RC are both equal to $0.08$. It is evident that as the number of users consuming the system’s service increases. This also raises the service hit ratio. When the number of users reaches 200, the service hit ratio of SCFL is $0.42$, while those of FLAE and LFU are $0.23$ and $0.15$, respectively. This demonstrates that the proposed strategy chooses service caches that are suitable for fulfilling the user’s requirements. This occurs because of the direct correlation between the number of users and the amount of data requested from the MEC servers. Enhancing the data enables the AAE model to more effectively capture distributions. When the user count in the system rises from 150 to 200, the service hit ratio of SCFL experiences an increase from $0.37$ to $0.42$. Nevertheless, despite this significant improvement, the service hit ratio of systems using SCFL only experiences a little rise from $0.42$ to $0.43$ when the user count increases from 200 to 250. This indicates that when the system has 200 users, the amount of user request data is sufficient for SCFL to achieve maximal efficiency. The saturation minimizes the impact of additional data on system performance.

Figure 8 shows the service hit ratio when the system contains different numbers of MEC servers. Specifically, the number of users and computing resources of each MEC server are 300 and 36 GHz. The number of MEC servers used in the investigations varied from 16 to 64. Notably, the size and coordination of the simulation area remained unchanged. By increasing the quantity of MEC servers, the coverage area of each server is reduced. Consequently, when the number of MEC servers in a system increases, the number of users served by each MEC server decreases. As shown in Figure 8, SCFL consistently demonstrates higher performance in all experimental settings, outperforming other techniques. When there are only 16 MEC servers in the system, the service hit ratios for SCFL and FLAE are $0.5$ and $0.4$, respectively. The values for RC, LRU, and LFU are $0.13$, $0.18$, and $0.24$, respectively. As stated above, increasing the quantity of MEC servers decreases the number of users using the services provided by each MEC. As a consequence, the quantity of data that each MEC server can gather to utilize in the model is constrained, which lowers model performance. SCFL and FLAE achieve service hit ratios of 0.42 and 0.37, respectively, when the system comprises 64 MEC servers.

5.4.2. Comparison of Service Delay

Figure 9 illustrates the average latency of the entire system during each operation. The evaluation is conducted by varying the computational capacity per MEC from 12 to 72 GHz in a system including 64 MEC servers and 300 users. SCFL demonstrates minimal delay when compared to the other approaches. When the computational resources of each server is set at 12 GHz, the delay incurred when using RC exceeds 200 s. In contrast, the corresponding latency for SCFL is approximately 140 s. On the other hand, as the resource capacity increases to 72 GHz, the latency of the complete system decreases to less than 80 s when using SCFL, compared to 105 s when using FLAE. This demonstrates the outstanding capability of SCFL in selecting suitable services. The substantial correlation between the services chosen and requests made by users enables handling these requests at the local MEC server rather than sending them to the cloud server, which increases the system latency.

The service delay of the entire system in each operation time slot with different numbers of users is shown in Figure 10. The experiments include a simulation of systems with 64 MEC servers, each providing a computational capacity of 36 GHz. The number of users varies from 50 to 250. It can be seen that the number of service requests received by MEC servers increases as the number of users in the system increases. Consequently, the number of requests the cloud server handles increases, resulting in increased latency for the entire system. When the number of users is 50, the service latency in the system using SCFL and FLAE is 35 and 48, respectively. In addition, LFU, LRU, and RC cause a latency of 55, 57, and 73 s, respectively. When the number of users reaches 250, the use of SCFL results in a system latency of approximately 100 s. In comparison, FLAE reveals a latency of approximately 125 s under the same conditions. Moreover, implementing LRU and RC in a system with 250 users results in a delay of over 150 s. Therefore, SCFL demonstrates outstanding effectiveness in providing services to different numbers of users.

Experiments are conducted to evaluate the overall latency of the system containing different numbers of MEC servers. The number of MEC servers increases from 16 to 64, with each server having a computational capacity of 36 GHz. The service is utilized by a total of 300 mobile users. Notably, the area and coordinates of the experimental area are unchanged. Therefore, when increasing the number of MEC servers, the coverage area of each MEC server will become smaller. The experimental results are shown in Figure 11. When the system comprises only 16 MEC servers, the average latency in a single round using SCFL is approximately 80 s, whereas that of the other methods exceeds 100 s. When the number of deployed servers is increased to 64, the system using SCFL experiences a minor increase in latency, reaching 90 s. In the same settings, RC, LRU, and LFU result in service delays of 170, 151, and 132 s, respectively. It is evident that using SCFL consistently results in minimal system delay compared to other approaches.

6. Conclusions

In this study, we propose a distributed server caching framework to optimize the performance of the MEC system. The proposed method aims to maximize the service hit ratio while minimizing service latency. This is the result of the capability to select cache services that satisfy user requirements while taking into account the resources of the system. The integration of the FL framework and AAE model enables each edge server to acquire in-depth knowledge derived from both local characteristics and global data distributions. The proposed approach efficiently mitigates the limitations of centralized systems, such as network congestion, by using FL. SCFL also guarantees the security and privacy of user data by avoiding from sharing original data that may include sensitive information. In addition, SCFL effectively addresses the challenges encountered by existing distributed cache systems, including complexity, convergence challenges, and high computing resource requirements. The proposed framework efficiently captures the complex data distributions due to the dynamic nature of the MEC system by using the AAE model, while also ensuring simplicity and convergence. The results of intensive experiments demonstrate that the proposed framework performs better than other strategies in effectively caching suitable services. Using SCFL helps increase the service hit ratio from $1.25$ to 5 times compared to its counterparts. Additionally, SCFL-using systems reduce service latency by 15–$50\%$, demonstrating their ability to adapt to system conditions.

Due to its simple nature, the integration of SCFL into current MEC infrastructures can be seamless, especially if the MEC system already accommodates machine learning operations. The connectivity between MEC servers and a central server allows for the formation of an FL architecture on the edge computing system. The AAE model is deployed at edge servers to capture local data distribution, while a central server is used to aggregate global knowledge received from the entire system. The MEC servers and the central server use a wired connection for the purpose of transferring models. Once the mixing knowledge is obtained, MEC servers conduct the inference process to provide cache scores for services. Each MEC server has the ability to independently make service cache decisions, taking into account the available resources and cache score. The proposed architecture guarantees scalability by integrating FL, which allows for the participation of various MEC servers without compromising the system’s functioning. In the future, we aim to expand the scope of research by conducting a comprehensive evaluation of the system latency. Specifically, all factors causing system delay, including computation, model training, and transmission, are investigated to improve the practicality of the proposed method. Furthermore, issues raised by the FL framework, such as training asynchronously between MEC servers, also need to be considered.