Client Selection

Selection must account for the heterogeneous and volatile resources of edge devices. Key constraints include:

• Battery Level: Selecting devices with sufficient charge to complete a training round.
• Network Connectivity: Ensuring stable, high-bandwidth connections for update transmission.
• Compute Availability: Checking for idle CPU/GPU cycles and sufficient RAM.
• Thermal State: Avoiding devices that may throttle due to overheating. Ignoring these leads to stragglers that delay aggregation and waste server resources.

The goal is to select clients whose local data provides the most learning signal for the global model. This involves:

• Assessing Data Distribution: Estimating if a client's data is IID or non-IID relative to the global population.
• Measuring Data Freshness: Prioritizing clients with newer, more relevant data to combat model drift.
• Evaluating Dataset Size: Balancing clients with large local datasets against those with rare, valuable examples.
• Detecting Data Poisoning: Screening for clients whose data may be maliciously crafted, a precursor to model poisoning.

In cross-device FL, it is impractical for all available clients to participate in every round. The system must handle:

• Massive Scale: Orchestrating selection from a pool of millions of devices.
• Unreliable Availability: Devices may go offline, disconnect, or decline participation mid-round.
• Synchronous vs. Asynchronous Aggregation: Deciding whether to wait for all selected clients (synchronous, simpler but slower) or aggregate updates as they arrive (asynchronous, faster but more complex). This necessitates robust fault-tolerant protocols and deadline enforcement.

Client devices are privately owned. Selection strategies must align user incentives with system goals:

• Incentive Mechanisms: Designing schemes (e.g., micropayments, improved model performance) to encourage high-quality clients to participate.
• Fairness and Bias: Avoiding selection patterns that systematically exclude certain device types or demographics, which can introduce bias into the global model.
• Transparency: Providing clients with clear information on resource consumption and data usage policies to build trust. Failure here results in low participation rates and unrepresentative training data.

Client selection is a primary lever for reducing the communication bottleneck, the dominant cost in FL. Strategies include:

• Update Compression: Selecting clients that can perform effective gradient compression or quantization.
• Reducing Round Frequency: Choosing clients likely to produce high-magnitude updates, reducing the total number of communication rounds needed for convergence.
• Geographic & Network-Aware Batching: Grouping clients by network topology to optimize aggregation server placement and reduce latency. The objective is to maximize learning progress per byte transmitted.

Common technical approaches to client selection include:

• Random Sampling: The baseline; simple and statistically sound but ignores utility and resources.
• Oort: A framework that prioritizes clients based on a utility-efficiency trade-off, using historical data on system and statistical utility.
• Power-of-Choice: Selects clients with the highest local loss values, biasing selection towards data that the current model performs poorly on.
• Federated Core: A system component in frameworks like TensorFlow Federated (TFF) that abstracts the selection process for simulation and deployment. The choice of strategy is a key hyperparameter in federated optimization.

Refers to Non-Independent and Identically Distributed data, the statistical heterogeneity where data distributions vary significantly across client devices. This is the norm, not the exception, in Federated Learning and poses a major convergence challenge.

• Example: Smartphone keyboard models encounter vastly different vocabulary and slang per user.
• Impact: Local models can diverge, biasing the global aggregation. Algorithms like FedProx are designed to mitigate this.

A cryptographic protocol that allows a Federated Learning server to compute the sum of client model updates without being able to inspect any individual client's contribution. This protects client privacy against a curious server.

• Mechanism: Uses techniques like Multi-Party Computation (MPC) or Homomorphic Encryption.
• Benefit: Enables privacy-preserving aggregation, a critical requirement for sensitive domains like healthcare.

The large-scale deployment scenario involving a massive number of unreliable, resource-constrained edge devices like smartphones or IoT sensors. Client Selection is particularly critical here.

• Characteristics: Millions of potential clients, high dropout rates, strict communication budgets.
• Selection Criteria: Must consider device battery, network type (Wi-Fi vs. cellular), and computational readiness to avoid stragglers.

The iterative cycles that define the Federated Learning training process. Each round consists of:

1. Client Selection (the topic of this glossary entry).
2. Broadcast of the global model to selected clients.
3. Local Training on client devices.
4. Aggregation of updates on the server.

• The total number of rounds directly impacts wall-clock training time and total network bandwidth consumed.