Availability-Aware Round Scheduling

The scheduler predicts when a client will be online and idle based on historical patterns and real-time signals. Common predictors include:

• Historical Uptime Patterns: Learning daily/weekly cycles of mobile phones or IoT sensors.
• Declared Availability Windows: Clients proactively signal their readiness (e.g., when charging and on Wi-Fi).
• Contextual Signals: Using device state like battery level, thermal status, and foreground app usage to infer availability.

Prediction enables proactive round scheduling, reducing idle server time and client dropout rates.

This protocol decouples client progress from a fixed global synchronization barrier.

Key Mechanism: The server maintains a global model and aggregates updates from clients as they complete their local training, regardless of when others finish.

Benefits for Availability:

• Accommodates Stragglers: Slow or intermittently connected devices do not block the round.
• Continuous Learning: The global model is updated more frequently, improving convergence speed.
• Utilizes Episodic Connectivity: Devices can train and submit updates during short online windows.

This is a foundational alternative to synchronous Federated Averaging (FedAvg) in dynamic environments.

When using asynchronous protocols, updates from clients may be based on an out-of-date global model. This staleness can harm convergence.

Aggregation Strategies:

• Time-Based Discounting: Apply a decay factor to older updates (e.g., weight = base_weight * (staleness_factor ^ delay)).
• Adaptive Server Optimizers: Algorithms like FedAsync or those using adaptive learning rates (e.g., FedAdam) naturally down-weight the impact of stale gradients.
• Buffer-and-Merge: Store stale updates and merge them strategically when they become relevant.

This mechanism ensures system stability despite highly variable client check-in times.

The scheduler maintains dynamic queues to prioritize which available clients to engage.

Queue Prioritization Factors:

• Data Criticality: Clients with data distributions underrepresented in recent rounds.
• Resource Freshness: Clients that have been idle longest to combat client drift.
• Update Quality: Historical contribution magnitude or data volume.
• System Objective: Balancing between model accuracy, fairness, and training speed.

When a device becomes available, the scheduler checks these queues to assign it a training task, optimizing overall federated utility.

This mechanism ensures training progress is not lost when a client disconnects unexpectedly.

Client-Side Checkpointing: The device periodically saves:

• The local model state.
• The optimizer state (e.g., momentum buffers).
• Processed data batch indices.

Server-Side Resilience: The server tracks:

• Round assignment state per client.
• Partial updates received.

On reconnection, the client can resume training from the last checkpoint, submitting a complete update. This is crucial for mobile networks with spotty coverage.

Availability-aware logic is implemented within federated learning orchestrators like Flower, TensorFlow Federated (TFF), or NVIDIA FLARE.

Typical Architecture:

1. Client Manager: Maintains the device registry with availability status.
2. Scheduler Service: Runs prediction and queuing algorithms.
3. Async Aggregator: Handles staleness-aware update merging.
4. Persistence Layer: Stores checkpoints and round state.

Example: In Flower, a custom Strategy class can override the configure_fit and aggregate_fit methods to implement priority-based selection and staleness-weighted aggregation, integrating directly with the framework's simulation or production runtime.

This is the canonical use case for availability-aware scheduling. It coordinates training rounds with the natural usage patterns of smartphones and tablets.

• Schedules rounds for periods of device idleness, charging, and connection to Wi-Fi.
• Leverages declarative availability where devices signal their readiness (e.g., via a background service).
• Maximizes participation from a massive, globally distributed fleet without degrading user experience or battery life.
• Example: Training a next-word prediction model across millions of phones by scheduling updates overnight when devices are plugged in and on home Wi-Fi.

In industrial settings, sensors and gateways have highly predictable but intermittent duty cycles. Scheduling aligns training with these operational windows.

• Syncs with data collection cycles (e.g., training occurs right after a batch of sensor readings is taken).
• Works around maintenance windows and scheduled downtime for machinery.
• Accounts for low-power sleep schedules common in battery-powered field sensors.
• Example: Training a predictive maintenance model for wind turbines using data from edge controllers, scheduling updates during periods of low wind when systems are in a monitoring-only state.

Connected vehicles have availability dictated by ignition cycles, connectivity zones (e.g., dealerships, home garages), and compute-intensive primary tasks like autonomous driving.

• Triggers training when the vehicle is parked, connected to a trusted high-bandwidth network, and has excess compute capacity.
• Uses predictive availability based on common driver patterns and telematics.
• Prioritizes safety-critical compute, pausing or canceling training rounds if vehicle systems require full resources.
• Example: Improving a traffic pattern recognition model by aggregating updates from electric vehicles only when they are charging at a station with high-speed cellular or Wi-Fi.

Medical devices (wearables, hospital monitors) and clinical workstations have strict usage protocols and privacy constraints that dictate availability.

• Schedules during off-hours for hospital-based workstations to avoid interfering with patient care software.
• Respects clinician workflows, only engaging devices when they are not in active diagnostic use.
• Integrates with duty rosters for devices shared among staff.
• Example: Training a model on data from wearable ECG patches by scheduling update transmissions during the patient's scheduled daily sync with a home base station.

In enterprise cross-silo FL (e.g., between different banks or hospital networks), 'availability' refers to scheduled compute windows and compliance with data governance policies.

• Aligns with pre-negotiated service-level agreement (SLA) windows for inter-organizational compute.
• Respects data sovereignty and privacy audit windows, only operating when all necessary governance checks are satisfied.
• Works around scheduled maintenance and backup cycles in private data centers.
• Example: Multiple financial institutions collaboratively training a fraud detection model, with aggregation rounds scheduled for 2 AM UTC on Sundays, a time pre-approved by all compliance officers.

In extreme edge scenarios (disaster response, rural areas, military tactical networks), connectivity is sporadic and must be actively exploited.

• Uses store-and-forward mechanisms where devices cache updates until a connection window is available.
• Employs delay-tolerant networking (DTN) principles to propagate model updates peer-to-peer when a central server is unreachable.
• Schedules based on predicted network contact graphs (e.g., when a drone or vehicle will be in range).
• Example: Training a model for wildlife tracking using data from sensors in a national park, with updates collected by a ranger's vehicle that drives through the area on a weekly schedule.

The foundational process of measuring and cataloging the computational resources, memory, network connectivity, and power availability of enrolled edge devices. This creates a dynamic registry used by the orchestrator to make informed scheduling decisions.

• Key Metrics: CPU/GPU type, available RAM, battery level, network bandwidth/latency, storage I/O.
• Purpose: Enables predictive scheduling by anticipating which devices can complete a training round successfully.

A dynamic orchestration strategy that assigns training tasks based on a client's real-time available resources, not just its static profile. It directly interacts with availability-aware logic to maximize round completion rates.

• Mechanism: Continuously evaluates device CPU load, memory pressure, and thermal status before assignment.
• Contrast with Availability-Aware: While availability-aware scheduling focuses on when a device is connectable, resource-aware scheduling focuses on if it has the compute/memory to train effectively at that moment.

A communication protocol where the server aggregates client model updates as soon as they arrive, eliminating the need for synchronized round completion. This is a critical alternative or complement to availability-aware scheduling for highly heterogeneous networks.

• Use Case: Accommodates clients with extremely variable training times due to compute differences or intermittent activity.
• Benefit: Prevents fast devices from idling while waiting for slow or temporarily offline devices, improving system efficiency.

A communication standard enabling reliable training over unstable networks. It provides the underlying mechanics that availability-aware scheduling leverages.

• Core Functions:
  • Update Caching: Devices store completed updates locally until a connection is available.
  • Session Resumption: Allows training to pause and resume after a connection drop without losing progress.
  • Efficient Synchronization: Uses differential updates to minimize data transfer when reconnecting.

A system design principle that modifies client selection and training intensity to minimize energy drain. It is a key constraint often integrated into availability-aware scheduling decisions.

• Strategies:
  • Defer training until a device is charging.
  • Reduce local computation (epochs) for low-battery devices.
  • Use more energy-efficient model architectures or compression for mobile clients.
• Goal: Preserve user experience and device longevity, which influences long-term client availability.

A system paradigm where the global model architecture and training workload can dynamically scale to match the collective resources of the available client pool. Availability-aware scheduling informs the "available pool" for this elasticity.

• Mechanism: The server may deploy a smaller sub-model or a reduced training task to a cohort of low-capability devices that are currently available.
• Relationship: Treats device heterogeneity and availability not as a problem to work around, but as a variable to adapt to dynamically.