PaperlayerView exact revision on arXiv

Source-linked AI summary

Clustered Federated Learning Architecture for Network Anomaly Detection in Large Scale Heterogeneous IoT Networks

Xabier Sáez-de-Cámara, Jose Luis Flores, Cristóbal Arellano, Aitor Urbieta, Urko Zurutuza

arXiv:2303.15986v2cs.CR

TL;DR

IoT intrusion detection faces evolving threats as well as overhead and data-isolation challenges in centralized and edge-based training. The paper combines FL with integrated unsupervised device clustering and reports low false-positive rates and high detection for most evaluated attacks, though some DoS attacks were missed in some clusters.

  • Problem

    Evolving IoT attacks challenge detection, while centralized training can impose overhead and privacy concerns and edge approaches can leave data isolated.

    Source: §I · pp. 2–3

  • Method

    The architecture trains autoencoder-based anomaly detectors with FL and clusters devices unsupervised using parameters from partially trained models.

    Source: §I · p. 3, §VII · p. 21

  • Results

    The global models showed low false positive rates and high detection for most real attacks, but some DoS-based attacks were missed for some device clusters.

    Source: §VII · p. 21

  • Takeaways & Limitations

    The integrated clustering avoids external fingerprinting tools and manual grouping, which the authors say may ease implementation in deployment settings.

    Source: §VII · p. 21

    Training assumes devices are operating normally and are not compromised, an assumption that may not hold in some adversarial settings.

    Source: §VII · p. 22

Abstract

from arXiv · show

There is a growing trend of cyberattacks against Internet of Things (IoT) devices; moreover, the sophistication and motivation of those attacks is increasing. The vast scale of IoT, diverse hardware and software, and being typically placed in uncontrolled environments make traditional IT security mechanisms such as signature-based intrusion detection and prevention systems challenging to integrate. They also struggle to cope with the rapidly evolving IoT threat landscape due to long delays between the analysis and publication of the detection rules. Machine learning methods have shown faster response to emerging threats; however, model training architectures like cloud or edge computing face multiple drawbacks in IoT settings, including network overhead and data isolation arising from the large scale and heterogeneity that characterizes these networks. This work presents an architecture for training unsupervised models for network intrusion detection in large, distributed IoT and Industrial IoT (IIoT) deployments. We leverage Federated Learning (FL) to collaboratively train between peers and reduce isolation and network overhead problems. We build upon it to include an unsupervised device clustering algorithm fully integrated into the FL pipeline to address the heterogeneity issues that arise in FL settings. The architecture is implemented and evaluated using a testbed that includes various emulated IoT/IIoT devices and attackers interacting in a complex network topology comprising 100 emulated devices, 30 switches and 10 routers. The anomaly detection models are evaluated on real attacks performed by the testbed's threat actors, including the entire Mirai malware lifecycle, an additional botnet based on the Merlin command and control server and other red-teaming tools performing scanning activities and multiple attacks targeting the emulated devices.

I. INTRODUCTION

IoT scale, heterogeneity, and evolving attacks challenge signature-based detection and centralized or edge-based ML training. The paper proposes unsupervised clustered federated learning and situates it among IoT intrusion-detection and clustered-FL research.

I. INTRODUCTION

  • Centralized cloud training can incur bandwidth, congestion, latency, and privacy costs, while edge training can leave data isolated; heterogeneous, non-IID clients can also hinder FL convergence.Signature-based systems struggle with obfuscation, changing botnet infrastructure, and delays in publishing detection rules.Source: §I · p. 3
  • The proposed architecture trains anomaly-based IDS models collaboratively through FL without sending devices’ local data, addressing network overhead and data isolation concerns.The detection models are autoencoders trained on benign traffic; attack traces are reserved for evaluation, so labeled attack data is unnecessary for training.Source: §I · p. 3
  • A fully unsupervised clustering step groups clients by similarities in partially trained model parameters, then starts an independent FL process for each device cluster.The clustering method is integrated into the FL pipeline and does not require external fingerprinting tools or manual clustering.Source: §I · p. 3
  • The authors evaluate the architecture in a heterogeneous emulated network with 78 IoT/IIoT devices, 12 cloud services and applications, and 10 attacker machines.The scenario uses diverse protocols and network behaviors.Source: §I · p. 3
  • The paper reports experimental results for its trained FL models and comparisons with a state-of-the-art approach.The introduction does not provide the comparison outcomes.Source: §I · p. 3

A. Federated Learning for IoT Intrusion and Anomaly Detection

  • Related IoT FL work spans unsupervised detection, supervised classification, multi-view models, hierarchical FL, and industrial-protocol IDS, with differing datasets and system designs.The cited approaches include D¨Iot, Rey et al., Popoola et al., Rahman et al., Attota et al., Quin et al., and Zhao et al..Source: A. Federated Learning for IoT… · p. 4
  • Prior IoT intrusion-detection work often uses supervised training, while unsupervised FL, integrated handling of device heterogeneity, and realistic large distributed evaluations remain less represented.Existing approaches may depend on manual segmentation, hardcoded properties, attack-type knowledge, or external tools; many evaluations use artificially partitioned datasets and 10 or fewer clients.Source: A. Federated Learning for IoT… · p. 4

B. Clustered Federated Learning

Clustered FL addresses convergence challenges in heterogeneous client populations by training separate global models for groups of clients. The paper distinguishes its unsupervised, integrated approach from prior methods with different clustering requirements and costs.

B. Clustered Federated Learning

  • Client or data clustering is one strategy for addressing single-global-model convergence problems in heterogeneous FL, particularly where IoT clients have inherent group structure.Other work also explores soft clustering, which allows clients to combine data from multiple distributions.Source: B. Clustered Federated Learning · p. 5
  • Prior clustered-FL methods use gradient or update similarity, iterative cluster assignment, or pretraining, and some require clients to receive multiple models or know the cluster count beforehand.Examples include Clustered FL, methods by Ghosh et al. [42] and Briggs et al., IFCA, and FedGroup,.Source: B. Clustered Federated Learning · p. 5
  • Other approaches use two FL processes or require a priori cluster counts, full repeated training, labels, or client data statistics, adding workload or complicating unsupervised use.These constraints are described for community-based FL, multi-center aggregation [47], and methods in –.Source: B. Clustered Federated Learning · p. 5
  • The proposed approach reduces centralized clustering costs through parameter dimensionality reduction and integrates unsupervised clustering into an anomaly-detection FL pipeline for IoT security.The authors contrast it with prior clustered-FL methods that focus on supervised settings and were not applied to IoT security.Source: B. Clustered Federated Learning · p. 5

III. PROPOSED SYSTEM MODEL

The system places local data capture, training, and inference on IoT clients, with an aggregation server coordinating clustering and federated training. Its clustered process trains separate global models for identified client groups.

III. PROPOSED SYSTEM MODEL

  • The system model combines a client-and-server architecture with integrated model fingerprinting for device clustering and autoencoder-based anomaly detection.The section introduces the deployment setting and the clustered FL process.Source: §III · p. 6

A. Deployment Setting and Architecture

1) Clients:

  • Each device acts as an FL client, capturing data, training locally, and performing inference; training data stays local while model parameters and minimal process metadata are transmitted.Low-powered sensors and actuators may use a hub or gateway for deployment.Source: 1) Clients · p. 6

2) Aggregation server:

  • The aggregation server initializes and distributes models and hyperparameters, collects client updates, performs fingerprinting and clustering, and returns cluster-specific aggregated models.The system architecture depicts the server mediating FL training.Source: 2) Aggregation server · p. 6

3) Attackers:

  • The considered threats include external actors scanning and compromising vulnerable devices and local adversaries using compromised devices to attack inside or outside the network..Source: 3) Attackers · p. 6

B. Clustered Federated Learning Process for Heterogeneous Devices

  • The FL setting assumes most devices can participate and that devices are uncompromised and non-adversarial before training; model-poisoning attacks are out of scope.Expected participation allows the server to maintain persistent state for each client during clustering.Source: B. Clustered Federated Learning… · p. 6
  • For clustering, clients first partially train the initialized model on local data and send it to the server, which assigns clients to groups using similarities between trained parameters.The server’s initial model and local-training hyperparameters are distributed to participating clients.Source: B. Clustered Federated Learning… · pp. 6–7
  • Each identified cluster runs an independent FL process until its global model converges; server-side optimization generalizes aggregation beyond FedAvg.FedAvg is the special case with SGD as SERVEROPT and server learning rate ηs = 1.0.Source: B. Clustered Federated Learning… · p. 7

C. Model Fingerprinting for Device Clustering

The device-clustering method uses partially trained model parameters as fingerprints, avoiding external fingerprinting or manual grouping. Dimensionality reduction and internal validation support clustering and selection of the number of groups.

C. Model Fingerprinting for Device Clustering

  • Grouping devices with similar behavior into separate global-model groups is intended to address non-IID data and hardware limits on training a single complex model.Each device receives an unsupervised group label for use during FL.Source: C. Model Fingerprinting for Device… · p. 7
  • Using local model updates avoids external fingerprinting tools and manual methods, requires no preliminary device-identification wait, and integrates clustering into FL training..Source: C. Model Fingerprinting for Device… · pp. 7–8
  • The server flattens partially trained model weights and biases, applies PCA, then clusters the reduced parameters with K-means using k-means++ initialization.The method hypothesizes that clients with similar data distributions will converge toward similar parameters when starting from the same initial model.Source: C. Model Fingerprinting for Device… · p. 8
  • Silhouette, Davies-Bouldin, and S Dbw internal validation scores are used to select the number of clusters without external data.The stated measures assess within-cluster compactness and between-cluster separation.Source: C. Model Fingerprinting for Device… · p. 8

D. Anomaly Detection Model

The anomaly detector learns normal IoT traffic with an autoencoder and uses reconstruction error to assess incoming samples. Its testbed models heterogeneous IoT/IIoT devices, communication behaviors, and network conditions.

D. Anomaly Detection Model

  • Autoencoders trained on benign traffic reconstruct normal behavior; reconstruction error indicates anomaly level when evaluating legitimate and attack samples.The encoder compresses input features into a smaller hidden space, and the training loss combines mean squared reconstruction error with L2 regularization.Source: D. Anomaly Detection Model · p. 8

A. IoT Testbed

  • The Gotham testbed uses emulated devices, malware, servers, and network equipment to generate realistic network traces.It is built on GNS3 and uses production libraries, Open vSwitch, VyOS, real malware samples, and red-teaming tools.Source: A. IoT Testbed · p. 8

1) City network devices:

  • The scenario connects city, cloud, and threat networks through 10 routers and 30 switches, with city devices using MQTT, CoAP, RTSP, DNS, NTP, and ICMP.The city network includes 12 device templates with varied payload sizes, formats, communication periodicity, encryption, authentication, and connection behavior.Source: A. IoT Testbed · p. 8, 1) City network devices · pp. 8–9
  • 78 device instances and random communication jitter create feature-distribution skew, data-quantity skew, and potentially non-independent network-trace samples.The scenario uses 12 templates to represent heterogeneous device behavior.Source: 1) City network devices · pp. 8–9

2) Cloud network devices:

The testbed includes cloud services, distinct threat actors, and federated traffic collection. It captures normal and attack traces at the devices rather than consolidating them into one dataset.

2) Cloud network devices:

  • Cloud services include MQTT brokers, CoAP clients, IP camera streaming servers, and DNS and NTP services.These services support communication with the city and threat networks.Source: 2) Cloud network devices · p. 9

3) Threat network devices:

  • The Mirai actor reproduces the malware lifecycle, from bot communication and scanning through credential brute force, infection, remote commands, and DoS attacks.The testbed’s Mirai components were adapted from published source code; the listed DoS activities include UDP, TCP, GRE, DNS, and Valve Source attacks.Source: 3) Threat network devices · p. 9
  • The Merlin actor performs C&C communication, tool transfer, remote commands, and hping3 DoS; the Calabrese actor runs network scans and CoAP amplification attacks.Calabrese uses Nmap, Masscan, and AMP-Research; its scans cover TCP and UDP ports.Source: 3) Threat network devices · pp. 9–10

B. Data Generation and Collection Method

  • Normal traffic trains the clustered FL anomaly detectors, while validation data includes normal and attack traces divided by scenario.Each device retains its own captured data; the traces are never aggregated into one dataset.Source: B. Data Generation and Collection Method · p. 10

1) Normal traffic data:

The testbed supplies benign traffic for training and separate normal and attack traffic for validation. Attack validation covers multiple Mirai, Merlin, scanning, and amplification scenarios.

1) Normal traffic data:

  • Normal traffic traces are collected per device without attacks and used for feature preprocessing, hyperparameter selection, and clustered FL training.The capture covers the first two hours, or one hour for IP camera devices, producing 3.3 GB of raw packets across 78 devices.Source: 1) Normal traffic data · p. 10

2) Validation-normal traffic data:

  • Validation-normal traces come from a later, separate capture and are used only to select the anomaly threshold, not for training.The capture spans two hours, or one hour for IP cameras.Source: 2) Validation-normal traffic data · p. 10

3) Validation-attack traffic data:

  • Validation-attack captures contain both normal activity and attacks, with five scenarios covering Mirai, Merlin, Masscan scans, and scan-amplification.The scenarios include Mirai scanning and loading, Mirai C&C-led DoS, Merlin C&C-led DoS, Masscan scanning, and Nmap scanning followed by CoAP amplification.Source: 3) Validation-attack traffic data · p. 10
  • The Mirai scenarios capture either its scanning-to-infection sequence or stealthier C&C-led DoS with scanning and brute forcing disabled.The other scenarios capture Merlin C&C-led DoS, Masscan scans, and Nmap scans followed by CoAP amplification.Source: 3) Validation-attack traffic data · p. 10

C. Machine Learning and Federated Learning Setup

  • Implementation uses PyTorch for ML models and server-side optimization, GNU Parallel for client training jobs, and scikit-learn for clustering and validation tools.The implementation section outlines data processing, model selection, device clustering, hyperparameter tuning, FL training, anomaly evaluation, and baseline comparisons.Source: C. Machine Learning and Federated… · pp. 10–11, §V · p. 11

A. Network Data Processing

The pipeline filters and transforms packet features before model training, with special port discretization to retain service semantics. Autoencoder selection balances reconstruction loss, model size, and regularization.

A. Network Data Processing

  • Raw pcaps are filtered, then 11 packet features are extracted and preprocessed; IP addresses are excluded so the model learns attack behavior rather than device identities.The selected features capture packet characteristics such as payload size, IP header fields, TCP flags, and payload entropy that may differ in attacks.Source: A. Network Data Processing · p. 11

1) Source and destination port feature processing:

  • Port numbers are discretized and one-hot encoded because numerical proximity does not imply similar service semantics.Three-range binning yields 27 features, while hierarchical binning adapted for MQTT, CoAP, and RTSP yields 69.Source: 1) Source and destination port feature… · pp. 11–12

B. Autoencoder Model Selection

  • The broader FL hyperparameter search is staged, selecting settings that minimize MSE in fewer rounds or epochs; L2 regularization and FL model averaging are described as overfitting mitigations.The tuning scope includes model architecture, client and server optimizers and learning rates, local epochs, FL rounds, and sampled clients.Source: B. Autoencoder Model Selection · p. 12
  • Autoencoder architecture selection uses non-federated experiments on normal traffic, choosing the simplest model with sufficiently low evaluation loss from the tested layer configurations.The input and output dimensions match the feature count, with 1–3 encoder hidden layers and a symmetric decoder.Source: B. Autoencoder Model Selection · p. 12

C. Device Clustering

The procedure clusters clients from partially trained model parameters, tunes FL optimizers and learning rates per cluster, then trains one global model per cluster. Local validation data sets detection thresholds; manually labeled attack data is used only to evaluate detection metrics.

C. Device Clustering

  • The server sends the selected autoencoder to 78 clients, then clusters their parameter updates after flattening and PCA reduction to explain at least 90% of variance.K-means++ is used, and the experiments vary local pretraining epochs ϵ and assess cluster counts with Silhouette, Davies-Bouldin and S Dbw.Source: C. Device Clustering · pp. 12–13

D. Federated Hyperparameter Tuning

  • Each cluster tunes client and server optimizers across 16 combinations, selecting the combination with lower average evaluation loss in fewer FL rounds.Learning rates are then refined by grid search, with E=1 and a shared initialization seed during tuning.Source: D. Federated Hyperparameter Tuning · p. 13

E. Clustered Federated Learning

  • The tuned process trains K cluster-specific global models for R rounds, varying local training epochs E and tracking client training and evaluation losses.The loss progression is monitored for possible overfitting signs.Source: E. Clustered Federated Learning · p. 13

F. Anomaly Detection

  • Each device evaluates its cluster’s trained global model on local validation-normal and validation-attack datasets.The validation-normal data estimates a local threshold; attack data is then used to identify anomalous packets.Source: F. Anomaly Detection · p. 13

1) Threshold selection:

  • Each device sets its threshold to the largest validation-normal MSE and flags packets whose MSE exceeds that threshold as anomalous.Thresholds are computed locally for each device.Source: 1) Threshold selection · p. 13

2) Anomaly detection performance:

  • Manually labeled attack data supplies evaluation ground truth, not training data; reported measures include accuracy, F1 score and MCC.Labels use attacker, victim, IoT and cloud node IP addresses and scenario timestamps; the authors note the heuristic labeling may misclassify packets.Source: 2) Anomaly detection performance · p. 13

G. Baseline experimental comparisons

The experiments compare Kitsune and two non-clustered FL baselines with the proposed approach. Clustering results support hierarchical port discretization with K=8, while the clustering and ground-truth metrics disagree for the three-range strategy.

G. Baseline experimental comparisons

1) Kitsune:

  • Kitsune is an unsupervised, online ensemble of autoencoders; unlike the proposed approach, it uses only local data and packet temporal features.Kitsune trains one sample at a time and does not filter IPv6 or ARP packets; the proposed approach extracts features from packets in isolation.Source: 1) Kitsune · pp. 13–14

2) non-clustered FL with weighted aggregation:

  • The non-clustered weighted-aggregation baseline removes clustering and trains one global model for all clients.Its aggregation weights each client’s contribution by the number of training samples used.Source: 2) non-clustered FL with weighted… · p. 14

A. Autoencoder Model Selection

  • The selected autoencoders use two hidden encoder layers with symmetric decoders; their layer widths depend on whether three-range or hierarchical port discretization is used.The three-range widths are 13 and 6 nodes; the hierarchical widths are 34 and 17, with ReLU activation, Adam at 1 × 10−3, L2 weight 1 × 10−5 and batch size 32.Source: A. Autoencoder Model Selection · p. 14

B. Device Clustering

  • Hierarchical discretization selected K=8 across internal and ground-truth similarity metrics; at higher ϵ, unsupervised estimates rose while supervised metrics remained at 8.For three-range discretization, internal metrics selected K=16 whereas ground-truth similarity scores peaked at K=12.Source: B. Device Clustering · pp. 14–15
  • The hierarchical K=8 clusters grouped all IP cameras together, separated some same-type devices by encryption, and grouped some heterogeneous devices by primary protocol.Table IV reports these clustering results for hierarchical port discretization at ϵ=4 and K=8.Source: Table IV · p. 15, B. Device Clustering · p. 15
  • For ϵ=2 and 1, unsupervised metrics identified K=9 and K=11, respectively; for ϵ=16 and 32, they tended toward about 11 and 17 clusters.The authors report that the larger-ϵ unsupervised estimates diverged from the supervised optimum of 8.Source: B. Device Clustering · p. 15
  • Fig. 4c projects 23 PCA components onto two dimensions, representing about 40% of explained variance, so some apparently close clusters may also be close in higher dimensions.The 23 components explain at least 90% of parameter variance; the projection shows only the first two.Source: B. Device Clustering · p. 15

1) Cluster stability for varying training data size:

Cluster assignments were mostly stable when clients used at least half their local training data, while federated optimizer tuning favored adaptive methods over standard SGD in the more complex clusters.

1) Cluster stability for varying training data size:

  • With ≥50% of local data, most clustering runs matched the reference exactly; below 50%, cluster quality and selected K became less stable.The stability check repeated each data fraction 30 times and compared adjusted Rand scores against the K = 8 reference clustering.Source: 1) Cluster stability for varying… · p. 15, Figure 5 · p. 16

C. Federated Hyperparameter Tuning

  • Adaptive CLIENTOPT or SERVEROPT methods generally converged faster and reached smaller losses than SGD, though some combinations showed increasing loss.Trials 9 and 10 performed best for Clusters 0, 2, and 4; Trial 10 reached a smaller loss than Trial 9 for Cluster 2.Source: C. Federated Hyperparameter Tuning · pp. 15–16
  • Grid search found many client/server learning-rate pairs with similarly low loss, so the authors selected a pair with lower loss across all three cases.The search varied η and ηs simultaneously and evaluated loss after 60 FL rounds.Source: C. Federated Hyperparameter Tuning · p. 16

D. Clustered Federated Learning

The clustered FL models showed stable training behavior and generally outperformed isolated training for lower-volume clusters, while detection results varied by device cluster and attack.

D. Clustered Federated Learning

1) Training baseline:

  • FL converged faster than isolated training for Clusters 0 and 2, while Cluster 4 had similar loss distributions; its devices generated 300–800 MB versus 230–270 KB and 100–170 KB of raw pcap data in Clusters 0 and 2.For Cluster 4, FL had lower average loss despite the similar distributions.Source: 1) Training baseline · p. 17

1) Cluster 0 (MQTT):

  • With device-specific thresholds chosen for zero false positives on validation-normal data, masscan packets were all correctly classified, while mirai-scan-load had one false positive and no missed anomalous packets.Masscan scored 1.0 accuracy, F1, and MCC; mirai-scan-load scored 0.9999 accuracy, 0.9999 F1, and 0.9997 MCC. In merlin-cnc-dos, the ICMP flood was missed (TP=25828, FN=5277; accuracy=0.8365, F1=0.9073, MCC=0.3891).Source: E. Anomaly Detection · p. 17, 1) Cluster 0 (MQTT) · pp. 17, 19

2) Cluster 2 (CoAP):

Clustered models detected the evaluated attacks strongly for Clusters 2 and 4, whereas the baselines exposed differences in performance across attack behavior and device-data volume.

2) Cluster 2 (CoAP):

  • Cluster 2 correctly classified all packets in four attack datasets and missed one scan-amplification packet, with 0.9999 accuracy, 0.9999 F1, and 0.9973 MCC for that case.The four perfect cases were Mirai scan-load, Mirai CNC DoS, Merlin CNC DoS, and masscan, each with 1.0 accuracy, F1, and MCC.Source: 2) Cluster 2 (CoAP) · p. 19

3) Cluster 4 (Camera):

  • Cluster 4 achieved 1.0 accuracy, F1, and MCC on Merlin CNC DoS and masscan; Mirai scan-load and Mirai CNC DoS each had 0.9999 accuracy and F1.The Mirai scan-load case had 0.9999 MCC, and Mirai CNC DoS had 0.9997 MCC.Source: 3) Cluster 4 (Camera) · p. 19

1) Kitsune:

  • Kitsune scored 0.9998 accuracy, 0.9999 F1, and 0.7397 MCC on Mirai CNC DoS but missed Mirai C&C traffic that the clustered model separated from normal activity.The clustered model missed some DoS packets; Kitsune detected the DoS attacks but not the C&C traffic.Source: 1) Kitsune · p. 19, Figure 10 · p. 20
  • On masscan, Kitsune missed low-volume and many medium-volume scans, while the clustered model detected activity at every scanning rate; Kitsune detected Merlin C&C, which is noisier than Mirai C&C.Kitsune's masscan metrics ranged from 0.7781–0.8122 accuracy, 0.8026–0.8865 F1, and 0.4665–0.5971 MCC.Source: 1) Kitsune · p. 19, Figure 11 · p. 20

2) non-clustered FL with weighted aggregation:

  • The weighted single global FL model performed poorly on Cluster 0 and Cluster 2 devices, but Cluster 4 metrics exceeded 0.9999 F1 or 0.9997 MCC across tested datasets.The authors attributed the imbalance possibly to sample-count weighting favoring six Cluster 4 devices that generated more data.Source: 2) non-clustered FL with weighted… · pp. 19, 21

3) non-clustered FL without weighted aggregation:

The equally weighted, non-clustered global model performs unevenly across device clusters, while the conclusions present clustered FL for unsupervised anomaly detection in heterogeneous IoT/IIoT. Evaluations report detection of most real attacks and identify boundaries involving training data, device mobility, and normal operating conditions.

3) non-clustered FL without weighted aggregation:

  • The baseline trains one global model (K = 1) with equal client weighting, Adam client optimization (η = 0.005), and SGD server optimization (ηs = 1.0).Training uses E = 4 local epochs and R = 100 rounds.Source: 3) non-clustered FL without weighted… · p. 21
  • Cluster 2 had near-zero F1 and MCC; on masscan, Cluster 4 reached 0.816 F1 and 0.830 MCC, yet results remained worse than clustered FL.The subsection also reports mixed results across mirai-scan-load, mirai-cnc-dos, and merlincnc-dos.Source: 3) non-clustered FL without weighted… · p. 21

VII. CONCLUSIONS

  • The proposed architecture trains unsupervised anomaly-detection models without labeled data and clusters devices by inspecting partially trained model parameters within the FL pipeline.It requires neither external fingerprinting tools nor manual clustering.Source: §VII · p. 21
  • In the emulated heterogeneous IoT/IIoT testbed, devices with similar communication patterns were grouped successfully, although clustering quality can fall when local training data is insufficient.The authors report a wide range of data amounts with mainly stable clustering, suggest ensuring enough data and repeating clustering, and note that clustering takes one communication round and little cost.Source: §VII · p. 21
  • FL converged faster than isolated edge training, especially for devices generating low volumes of training data.Source: §VII · p. 21
  • On real attacks, clustered models had low false-positive rates and high detection for most attacks, detected Mirai C&C heartbeats and slow scans, but missed some DoS attacks.Kitsune detected those DoS attacks but misclassified the stealthier activity.Source: §VII · p. 21
  • Clustered FL outperformed non-clustered baselines; a single global model showed high bias toward devices producing more training data or lacked generalization.The authors identify personalization through clustered FL as advantageous for unsupervised network anomaly detection.Source: §VII · p. 21
  • The experiments covered low-mobility devices; high-mobility settings remain future work, with dynamic or soft clustering suggested for changing device distributions.Source: §VII · pp. 21–22
Loading 2303.15986v2…