Blog
Perspective

Telemetry that survives the dead zone

Offline Protocol · Aug 1, 2026
logisticstelemetrymaritimefleetcold chain
Telemetry that survives the dead zone

Your telemetry architecture has a single point of failure, and it is the one link you do not control: the cellular tower your reefer truck just drove past, or the satellite pass your vessel is between. Everything upstream of that link, the dashboards, the alerting, the cold chain audit trail, is only as good as its uptime. And on the routes and sites this equipment actually operates in, that uptime is not guaranteed. It is a bet.

The stream goes dark exactly where the risk is highest

Cold chain, fleet, and remote-asset telemetry all share the same failure mode. A refrigerated container crosses an ocean where no cell tower reaches and depends on satellite fill-in for backhaul. A mining site sits underground or behind terrain that blocks line of sight. A fleet truck spends part of every route in a coverage gap between towers. In every one of these cases, the moment the link drops is not a random moment, it is a predictable one, tied to the exact conditions your operation runs in. And it is exactly when something is most likely to go wrong that your visibility into it disappears.

The stakes are rising, not falling. The cold chain monitoring market alone is forecast to grow from roughly $8 billion in 2026 to $22.2 billion by 2035, a sign of how much operational and compliance weight is being placed on continuous, trustworthy telemetry. At sea, the picture is worse than a clean loss of signal: in high-traffic corridors like Singapore, Rotterdam, and the English Channel, overlapping AIS and satellite transmissions cause routine signal collisions and dropped position reports, so even “connected” stretches lose data. Fleet operators see the same pattern on land, where operators building around cellular trackers plan explicitly for the towers to go silent mid-route. The industry has converged on the same conclusion from three different directions: the network you are depending on for telemetry was never going to hold the whole route.

Most stacks treat that gap as someone else’s problem

The common response is to add a second cellular carrier, or a satellite modem as a fallback, and call the redundancy problem solved. That helps, but it does not close the gap, because both of those are still long-haul links with their own outage modes, their own latency, and their own cost per byte. None of them address the actual moment of loss: the seconds to hours where the device has no path back to a server at all. During that window, most telemetry stacks do not degrade, they stop. Readings queue locally if you are lucky, or they are simply lost, and either way the operator watching the dashboard sees a gap they cannot explain until the device reconnects.

What DORS changes about that moment

DORS, the transport layer of Offline Protocol, does not treat the internet as the only path. Every device running it also carries BLE and WiFi Direct, and DORS scores all three transports continuously on signal strength, congestion, and reliability, routing traffic over whichever is best right now. When satellite or cellular degrades or drops, that is not a special failure state the system has to detect and recover from. It is just one candidate removed from a list that still has others. Traffic keeps moving over BLE and WiFi Direct, sub-second, with no reconfiguration and no code change in the application above it.

That matters for telemetry specifically because it changes what “no cellular coverage” means for a device. A truck idling in a coverage gap next to another truck, a sensor near a gateway inside a mine, a vessel within WiFi Direct or BLE range of another vessel or a shore station: none of those devices are actually alone, even when the long-haul link is down. DORS lets them discover each other and relay data hop by hop, up to 8 hops, with acknowledgment, retry, deduplication, and TTL so a reading that takes an indirect path still arrives exactly once. Reliability doesn’t require the tower. It requires other devices nearby, which in a fleet, a yard, a vessel, or a mine site, there usually are.

On top of that transport, Offline Protocol’s telemetry layer is built to keep runtime observability flowing off-link, not just to buffer until reconnect. Metrics, transport state, and routing data move across the mesh the same way any other message does, so the operations team watching a remote fleet or a set of offshore assets does not lose visibility the instant the satellite or cellular path degrades. They get a stream that reroutes, rather than a gap they have to reconstruct after the fact.

None of this replaces your long-haul link when it is working. The internet, when it is present, is simply the longest and fastest transport DORS has available, and it uses it gladly. The difference shows up specifically in the stretches where that link is not present, which for cold chain, maritime, fleet, and remote-site telemetry is not an edge case. It is a routine part of the route.

Where this fits your stack

If your telemetry architecture currently has a single long-haul link standing between “observable” and “dark,” that is the gap worth closing before the next outage does it for you. See how the transport layer behaves under failover in how DORS failover works, read the technical detail on offline telemetry, or see the fit for logistics and fleet operations. If you want to talk through your specific routes and dead zones, get in touch.

More posts
Announcement · Aug 13, 2026

Open sourcing the coordination layer for the disconnected edge

Perspective · Jul 29, 2026

We built the world on a dependency nobody declared