arXiv:2605.16089v1 [cs.LG] 15 May 2026
Centralized vs Decentralized Federated Learning: A trade-off performance analysis Chaimaa MEDJADJI
Guilain LEDUC
Sylvain KUBLER
Yves Le Traon
University of Luxembourg [email protected]
University of Luxembourg [email protected]
University of Luxembourg [email protected]
University of Luxembourg [email protected]
Abstract—Federated Learning (FL) has emerged as a promising paradigm for collaborative model training across distributed edge devices while preserving data privacy especially with the huge increase amount of data due to the adoption of technologies which contributes to the growing number of IoT devices. Storing this amount of data centrally is challenging due to issues like limited communication, privacy, and regulations. FL can be Centralized (CFL), Decentralized (DFL), and Semi-decentralized (SDFL). Choosing the right FL architecture depends on the application’s needs. However, very few research studies have experimentally compared these three types of architectures to not only understand the respective strengths and limitations, but also trade-offs between different performance indicators. This paper overcome this lack of analysis, conducting experimental analyses using the Fedstellar simulator, MNIST dataset, and MLP classifier.
Index Terms—Federated Learning, Centralized Federated Learning (CFL), Decentralized Federated Learning (DFL), SemiDecentralized Federated Learning (SDFL), Benchmaking, Networking.
I. I NTRODUCTION The rise of emerging application scenarios, such as augmented and virtual reality, autonomous driving, and Digital Twin, has triggered a substantial surge in the number of Internet of Things (IoT) devices. The International Data Corporation (IDC) estimates that 55.7 billion IoT devices will be connected by 2025, generating almost 80B zettabytes (ZB) of data. This data explosion will contribute to a total global data storage exceeding 175 ZB. Artificial Intelligence (AI), particularly Machine Learning (ML), is well-positioned to the immense volumes of data anticipated in the coming years. However, data from a multitude of IoT devices are often stored in distributed architectures for diverse scenarios such as smart grids, remote health monitoring, or the Internet of Vehicles. Challenges such as limited communication resources, data privacy concerns, and country-specific regulations render the centralized collection of data impractical or inefficient, as traditionally practiced in ML. In 2016, Google emerged Federated Learning (FL) [13] as a solution to this challenge, enabling clients – referred to as participants or nodes of a federation – to collaboratively train models without the need to share raw training data. FL can be categorized into three types of architectures, namely:
Centralized (CFL), Decentralized (DFL), and a combinaison of the two known as Semi-decentralized (SDFL). The choice of using one type of architecture or another is highly dependent on the application requirements and constraints. However, there are other aspects to take into consideration as well, such as how a given FL architecture impacts on the application performance. A recent survey [5] has emphasized the intricate nature of DFL and the multitude of Key Performance Indicators (KPIs) – over 40 – to be taken into account when evaluating (D)FL platforms. While research studies have focused on the architectural design of CFL, DFL and SDFL, very little research, if any, has focused on experimentally comparing these architectures. Understanding how CFL, DFL, and SDFL perform across various KPIs is crucial, as it can reveal potential trade-offs or synergies among them. This paper presents the initial experimental analyses in this context. Section II provides the necessary background about CFL, DFL and SDFL. Section III gives insight into the methodology underlying our experimental analyses. Section IV presents the results of our experiments conducted with the Fedstellar simulator, MNIST dataset, and MLP classifier MNIST data. The conclusion is provided in section V. II. R ELATED WORKS Section II-A provides a comprehensive overview of various FL architectures, including CFL, DFL, and SDFL. In Section II-B, the discussion delves into the expanding body of literature regarding DFL and SDFL, along with investigations that compare these architectures with CFL. A. Federated Learning (FL) architecture types FL is a ML setting to synthesize global models from local models trained on the edge. FL was first developed by Google in 2016 [13] for their Gboard application, to learn new words and phrases. FL is a decentralized training approach where an iterative process computes model training updates at the edge, aggregating these updates to produce the global update to be applied to the model. This core concept of aggregating model updates was key in allowing for a single global model to be produced from edge training. To build this global model, an aggregation mechanism is implemented to merge in a consistent manner the set of local models produced at some iteration. The most well-known aggregation algorithm, popular
(a) Centralized FL
(b) Decentralized FL
(c) Semi-Decentralized FL
Fig. 1. Federated Learning Architectures
for its simplicity and efficiency, is called federated averaging (FedAvg). FedAvg computes the parameter-wise arithmetic mean across the local models. Currently, most of the FL applications rely on a CFL architecture, as illustrated in Fig. 1(a). CFL has gained a significant attention from academia and industry [16]. Lim et al. [17] mentioned that researchers mainly focused on CFL applications in mobile networks across various end-user scenarios : the application of FL in broader contexts involving heterogeneous IoT devices ( [18]), security and privacy concerns ( [19]), proposition of secure protocols between servers and participants ( [20]). Furthermore, other studies, such as [22], explored the applicability of CFL in specific medical scenarios, emphasizing privacy-preserving mechanisms for sensitive data. Witt et al. [23] detailed commonly used frameworks in CFL applications. CFL offers certain conveniences, but also comes with its own set of disadvantages. Li et al. [1] highlight the main challenges faced by CFL caused mainly by the server as third trust party and single point of failure. These challenges include the increase of data transmissions, especially when dealing with multiple participating nodes. Li et al. [1] also point out the problem of reliance on a central server that can introduce communication bottlenecks and increased network traffic when faced with a large number of participants, leading to higher latency and reduced efficiency [2]. As another problem of CFL, the security of the application can be impacted if the central server is maliciously compromised [3]. To overcome the above-mentioned limitations, DFL was introduced in 2018 by Lalitha et al. [4]. DFL is based on the decentralized aggregation of model parameters among neighboring participants, eliminating the necessity for a central server, as depicted in Fig. 1(b). It ensures collaborative learning by leveraging local computation and exchanging model parameters between nodes. Its operation revolves around swiftly transmitting updates computed locally by each node to the broader network. These local transmissions enable adjacent nodes to enhance their models, culminating in the creation of a more intelligent and privacy-preserving collaborative model. In contrast to the previous approaches of FL, the SDFL architecture [30] is a hybrid of both architectures CFL and DFL, as illustrated in Fig. 1(c). It maintain the aggregator
role which rotates randomly among participants at each round of the learning process. B. CFL vs. DFL: current state of affairs In contrast to CFL, DFL and SDFL were first employed to prevent communication bottleneck situations, which can quickly occur in CFL and result in performance issues [29]. As of today, most research on DFL and SDFL focuses on analyzing the usage of Distributed Ledger Technology (DLT) such as Blockchain [24], [28]. Also, authors have explored the applicability of DFL in specific domains such as the Internet of Vehicles (IoV) [25], wireless communications [26], and Unmanned Aerial Vehicle (UAV) devices [27]. These studies investigate the performance of DFL in targeted application scenarios, but rarely, not to say never, experimentally compare the pros and cons of DFL over CFL, and vice-versa (e.g., identification of trade-offs between different performance indicators, aka KPIs). Although decentralized methods showing promise in achieving comparable convergence to centralized methods with reduced communication, their test performance remains inefficient in empirical studies. III. P ERFORMANCE COMPARISON METHODOLOGY To evaluate to what extent the different FL architectures (CFL, DFL, SDFL) perform well under specific application scenarios, and analyze/identify possible trade-offs in performance, the methodology depicted in Fig. 2 is defined. The first stage consists in simulating the FL process. The second stage involves implementing relevant KPIs for CFL, DFL and SDFL performance evaluation. The third stage consists in identifying the trade-offs that may possibly appear between the implemented KPIs. The three stages are elaborated on in sections III-A to III-C. As of today, to the best of our knowledge, only the FedStellar platform [11] supports the simulation of all three FL architectures, enabling the testing of highly scalable network configurations. Additionally, it facilitates the monitoring of multiple KPIs throughout various stages of the FL process. This leads us to choose FedStellar as the foundational simulation layer for our comparative analysis methodology.
Fig. 2. Methodology underlying the method of evaluating and identifing the trade-offs between different KPIs.
A. Stage 1: FL process simulation Due to the intricate nature of implementing the three types of FL architectures, scholars have initiated the development of simulators for evaluation purposes. Several FL simulator platforms have been introduced in recent years, as outlined in TABLE I. This table highlights the characteristics of each platform, including: (i) FL architectures: the supported types of architecture (CFL and/or DFL and/or SDFL); (ii) Scalability: the platform’s ability to accommodate large FL networks (classified on a 3-scale basis: low, medium, high); (iii) Metrics: which can be employed within the solution to assess the FL process; (iv) Open source: indicating whether the simulator is open source or proprietary. B. Stage 2: KPIs for CFL, DFL, and SDFL performance evaluation The recent survey of Beltran et al. [5] has proposed a taxonomy of KPIs, along with categories, to cover the different aspects of FL, as shown in Fig. 3. KPIs are categorized in three categories: • Node: it evaluates the performance of participating nodes within the FL network. The heterogeneity and dynamism of the participating nodes introduces complexity to the network, making it crucial to identify relevant factors for evaluation. The Node category is declined into: (i)
Resource capabilities: evaluate the computational power and the network capacity; (ii) Node mobility: evaluate the high dynamism of the network. • Communications: it evaluates the extent to which the communication layer is efficient and effective. Indeed, the exchange of model parameters between nodes can lead to instability that may compromise the reliability of the system/application. The Communications category is declined into: (i) Communication flexibility: evaluate the FL network capacity to adapt to dynamic network conditions and maintain stable communication channels; (ii) Network overhead: quantify the additional resources consumed by communication processes beyond the essential data exchange. Evaluating this overhead helps in measuring the efficiency and scalability of the FL network. • Model: it evaluates the efficiency and effectiveness of the FL model to accomplish its learning task. It divides into (i) Performance: evaluate the efficiency of the FL model; (ii) Trustworthiness: evaluate trustworthiness aspects of AI systems, including transparency, robustness, fairness, and so forth [31]. In total, over 40 KPIs have been delineated in [5] across the aforementioned three categories, recognizing that some KPIs may encompass several others (e.g., explainability could be assessed through faithfulness, stability, transferability, or
TABLE I C OMPARISON OF SOME FL FRAMEWORKS . Solution TFF FATE BrainTorrent ScatterBrained PySyft IPLS 2DF-IDS P2PFL FedStellar
FL architecture CFL CFL SDFL DFL CFL, DFL DFL DFL DFL CFL, DFL, SDFL
Scalability Medium Medium Low Medium Medium Medium Medium High
Evaluation Metrics Model performance, Convergence Time Model performance Model performance, CPU usage Model performance Model performance Model performance (Accuracy) Model performance Model performance (Accuracy, Loss) Model performance, Resources usage, Communication
Open source Yes Yes No Yes Yes Yes No Yes Yes
Fig. 3. KPIs introduced by Beltran et al. [5] to evaluate (D)FL architectures/implementations.
compactness of the explanation). It is important to note that the three categories identified by [5] may be perceived as different in nature: Node and Communications KPIs may be viewed as constrained by the underlying or implemented network infrastructure, while Model KPIs may be seen as the ultimate objective of the application (ensuring adherence to the FL model requirements). While our study’s long-term objective is to encompass all categories and their associated KPIs, we are currently constrained – due to the simulator – in the number of KPIs we can measure or assess at this stage. Presently, FedStellar only permits the experimental measurement of (1) accuracy, (2) precision, (3) recall, (4) F-score, (5) loss, (6) CPU usage percentage, and (7) bytes exchanged between participants. C. Stage 3: Identification des trade-offs between the KPIs The last stage consists in anlayzing possible trade-offs between KPIs, and highlight the key distinctions among the different FL architectures under specific application and network conditions.
IV. E XPERIMENTS AND RESULTS A set of experiments were conducted to evaluate the performance of the three types of FL architectures in a given use case scenario. Section IV-A outlines the experimental setup. Section IV-B) delves into the results of the measured KPIs, with a focus on model performance, communication cost, and scalability. A. Experimental setup Fedstellar simulator was used to implement a given use case scenario. In this regard, the MNIST dataset is used, which contains 60.000 images of handwritten digits categorized into 10 classes (0 to 9). In our experiments, the MNIST dataset is partitioned into subsets corresponding to the number of participants (|N |), with each participant (ni ) being allocated a subset comprising approximately di = 60000/|N | samples, ensuring uniform distribution of labels. Multilayer Perceptron (MLP) [12] is used as classification model in our experiments. Throughout the experiments, we maintained a fixed number of rounds (10 rounds) and epochs (3 epochs). The network
(a) Accuracy
(d) Recall
(b) Loss
(c) Precision
(e) Bytes exchanged in the FL network
(f) CPU usage percentage
Fig. 4. Performance Evaluation Metrics with |N | = 3 : (a) Accuracy (b) Loss (c) Precision (d) Recall (e) Bytes exchanged in the FL network (f) CPU usage percentage. The DFL is the most efficient one with an accuracy of 97,84%, a loss of 0.072925 using the less resources usage. The SDFL can reach a very close performance to the DFL one with an accuracy of 96.31% and a loss of 0.133429, but it requires more time (see TABLE II). CFL converges to the performance faster than the others and it is more stable but it is less efficient with an accuracy of 94.45% and a loss of 0.161705, and it is the greediest one in terms of resources usage.
topology of participants in FL is configured as fully connected to ease communication and collaboration between participants. To investigate the influence of scalability on the FL process, we alter the number of participants in each experiment. Beginning with 3 participants due to constraints in computer capacity, we gradually increase to 4, then to 6, and finally to 8 participants. B. Results and analysis In the following, results obtained for the three FL architectures (CFL, DFL, SDFL) with respectively 3, 4, 6, and 8 participants in the FL aggregation process are commented. Let us also mention that all the results represent the average of all the participants’ results collected from the experiments. Fig. 4 gives insight into the measured KPIs when using a network of 3 participants in the FL process. It can be observed that the DFL architecture exhibits the highest performance, achieving an accuracy of 97.84% Fig. 4(a), a precision of 97.82% Fig. 4(c), a recall of 97.85% Fig. 4(d) with the lowest loss value of 0.0729 Fig. 4(b) (TABLE II shows the test results of some evaluation metrics for the implemented scenarios). Meanwhile, the semi decentralized federated learning (SDFL) architecture closely approaches the performance of DFL with an accuracy of 96.31% Fig. 4(a), a precision of 96.28%, a
TABLE II ACCURACY (%) AND C ONVERGENCE TIME RESULTS . W ITH THE INCREASE OF THE PARTICIPANTS ’ NUMBER , THE MODEL’ S PERFORMANCE IS DECLINING AND THE CONVERGENCE TIME IS INCREASING FOR BOTH CFL AND SDFL DUE TO THE LARGER NETWORK SIZE . I N CONTRAST, DFL DEMONSTRATES A DECREASE IN CONVERGENCE TIME BECAUSE OF THE SMALLER SIZE OF LOCAL DATA . T HIS HIGHLIGHTS DFL AS A PROMISING SOLUTION FOR SCALABILITY CHALLENGES .
CFL
DFL
SDFL
Number of Participants 3 4 6 8 3 4 6 8 3 4 6 8
Model (Accuracy %) 94.45% 91.47% 90.78% 89.83% 97.84% 97.61% 97.5% 97.16% 96.31% 97.43% 97.22% 97.06%
Time (min) ≈ 18 ≈ 19 ≈ 20 ≈ 22 ≈ 43 ≈ 41 ≈ 36 ≈ 31 ≈ 31 ≈ 34 ≈ 35 ≈ 40
recall of 96.31% and a loss value of 0.1334, requiring less time (about 6 min according to TABLE II). Additionally, the CFL architecture demonstrates faster convergence to performance
(a) Accuracy
(b) Loss
(c) Bytes exchanged
(d) CPU usage percentage
Fig. 5. Performance Evaluation Metrics with |N | = 4 : (a) Accuracy (b) Loss (c) Bytes exchanged in the federation network (d) CPU usage percentage. The DFL and the SDFL are the most performant architectures with an accuracy of 97.61% and 97.43% respectively. However, the SDFL is faster in term of convergence in comparison with the DFL with a loss of 0.08832. The SDFL is being close to the DFL in term of resource usage but the DFL still the less expensive architecture in term of communication. The CFL stays to the faster one in comparision with others and it is more stable but it is less performant than DFL and SDFL with an accuracy of 91.47% and a loss of 0.154246.
(a) Accuracy
(b) Loss
(c) Bytes exchanged
(d) CPU usage percentage
Fig. 6. Performance Evaluation Metrics with |N | = 6 : (a) Accuracy (b) Loss (c) Bytes exchanged in the federation network (d) CPU usage percentage. The DFL and the SDFL are the most efficient architectures with an accuracy of 97.5% and 97.22% respectively. However, the SDFL is faster in term of convergence in comparison with the , which is (the DFL) the less communication costing architecture, with a loss of 0.090313. The SDFL is being close to the DFL in term of resource usage. The CFL stays to the faster one in comparison with others and it is more stable but it is less performant than DFL and SDFL with an accuracy of 90.78% and a loss of 0.266932.
levels compared to the others (about half of the time according to TABLE II) with less efficient performances (accuracy of 94.45% Fig. 4(a)), showcasing greater stability. This outcome aligns with expectations, as CFL is inherently more resourceintensive (according to Fig. 4(e) and Fig. 4(f)) due to its reliance on a central server entity for model aggregation, while DFL stands out as more lightweight, eliminating the need for an additional aggregation entity (Fig. 4(e)). As evidenced in Fig. 5, 6, and 7, when scaling the number of participants respectively to 4, 6 and 8 in the learning process, both DFL and SDFL architectures exhibit superior performance, boasting precision exceeding 97% according to Fig. 5(a), Fig. 6(a), Fig. 7(a) and TABLE II (with a marginal difference of approximately 0.2% between them) with the minimum loss values as shown in Fig. 5(b), 6(b), and 7(b) when comparing them to CFL. Let us note that, concerning the model’s performance, we included only the accuracy results involving 4, 6, and 8 participants due to the page constraints. One may also observe that SDFL converges faster than DFL when the participant count is 4 and 6 (see Fig. 5(a) and 6(a)). However, when scaled to 8 participants, DFL demonstrates faster convergence compared to SDFL Fig. 7(a) and TABLE II. This observation was somehow expected, given that DFL lacks of a global aggregation process, which typically contributes to its accelerated convergence. Despite this difference in
convergence rates, the communication costs between DFL and SDFL remain closely aligned throughout the scaling process according to Fig. 5(c), 6(c) and 7(c). Furthermore, despite the fact that CFL is characterized as resource-intensive, it maintains its position as the swiftest in achieving performance convergence, showcasing greater stability. In centralized (CFL) setups, a notable trend can be observed: as the number of participants increases, there is often a decline in model performance. This phenomenon arises due to the diminishing number of samples assigned to each participant. With a broader participant pool, the dataset gets divided into smaller subsets, constraining the volume of data accessible for training. Consequently, this decrease in sample size impedes the model’s capacity to generalize effectively, leading to diminished performance. In contrast to DFL and SDFL architectures, the number of clients participating in the federation does not significantly impact the performance of the model. This resilience stems from the distributed nature of these architectures, where each participant retains a local dataset and computes model updates independently. Thus, the model’s performance remains stable regardless of the number of participants. Nevertheless, it is important to highlight that although DFL and SDFL demonstrate consistent performance across different participant counts, they usually demand more time to converge (cf., TABLE II). This
(a) Accuracy
(b) Loss
(c) Bytes exchanged
(d) CPU usage percentage
Fig. 7. Performance Evaluation Metrics with |N | = 8 : (a) Accuracy (b) Loss (c) Bytes exchanged in the federation network (d) CPU usage percentage. The DFL and the SDFL still the most performant architectures with an accuracy more than 97% . However, the SDFL is faster in term of convergence in comparison with the DFL one. The SDFL is being really close to the DFL in term of resource usage. The CPU usage is being almost the same for all scenarios: CFL, DFL and SDFL, but still the CFL is more expensive when it comes to the communication cost with less model performance (accuracy of 89.83%).
(a) Accuracy CFL
(b) Accuracy DFL
(c) Accuracy SDFL
Fig. 8. Accuracy average in all scenarios: (a) CFL (b) DFL (c) SDFL. In CFL, increasing the number of participants in the network leads to a decrease in model’s performance. This occurs because each participant has less data samples. In contrast, the performance of the model DFL and SDFL remains practicaly the same. However, the convergence time of the model is prolonged in DFL and SDFL settings.
elongated convergence period is ascribed to the decentralized nature of these architectures, which necessitates coordination and communication among participants to aggregate model updates. Despite the extended convergence time, DFL and SDFL confer the benefit of resilience to fluctuations in participant count, thereby ensuring stable model performance over time. V. C ONCLUSION This paper addresses the lack of experimental studies between the three types of Federated Learning (FL) architectures, Centralized FL (CFL), Decentralized FL (DF) and SemiDecentralized FL (SDFL). Although the choice of the type of architecture is highly dependent on the application needs and constraints, simulating the different architectures to understand their limitations (and benefits) in terms of performance is important. This paper is an attempt to bring into light possible trade-offs between distinct performance indicators (aka KPIs). Our experiments show that DFL emerges as a promising strategy, offering enhanced performance while maintaining data privacy. Conversely, in larger networks, SDFL presents itself as a cost-effective solution, delivering comparable performance with reduced resource requirements. However, when speed is of paramount importance, CFL remains the optimal choice for achieving fast results. In essence, DFL, SDFL and CFL exhibit strengths and weaknesses. The best option depends on factors like the nature of the data, the number of nodes/clients, privacy
considerations, and infrastructure availability requirements or constraints. Looking ahead, our future research aims to cover a wider range of KPIs, and explore further trade-offs among KPIs in diverse FL applications. This will require to extend the code of the FedStellar platform. Furthermore, we plan to develop and release a decision support tool to guide application and network managers in selecting the most appropriate FL architecture (and possibly platform) depending on their application needs, requirements, and constraints. R EFERENCES [1] Li, Tian, et al. ”Federated learning: Challenges, methods, and future directions.” IEEE signal processing magazine 37.3 (2020): 50-60. [2] Zhang, Jiale, et al. ”Poisoning attack in federated learning using generative adversarial nets.” 2019 18th IEEE international conference on trust, security and privacy in computing and communications/13th IEEE international conference on big data science and engineering (TrustCom/BigDataSE). IEEE, 2019. [3] Kairouz, Peter, et al. ”Advances and open problems in federated learning.” Foundations and trends® in machine learning 14.1–2 (2021): 1210. [4] Lalitha, Anusha, et al. ”Fully decentralized federated learning.” Third workshop on bayesian deep learning (NeurIPS). Vol. 2. 2018. [5] Beltrán, Enrique Tomás Martı́nez, et al. ”Decentralized federated learning: Fundamentals, state of the art, frameworks, trends, and challenges.” IEEE Communications Surveys & Tutorials (2023). [6] Yuan, Liangqi, et al. ”Decentralized federated learning: A survey and perspective.” arXiv preprint arXiv:2306.01603 (2023).
[7] Elmrabit, Nebrase, et al. ”Evaluation of machine learning algorithms for anomaly detection.” 2020 international conference on cyber security and protection of digital services (cyber security). IEEE, 2020. [8] Ait Mahammed, Fatima. ”Approches d’apprentissage automatique pour la détection du Spam Web: exploration de diverses caractéristiques.” (2018). [9] Rainio, O., Teuho, J. & Klén, R. Evaluation metrics and statistical tests for machine learning. Sci Rep 14, 6086 (2024) [10] Martinez, M., & Stiefelhagen, R. Taming the cross entropy loss. In Pattern Recognition: 40th German Conference, GCPR 2018, Stuttgart, Germany, October 9-12, 2018, Proceedings 628–637, Vol. 40. Springer (2019). [11] Beltrán, Enrique Tomás Martı́nez, et al. ”Fedstellar: A platform for decentralized federated learning.” Expert Systems with Applications 242 (2024): 122861. [12] Popescu, Marius-Constantin, et al. ”Multilayer perceptron and neural networks.” WSEAS Transactions on Circuits and Systems 8.7 (2009): 579-588. [13] Konecný, Jakub, et al. ”Federated learning: Strategies for improving communication efficiency.” arXiv preprint arXiv:1610.05492 8 (2016). [14] Bonawitz, K., Eichner, H., Grieskamp, W., et al.: Towards federated learning at scale: System design. arXiv preprint arXiv:1902.01046 (2019) [15] Bonawitz, K., Ivanov, V., Kreuter, B., Marcedone, A., McMahan, H.B., Patel, S., Ramage, D., Segal, A., Seth, K.: Practical secure aggregation for privacy-preserving machine learning. In: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. pp. 1175–1191. ACM (2017) [16] T. Li, A. K. Sahu, A. Talwalkar, and V. Smith, “Federated learning: Challenges, methods, and future directions,” IEEE Signal Processing Magazine, vol. 37, no. 3, pp. 50–60, 2020. [17] W. Y. B. Lim et al., “Federated learning in mobile edge networks: A comprehensive survey,” IEEE Communications Surveys & Tutorials, vol. 22, no. 3, pp. 2031–2063, 2020. [18] D. C. Nguyen, M. Ding, P. N. Pathirana, A. Seneviratne, J. Li, and H. V. Poor, “Federated learning for Internet of Things: A comprehensive survey,” IEEE Communications Surveys & Tutorials, vol. 23, no. 3, pp. 1622–1658, 2021. [19] L. U. Khan, W. Saad, Z. Han, E. Hossain, and C. S. Hong, “Federated learning for Internet of Things: Recent advances, taxonomy, and open challenges,” IEEE Communications Surveys & Tutorials, vol. 23, no. 3, pp. 1759–1799, 2021. [20] V. Mothukuri, R. M. Parizi, S. Pouriyeh, Y. Huang, A. Dehghantanha, and G. Srivastava, “A survey on security and privacy of federated learning,” Future Generation Computer Systems, vol. 115, pp. 619– 640, 2021. [21] P. Boobalan et al., “Fusion of federated learning and industrial Internet of Things: A survey,” Computer Networks, vol. 212, p. 109048, 2022. [22] Joshi, Madhura, Ankit Pal, and Malaikannan Sankarasubbu. ”Federated learning for healthcare domain-pipeline, applications and challenges.” ACM Transactions on Computing for Healthcare 3.4 (2022): 1-36. [23] L. Witt, M. Heyer, K. Toyoda, W. Samek, and D. Li, “Decentral and incentivized federated learning frameworks: A systematic literature review,” arXiv preprint arXiv:2205.07855, 2022. [24] Qu, Youyang, et al. ”Decentralized privacy using blockchain-enabled federated learning in fog computing.” IEEE Internet of Things Journal 7.6 (2020): 5171-5183. [25] M. Billah, S. T. Mehedi, A. Anwar, Z. Rahman, and R. Islam, “A systematic literature review on blockchain enabled federated learning framework for Internet of Vehicles,” arXiv preprint arXiv:2203.05192, 2022. [26] R. Gupta and T. Alam, “Survey on federated-learning approaches in distributed environment,” Wireless Personal Communications, Mar 2022. [27] D. Saraswat et al., “Blockchain-based federated learning in UAVs beyond 5G networks: A solution taxonomy and future directions,” IEEE Access, vol. 10, pp. 33 154–33 182, 2022. [28] Qu, Youyang, et al. ”Blockchain-enabled federated learning: A survey.” ACM Computing Surveys 55.4 (2022): 1-35. [29] Yemini, Michal, et al. ”Semi-decentralized federated learning with collaborative relaying.” 2022 IEEE International Symposium on Information Theory (ISIT). IEEE, 2022. [30] Roy, Abhijit Guha, et al. ”Braintorrent: A peer-to-peer environment for decentralized federated learning.” arXiv preprint arXiv:1905.06731 (2019).
[31] Kaur, Davinder, et al. ”Trustworthy artificial intelligence: a review.” ACM computing surveys (CSUR) 55.2 (2022): 1-38.