On-Device Resource Monitor

The monitor collects continuous, low-overhead metrics from the device's operating system and hardware sensors. This provides a live snapshot of resource availability, which is critical for making immediate training decisions.

Key metrics tracked include:

• CPU Utilization: Percentage of processor cores in use.
• Memory Pressure: Available RAM and swap usage.
• Battery State: Current charge level and discharge rate.
• Thermal Status: Core temperature and throttling flags.
• Network Bandwidth: Available uplink/downlink speed and latency.

This data forms the basis for all adaptive federated learning policies.

Beyond current state, advanced monitors use time-series analysis to predict future resource constraints. By analyzing historical patterns (e.g., periodic user activity, scheduled tasks, battery drain curves), the agent can forecast if sufficient resources will be available to complete a training round.

This enables proactive strategies such as:

• Deferring training until a predicted high-power state (e.g., device charging).
• Pre-emptively reducing batch size if memory pressure is forecast to increase.
• Warning the federated orchestrator of impending client dropout due to low battery.

The monitor enforces local resource guardrails by dynamically adjusting training hyperparameters or pausing execution. It translates raw telemetry into actionable limits for the training loop.

Common throttling actions include:

• Dynamic Batch Sizing: Reducing local batch size to stay within available RAM.
• Learning Rate Scaling: Adjusting the optimizer step size based on system stability.
• Early Stopping: Halting local epochs if CPU usage exceeds a thermal threshold.
• Gradient Checkpointing: Trading compute for memory by re-calculating activations.

This ensures training does not crash the device or degrade the user experience.

The agent compiles static and dynamic device information into a structured capability profile reported to the federated learning server. This profile is essential for intelligent client selection and resource-aware scheduling.

A comprehensive profile includes:

• Static Attributes: CPU architecture, total RAM, NPU presence, OS version.
• Dynamic Status: Current metrics from telemetry (e.g., battery at 45%).
• Declared Policies: User preferences (e.g., "only train on Wi-Fi").
• Historical Reliability: Success/failure rate of previous training tasks.

This allows the orchestrator to stratify clients and assign appropriate workloads.

The monitor is not a standalone component; it exposes APIs or signals that integrate directly with the federated learning client library and the central orchestrator. This creates a closed-loop control system for the entire federation.

Integration points enable:

• Pre-Training Checks: The orchestrator queries capability profiles before selecting clients for a round.
• In-Training Adaptation: The local client library receives real-time signals to throttle.
• Post-Training Analytics: The server logs resource usage per client to refine future scheduling algorithms.

Frameworks like TensorFlow Federated and Flower provide hooks for such integrations.

A primary function is to enforce hardware safety and preserve user experience by preventing excessive battery drain or overheating. This is non-negotiable for consumer devices (smartphones, tablets).

The monitor implements safeguards like:

• Absolute Cut-offs: Pausing all training if battery falls below 10% or temperature hits a critical limit.
• Graceful Degradation: Progressively reducing CPU frequency allowance as temperature rises.
• User-Centric Scheduling: Respecting "Do Not Disturb" or sleep mode periods.

This ensures federated learning operates as a background task without negatively impacting device primary functions or longevity.

The monitor tracks CPU utilization percentage and available RAM to prevent system lag and out-of-memory crashes during local training.

• Example: A smartphone client detects CPU usage exceeding 80% and available RAM dropping below 100MB.
• Action: The monitor triggers dynamic batching, reducing the local batch size from 32 to 8 to lower memory pressure and CPU load, ensuring the training task completes without crashing the user's foreground applications.

Continuous tracking of battery percentage, charge state (charging/discharging), and estimated remaining battery life enables battery-aware federated learning.

• Example: An IoT sensor on battery power has 30% charge remaining and is not connected to a charger.
• Action: The monitor informs the orchestrator to either skip selection for the upcoming training round or to apply extreme compute-aware selection constraints, limiting the client to a minimal number of training steps to preserve operational longevity.

The monitor reads device temperature sensors and thermal throttling flags to prevent hardware damage and performance degradation.

• Example: A device's system-on-chip (SoC) temperature reaches a predefined high-threshold (e.g., 75°C).
• Action: The monitor initiates thermal-throttling management, proactively pausing the local SGD loop, reducing CPU clock speed, or switching to a more efficient but less accurate partial model participation scheme until temperatures normalize.

Assessing network type (Wi-Fi, 5G, LTE), signal strength, available bandwidth, and data cost informs communication strategies.

• Example: A mobile device switches from unmetered Wi-Fi to a metered cellular connection with poor signal.
• Action: The monitor enforces connectivity-aware compression, applying aggressive quantization (e.g., 1-bit SGD) or top-k sparsification to the model update before transmission, minimizing data usage and cost for the end user.

Monitoring available storage space and flash memory write endurance is critical for devices that may need to cache models or swap gradients to disk.

• Example: A client with limited RAM needs to use gradient checkpointing, which trades compute for memory by re-computing activations, requiring frequent disk writes.
• Action: The monitor checks if sufficient storage I/O bandwidth and space exist. If not, it may downgrade to a simpler federated dropout strategy that keeps the entire working set in memory.

Detecting the presence and current load of specialized Neural Processing Units (NPUs), GPUs, or DSPs allows for optimal workload placement.

• Example: A client's resource monitor identifies an idle, dedicated NPU capable of accelerating convolutional layers.
• Action: The monitor signals the Federated Hardware Abstraction Layer (HAL) to compile and execute the model's compute-intensive layers on the NPU, while keeping other operations on the CPU, dramatically speeding up local training and reducing energy consumption.

The systematic process of measuring and cataloging the computational resources, memory, network connectivity, and power availability of edge devices enrolled in a federated learning system. This profile is stored in a federated device registry and is the foundational data used for all subsequent resource-aware decisions.

• Static Profiling: Captures immutable hardware specs (e.g., CPU model, total RAM).
• Dynamic Profiling: Continuously updates with real-time metrics (e.g., available memory, battery percentage, CPU load) via the on-device resource monitor.

A federated learning orchestration strategy that dynamically assigns training tasks based on real-time client resource states. The scheduler uses inputs from client capability profiling and the on-device resource monitor to make decisions.

• Compute-Aware Selection: Prioritizes devices with sufficient free CPU/GPU cycles.
• Availability-Aware Round Scheduling: Aligns training with device active periods to accommodate sleep cycles.
• Goal: Maximize round completion rate and system efficiency while preventing device overload.

A client-side optimization technique where the local batch size for stochastic gradient descent is automatically adjusted per device based on its current available memory and compute capacity.

• Prevents Out-of-Memory (OOM) Errors: Reduces batch size when memory pressure is high.
• Optimizes Throughput: Increases batch size on powerful, idle devices to utilize full compute.
• Works in tandem with techniques like gradient checkpointing for extreme memory constraints.

A method that splits a neural network model into segments, offloading computationally intensive layers to a server or nearby edge node while keeping simpler layers on the resource-constrained device. This enables federated training of models that would otherwise be too large for the device.

• Split Learning: A common implementation where the device runs early layers, sends activations to a server for later layers, and receives gradients back.
• Use Case: Allows smartphones to participate in training large vision models by only computing initial convolutions.

A variant of the core Federated Averaging (FedAvg) algorithm designed to aggregate model updates from clients with vastly different computational capabilities. Standard FedAvg can be biased towards powerful devices that complete more local epochs.

• Weighted Averaging: Weights client updates by the amount of local work completed (e.g., number of samples processed).
• Variable-Length Training Rounds: Allows clients to perform different numbers of local steps based on their resources before submitting an update.

A system design principle that modifies client selection, training intensity, and communication frequency to minimize energy drain on mobile and IoT devices. It directly uses battery level data from the on-device resource monitor.

• Deferral: Postpones training tasks until a device is charging.
• Intensity Scaling: Reduces CPU frequency or limits local epochs when battery is low.
• Primary Goal: Preserve user experience and device longevity, which is critical for consumer-facing applications.