# Federated Learning-Based Service Caching in Multi-Access Edge Computing System
## 3 System Model
### 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,\ldots,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,\ldots,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,\ldots,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}(t_{u})\) below.  
\[r_{u}(t_{u})=(u,s_{u}(t_{u}),d_{u}(t_{u})), \tag{1}\]  
where \(u\), \(s_{u}(t_{u})\), and \(d_{u}(t_{u})\) 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 \(i\)th most popular service of the system, which is determined as follows  
\[p_{i}=\frac{\frac{1}{\tilde{r}^{\gamma}}}{\sum_{s=1}^{S_{all}}\frac{1}{s^{ \gamma}}} \tag{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.  
Figure 1: MEC system architecture.