Client Eligibility

Devices must meet minimum hardware and network requirements to participate effectively. This prevents stragglers and ensures timely completion of training rounds.

• Compute & Memory: Sufficient CPU/GPU cycles and RAM to execute the local training task.
• Battery Level: For mobile devices, a charge threshold (e.g., >30%) to avoid interruption.
• Network Bandwidth: Stable, sufficient connection to download the global model and upload updates within a deadline.
• Storage: Available space to store the model and a local dataset.

Example: A smartphone is only eligible if it is charging, connected to Wi-Fi, and has >2GB of free RAM.

Clients must possess a local dataset that is both quantitatively and qualitatively adequate for meaningful model improvement.

• Minimum Data Volume: A threshold number of local samples (e.g., >100 images) to compute a stable gradient.
• Data Distribution: Relevance to the current global learning objective; devices with outdated or irrelevant data may be excluded.
• Label Availability: For supervised tasks, a sufficient number of correctly annotated samples.
• Data Freshness: Recent data may be prioritized for tasks involving concept drift.

Example: In a next-word prediction task, a device is eligible only if it has a local text corpus exceeding 10,000 tokens.

Devices must pass security attestations to ensure they are not compromised and will execute the training protocol correctly. This is critical for mitigating Byzantine attacks.

• Device Integrity: Verified via hardware roots of trust (e.g., TPM) or secure boot.
• Client Authentication: Valid, non-revoked credentials to join the federation.
• Runtime Attestation: Confirmation that the training code is executing in a trusted execution environment (TEE).
• Reputation Score: A historical trust score based on past participation behavior.

Example: An industrial sensor must provide a valid hardware attestation report before being allowed to download the model.

The device's current operational context determines its readiness to participate in a potentially resource-intensive training job.

• Online Status: The device must be actively connected to the federated learning server.
• Idle State: Training is often scheduled for periods of device inactivity (e.g., overnight) to avoid disrupting primary user functions.
• Thermal State: Devices overheating may be excluded to prevent hardware damage.
• Predictable Uptime: Estimated availability to complete the entire local training epoch.

Example: A smart thermostat may only be eligible for training during the night when ambient temperature adjustments are infrequent.

Clients are evaluated based on the expected contribution their local data will make to improving the global model. This moves beyond basic availability to optimize learning efficiency.

• Gradient Norm: The magnitude of the client's previous update, used as a proxy for update significance.
• Training Loss: Devices with higher local loss may be prioritized, as their data likely represents under-learned concepts.
• Data Diversity: Clients with data distributions that differ from the current global model's knowledge (high loss) or that fill a gap in the overall data manifold.
• Shapley Value Estimation: An approximation of the client's marginal contribution to model performance.

Example: A selection algorithm (like Oort) scores clients by a composite of their reported training loss and historical resource reliability.

Eligibility must align with organizational policies, regulatory requirements, and fairness objectives to ensure equitable and compliant system operation.

• Fairness Quotas: Guaranteeing minimum selection rates for devices from underrepresented geographical regions or demographic groups to mitigate bias.
• Data Sovereignty: Ensuring clients are located within approved legal jurisdictions for data processing.
• Participation Limits: Capping the number of times a single client can be selected to prevent over-representation.
• Incentive Compliance: Verification that the client meets the terms of any participation incentive scheme.

Example: A global model for a healthcare application may enforce a policy that at least 20% of selected clients per round must be from European Union countries to comply with GDPR training locality requirements.

Client selection is the overarching process of determining which eligible edge devices or data silos will participate in a given training round. It moves beyond simple eligibility to apply a selection policy—a rule-based, heuristic, or ML-driven algorithm—that optimizes for objectives like faster convergence, improved model accuracy, or system efficiency. This process is critical for managing client heterogeneity and mitigating stragglers.

Client profiling is the continuous process of collecting and maintaining metadata about federated clients to inform selection decisions. This metadata creates a dynamic profile for each device, including:

• Hardware capabilities (CPU, memory, NPU)
• Network conditions (bandwidth, latency)
• Data statistics (dataset size, label distribution)
• Historical behavior (reliability, past contribution) Profiles enable resource-aware selection and are the data foundation for calculating a client's utility function score.

A utility function is a mathematical formula that quantifies the expected benefit of selecting a specific client. It translates client profile data into a single score used for ranking and selection. Common factors in a utility function include:

• Statistical utility: The potential improvement to the global model (e.g., based on local gradient norm or training loss).
• System efficiency: The client's resource availability to complete training quickly.
• Fairness: A penalty or bonus to ensure diverse participation and bias mitigation. Frameworks like Oort explicitly optimize for a joint utility of statistical and system efficiency.

Straggler mitigation refers to techniques designed to prevent slow or unresponsive devices from delaying the completion of a federated learning round. It is a core driver for sophisticated selection strategies. Methods include:

• Resource-aware selection: Pre-filtering clients based on battery, compute, and connectivity.
• Deadline-aware protocols: Frameworks like FedCS that select clients who can complete work within a specified time window.
• Asynchronous FL selection: Aggregating updates as they arrive, bypassing the need to wait for the slowest client. Effective mitigation is essential for practical system deployment.

A selection policy is the core algorithm that governs how clients are chosen. It implements the strategy defined by the utility function. Common policy types include:

• Random Selection: A uniform baseline, often used to establish client diversity.
• Power-of-Choice: Selects the best client from a randomly sampled subset to improve convergence speed.
• Tier-based (TiFL): Groups clients into tiers based on capability and samples from each to handle heterogeneity.
• Multi-Armed Bandit: Treats clients as 'arms' and uses online learning to balance exploring new clients and exploiting known high-performers. The policy is executed by the federated learning orchestrator.

Fairness-aware selection incorporates constraints to prevent systematic over- or under-representation of client groups, which can lead to biased global models. Bias mitigation in selection involves:

• Stratified sampling: Ensuring participants are drawn proportionally from defined subgroups (strata).
• Fairness constraints: Adding terms to the utility function that penalize the repeated selection of the same devices.
• Contribution valuation: Using concepts like the Shapley value to quantify and potentially compensate for data contributions, encouraging broader participation. Without these measures, selection can amplify existing data imbalances.