Semi-asynchronous Federated Learning in Flower: Framework Extension and Performance Assessment Víctor Hidalgo-Izquierdoa,∗, Carmen Carriónb,1 , Blanca Caminerob,1
arXiv:2606.24230v1 [cs.DC] 23 Jun 2026
a
Instituto de Investigación en Informática de Albacete, Universidad de Castilla-La Mancha, Investigación 2, Albacete, 02071, Castilla-La Mancha, Spain b Departamento de Sistemas Informáticos, Universidad de Castilla-La Mancha, Edificio Juan Manuel, Campus Universitario, Albacete, 02071, Castilla-La Mancha, Spain
Abstract This paper presents an extension of the Flower federated learning framework to support Semi-Asynchronous Federated Learning (SAFL). The proposed approach adapts the traditional synchronous paradigm to better handle client heterogeneity and straggler effects. By introducing a semi-asynchronous training strategy, the system allows partial synchronization among clients while maintaining training efficiency and scalability. We implement and evaluate the proposed modification within Flower, instantiated as the FedSaSync strategy, demonstrating improved robustness and reduced idle time compared to fully synchronous baselines in heterogeneous environments. The results show that SAFL can balance convergence stability and system efficiency in heterogeneous environments typical of edge and distributed learning scenarios. Keywords: Federated Learning, Semi-Asynchronous, System Heterogeneity, Flower data availability across edge environments, enabling new opportunities for data-driven The metadata of this project is listed in Taanalysis and decision-making [1]. ble 1. Traditional Machine Learning (ML) approaches rely on centralized cloud infras1. Motivation and significance tructure, in which data collected by edge The rapid growth of distributed data- devices is transmitted to remote servers for generating devices has led to large-scale training. However, this paradigm raises significant concerns about communication ∗ overhead, latency, privacy, and security, Corresponding author Email address: [email protected] thereby motivating the development of de(Víctor Hidalgo-Izquierdo) centralized learning approaches [2]. 1 Metadata
All other authors contributed equally to this work
In this context, Federated Learning (FL)
Nr.
Code metadata description
Metadata
C1 C2
Current code version Permanent GitHub link to code/repository used for this code version
C3 C4 C5
Legal Code License Code versioning system used Software code languages, tools, and services used Compilation requirements, operating environments & dependencies
v1.0 https://github.com/ VictorHidalgoUCLM/SAFlwr/tree/ main/baselines/fedsasync Apache-2.0 license Git Python, Flower, PyTorch
C6
C7 C8
If available Link to developer documentation/manual Support email for questions
Requirements: Python environment with Python 3.12.12, Dependencies: flwr[simulation] ≥ 1.24.0, flwrdatasets[vision] ≥ 0.5.0, torch = 2.8.0, torchvision = 0.23.0 https://github.com/flwrlabs/flower [email protected]
Table 1: Code metadata
has emerged as a promising solution to these limitations by shifting the learning process closer to the data sources [3, 4, 5, 6, 7]. FL follows a client-server architecture in which a central server orchestrates the training process, and multiple clients perform local model training on their private datasets. Clients periodically transmit model updates to the server, which aggregates them into a global model and redistributes the updated parameters. By avoiding direct data sharing, FL significantly mitigates privacy and security concerns while reducing communication latency and bandwidth consumption. However, conventional FL typically relies on a synchronous training process, where the global model is updated only after receiving contributions from all participating clients [8]. In heterogeneous Internet of Things (IoT) environments, this rigid syn-
chronization requirement becomes a major limitation, as slower or less capable devices, often referred to as stragglers, can delay the entire training process [9]. Consequently, the overall learning pace is effectively determined by the slowest participant, reducing system efficiency and scalability. Asynchronous Federated Learning (AFL) partially addresses these problems by loosening the strict synchronization requirement, enabling clients to submit updates independently. Nonetheless, this flexibility may reduce efficiency and hinder model convergence, especially in resource-limited settings where outdated client updates can seriously affect convergence. These issues justify adopting SAFL, which strikes a balance between full synchronization and asynchrony. SAFL has recently received increasing attention in the literature and is designed to address robustness and energy 2
efficiency in heterogeneous edge environments [10]. Several open-source frameworks have been proposed to facilitate research and development in FL, including TensorFlow Federated (TFF) [11], Federated AI Technology Enabler (FATE) [12], Flower [13], or PySyft [14]. Among these, Flower stands out for its modular architecture, lightweight design, active community, and ongoing development. Unlike ecosystem-dependent alternatives, Flower decouples the federated infrastructure from the underlying local training logic, allowing seamless integration with any ML framework (e.g., PyTorch, TensorFlow, or JAX). This modular architecture, backed by an active community and continuous development, provides the ideal flexibility for implementing and benchmarking custom, community-driven training and aggregation strategies [15]. Several studies have investigated semiasynchronous synchronization methods, each with different formulations. A typical variant introduces semi-asynchronous training mechanisms that control the degree of client synchronization, as in FedSA [16], ASAFL [17], FedSAP [18], ASFL [19], or SASAFL [20]. A major challenge in current FL research is the lack of a standardized framework for synchronization strategies, which often forces researchers to rely on custom, isolated simulation environments, severely hindering the reproducibility of results. While Flower has established itself as a mature, production-ready framework capable of becoming the industry standard, it currently lacks native support for semiasynchronous mechanisms. To address this limitation, this work implements the core
semi-asynchronous orchestration at the application level within Flower. By doing so, we provide an accessible and standardized environment that enables future SAFL research to be implemented, benchmarked, and reproduced directly on a reliable platform. To the best of our knowledge, this is the first implementation of a semi-asynchronous training method within the Flower framework. The software presented in this work represents a valuable contribution to the Flower ecosystem. Although SAFL has attracted growing interest in recent years, support for this synchronization paradigm is still limited in widely adopted FL frameworks. In summary, the primary contributions of FedSaSync are outlined below: • Native Semi-Asynchronous Aggregation Mechanism: This work introduces a native semi-asynchronous aggregation method for FL, implemented as the FedSaSync strategy. Global model updates are triggered once a predefined number of clients, M , have completed their local training, decoupling aggregation from full client synchronization. • Support for Heterogeneous and Time-Varying Clients: The proposed mechanism enables a faithful realization of semi-asynchronous behavior in environments with heterogeneous and time-varying client execution times, reducing the impact of slow participants on the aggregation process. • Open-Source Implementation for 3
Reproducible Research: This work provides an open and detailed implementation of the proposed SAFL mechanism. Following the architectural design principles of the Flower baselines, the software serves as a reusable and extensible foundation for future research and reproducible experimentation.
2.1. Software Architecture The software architecture follows the design principles of the Flower FL framework. Flower is designed to enable a seamless transition from experimental research in simulation environments to system-level research on edge devices. Its main design goals include scalability, communication, and client agnosticity, privacy preservation, and flexibility to support both experimental studies and real-world deployments. Conceptually, Flower organizes FL as the interaction between global and local computations, providing the infrastructure required to execute FL processes at scale. Our implementation extends the baseline Flower framework while preserving its modular architecture. To enable SAFL, the functions responsible for synchronous coordination in the original implementation have been adapted while maintaining compatibility with the framework design. In the architectural diagrams presented in the following sections, the modified functions are highlighted in bold to distinguish them from the original Flower implementation. The client-side architecture is illustrated in Figure 1, where the Client module serves as the main component defining the behavior of a federated client. Its role is to encapsulate the local training and evaluation logic executed on each client. This module instantiates a ClientApp() object named app obtained from the Flower framework. The application exposes the train and evaluate functions through decorators, which can be overridden within the Client module to implement custom client-side logic. In addition, the Dataset module and the Model module define the data and
• Systematic Evaluation of SemiAsynchronous Training: The proposed extension enables a systematic study of the effects of different semiasynchronous configurations, facilitating analysis of convergence, training efficiency, and client participation dynamics across varying levels of heterogeneity.
2. Software description In this section, we present the software implementation that supports the semiasynchronous FedSaSync strategy within the Flower framework. First, we describe the overall software architecture of Flower through two class diagrams and the project directory structure, providing a high-level overview of the system and highlighting the components that were modified or extended. Subsequently, we detail the specific functionalities added or modified in our implementation, illustrated by the algorithm that formalizes and clarifies the proposed approach. Finally, auxiliary framework extensions developed to ensure determinism, monitoring, and overall utility during experimental evaluation are detailed. 4
model components of the system, respec- posed strategy, namely strategy_name, tively. The former is responsible for gen- semiasync_deg, number_slow, and erating the data loaders required by each dataset_name, are highlighted in blue and client, while the latter defines the neural will be detailed in later sections. Additionnetwork architecture (Net) along with its ally, both the FedSaSync() implementation corresponding training and evaluation pro- and the server module rely on auxiliary cedures. utilities provided in the Utils module, The server-side architecture, illustrated in enabling customized metrics aggregation Figure 2, follows a similar design, in which and system logging. These additions are the Server module is the key component essential for monitoring training dynamthat defines the behavior of the federated ics and collecting experimental data for server. Its role is to coordinate the global subsequent analysis. training process and manage the aggrega- 1 # Initialize FedSaSync strategy tion of client updates. This module instan- 2 strategy = FedSaSync ( fraction_train = fraction_train , tiates a ServerApp() object named app, 3 4 fraction_ evaluate = also obtained from the Flower framework. fraction_evaluate , The application exposes the main function 5 m in _ a va i la b l e_ n od e s =2 , via a decorator that selects and configures 6 strategy_name=strategy_name, the FL strategy used during training. 7 semiasync_deg=semiasync_deg, number_slow=number_slow, To support SAFL, the server module im- 8 9 dataset_name=dataset_name, plements a custom extension built on 10 train_metrics_aggr_fn = top of the Flower framework. This extrain_metrics_aggr_fn , tension overrides the standard FedAvg()11 ) baseline and introduces the necessary Listing 1: main(): Initialization of FedSaSync components to enable semi-asynchronous strategy coordination between clients and the server. Within this extended frame- Finally, Figure 3 presents the overall project work, we instantiate a semi-asynchronous structure. The FedSaSync directory constrategy, FedSaSync(), which leverages tains all source code related to the client send_and_receive_semiasync() as the and server modules described above. The core mechanism governing synchronization pyproject.toml file defines the project and communication. This design provides a configuration and dependencies, which are The general interface for semi-asynchronous ex- detailed in subsequent sections. ecution, allowing different aggregation be- _static directory stores execution results haviors to be implemented on top of the in CSV format, while a dedicated Python script generates plots and saves the resultsame underlying communication logic. The main() function of the server module ing figures in the same directory. Finally, initializes and activates the FedSaSync() the Bash scripts define and automate the strategy instead of the default FedAvg() experimental setup used in this work. strategy (see Listing 1), where the These components and data collection specific parameters added for our pro- mechanisms form the foundation of our im5
,
+!" !"#
!"#
!"# ! "$" % & &% & %'( ) ( ) *
1 2 3
%% 4 5%% / 6 3 . 6 7 # 6 3 . 6
,-. / %0 & 1 %'1 1 *
Figure 1: FedSaSync client class diagram.
7 # %/ * %-* %% (% *)G* *.(*2. % ((( * @ (-*4 .- ((( *4 .- @ (-* %4*- & /%& @ (& ( F 0.D+%% (E % ( & .* /%& - *- %& -& * @ (& 4 .- * @ (& 4 .- *@ ,%-.
7 8 "
#8! % 9 :;54(: 8 "! # 9 <= >! ? 9 = ! % 9 :-@A%B @ <=:
22 34522 ( & 6 1
! ! 8 " ( & %(* & % 2.*% C -2.D. %D E& . %D EE
" $# ! %4*- & /%& @ (& ( & %(* F 0.D+%% (E
!"! ##!$ %& ' () (* * + ,
! !"! 8 " ( & %% (%& -& %(* & %/ *(& . %*- F 0.D+%% (E
! # %-.& % (/* & % - 0*%.'& %* 1
( & .* /%& - *- %& -& * @ (& 4 .- * @ (& 4 .- *@ ,%-.
Figure 2: FedSaSync server class diagram.
6
%/ *(&
Figure 3: FedSaSync project architecture.
plementation. The following sections provide a detailed description of the specific functionalities implemented within this architecture.
of received updates reaches the semiasynchronous synchronization degree M , an aggregation event is triggered without waiting for the remaining clients. This stands in sharp contrast to the traditional FedAvg strategy, which operates in a strictly synchronous manner and requires updates from all selected clients before triggering an aggregation, making it highly susceptible to the straggler problem. The clients that contributed to the aggregation are then released and become eligible for subsequent training tasks, making them available for assignment in subsequent rounds. To maintain round semantics, all rounds operate in a semi-asynchronous manner, except for the final round, which aggregates synchronously by waiting for all remaining client updates before ending the training process.
2.2. Software functionalities
The main extension introduced to the Flower framework is a module that enables semi-asynchronous execution under different FL strategies. As a core instantiation of this mechanism, we propose FedSaSync, which extends the synchronous FedAvg algorithm by supporting semi-asynchronous aggregation. In this setup, model updates are aggregated whenever a predefined number of clients complete their local training. The implementation of the semiasynchronous aggregation system follows the workflow described in Algorithm 1. The server keeps track of the clients currently involved in training and con- It is important to note that M acts as a tinuously collects their updates as they lower bound rather than a strict cardinality become available. Whenever the number constraint. In practice, multiple clients may 7
complete their local training simultaneously, leading to aggregation events involving more than M updates when those updates become available in the same polling iteration. This behavior is intentional and allows the system to naturally exploit concurrent completions without enforcing artificial synchronization barriers. This behavior is implemented as follows. After dispatching the training tasks for the sampled clients and registering the corresponding busy clients into the msg_dict Python dictionary (lines 1–8), the server continuously polls for client replies (lines 13–21). Aggregation is triggered as soon as M updates are available (lines 17–21), interrupting the waiting loop and enabling intermediate aggregation without blocking on slower clients. In the final round of the federated training, the server instead waits until all pending replies have been received before proceeding (line 17). Finally, clients whose updates have been processed are removed from the set of busy nodes (lines 22– 26), making them available for new training tasks within the same global round. To support this behavior, several methods of the FedSaSync strategy interface were extended. In addition, sample_nodes_semiasync() implements deterministic selection of available clients from the set of free nodes, ensuring that only eligible clients participate in training rounds. The remaining modifications are auxiliary to the strategy’s execution. The __init__() method was extended to include the additional parameters required by the semi-asynchronous mechanism, while configure_train() integrates the custom client-selection procedure into the training
pipeline. Finally, start() was adapted to manage semi-asynchronous execution, measure elapsed time between aggregation events, and record runtime logs for later analysis. 2.3. Auxiliary Framework Extensions To support the experimental evaluation of the proposed strategy, several auxiliary extensions were also incorporated into the framework: 1. The data management pipeline was extended to support selecting different datasets and deterministic partitioning across clients. Additionally, model initialization and server-side parameter generation were adapted to ensure reproducible executions. 2. The client implementation was extended with monitoring capabilities. In particular, each client records its local training time, which the server later aggregates to analyze the system’s temporal behavior. Support for emulated slow clients was also incorporated to evaluate the impact of heterogeneous training speeds. 3. The utility layer was enhanced with mechanisms to aggregate trainingrelated metrics and generate execution logs. These logs store information such as training times, aggregation events, and round progression, facilitating the analysis and reproducibility of experimental results. Finally, the configuration file pyproject.toml was extended with additional parameters (see Listing 2) required by the proposed system, including 8
the experiment name, the degree of semiAlgorithm 1 Semi-asynchronous Send and asynchrony, the number of slow clients, Receive and the selected dataset. These parameRequire: Grid G, messages M, time- ters offer a flexible way to configure and out T (optional), message dictionary reproduce various experimental scenarios, msg_dict, synchronization degree M , with values overwritten during execution. last round flag L 1 # Custom config values accessible Ensure: Returned messages R via ‘ context . run_config ‘ 1: msg_ids ← G.push_messages(M) 2 [ tool . flwr . app . config ] name = " FedSaSync " num - server - rounds = 50 2: if msg_dict is None then 5 fraction - train = 1.0 3: msg_dict ← ∅ 6 fraction - evaluate = 1.0 4: end if 7 local - epochs = 1 5: for each (msg_id, msg) in msg_ids × M 8 semiasync - deg = 10 9 number - slow = 0 do 10 dataset - name = " uoft - cs / cifar10 " 6: n ← msg.metadata.dst_node_id Listing 2: pyproject.toml default configuration 7: msg_dict[n] ← msg_id 3 4
8: end for
3. Illustrative examples
9: delete M 10: A ← set(msg_dict.values()) 11: R ← [ ] 12: tend ← time() + (T if T ̸= None else 0) 13: while T = None or time() < tend do 14: Rnew ← G.pull_messages(A) 15: R ← R ∪ Rnew 16: A ← A \ Replies(Rnew ) 17: if (¬L ∧ |R| ≥ M ) ∨ (L ∧ A = ∅)
This section presents an empirical evaluation of the proposed SAFL framework under controlled and homogeneous data conditions. The goal is to provide an initial understanding of the system’s behavior under varying degrees of synchronization and client execution delays, rather than to establish definitive performance guarantees. To this end, we analyze the interplay between aggregation frequency, client heterogeneity in computation time, and overall training efficiency.
then 18: break 19: end if 20: sleep(3) 21: end while
3.1. Experimental setup The experimental evaluation considers an image classification task using two standard benchmark datasets: CIFAR-10 and MNIST. Both datasets contain 10 classes and are distributed across 10 clients using an IID partitioning strategy, ensuring that each client receives data drawn from the
22: for each n in keys(msg_dict) do 23: if msg_dict[n] ∈ / A then 24: delete msg_dict[n] 25: end if 26: end for 27: return R
9
same underlying distribution. This configuration yields homogeneous data across clients and mitigates statistical heterogeneity, enabling clearer analysis of system behavior under controlled conditions. The baseline model is a simple convolutional neural network implemented in PyTorch, following the default architecture provided in the Flower framework. The model is adapted to each dataset in terms of input dimensionality and learning rate configuration. For CIFAR-10, training is performed over 50 communication rounds, while MNIST is trained over 25 rounds. The learning rate is set to 0.01 for CIFAR-10 and 0.05 for MNIST, following standard configurations for these benchmarks. Unless otherwise specified, the system operates with 10 clients in total, all of whom participate in every training round (client fraction of 1.0). Each client is allocated 2 CPU cores and no GPU resources. The default aggregation strategy is FedSaSync, with a semi-asynchronous synchronization degree M = 10 (synchrony), and no artificially induced slow clients. To evaluate the impact of heterogeneity and semi-asynchronous execution, additional experimental configurations are summarized in Table 2. These configurations vary along three main factors: (i) the dataset (CIFAR-10 or MNIST), (ii) the number of artificially slow clients (0, 1, or 2), and (iii) the synchronization degree M , which takes values in {7, 8, 9, 10} under the proposed FedSaSync strategy, along with a fully synchronous baseline using standard FedAvg for comparison. The number of communication rounds and learning rates is kept fixed for each dataset
across all configurations. These experiments are implemented through the scripts run_{dataset}_experiments.sh. 3.2. Evaluation methodology The results are presented in three subfigures per dataset, each corresponding to a different number of simulated slow clients. Within each subfigure, different values of M are compared. Performance is evaluated in terms of test loss as a function of wall-clock training time rather than communication rounds. This choice is motivated by the system’s semi-asynchronous nature, where communication rounds are not uniformly defined across clients and therefore may not provide a strictly comparable unit of progress. Consequently, loss-versus-time curves are used as a more consistent evaluation metric across configurations. 3.3. Results For CIFAR-10 (see Figure 4), several observations can be made. First, to validate the implementation, we tested the semi-asynchronous configuration with M = 10. As expected, it closely resembles FedAvg in behavior, as aggregation occurs only after all clients have finished. This confirms that the semi-asynchronous mechanism correctly matches the synchronous behavior under maximum-threshold constraints. Second, under the aggregation rule, as soon as M or more clients are ready, all available updates are incorporated In our simulation, where client slowness is modeled via deterministic sleep delays, clients with similar profiles complete their training within the same time window. As
10
Dataset name
Table 2: Experiment configurations. Slow clients Semi-asynchronous degree Number of rounds Learning Rate
{CIFAR10, MNIST} {0, 1, 2}
{7, 8, 9, 10, FedAvg}
a result, configurations where M ≤ (N − Nslow ) operate at fast-client speeds because they bypass the stragglers. But higher M values may force the server to wait, making system performance directly dependent on slow clients. Additionally, Table 3.3 reports the effectiveness of each configuration in terms of model convergence speed. This metric is defined as the reduction in loss achieved per unit of time, i.e., ∆loss/second, providing a quantitative measure of training efficiency. These results align with the trends observed in the previous figure. For instance, in a setting with two slow clients, the configuration with M = 8 achieves higher convergence efficiency than configurations with larger M , indicating faster loss reduction over time. This metric is computed as the ratio between the total decrease in loss over a training run and the corresponding total execution time. A similar trend is observed for MNIST (see Figure 5 and Table 3.3). These results demonstrate the viability of the proposed implementation and confirm that the semi-asynchronous mechanism operates as intended. Overall, the framework provides a solid foundation for further investigation of SAFL under large-scale and heterogeneous environments.
CIFAR10=50 MNIST=25
CIFAR10=0.01 MNIST=0.05
4. Software limitations The proposed implementation is built on top of the Flower framework, and therefore inherits certain design choices and constraints specific to this environment. In particular, Flower relies on a Grid abstraction to manage federated clients and coordinate communication between them. As a consequence, the presented semiasynchronous implementation is partially coupled to the framework’s underlying execution model. While the general concept of semi-asynchronous coordination is not framework-dependent, its concrete realization may vary across different FL systems. In addition, the current implementation is subject to limitations inherent in the communication backend’s design. The Grid component is primarily optimized for synchronous execution patterns, in which coordinated broadcast and aggregation operations dominate the communication paradigm. As a result, introducing semi-asynchronous behavior may lead to suboptimal performance under certain conditions, particularly in scenarios involving large numbers of clients or highly variable communication patterns. Furthermore, the proposed approach requires the semi-asynchronous degree to be defined a priori and remain fixed throughout the training process. This constitutes a significant limitation, as it assumes some knowledge of client performance character-
11
Slow clients = 0
2.2
Slow clients = 1
Slow clients = 2
2.0
Loss
1.8 1.6 1.4 1.2 2
50
75
100 125 Time
150
FedSaSync (M = 7)
175
200
0
50
100
150
FedSaSync (M = 8)
Time
200
250
300
350 0
FedSaSync (M = 9)
50
100
150
200 Time
FedSaSync (M = 10)
250
300
350
FedAvg
Figure 4: Test accuracy versus wall-clock time for CIFAR-10 under different semi-asynchronous configurations and numbers of slow clients. Strategy → Slow clients ↓ Slow = 0 Slow = 1 Slow = 2
FedSaSync (M = 7) 0.0055 0.0054 0.0055
FedSaSync (M = 8) FedSaSync (M = 9) 0.0055 0.0055 0.0055
0.0054 0.0054 0.0033
FedSaSync (M = 10)
FedAvg
0.0054 0.003 0.003
0.0052 0.003 0.003
Table 3: ∆loss time (efficiency) per configuration for CIFAR-10.
istics before deployment. In real-world federated environments, particularly in IoT scenarios, client availability, computational capacity, and communication quality may vary dynamically over time, while unexpected communication failures can further alter system behavior. Consequently, a static semi-asynchronous degree may become suboptimal during execution, leading to inefficient synchronization decisions and limiting the framework’s ability to adapt to changing operating conditions.
clude this functionality in the official implementation. This integration enables practitioners and researchers to directly explore, reuse, and extend the proposed semi-asynchronous system within the Flower ecosystem. In particular, the implementation will be accessible via the framework’s public repository, allowing users to experiment with semi-asynchronous execution without requiring additional modifications or custom engineering.
5. Impact
6. Conclusions
This work contributes to the Flower framework codebase by extending its capabilities with an SAFL mechanism. As a result, future versions of Flower are expected to in-
This work proposes FedSaSync, an extension of the Flower framework to implement native SAFL, enabling federated systems to better adapt to heterogeneous and low-
12
Slow clients = 0
1.6
Slow clients = 1
Slow clients = 2
1.4 1.2 Loss
1.0 0.8 0.6 0.4 0.2 0.0
20
40
Time
60
80
FedSaSync (M = 7)
100
20
40
60
80
FedSaSync (M = 8)
100 Time
120
140
160
FedSaSync (M = 9)
20
40
60
80
100 Time
FedSaSync (M = 10)
120
140
160
FedAvg
Figure 5: Test accuracy versus wall-clock time for MNIST under different semi-asynchronous configurations and numbers of slow clients. Strategy → Slow clients ↓ Slow = 0 Slow = 1 Slow = 2
FedSaSync (M = 7) 0.0156 0.0152 0.0158
FedSaSync (M = 8) FedSaSync (M = 9) 0.0157 0.0147 0.0157
0.0156 0.0146 0.0088
FedSaSync (M = 10)
FedAvg
0.0157 0.0088 0.0088
0.0156 0.0088 0.0088
Table 4: ∆loss time (efficiency) per configuration for MNIST.
resource environments, achieving a middleground between fully synchronous FL and asynchronous FL. The software architecture and operational mechanisms are described in detail, providing a comprehensive overview of the proposed mechanism. The proposed strategy has been tested in simulated environments with time-varying clients to model heterogeneous conditions. Experiments were conducted on the CIFAR10 and MNIST datasets, varying the simulated slow clients to analyze heterogeneous environments of different scales. The experimental results show that the FedSaSync strategy behaves similarly to FedAvg when all clients are homogeneous, and outperforms FedAvg as system heterogeneity increases, demonstrating that semiasynchronous coordination can effectively
mitigate the impact of client heterogeneity by reducing idle time and improving resource utilization. Despite the promising results, the proposed approach remains subject to several limitations, including its dependence on the Flower execution model, the constraints imposed by a communication backend optimized for synchronous operation, and the use of a fixed semi-asynchronous degree. These factors may limit scalability and adaptability in highly dynamic federated environments, motivating future research on framework-independent and adaptive semi-asynchronous strategies. Overall, the results indicate that FedSaSync constitutes a promising initial approach to SAFL in heterogeneous environments and lays the foundation for future research on
13
adaptive coordination mechanisms. Acknowledgements This publication is part of the I+D+i project PID2024158682OB-C32, funded by MICIU/AEI/10.13039/501100011033/and FEDER/UE. It has also been supported by 2025-GRIN-38312 grant funded by the University of Castilla-La Mancha for Consolidated Research Groups. The first author is also supported by a predoctoral contract funded by the University of Castilla-La Mancha (UCLM) and cofinanced by the European Union through the European Social Fund Plus (ESF+). Declaration of generative AI and AI-assisted technologies in the manuscript preparation process During the preparation of this work, the author(s) used Grammarly, ChatGPT (OpenAI), and Perplexity AI in order to improve language, clarity, and readability. The use of these tools was limited to language refinement and information support. After using these tools, the authors carefully reviewed, edited, and validated the content as needed, and take full responsibility for the final content of the publication. References [1] Y. Liu, Y. Zhou, K. Yang, X. Wang, "Unsupervised Deep Learning for IoT Time Series", IEEE Internet of Things Journal 10 (16) (2023) 14285–14306. doi:10.1109/JIOT.2023.3243391. 14
[2] F. C. Andriulo, M. Fiore, M. Mongiello, E. Traversa, V. Zizzo, "Edge Computing and Cloud Computing for Internet of Things: A Review", Informatics 11 (4) (2024). doi:10.3390/informatics11040071. [3] M. Alsharif, R. Kannadasan, W. Wei, K. Nisar, A.-H. Abdel-Aty, "A contemporary survey of recent advances in federated learning: Taxonomies", applications, and challenges, Internet of Things (Netherlands) 27 (2024). doi: 10.1016/j.iot.2024.101251. [4] H. N. C. Neto, J. Hribar, I. Dusparic, D. M. F. Mattos, N. C. Fernandes, "A Survey on Securing Federated Learning: Analysis of Applications", Attacks, Challenges, and Trends, IEEE Access 11 (2023) 41928–41953. doi: 10.1109/ACCESS.2023.3269980. [5] O. R. A. Almanifi, C.-O. Chow, M.L. Tham, J. H. Chuah, J. Kanesan, "Communication and computation efficiency in Federated Learning: A survey", Internet of Things 22 (2023) 100742. doi:10.1016/j.iot.2023. 100742. [6] K. Houidi, M. Said, A. Hakiri, N. Mellouli-Nauwynck, H. K. Ben Ayed, "Federated Learning Models for Real-Time IoT: A Survey", in: 2024 IEEE 27th International Symposium on Real-Time Distributed Computing (ISORC), 2024, pp. 1–6. doi:10.1109/ISORC61049.2024. 10551367. [7] P. Boobalan, S. P. Ramu, Q.-V. Pham, K. Dev, S. Pandya, P. K. R. Mad-
dikunta, T. R. Gadekallu, T. HuynhThe, "Fusion of Federated Learning and Industrial Internet of Things: A survey", Computer Networks 212 (2022) 109048. doi:10.1016/j. comnet.2022.109048.
with data protection, Journal of Machine Learning Research 22 (226) (2021) 1–6. URL http://jmlr.org/papers/v22/ 20-815.html
[13] D. J. Beutel, T. Topal, A. Mathur, X. Qiu, J. Fernandez-Marques, Y. Gao, L. Sani, K. H. Li, T. Parcollet, P. P. B. de Gusmão, N. D. Lane, Flower: A friendly federated learning research framework (2022). arXiv: 2007.14390. [9] X. He, H. Huang, C. Wang, F. Hu, URL https://arxiv.org/abs/2007. T. Cai, Z. Zheng, "A Fairness14390 Guaranteed Framework for SemiAsynchronous Federated Learning", [14] A. Ziller, A. Trask, A. Lopardo, IEEE Transactions on Network Science B. Szymkow, B. Wagner, E. Bluemke, and Engineering 12 (2025) 4462–4479. J.-M. Nounahon, J. Passeratdoi:10.1109/TNSE.2025.3572223. Palmbach, K. Prakash, N. Rose, [8] H. G. Abreha, M. Hayajneh, M. A. Serhani, "Federated Learning in Edge Computing: A Systematic Survey", Sensors 22 (2) (2022) 450. doi:10. 3390/s22020450.
[10] C. Xu, Y. Qu, Y. Xiang, L. Gao, "Asynchronous federated learning on heterogeneous devices: A survey", Computer Science Review 50 (2023) 100595. doi:10.1016/j.cosrev. 2023.100595.
T. Ryffel, Z. N. Reza, G. Kaissis, PySyft: A Library for Easy Federated Learning, Springer International Publishing, Cham, 2021, pp. 111–139. doi:10.1007/978-3-030-70604-3_5. URL https://doi.org/10.1007/ 978-3-030-70604-3_5
[11] K. Bonawitz, H. Eichner, W. Grieskamp, D. Huba, A. Ingerman, [15] Flower AI, Flower baselines documentation, https://flower.ai/docs/ V. Ivanov, C. Kiddon, J. Konečný, baselines/index.html, accessed: S. Mazzocchi, H. B. McMahan, T. V. 2026-05-29. Overveldt, D. Petrou, D. Ramage, J. Roselander, Towards federated learning at scale: System design [16] Q. Ma, Y. Xu, H. Xu, Z. Jiang, L. Huang, H. Huang, "FedSA: A (2019). arXiv:1902.01046. Semi-Asynchronous Federated LearnURL https://arxiv.org/abs/1902. ing Mechanism in Heterogeneous 01046 Edge Computing", IEEE Journal [12] Y. Liu, T. Fan, T. Chen, Q. Xu, on Selected Areas in CommuniQ. Yang, Fate: An industrial grade cations 39 (12) (2021) 3654–3672. doi:10.1109/JSAC.2021.3118435. platform for collaborative learning 15
[17] Z. Chen, W. Yi, H. Shin, A. Nallanathan, "Adaptive SemiAsynchronous Federated Learning Over Wireless Networks", IEEE TRANSACTIONS ON COMMUNICATIONS 73 (2025) 394–409. doi:10.1109/TCOMM.2024.3425635. [18] P. Zhao, Z. Liao, Y. Zhao, J. Xu, A. Yi, "A semi-asynchronous federated learning method integrating personalization and staleness awareness for traffic flow prediction in dynamic Internet of Vehicles", Journal of Supercomputing 81 (Jun. 2025). doi: 10.1007/s11227-025-07523-0. [19] J. Yu, R. Zhou, C. Chen, B. Li, F. Dong, "ASFL: Adaptive Semiasynchronous Federated Learning for Balancing Model Accuracy and Total Latency in Mobile Edge Networks", in: Proceedings Of The 52ND International Conference On Parallel Processing, ICPP 2023, 2023, pp. 443–451. doi:10.1145/3605573.3605582. [20] M. Yu, J. Choi, J. Lee, S. Oh, "Staleness aware semi-asynchronous federated learning", Journal of Parallel and Distributed Computing 193 (2024) 104950. doi:https://doi.org/10. 1016/j.jpdc.2024.104950.
16