Every embedded device connected to a network is a candidate for over-the-air firmware updates. But the economics of delivering those updates vary dramatically with the deployment context. A gateway ECU in a vehicle with a high-bandwidth LTE connection can receive a 2 MB full firmware image with negligible cost and minimal time. The same update delivered over a narrowband IoT network to a field sensor on a metered cellular data plan costs real money and takes real time — multiplied across thousands of devices.
Delta OTA, also called differential OTA or incremental firmware update, addresses this problem by delivering only the binary difference between the old firmware version and the new one. For firmware updates where the change set is small relative to the total image size, delta patches can be 80 to 95 percent smaller than the corresponding full firmware image. At scale, across bandwidth-constrained deployments, this difference is commercially significant.
How Delta OTA Works: The Fundamental Mechanism
Delta OTA requires three components: a patch generator that runs in the build infrastructure, a patch file that is delivered to the device, and a patch engine that runs on the embedded device to reconstruct the new firmware from the old firmware and the patch. The patch generator takes the old firmware image and the new firmware image as inputs, applies a binary diff algorithm to identify the regions that differ between the two, and encodes those differences as a compact patch file. Common binary diff algorithms used in embedded contexts include bsdiff, which produces compact patches by exploiting similarity in binary data structures, and xdelta, which uses rolling hash functions for fast patch generation.
The patch engine, running on the embedded device, applies the patch file to the existing firmware image to reconstruct the new image. The output must be byte-for-byte identical to the new firmware image that a full OTA would deliver.
Delta OTA vs Full OTA: When Each Is Appropriate
| Factor | Favours Delta OTA | Favours Full OTA |
|---|---|---|
| Bandwidth cost | Metered cellular, NB-IoT, narrow LPWAN | Wi-Fi, wired Ethernet, high-bandwidth LTE |
| Update frequency | Frequent minor updates | Infrequent major releases |
| Field version fragmentation | Single known base version | Multiple base versions in field |
| Device RAM availability | Sufficient for patch engine | Severely constrained |
| Update reliability requirement | High - retries are expensive | Standard |
| Build infrastructure complexity | Higher - per-version patches | Lower - single image per release |
The most significant practical limitation of delta OTA is version fragmentation. A delta patch is generated from a specific source version to a specific target version. If devices in the field run multiple different firmware versions, a separate patch file must be generated and managed for each source version. A common production strategy is to maintain delta patches from the most recent N versions to the current target, and fall back to full image OTA for devices running older versions.
Patch Application Strategies for Resource-Constrained Devices
In-place patching reads from the source flash region and writes the patched result to the target flash region simultaneously. This requires an A/B partition layout with separate source and target storage, because in-place modification of the active partition while the application is running would corrupt the executing firmware. The patch engine reads from the inactive partition, applies the patch, and writes the result to the update partition.
RAM-constrained patch application is necessary on devices where loading the full patch file into RAM is not feasible. Streaming patch algorithms process the patch file sequentially without requiring the complete patch to be resident in RAM simultaneously. Patch application time is another consideration — on a 32-bit embedded MCU at 100 MHz, a 50 KB patch applied to a 512 KB firmware image might take 5 to 30 seconds depending on algorithm complexity. Bootloader timeout configurations must account for this, and watchdog timers must be serviced during the patch application loop.
Security Considerations for Delta OTA
Patch file authentication is essential. A maliciously crafted patch file could corrupt the reconstructed firmware in controlled ways. The patch file must be signed with the same asymmetric signing key used for full firmware images, and the bootloader must verify the patch file signature before beginning patch application — not just verify the resulting patched image after application.
Output image verification after patch application must be performed even when the patch itself is authenticated. The CRC or cryptographic hash of the reconstructed image must match the expected value of the target firmware before the bootloader commits the update. Source image verification before patch application prevents the patch engine from being invoked on a corrupted source image, which could produce unpredictable output.
Implementing Delta OTA with RAPIDSEA
RAPIDSEA's OTA update stack and bootloader suite provide the architectural foundation on which delta OTA can be built for automotive and industrial embedded deployments. The A/B partition bootloader with signed image verification, boot confirmation, and anti-rollback protection provides the core update infrastructure that delta OTA requires. The patch engine integration point in the bootloader's update processing sequence supports custom or third-party diff algorithm implementations while maintaining the security and reliability properties of the underlying bootloader.
For EVSE controllers, industrial IoT gateways, and automotive telematics units operating on metered cellular connectivity, RAPIDSEA's OTA infrastructure combined with a delta patch strategy delivers meaningful bandwidth and operational cost reductions across the update lifecycle.
Conclusion
Delta OTA updates deliver substantial bandwidth, cost, and time savings for embedded deployments where full image delivery is expensive, slow, or operationally disruptive. The correct implementation requires a sound patch generation strategy, a resource-aware patch engine design, careful version management across the device fleet, and a security model that authenticates both the patch file and the resulting output image.
RAPIDSEA's bootloader and OTA infrastructure provides the secure, reliable update foundation that makes delta OTA deployment practical, allowing embedded teams to add differential update capability on top of a production-validated bootloader rather than building the entire update stack from scratch.
Ready to implement delta OTA for your embedded deployment? Contact our team to request an evaluation build or book a technical demo.