Differential Firmware Update
also called Binary Patch Update, Delta Image Shipping
Shipping a byte-level patch against one exact source image instead of a whole firmware build, which cuts transfer by an order of magnitude and makes the server responsible for knowing precisely what each device is running.
A 40000-unit sensor fleet on EU868 LoRaWAN needs a firmware fix. At the slowest data rate the application payload ceiling is 51 bytes and the sub-band duty cycle is 1%, so a 180 KB image is thousands of frames of airtime per device against a gateway budget shared by everything beneath it. The full image is not slow to ship; it is not shippable. A delta is around 9 KB.
The arithmetic hides a shift in responsibility. A full image is self-contained - any device in any state can apply it. A patch is only meaningful against one exact source, so the server must know the precise bytes installed on each device.
Why it matters
On LoRaWAN, slow NB-IoT or a satellite backhaul billed by the kilobyte, full-image updates are impossible or cost more than the device, so this is the difference between a maintainable fleet and an unmaintainable one.
It matters again because of how it fails. A signature over the patch proves nothing about the result. The patch really was signed by you, so verification passes, the patcher runs without error, and the output is garbage of exactly the right length. Only a digest of the reconstructed image catches it, so a team carrying its old signing model across installs corrupt firmware with a valid signature.
Implementation patterns
- The request carries a digest of the running image, not a version string - a version is an assertion, a digest is a measurement.
- The server answers three ways: a delta from that digest, a full image, or an explicit "no path from here" on a dashboard rather than a stalled device.
- The manifest carries a digest of the reconstructed image, verified before the new slot is marked bootable. RFC 9019 (April 2021) puts that manifest at the centre of the architecture for this reason.
- Retain every shipped image indefinitely, the cost that kills delta programmes in year three, and alert on attempted-and-declined.
Industry example
A LoRaWAN fleet in the EU863-870 band at DR0 gets 51 bytes of application payload per frame, and a payload that size occupies on the order of three seconds of airtime; under a 1% duty cycle on the main sub-bands a gateway's downlink capacity is a few tens of seconds per hour, shared across everything under it. Fleet-wide delivery of a 180 KB image is weeks of saturation, which is why update work on these networks is built on fragmentation and deltas.
RFC 9019, the IETF firmware update architecture for IoT, covers the surrounding machinery: it separates the author who builds firmware from the operator who authorises deployment, and supports both client-initiated updates, where the device polls, and server-initiated ones, noting the latter allows a faster response. On a duty-cycle-limited bearer polling is usually the only viable model, because the downlink needed to notify is itself scarce.
Failure scenarios
- Per-unit data inside the patched region - calibration constants, a serial, a trim value written at manufacture - so no two units share a base.
- The long tail on N-3 when deltas were built only from N-1, shown as pending rather than impossible.
- Discarding old images, after which half the fleet has no upgrade path.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Deltas against a verified base | an order of magnitude less transfer | every image kept forever - per-device base tracking - a digest check on the result |
| Full images only | any device in any state can update | impossible on duty-cycle-limited bearers |
When not to use it
On any bearer where the whole image fits in the maintenance window. Cellular, Wi-Fi and Ethernet make every problem above disappear for bandwidth nobody bills by the byte. Deltas answer a physical limit, not a general wish to optimise.
When your installed images are not reproducible. If you cannot state the exact bytes on a device you cannot build a correct patch, so the first project is making images reproducible.
And when no recovery path exists. A failed update on a bearer that cannot carry a full image is a van, and that belongs in the budget as a field-service liability.
Interview question
Q: You move a 50000-device fleet from full images to binary deltas. Three months later a rollout stalls at 91% with no device reporting an error. What is happening, what made it silent, and what would you have built differently?
What a strong answer covers: the stall as a base-image mismatch, where the patch applies cleanly to the wrong source · that a correct digest check makes this silent by design, so the alert must be attempted-and-declined rather than rollout percentage · the causes of divergence, from per-unit manufacturing data to bad-block remapping · and requesting by digest rather than version.
Quick check
Quiz: Why is a valid signature on a firmware delta not evidence the device will boot correct firmware? — The signature covers the patch, not the output. If the source differs by a byte the patcher produces a well-formed wrong image, and only a digest of the reconstructed image detects it.
Flashcard: What must a device send when requesting a delta? — A digest of the image it is running, because a version is an assertion not a measurement. The server must keep every image ever shipped.