The Fleet That Checks In Once a Month: OTA Strategies for Rarely-Connected Devices

Ask any fleet operator how long their devices stay connected and the honest answer is usually uncomfortable. Agricultural sensors across the Midwest wake up during brief LoRa windows. RV battery monitors come alive for a few days around Memorial Day, then vanish until Labor Day. Marine electronics may sit in dry dock from October through April. For these fleets, the conventional OTA model — push, confirm, move on — simply doesn't apply.

At ARR-OTA, we spend a lot of time thinking about the connected edge of the fleet. This article is about the other end: devices whose default state is sleep, and what it takes to ship firmware to them anyway.

The Math of Absence

Consider a wildlife tracking deployment where devices transmit for ninety seconds per day. At a 99.9% offline rate, a firmware update targeting 95% of the fleet takes roughly two years to complete — assuming every check-in results in a successful transfer. That math changes how you design everything upstream of the update itself: the packaging, the protocol, and the patience of your rollout policy.

The first consequence is that update velocity is no longer a function of your server capacity. It is a function of device uptime, which you don't control. Any OTA system built for always-on hardware will quietly starve a mostly-offline fleet.

Design for Interruption, Not Completion

The single most valuable property you can give a transfer to a rarely-connected device is resumability. A device that wakes with 4% battery and a two-minute connectivity window cannot afford to restart a 1.2 MB image from byte zero because a TCP connection dropped at 80%.

Concretely, this means:

• Chunked downloads with server-side acknowledgment. The device records which chunks it holds in persistent storage; on reconnect, it asks the server where to resume rather than what to download.
• Content-addressed chunks. Hash each block so a partially-written flash sector can be validated independently. If chunk 47 of a payload is corrupt, re-fetch chunk 47 — not the image.
• Write-ahead staging. Never write firmware to the active slot. Stage to secondary storage (or a designated OTA partition) so an interrupted update leaves the device fully functional on its current version.

Delta updates matter even more here than in always-on fleets. If a device only has a 90-second window, the difference between a 40 KB diff and a 2 MB full image is the difference between one check-in and twenty. Binary diffing was not an optimization for this class of hardware; it is a prerequisite.

Opportunistic Windows and the Update Handshake

Devices that sleep through your rollout need a well-defined handshake for the moments they do appear. A practical pattern looks like this:

1. Announce on wake. The device sends a compact status frame — current version, available storage, battery state, chunk bitmap. Keep it under a few hundred bytes; on cellular or satellite links, every kilobyte is billed.
2. Server decides scope. Rather than streaming the full image immediately, the server may respond with metadata only, letting the device schedule the heavy transfer for a better window — shore power, stronger signal, warmer temperature.
3. Transfer in slices. The device pulls as many chunks as its window allows, then confirms the bitmap and returns to sleep.
4. Verify and commit atomically. Only after a full-image hash check does the device swap slots. A failed verification leaves the old firmware untouched.

The handshake's most important property is idempotency. A device might disappear mid-transfer for three weeks and return expecting to pick up exactly where it left off. Your server must treat that as normal, not exceptional.

Triage When Bandwidth Is Scarce

When connectivity is a shared, scarce resource — a single gateway serving a field of sensors, a satellite modem with a monthly data budget — you need an explicit priority policy. Reasonable tiers include:

• Security-critical fixes first. A CVE in your TLS stack outranks a UI polish release, always. Devices that rarely check in accumulate exposure; front-load the risky ones.
• Worst-version devices before near-current ones. A device three major versions behind represents more accumulated risk and a larger diff surface than one missing a single patch. Prioritize by drift, not by check-in order.
• Healthy hardware before marginal hardware. A device reporting a failing battery should not be handed a 15-minute flash write. Defer updates for devices whose telemetry suggests they can't survive the process, and flag them for human review.

This triage is the server's job, not the device's. The device should be as simple as possible: report state, obey instructions, verify everything.

Patience Is a Feature

The cultural shift is the hardest part. Teams accustomed to watching a rollout reach 90% in six hours must learn to read a dashboard where 40% after six weeks is on pace. Set expectations with stakeholders early: for a seasonally-connected fleet, define rollout targets in months, publish projected completion curves based on historical check-in data, and treat a slow curve as information about your fleet rather than a failure of your pipeline.

It also means your observability needs to tolerate silence. A device that hasn't checked in for 45 days isn't necessarily lost — it might be in a barn. Distinguish "offline as designed" from "offline as failure" using expected check-in intervals per device class, and alert only on deviations from each device's own rhythm.

Ship for the Fleet You Actually Have

The temptation is to design OTA for the devices you demo in the office — plugged in, on Wi-Fi, always awake. The fleet in the field is different, and it's the one that determines whether your customers trust your updates. Build for resumption, budget your bytes, triage your bandwidth, and measure progress on the fleet's clock, not yours.

Devices that sleep through your rollout will still take your update — if the system was designed for the ninety seconds they give you.