Task Scheduler

The scheduler's primary function is to algorithmically select a subset of available clients for each training round. This involves evaluating client eligibility based on dynamic criteria:

• Resource Availability: Device battery level, free memory, and CPU load.
• Network Conditions: Connection type (Wi-Fi vs. cellular), bandwidth, and latency.
• Data Relevance: Statistical properties of the local dataset to ensure representativeness.
• System State: Whether the device is idle, charging, or in a low-power state. Policies like random sampling, power-aware selection, or data-diversity maximization are implemented here to balance efficiency, fairness, and model convergence.

In multi-tenant or multi-job environments, the scheduler must arbitrate between competing training tasks. It enforces priority policies (e.g., high-priority job for a critical model update) and fairness policies to prevent client resource starvation. Common strategies include:

• Weighted Fair Queuing: Allocates client participation slots proportionally to job priority.
• Deadline-Aware Scheduling: Prioritizes jobs with strict convergence deadlines.
• Client Fairness: Ensures no single device is over-sampled, promoting statistical fairness across the population and preventing bias from dominant clients.

Federated edge networks are defined by extreme heterogeneity in device capability. The scheduler must match task complexity to client resources. Key mechanisms include:

• Capability Profiling: Maintaining a registry of client compute, memory, and hardware accelerator (e.g., NPU) specs.
• Adaptive Model Partitioning: Assigning smaller sub-models or fewer training steps to constrained devices.
• Dynamic Batching: Adjusting local batch sizes per device to fit memory limits. This function prevents stragglers from bottlenecking round completion and ensures efficient use of the entire device spectrum.

The scheduler orchestrates the synchronous or semi-synchronous execution of a federated learning round. It manages the temporal workflow:

1. Task Dispatch: Sends the current global model and training configuration to selected clients.
2. Timeout Management: Sets and monitors round deadlines, handling stragglers and client dropouts.
3. Update Collection: Triggers the aggregation phase once a sufficient number of updates are received or a timeout occurs. This coordination is critical for maintaining the logical consistency of the iterative federated averaging process.

Given the unreliable nature of edge networks, the scheduler implements robust fault tolerance strategies:

• Checkpointing: Periodically saving global model state to allow job resumption.
• Retry Logic: Re-assigning tasks from failed or unresponsive clients to healthy ones.
• Partial Participation Tolerance: Proceeding with aggregation even if some clients drop out, a core tenet of federated learning.
• State Reconciliation: Tracking which clients have received which model version to prevent state corruption. This ensures job completion despite an unpredictable client population.

The scheduler optimizes for system-wide efficiency, directly impacting operational costs. It makes decisions to:

• Minimize Communication Rounds: The most expensive federated learning cost factor. It may delay a round to wait for high-quality clients on unmetered networks.
• Reduce Client Energy Consumption: Scheduling training during charging cycles or on Wi-Fi to preserve user device battery.
• Balance Server Load: Staggering client check-ins and update uploads to prevent server-side throttling. By treating client resources as a constrained commodity, the scheduler maximizes utility per unit of consumed energy and bandwidth.

A simple, fair-share policy where the orchestrator selects clients in a fixed, circular order. This ensures all registered clients get an equal opportunity to participate over time, preventing starvation.

• Key Mechanism: Maintains a pointer to the last selected client; the next eligible client in the list is chosen for the subsequent round.
• Use Case: Effective in homogeneous environments with clients of similar capability and data quality. Provides basic fairness but ignores client readiness, potentially leading to idle rounds if selected clients are offline or busy.
• Example: In a cross-silo setting with three reliable hospital servers, the scheduler might select Hospital A, then B, then C, then back to A in a predictable cycle.

A policy that selects clients based on their real-time resource state—such as battery level, available memory, CPU load, and network bandwidth—to maximize round completion success.

• Key Mechanism: The scheduler queries a Resource Monitor for client telemetry. Clients below resource thresholds (e.g., battery < 20%) are deprioritized or skipped.
• Use Case: Critical for cross-device federated learning on smartphones and IoT sensors, where device availability is volatile. This policy minimizes client dropout during training rounds.
• Impact: Increases overall system efficiency and model convergence stability by reducing failed rounds, though it may introduce bias towards clients with consistently better resources.

An advanced policy that prioritizes clients based on both system utility (training speed) and statistical utility (data quality/quantity) to accelerate global model convergence.

• Key Mechanism: Scores each client. System utility is often measured by client throughput (examples processed per second). Statistical utility can be the local loss value or the size of the client's local dataset. Clients with high scores are selected.
• Use Case: Developed to address the inefficiency of random selection in environments with non-IID data and heterogeneous client capabilities. It explicitly optimizes for faster training.
• Example: The Oort scheduler (research prototype) uses this hybrid approach, demonstrably reducing time-to-accuracy by up to ~2x compared to random selection in simulated environments.

Assigns static or dynamic priority levels to clients or federated jobs, ensuring critical tasks are serviced first. Priorities can be based on Service Level Agreements (SLAs), client tier, or job urgency.

• Key Mechanism: Each client or job has a priority queue. The scheduler always selects from the highest-priority non-empty queue. Within a queue, another policy (e.g., round-robin) may be used.
• Use Case: Essential in multi-tenant federated learning platforms where different organizations or departments have varying importance. Also used to prioritize retries of failed rounds.
• Example: A financial institution might assign higher priority to a fraud detection model update over a less critical marketing model, ensuring regulatory SLAs are met.

A policy designed to improve performance for clients with worse local data distributions (e.g., underrepresented classes), promoting fairness across the federation.

• Key Mechanism: Adapts the client selection probability or the aggregation weighting based on client performance. Algorithms like q-FedAvg assign higher weight to clients with higher loss, effectively prioritizing their updates to improve their local model accuracy.
• Use Case: Addresses the "winner-takes-all" problem where the global model converges to perform well only for clients with majority data patterns. Crucial for applications requiring personalized federated learning or equitable healthcare diagnostics.
• Challenge: Can slow overall global accuracy improvement in favor of improving worst-case client performance.

A policy that schedules training rounds to meet a specified global deadline, adapting client selection and local training parameters (like epochs) to ensure timely aggregation.

• Key Mechanism: The scheduler works backward from a round deadline. It may select only the fastest clients or dynamically adjust the number of local training steps (epochs) assigned to each client to fit the time window.
• Use Case: Vital for real-time or near-real-time federated learning applications, such as adaptive traffic prediction or live content recommendation, where model updates must be deployed within a strict operational cycle.
• Integration: Often works in tandem with a Convergence Monitor and Resource Monitor to make informed trade-offs between speed and model quality.

The Round Coordinator is the component that manages the execution of a single federated learning training round. It works directly with the Task Scheduler to sequence the round's phases:

• Client Selection: Receives the eligible client list from the scheduler.
• Task Dispatch: Sends the training task and model to selected clients.
• Update Collection: Manages timeouts and gathers client model updates.
• Aggregation Triggering: Signals the Central Aggregator to combine updates once a sufficient number are received. The Task Scheduler determines when and in what order rounds are executed, while the Round Coordinator handles the per-round workflow.

The Client Selection Module is the algorithmic component that chooses which devices participate in a given training round. It provides the candidate pool for the Task Scheduler, which then allocates resources and sets the execution timeline. Selection is based on dynamic criteria:

• Resource Availability: Device battery, CPU, memory, and network connectivity.
• Data Relevance: Statistical properties of the local dataset (e.g., data distribution, sample count).
• System Objectives: Policies for fairness (ensuring all clients train eventually) or efficiency (prioritizing fast, reliable devices). The scheduler uses this module's output to build a feasible and optimal execution plan for the round.

The Resource Monitor is a telemetry system that collects real-time metrics from federated clients and server infrastructure. It is the primary data source for a dynamic Task Scheduler. Metrics include:

• Client-Side: CPU load, available memory, battery level, network bandwidth/latency, and current thermal state.
• Server-Side: Aggregator load, queue depths, and network ingress/egress. The Task Scheduler consumes this stream to make informed decisions, such as deprioritizing a client with 10% battery or delaying a round during peak network congestion. This enables proactive scheduling that adapts to system state.

The Heterogeneity Handler is a system module designed to manage variability across clients. It provides the Task Scheduler with strategies and normalization functions to deal with differences in:

• Compute Capability: Adjusting batch sizes or local epochs for devices ranging from smartphones to servers.
• Network Conditions: Staggering update uploads or enabling compression for slow connections.
• Data Distribution: Applying techniques to mitigate statistical skew (non-IID data). The scheduler uses these strategies to create personalized task assignments. For example, it might assign a shorter training task to a constrained IoT sensor while a powerful edge server receives a more complex model variant.

The Fault Tolerance Manager implements strategies to ensure job completion despite client dropouts and network failures. It provides the recovery protocols that the Task Scheduler must orchestrate. Key mechanisms include:

• Checkpointing: Periodically saving global model state to allow rollback.
• Client Dropout Handling: Defining timeouts and specifying minimum participant thresholds for each round.
• Retry Logic: Policies for re-scheduling tasks on failed clients or alternative devices. The Task Scheduler integrates these policies, deciding when to trigger a retry, when to proceed with partial updates, and when to restore from a checkpoint. This makes the scheduler responsible for maintaining forward progress in an unreliable environment.

The Workflow Engine automates and sequences the high-level steps of the federated learning lifecycle using a directed acyclic graph (DAG). It defines the macro-dependencies that the Task Scheduler operates within. A typical workflow DAG includes nodes for:

• Model initialization and distribution.
• Iterative training rounds (each round is a sub-graph managed by the Round Coordinator).
• Model validation and evaluation.
• Deployment to inference endpoints. The Task Scheduler is responsible for executing the resource-aware, timed execution of each node in this workflow. While the engine defines what needs to happen and in what order, the scheduler determines how and when it happens on the available infrastructure.