Over-the-Air Update (OTA)

The Update Client is a lightweight software agent embedded in the device firmware responsible for the local update process. Its core duties include:

• Polling a remote server for new updates.
• Downloading and validating update packages.
• Managing the update in a dedicated, non-volatile memory partition.
• Handing off control to the Bootloader, a minimal, immutable program that performs the critical swap to the new firmware image upon a verified restart, ensuring a failsafe rollback mechanism is available.

To minimize bandwidth and energy use, OTA systems for TinyML employ advanced payload formats.

• Delta Updates (Bsdiff): Transmit only the binary differences between the old and new firmware, reducing payload size by 80-95%.
• Model-Only Updates: In Federated Learning, transmit only the new model parameters (weights), not the entire application firmware.
• Compression: Apply algorithms like LZ4 or Zstandard to the delta or model payload before transmission. This is critical for microcontrollers with limited flash memory, where even a 100KB update can be significant.

Security is non-negotiable for OTA updates. This involves a chain of trust:

• End-to-End Encryption: Payloads are encrypted (e.g., using AES) during transit.
• Cryptographic Signing: The update server signs the payload with a private key. The device's bootloader verifies this signature using a pre-provisioned public key before installation, ensuring the update is authentic and untampered.
• Secure Boot: The bootloader itself is validated via hardware-rooted keys, establishing a root of trust. This prevents malicious firmware from taking control of the device.

The central Update Server orchestrates the process. Key functions include:

• Device Registry: Tracks all deployed devices, their current firmware/model versions, and status.
• Rollout Management: Enables staged rollouts (e.g., 1%, 10%, 100%) and A/B testing of new models.
• Campaign Targeting: Allows updates to be pushed to specific device cohorts based on hardware, location, or data distribution.
• Health Monitoring: Tracks update success/failure rates and device telemetry post-update, enabling automatic rollback if failure thresholds are exceeded.

OTA updates must handle unreliable, intermittent, and low-bandwidth networks (LPWAN, satellite). Protocols are designed for resilience:

• Resumable Transfers: Use HTTP range requests or CoAP block-wise transfer to resume interrupted downloads.
• Acknowledgment Schemes: Ensure packets are received; the server retransmits missing chunks.
• Low-Power Priority: Schedule downloads during periods of good connectivity and low device activity to conserve energy. For TinyML, protocols like MQTT-SN or CoAP are common.

A failsafe mechanism is essential for mission-critical deployments. This is typically implemented via a dual-partition scheme (A/B) in device flash memory:

• The device always runs from the active partition (e.g., A).
• The new update is written to the inactive partition (B).
• After validation, the bootloader switches the boot pointer to partition B.
• If the new firmware fails to boot or passes a health check (e.g., a watchdog timer), the bootloader automatically reverts to the known-good partition A. This ensures device functionality is always maintained.

The process of embedding a machine learning model and its associated runtime into the low-level system software that directly controls an embedded device's hardware. For OTA updates in federated learning, this involves creating a single, deployable binary image that includes:

• The embedded FL runtime for local training.
• The quantized global model parameters.
• Communication protocols for secure aggregation.
• Resource managers to handle compute constraints and energy budgets. Successful integration ensures the OTA payload executes deterministically on the target Microcontroller Unit (MCU).

A lightweight software library deployed on a microcontroller that manages the local execution of the federated learning client protocol. It is a core component delivered via OTA updates and is responsible for:

• Loading the latest global model.
• Executing on-device training using the local on-device dataset.
• Applying differential privacy or secure aggregation protocols.
• Managing communication during the availability window.
• Handling heterogeneous client capabilities and thermal throttling. This runtime must operate within the device's strict memory footprint and compute constraints.

An embedded system, such as a microcontroller-based sensor, with severe limitations in memory, processing power, energy, and bandwidth. These constraints define the OTA update challenge for federated edge learning:

• Memory Footprint: OTA payloads must be minimal, often requiring model sparsification and post-training quantization.
• Compute Constraint: Limits the complexity of training algorithms that can be executed locally.
• Energy Budget: Wireless communication for OTA and local training must minimize battery drain.
• Network Bandwidth: Drives the need for sparse updates and efficient compression. OTA mechanisms must be designed to function reliably within these immutable hardware limits.

The variation in hardware capabilities, data distributions, and network conditions among devices in a federation. This heterogeneity critically impacts OTA update strategies:

• Hardware Variation: Different MCUs may require different compiled model binaries (TinyML stack output), complicating a one-size-fits-all OTA payload.
• Partial Participation: Only devices within an availability window can receive and apply an update.
• Straggler Problem: Slow devices can delay system-wide adoption of a new model version.
• Data Heterogeneity: Non-IID data across clients may necessitate personalized federated learning models, which could be delivered via targeted OTA updates. OTA systems must manage this diversity to ensure robust model deployment.

The process of inducing sparsity in a neural network by zeroing out a significant fraction of its parameters. This technique is crucial for creating OTA-updatable models for federated edge learning because:

• It drastically reduces the model size, decreasing the OTA transmission time and energy cost.
• It enables sparse updates, where clients only communicate the non-zero changes to their local models, saving bandwidth.
• Sparse models can be stored and computed more efficiently on a resource-constrained device.
• Combined with weight pruning and quantization, sparsification is part of the core optimization pipeline for TinyML deployment.

The process of updating a model's parameters directly on an edge device using locally generated data. OTA updates deliver the foundational model and algorithms that make this possible. Key considerations include:

• Warm-Start Model: OTA often delivers a pre-trained model to mitigate the cold-start problem.
• Compute Constraint: Training algorithms must be designed for low-power MCUs, using techniques like low-precision arithmetic.
• Energy Budget: Training cycles must be managed to avoid excessive battery drain.
• On-Device Dataset: Training uses local sensor data streams, processed via on-device preprocessing. This capability enables continual learning and personalization without raw data ever leaving the device.