$$\rightleftharpoonup{xx}$$
$$\longleftharp{xx}$$,
$$\longrightharp{xx}$$,
Overview
An Intelligent Federated Learning Framework (IFLF) was developed to efficiently manage data and system heterogeneity in non-colocated environments. The system architecture consisted of five layers: the Data Layer, Client Layer, Aggregation Layer, Adaptation and Optimization Layer, and the Interpretability Layer. The modules were deployed over a distributed computing setup with a central aggregation server and multiple client nodes. Secure socket connections (SSL/TLS) were used for communication between nodes to ensure privacy and data integrity. The following procedure was used to prepare datasets, set up the architecture, conduct federated training, and assess interpretability.
Computational environment configuration
The computational environment was configured by installing the required software frameworks for implementing the federated learning framework. Python was used as the primary programming language for model development and experimentation. Machine learning libraries including TensorFlow or PyTorch were installed for neural network training, along with additional libraries such as NumPy, Scikit-learn, and Pandas for data preprocessing and analysis. Federated learning libraries such as Flower or PySyft were installed to simulate distributed client environments. The computing environment was configured on a workstation equipped with GPU acceleration, where available. All clients and the aggregation server were configured to communicate through secure socket connections (SSL/TLS). All required datasets were verified to be accessible within each client node's local storage before initiating federated training. The software frameworks, datasets, and computational environment required for reproducing the protocol are summarized in the Table of Materials.
Initialization of federated nodes
The central aggregation server was configured using the Flower federated learning framework. The aggregation server was started using the following command:
python server.py --rounds 100 --clients 10 --secure_connection True
Individual client nodes were launched on separate terminals or computing environments using the following command:
python client.py --client_id 01
Secure socket communication was configured by generating SSL/TLS certificates using the OpenSSL toolkit.
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
Secure communication between the server and clients was enabled by specifying the certificate paths in the configuration file. Connectivity was verified by executing a test communication round before initiating the federated training process.
Dataset preparation and description
Representative public datasets were selected to evaluate performance across different domains and data modalities. FEMNIST is an advanced MNIST database for handwritten character recognition, containing 62 classes (A–Z, a–z, digits 0–9), where each client represents one writer’s data, inducing natural non-IID distributions. FLamby is a medical imaging benchmark composed of different cross-silo medical datasets (e.g., heart MRI, histopathology images), where each hospital or institution acts as a federated client. FedGraphNN is a benchmark for graph neural networks covering tasks such as citation networks, molecule classification, and social graphs, where clients contain different subgraphs or node features. CICIDS2017 is a cybersecurity dataset for intrusion detection with more than 80 features of network traffic flows across attack types such as DDoS, PortScan, and Botnet, where each client represents a separate network domain or sensor.
Dataset statistics
The key characteristics of the datasets used in the experiments were summarized to ensure reproducibility of the federated learning setup. FEMNIST contains approximately 805,263 handwritten character samples distributed across 3,550 writers, with 62 classes representing uppercase letters, lowercase letters, and digits, and each client corresponds to a single writer with approximately 200–300 samples on average. FLamby provides cross-silo healthcare datasets, and in this study, the medical imaging dataset contains approximately 20,000 samples collected from multiple hospitals, where each hospital acts as an independent federated client. FedGraphNN includes multiple graph learning datasets such as citation networks and molecule graphs, typically containing thousands of nodes and edges with node feature vectors ranging between 50–500 dimensions depending on the task. CICIDS2017 contains approximately 2.8 million network traffic flows with 80 statistical features extracted from network packets and includes multiple attack categories such as DDoS, PortScan, and Botnet traffic, where each federated client represents a different network environment or monitoring sensor. The datasets used in this study were released between 2017 and 2023 and are publicly available for federated learning research. The statistical characteristics of the datasets used in the experiments are summarized in Table 1.
| Dataset | Domain | Samples | Features | Classes | Clients | Release Year |
| FEMNIST | Vision (Handwritten Characters) | 8,05,263 | Image pixels (28×28) | 62 | 3,550 | 2017 |
| FLamby | Healthcare Imaging | ~20,000 | Image features | Binary / multi-class | 5 | 2023 |
| FedGraphNN | Graph Learning | ~10k–100k nodes | 50–500 node features | Task dependent | 7 | 2021 |
| CICIDS2017 | Cybersecurity | ~2.8 million flows | 80 | Multiple attack classes | 10 | 2017 |
Table 1: Summary of datasets used in the Intelligent Federated Learning Framework experiments. The table summarizes the characteristics of the datasets used in this study, including application domain, total number of samples, number of features, number of classes, number of federated clients, and dataset release year. These statistics provide an overview of the heterogeneous data modalities used to evaluate the framework.
Client-level heterogeneity
Client-level heterogeneity was introduced through dataset partitioning. Although four datasets from different domains were used for evaluation, heterogeneity was introduced within each federated dataset through client-level partitioning. Each dataset was divided among multiple clients, resulting in non-identical local data distributions (non-IID). Different subsets of samples or classes were assigned to individual clients to simulate realistic federated learning conditions, representing statistical heterogeneity within each dataset. Approximately 5–10% of the total dataset was assigned to each client while maintaining class imbalance to emulate real-world non-IID federated environments. The term heterogeneous datasets in this study refers to client-level statistical heterogeneity rather than differences between independent experimental datasets. The benchmark datasets exhibited different forms of statistical heterogeneity, including variations in individual writing styles in FEMNIST, differences in imaging protocols and patient demographics in FLamby datasets, structural variations in FedGraphNN datasets, and diverse network traffic patterns in CICIDS2017, collectively creating realistic non-IID data distributions that challenge federated optimization algorithms.
Dataset-specific preprocessing
Dataset-specific preprocessing operations were carried out to standardize input formats before federated training. For FEMNIST, handwritten character images were converted to grayscale, resized to 28×28 pixels, and normalized to the interval [0, 1], with corrupted or incomplete samples removed and class labels one-hot encoded, and samples organized by writer IDs so that each writer corresponded to a federated client. For FLamby, medical images were resized to 224×224 pixels, normalized using dataset-specific mean and standard deviation, augmented using techniques such as horizontal flipping, rotation, and contrast adjustment, and partitioned according to hospital identifiers. For FedGraphNN, graph structures were constructed by defining node features, adjacency matrices, and edge relationships, node feature vectors were normalized, graph data were converted into sparse adjacency representations, and graphs were partitioned across clients as subgraphs. For CICIDS2017, duplicate records were removed, missing values were imputed with the mean, categorical features were encoded, feature normalization was applied, and benign and attack traffic were balanced using stratified sampling. Each client dataset was divided into 80% training, 10% validation, and 10% testing subsets, ensuring that class distributions were preserved. Client datasets were stored in separate folders (Client_01, Client_02, …), and local node access was restricted for privacy purposes.
Architecture of the Intelligent Federated Learning Framework (IFLF)
The Intelligent Federated Learning Framework was organized into a five-layer architecture consisting of the Data Layer, Client Layer, Aggregation Layer, Adaptation and Optimization Layer, and Interpretability Layer, as illustrated in Figure 1. The architectural layers were designed to pass information sequentially. After preparing and partitioning heterogeneous datasets according to client ownership, the Data Layer transmitted information to the Client Layer, where local models were trained and model updates were generated. These updates were sent to the Aggregation Layer, where reliability and similarity metrics guided the aggregation of weighted client contributions. The Adaptation and Optimization Layer ensured a smooth global training process by varying learning-rate parameters in accordance with gradient variance. Finally, the Interpretability Layer leveraged explainable artificial intelligence methods such as SHAP and LIME to interpret the global model and produce explanations of predictions.

Figure 1. Architecture of the Intelligent Federated Learning Framework. The framework is divided into five layers: Data, Client, Aggregation, Adaptation and Optimization, and Interpretability. Data from non-colocated, heterogeneous clients are locally processed, aggregated based on reliability and similarity, adaptively optimized, and interpreted using SHAP or LIME. Arrows indicate the iterative communication between clients and the central server forming the federated learning loop. Please click here to view a larger version of this figure.
Data layer
Datasets were divided by client ownership and privacy requirements, with dedicated storage locations maintained for each client. Different preprocessing pipelines were applied, and features were normalized to ensure standardized input formats across domains.
Client layer
Distributed clients representing devices, organizations, or institutions were set up, each receiving an identical copy of the global model initialized with the same parameters. Local training was performed using client-specific datasets with optimization methods such as stochastic gradient descent or Adam, while only model parameters or gradients were communicated to preserve data privacy.
Aggregation layer
A central aggregation unit received encrypted model updates from all clients and evaluated their reliability and similarity before aggregation. Reliability scores based on validation performance were used to determine the importance of client updates, and similarity between updates was assessed using methods such as clustering or cosine similarity. Weighted aggregation was performed, and the updated global model was redistributed to clients.
Adaptation and optimization layer
Optimization parameters were dynamically adjusted based on training progress across clients. Learning rates were scheduled to reduce update variance, and additional techniques such as proximal regularization and adaptive weighting were applied to mitigate client drift and improve convergence stability.
Interpretability layer
Explainable artificial intelligence methods such as SHAP and LIME were used to generate feature attribution scores and model explanations. Outputs included feature importance rankings, attribution maps, and visual explanations, which were interpreted in the context of domain-specific knowledge to ensure transparency.
Federated training
The Intelligent Federated Learning Framework was implemented through initialization of the global model at the central aggregation server, followed by definition of training hyperparameters, including learning rate, communication rounds, and local epochs. The global model parameters were distributed to all clients, who then performed local training using their private datasets. Local training loss and validation accuracy were computed, and model updates were generated and encrypted before transmission to the aggregation server. The reliability of client updates was evaluated based on validation performance using Equation 1.
(1)
Where Acci represents the validation accuracy of client i.
Similarity between client updates was computed using cosine similarity of gradient vectors, as defined in Equation 2.
(2)
Where gi and gj represent the gradient vectors of different clients.
Adaptive aggregation weights were computed by combining reliability and similarity scores, as defined in Equation 3.
(3)
The adaptive aggregation weight for each client was determined by combining reliability and similarity scores. The reliability metric reflected the validation accuracy of the local client model, while the similarity metric measured the cosine similarity between client gradient updates.
The aggregation weight wi therefore prioritized clients that both demonstrated reliable validation performance and exhibited consistent update directions with the global optimization objective.
The normalized weights ensured that the total contribution of all participating clients summed to one, thereby maintaining stability in the global model update.
The weights were normalized such that
.
Global model update
Client models were aggregated using a weighted average, as shown in Equation 4.
(4)
Where Mi represents the local parameters of client i.
The updated global model parameters were broadcast to all clients.
Adaptive learning rate modulation
The variance of client gradients across communication rounds was monitored. The learning rate was dynamically adjusted according to Equation 5.
(5)
Where Var(g) represents gradient variance across clients.
The updated learning rate was applied during the next local training cycle. The adaptive learning rate was controlled by the central aggregation server and applied globally across all clients during subsequent training rounds. This global adjustment ensured consistent optimization behavior while accounting for variance in client updates. Because learning rate modulation was performed at the server level, all participating clients received the updated learning rate together with the broadcast global model parameters.
Federated learning performance evaluation
Global model accuracy was evaluated using the aggregated test dataset, as shown in Equation 6.
(6)
Where TP represents the number of true positive predictions, TN represents true negative predictions, FP represents false positive predictions, and FN represents false negative predictions
Fairness across clients was measured by computing the variance of client accuracy.
Communication cost was calculated as the total number of model parameters transmitted between clients and the aggregation server across all communication rounds. The total communication overhead was therefore estimated as shown in Equation 7.
(7)
Where R is the number of communication rounds, C is the number of clients, and S represents model size.
Model interpretability analysis was performed using SHAP to compute global feature importance scores and LIME to generate local explanations for individual predictions. Feature attribution results were visualized to interpret model behavior.
Troubleshooting
Unstable convergence occurred when client datasets were highly heterogeneous or contained extremely imbalanced class distributions. In such cases, local training epochs were reduced or the initial learning rate was decreased to stabilize gradient updates. Highly skewed client distributions led to dominance of a small number of clients during aggregation, which was mitigated by adjusting the reliability weighting threshold or increasing client participation diversity. Unreliable client participation caused by network interruptions disrupted communication rounds; therefore, partial participation was enabled, allowing the aggregation server to proceed with available client updates. Interpretability failure or inconsistent feature attribution arose when models were over-regularized or trained on insufficient data, and data preprocessing steps were verified while ensuring that SHAP or LIME explanations were generated after model convergence.
The iterative sequence of model initialization, local training, intelligent aggregation, adaptive optimization, and interpretability analysis is depicted in Figure 2, which represents the overall workflow of the Intelligent Federated Learning Framework (IFLF).

Figure 2. Workflow of the Intelligent Federated Learning Framework. The figure depicts the iterative cycle of phases, including initialization, local training, aggregation, adaptive optimization, and interpretability, illustrating the end-to-end operation of the framework. Please click here to view a larger version of this figure.
Performance evaluation
Global and local metrics including accuracy, precision, recall, and F1-score were calculated. Fairness was measured through the variance of local client accuracy. Communication efficiency was examined as the size of data transferred per round. Model performance was evaluated against typical federated baselines such as FedAvg, FedProx, and FedOpt. Outcomes were presented using convergence curves, confusion matrices, and interpretability plots. All experimental settings, logs, and checkpoints were stored to ensure reproducibility.
Workflow summary
The IFLF cycle was carried out by continuously repeating local training, smart aggregation, adaptive optimization, and interpretability analysis. Data privacy was maintained by keeping data at local nodes while enabling collaborative model improvement. These steps incorporated mechanisms to address fairness, transparency, and performance across non-colocated clients.