PaperlayerView exact revision on arXiv

Source-linked AI summary

Topology-aware Federated Learning in Edge Computing: A Comprehensive Survey

Jiajun Wu, Steve Drew, Fan Dong, Zhuangdi Zhu, Jiayu Zhou

arXiv:2302.02573v2cs.LGcs.DC

TL;DR

Edge computing combines heterogeneous data with privacy constraints, while star-topology FL has communication bottlenecks and reliance on a central server. This survey uses a systematic search to compare topology-focused FL research. It concludes that topologies affect FL efficiency and effectiveness, but also add complexity, and no topology meets every user’s needs.

  • Problem

    Edge computing combines heterogeneous data and privacy constraints, while star-topology FL has a communication bottleneck and relies heavily on a central server.

    Source: §1 · p. 2, §5.4 · p. 33

  • Method

    The survey uses a PRISMA search strategy to systematically collect topology-focused FL papers and compare network topologies and their effects.

    Source: §2.1 · p. 4, §6 · p. 34

  • Results

    Network topologies substantially affect FL efficiency and effectiveness, and different structures bring benefits alongside extra complexity.

    Source: §6 · p. 34

  • Takeaways & Limitations

    Topology choice entails a privacy trade-off, and no single topology meets all users’ needs.

    Source: §5.4 · p. 33

    The survey identifies further research needs on how network topologies affect ethical and privacy issues.

    Source: §5.4 · p. 33

Abstract

from arXiv · show

The ultra-low latency requirements of 5G/6G applications and privacy constraints call for distributed machine learning systems to be deployed at the edge. With its simple yet effective approach, federated learning (FL) is a natural solution for massive user-owned devices in edge computing with distributed and private training data. FL methods based on FedAvg typically follow a naive star topology, ignoring the heterogeneity and hierarchy of the volatile edge computing architectures and topologies in reality. Several other network topologies exist and can address the limitations and bottlenecks of the star topology. This motivates us to survey network topology-related FL solutions. In this paper, we conduct a comprehensive survey of the existing FL works focusing on network topologies. After a brief overview of FL and edge computing networks, we discuss various edge network topologies as well as their advantages and disadvantages. Lastly, we discuss the remaining challenges and future works for applying FL to topology-specific edge networks.

1 INTRODUCTION

Edge computing creates demand for distributed learning under latency and privacy constraints, while network topology can both constrain FL and offer ways to address bottlenecks. This survey organizes FL research around edge-network topologies, compares their trade-offs, and identifies future research directions.

1 INTRODUCTION

  • Privacy requirements and latency constraints motivate edge-based learning, where data should remain at the edge.The paper presents federated learning as an approach for edge computing that avoids violating privacy legislation.Source: §1 · p. 2

1.1 Scope and Contribution

  • Existing surveys had not organized FL in edge computing from the network-topology perspective, despite topology’s benefits and challenges.The survey frames topology both as a constraint, such as added communication layers, and as a way to address bottlenecks such as communication overhead and reliance on a central server.Source: §1 · p. 2, §1.1 · p. 3
  • The survey categorizes FL studies by edge-network structure and classifies them into star, mesh, hybrid, and less common topologies.It also reviews selected works’ designs, baselines, benchmarks, and findings.Source: §1.1 · p. 3
  • The authors use a PRISMA-based review and outline challenges and future research directions for topology-aware FL.The survey positions its topology perspective against reviews focused on features such as data partitioning, communication architecture, or communication protocols.Source: §1.1 · p. 3

2 RESEARCH METHODOLOGY

The authors set out to identify FL network topologies, examine their benefits and challenges, and summarize baseline methods and datasets. They searched by topology using PRISMA and applied stated eligibility criteria, retaining 42 papers organized into five major topology types.

2.1 Research Goals Formulation

  • The review aims to identify FL network structures, examine their benefits and challenges, and summarize surveyed papers’ baselines and datasets.The authors use PRISMA and show a tree-topology search as an example.Source: §2.1 · p. 4

2.2 Search Strategy

  • After a broad “federated learning AND topology” search returned few papers, the authors restarted by searching topology structures as separate branches and grouping papers by major or minor topology.The listed search steps begin with a topology structure and then apply PRISMA.Source: §2.2 · pp. 4–5

2.3 Inclusion and Exclusion Criteria

  • The criteria required peer-reviewed work on unique topologies using FL and strong baselines; the review retained 42 papers across five major topology types.Exclusions included studies without FL, experiments without known baselines, application-centered case studies, and benchmark papers evaluating existing work.Source: §2.3 · p. 5

3.1 Background

The section introduces federated learning and explains how data and system heterogeneity, privacy concerns, convergence, and communication efficiency shape its design. It presents FedAvg as a communication-efficient approach and describes strategies for addressing differing clients and network conditions.

3.1 Background

  • FedAvg has workers train locally for multiple iterations before sending updated model parameters, reducing communication rounds versus FedSGD at the cost of more local computation.The survey notes that communication costs often overshadow computation costs in FL scenarios with limited local data.Source: §3.1 · p. 6

3.1.1 Statistical and System Heterogeneity.

  • Statistical heterogeneity means clients have differing local data distributions, which can cause client drift and biased global models; personalized learning and constrained updates are proposed responses.System heterogeneity in computation, memory, and bandwidth also makes a single model architecture unsuitable for all clients.Source: §3.1.1 · pp. 6–7

3.1.2 Privacy.

  • FL avoids direct data exchange but does not eliminate privacy risks, since adversaries may infer original data from model parameters.Secure multi-party computation, differential privacy, verifyNet, and adversarial training are listed as privacy-preserving techniques.Source: §3.1.2 · p. 7

3.1.3 Convergence Guarantee.

  • Prior theoretical analyses of FL under different problem settings conclude that FedAvg can achieve linear convergence speedup under commonly adopted assumptions.Source: §3.1.3 · p. 7

3.1.4 Communication efficiency.

  • Communication efficiency can be improved by reducing rounds or transmitted data, while topology choices trade off direct communication with central servers against peer-to-peer or hierarchical exchange.The survey describes star, tree, fully meshed, and hybrid designs, and notes that personalized FL can share only partial model parameters.Source: §3.1.4 · p. 7

3.2 FL Characteristics Specific to Edge Computing

Edge computing differs from the typical star-topology FL setup through heterogeneous devices, hierarchical organization, and volatile participation. These characteristics influence energy use, task placement, clustering, and topology design.

3.2 FL Characteristics Specific to Edge Computing

  • Practical edge architectures and network configurations differ from the naive star topology and can affect FL design and deployment.Source: §3.2 · p. 7

3.2.1 Heterogeneity, energy efficiency, and task offloading.

  • Battery-powered devices vary greatly in capability, so energy-aware design and offloading FL tasks from weaker devices to more powerful ones are relevant to edge topologies.Energy constraints can make a star topology unsuitable at large scale when the central edge server exceeds its capacity.Source: §3.2.1 · p. 8

3.2.2 Hierarchy and clustering.

  • Multi-tier edge hierarchies separate device and server roles, enabling clustering and aggregation; dynamic topologies can respond to internal and external factors.Lower-capability devices may collect and upload sensing data, while edge servers train local models and receive global updates.Source: §3.2.2 · p. 8

3.2.3 Availability and mobility.

  • Mobile edge devices can enter or leave network boundaries and switch clusters, interrupting task processing and motivating dynamic-format topologies with device or server additions and removals.Source: §3.2.3 · pp. 8–9

3.3 FL Challenges and Solutions in Edge Network Topologies

The section links edge-network topology choices to FL challenges involving organizational data, communication, and data imbalance. It describes topology-based approaches including transfer learning, hierarchical aggregation, decentralized aggregation, and tree-topology mediators.

3.3.1 Scattered data across organizations.

  • For organizations with strict restrictions on sharing data or intermediate models, federated transfer learning can combine their data without violating privacy regulations.Compared with vanilla FedAvg, it can learn from the entire dataset rather than only samples with common features.Source: §3.3.1 · p. 9
  • Hierarchical edge topology pools and aggregates device updates, reducing the communication costs of sending them to the cloud.Direct communication with a central server can be expensive and cause high latency for some edge devices.Source: §3.3.2 · p. 9

3.3.2 High communication costs.

  • Decentralized aggregation distributes partial aggregation across relaying edge servers, so a compromised central server cannot see all clients’ fine-grained updates.Source: §3.3.3 · p. 9

3.3.4 Imbalanced data distribution.

  • For imbalanced data, tree-topology methods such as Astraea place mediators between the FL server and clients.The survey contrasts bursty AR data with smaller, periodic temperature-monitoring data.Source: §3.3.4 · p. 9

3.4 Categorization of Topology-aware FL in Edge Computing

The survey organizes FL studies along several dimensions, including data partition, update protocol, federation scale, and global-model organization. These categories distinguish settings with different client data, synchronization, participation scale, and aggregation structures.

3.4 Categorization of Topology-aware FL in Edge Computing

  • FL studies are categorized by different characteristics, including data partition, communication protocol, federation scale, and global-model organization.The survey notes that existing work lacks a standard systematic categorization of topology-aware FL studies.Source: §3.4 · pp. 9–10

3.4.1 Based on Data Partition: Horizontal FL (HFL), vertical FL (VFL), and federated transfer learning (FTL).

  • HFL uses the same feature set across clients, VFL combines different feature sets for the same or overlapping samples, and FTL addresses heterogeneity in both feature and sample spaces.FTL uses feature transformations to project source features into a common subspace for knowledge transfer.Source: §3.4.1 · p. 10

3.4.2 Based on Model Update Protocols: Synchronous, Asynchronous, and Semi-synchronous FL.

  • Synchronous FL waits for all learners each round, asynchronous FL lets learners request updates independently, and semi-synchronous FL mixes models at a synchronization point.The survey notes that synchronous training can leave learners underused, while asynchronous updates can increase communication costs and lower global-model generalization.Source: §3.4.2 · p. 10

3.4 Categorization of Topology-aware FL in Edge Computing

  • FL studies also distinguish IID from non-IID data settings, since local data are often non-IID and can reduce performance when not specifically addressed.Source: §3.4.3 · p. 10

3.4.4 Based on Scale of Federation: Cross-silo and Cross-device FL.

  • Cross-silo FL coordinates a small number of large data centers, whereas cross-device FL involves many devices with relatively little data per device.Source: §3.4.4 · pp. 10–11

3.4.5 Based on Global Model: Centralized and Decentralized FL.

  • Centralized FL uses a central server to compute the global model or coordinate devices, while fully decentralized FL has no overarching server and connects devices peer-to-peer or device-to-device.Source: §3.4.5 · p. 11

4 TYPES OF FL NETWORK TOPOLOGY

The survey organizes FL by network topology, presenting topology as a lens for reviewing existing work and its potential benefits for communication efficiency, privacy, and scalability.

4 TYPES OF FL NETWORK TOPOLOGY

  • FL topology describes how edge devices communicate with one another and a centralized server, and the survey groups designs as centralized, decentralized, hybrid, or other types.The survey uses this perspective to organize state-of-the-art FL studies rather than focusing on features such as data partitioning or communication protocols.Source: §4 · pp. 11–12

4.1 Star Topology

Star topology remains the common, straightforward FL architecture, but its centralized communication pattern can create cost, privacy, and security concerns. The survey reviews star-based methods addressing communication, heterogeneity, personalization, and secure aggregation.

4.1 Star Topology

  • The star architecture centrally aggregates and distributes models, but can incur high communication costs and raise privacy and security concerns at the central server.The survey notes that this straightforward design may not fit every FL system.Source: §4.1 · p. 12
  • SplitNN [128] enabled health entities to collaborate without sharing raw data, achieved performance similar to single-machine neural networks, and reduced client-side computation.Experiments used MNIST, CIFAR-10, and ILSVRC 2012.Source: §4.1 · p. 13

4.1.1 Asynchronous FL topologies.

  • Synchronous FL limits communication rounds but makes faster clients wait, whereas asynchronous FL lets clients update when ready but increases communication costs.Semi-synchronous FL [121] sets synchronization points so faster clients can complete additional training rounds without excessive communication.Source: §4.1.1 · p. 13

4.1.2 Personalized star topology.

  • Personalized star methods reduce transmitted model content through partial uploads or dynamically sized models; pFedGate [12] combines sparse personalization with device-resource constraints.The survey also reports that client-cohort failure rates rose from 0% to 80% as cohort size increased from 10 to 800.Source: §4.1.2 · p. 14, §4.1.3 · p. 14

4.1.3 Cohorts & Secure aggregation.

  • Secure aggregation methods use sparse communication structures to reduce resource needs, including CCESA [16], which uses a sparse random graph of secret-sharing nodes instead of a complete graph.The cited protocols and [16] require three interaction rounds between server and clients.Source: §4.1.3 · p. 14

4.2 Tree Topology

Tree FL adds edge-server tiers between devices and the central server, enabling hierarchical or dynamic arrangements. The surveyed work explores these structures for communication and resource trade-offs, changing participants, grouping, and privacy-related design.

4.2 Tree Topology

  • A tree topology has at least three levels, with edge servers connecting devices to the central server; otherwise, the structure is considered a star topology.The hierarchy can include arbitrary client layers and cluster sizes that vary with data distribution and other cluster parameters.Source: §4.2 · p. 14, Figure 6 · p. 15, Figure 7 · p. 15
  • Tree FL studies are categorized as hierarchical or dynamic, and typical designs include cloud, edge, and device tiers.End-edge-cloud FL used heterogeneous model selection and aggregation and reported better accuracy, precision, recall, and F1 than other methods in its 6G settings.Source: §4.2 · p. 15, Figure 8 · p. 16, §4.2.1 · p. 16

4.2.1 Typical tree topology FL.

  • HierFAVG trades client-edge communication against edge-cloud communication, reducing cloud communication rounds while balancing local updates and edge aggregation.With fixed overall communication k1k2, fewer local-update rounds k1 and more edge communication can speed training; excessive client-edge communication can increase energy consumption.Source: §4.2.2 · pp. 16–17
  • HFEL jointly minimizes system energy and delay per global iteration by allocating computation and communication resources, with a scheduling algorithm intended to relieve core-network overhead.Its objective combines energy E and delay T with varying weights.Source: §4.2.2 · p. 17
  • Hierarchical aggregation can improve scalability: one layered approach transmits at most one gradient per link and has time cost that grows logarithmically rather than linearly.Other work considered uniform edge data distribution and jointly optimizing energy consumption and gradient divergence.Source: §4.2.1 · p. 16, §4.2.2 · p. 17
  • EdgeFed offloads part of local training to edge servers and reduces communication costs, but transmitted low-layer data may let an edge server restore the original data.Devices compute lower model layers locally; edge servers pool their outputs and process the remaining layers.Source: §4.2.2 · pp. 18–19

4.2.3 Dynamic Topology.

  • In dense edge networks, Mhaisen et al. proposed dynamic tree topologies where devices pair with different edge servers across aggregation rounds; choosing the best server yields UE-edge assignment solutions.Separately, [133] jointly optimized device sampling and data-offloading configurations to maximize training accuracy under network and device capability constraints; TOFEL jointly optimized topology and computing speed to minimize energy and latency. Astraea used a mediator to reschedule client training, while Auto-Group automatically grouped users to balance group data distributions against the global distribution.Source: §4.2.3 · pp. 19–20, §4.2.4 · p. 20

4.2.4 Grouping strategy and privacy enhancement.

  • Grouping strategies include tiering clients by response latency, with synchronous training within tiers and asynchronous training across tiers; hierarchical designs also allow flexible placement of privacy defenses and verification.The survey also describes assigning clients to global-model subnetworks based on local resources.Source: §4.2.4 · pp. 20–21

4.3 Decentralized\Mesh Topology

This section surveys decentralized mesh FL and related wireless and blockchain approaches that distribute communication or aggregation beyond a conventional central server. The reviewed works target communication efficiency, latency, robustness, and trust, while also reporting constraints such as blockchain communication overhead.

4.3 Decentralized\Mesh Topology

  • Mesh FL exchanges models directly between connected devices without a central aggregator, and gossip learning was generally comparable to FL or better in some scenarios.The survey also reports lower busiest-node communication cost for decentralized FL and a potential one-order-of-magnitude speedup for D-PSGD over optimized centralized counterparts [67].Source: §4.3 · p. 21

4.3.1 Decentralized Topology in Wireless Networks.

  • BACombo’s segmented gossip and bandwidth-aware worker selection reduced training time by up to 18 times versus baselines without accuracy degradation.Its worker-selection model greedily chooses workers with sufficient bandwidth to reduce transmission delay.Source: §4.3.1 · p. 23
  • Decentralized FL balances local updates against inter-node communication; compressed communication yields linear convergence for strongly convex objectives [73].The survey notes that balancing communication and computation rounds matters under constrained resources [73].Source: §4.3.1 · pp. 23–24
  • FedPGA’s partial-gradient exchange and adaptive updating achieved up to 14 × faster training than baselines without compromising accuracy.The method targets high training latency in traditional star-topology FL.Source: §4.3.1 · p. 24

4.3.2 Routing in Decentralized Topology.

  • Simulations across network settings found scale-free and small-world networks more suitable for decentralized FL, while hierarchical networks traded off convergence speed.The study varied topologies, datasets, and machine-learning models.Source: §4.3.2 · pp. 24–25

4.3.3 Blockchain-based Topology.

  • Blockchain-based FL replaces the central server’s global-model role with ledger-based mechanisms, but Bitscotti’s communication overhead prevents support for large deep-learning models.At 200 peers, Bitscotti showed similar utility to traditional star-topology FL.Source: §4.3.3 · pp. 25, 27
  • BFLC inserts a committee to validate and package updates, while FL-Block uses miners to verify and store local updates.The survey also describes Proof of Training Quality, which selects a committee leader by model MAE.Source: §4.3.3 · pp. 25–26
  • Tuning the block arrival rate was reported to minimize system delay in blockchain-based vehicular FL.The analysis considered retransmission rate, block size, block arrival rate, and frame sizes.Source: §4.3.3 · p. 27

4.4 Minor Topologies

The survey reviews less-common and hybrid topologies that adapt communication and aggregation to edge-network structure. The examples include rings, cliques, grids, fog and multi-server systems, and ring-tree convergecast designs.

4.4.1 Ring Topology.

  • RingFed clients preaggregate updates and contact the central server periodically; it outperformed FedAvg in most cases and optimized training on non-IID data [144].The server assists in passing parameters but does not perform the training tasks [144].Source: §4.4.1 · p. 27

4.4.2 Clique Topology.

  • D-Cliques group sparsely interconnected clients into locally fully connected neighborhoods whose label distributions represent the global distribution, reducing links and mitigating label-skew effects [4].The design avoids a fully connected topology across all clients [4].Source: §4.4.2 · pp. 28–29, Figure 10 · p. 28

4.4.3 Grid Topology.

  • In the evaluated line, ring, star, and grid networks, more neighbors led to faster convergence and higher accuracy [118].Grid clients have four neighbors, compared with two in the ring [118].Source: §4.4.3 · p. 29

4.4.4 Hybrid Topology.

  • Hybrid topologies combine traditional designs; fog learning fuses star and mesh structures with layered communication, including D2D links at the edge.D2D offloading among trusted devices may trade privacy for offloading, while inter-layer offloading can increase local-data similarity and reduce model bias.Source: §4.4.4 · p. 29, §4.4.5 · pp. 29–30, Figure 11 · p. 29

4.4.5 Fog Topology (Star + Mesh).

  • MH-FL combines intra-cluster D2D consensus with multi-stage parameter relaying across layers, using limited- or extensive-uplink clusters [38].FedP2P retains a central server for a small number of aggregated partitions, while TT-HF combines star FL with cooperative D2D communications [17].Source: §4.4.5 · p. 30
  • P-FedAvg uses multiple parameter servers that aggregate locally and mix parameters with neighboring servers; the 2d-torus was the most robust among ring, 2d-torus, and star comparisons.The study reports convergence-rate gains when the network is not sparsely connected.Source: §4.4.5 · p. 30
  • Dinh et al.’s in-network aggregation architecture improved network latency by 4.6 times [22], while FedCH improved completion time by 49.5-79.5% and network traffic by 57.4-80.8%.FedCH uses heterogeneous-capacity client clusters and asynchronous global aggregation by cluster heads.Source: §4.4.5 · pp. 30–31

4.4.6 Semi-ring Topology (Ring + Star/Tree).

  • The semi-ring design forms local rings among one-hop peers and an n-ary convergecast tree from those rings to the aggregator; its analysis found superior system latency.TornadoAggregate also uses a ring architecture for accuracy and scalability [59].Source: §4.4.6 · p. 31, Figure 12 · p. 31

5 CHALLENGES AND FUTURE RESEARCH ROADMAPS

This section surveys open challenges and research directions for topology-aware FL, from choosing and managing topologies to privacy, availability, and real-world validation.

5.1 Topology selection

  • Choose topology by server dependence, star suitability, and existing structure; where devices already form server-managed subgroups, optimize the evident tree for communication efficiency or security.The survey also identifies developing new topologies or combinations of existing ones as a research opportunity.Source: §5.1 · pp. 31–32

5.2 Communication cost

  • Communication-cost work should account for battery-limited aggregation and transmission and changing bandwidth, mobility, density, or link failures through energy-aware, dynamic, fault-tolerant topology control.The survey calls for finding topologies that deliver models reliably and on time based on transmission volume.Source: §5.2 · p. 32

5.3 Client-drift

  • Client drift can let a noisy device bias its cluster model; opportunistic routing can incorporate outside-cluster models and reduce repeated transmissions of updates based on the same data.The passage describes contributions of local models to multiple clusters as a way to mitigate bias and improve privacy.Source: §5.3 · pp. 32–33

5.4 Ethical/Privacy concerns

  • Star designs concentrate privacy responsibility centrally, tree intermediates offload it but need protection, and decentralized designs trade server exposure for peer-to-peer privacy risks.Neighbor-model mingling is described as reducing vulnerability to differential-privacy attacks, while the survey concludes privacy remains a trade-off with no universally suitable topology.Source: §5.4 · p. 33

5.5 Availability-aware FL assisted by topology overlay

  • When edge-server failures threaten aggregation availability, meshed server links can support task replication, trading robustness against redundancy; logical overlays can group devices by data intensity and distribution.The overlay example maps devices from physical clusters into separate logical clusters.Source: §5.5 · p. 33

5.6 Conduct real-world deployment

  • Most topology-related FL evaluations are simulated; real edge deployments and testbeds could validate model deployment and inference time, communication costs, and other practical challenges.The survey notes that realistic deployment would move evaluation beyond proofs of concept in simulations.Source: §5.6 · pp. 33–34

6 CONCLUSION

The survey compares star, tree, decentralized, and hybrid topologies and discusses their effects on FL efficiency and effectiveness. It concludes that topology choice involves added complexity and depends on system needs and architecture.

6 CONCLUSION

  • The survey summarizes star, tree, decentralized, and hybrid topologies and compares their substantial effects on FL efficiency and effectiveness.Source: §6 · p. 34
  • Alternative topologies can benefit the network but add complexity, so choosing one depends on whether the simple star meets the system's needs.Source: §6 · p. 34
  • FL architectures should account for central-server necessity, clients' diurnal activity patterns, and options for intermediate servers.Source: §6 · p. 34
Loading 2302.02573v2…