Satellite & LEO Backhaul for Remote Edge AI Sites 2026 — Link Selection, Latency & Gateway Sizing

Edge AI hardware ends up at remote sites for one reason: the site is remote. Wellheads, pipelines, substations, mines, forestry blocks, offshore platforms and disaster-response deployments all have a workload worth computing on and a network nobody would trust to carry it. Every one of them runs the same architecture decision — compute locally, transmit a conclusion — but the link behind that decision is usually chosen last, from a consumer price list, and then constrains the whole system for a decade.

This guide treats the backhaul link as a hardware design input. It covers how GEO VSAT, LEO constellations, private LTE/5G and narrowband radio differ in latency, throughput and duty cycle; what each round trip forbids; how to size storage around an outage rather than an average; and how the terminal's power draw changes the compute you can actually fit on site.

Decide at the Edge, Report the Conclusion

The unifying rule of remote edge AI is that the link carries decisions, not signals. A single 1080p camera at a modest 3 Mbit/s produces roughly 32 GB of video per day. Eight of them produce around 260 GB per day, or about 8 TB per month. No satellite service priced for industrial telemetry carries that, and the services that could are priced for broadcast, not for a mine. The camera node therefore has to answer its own question — is there a crack, a person, a hot spot — and put an event on the wire only when the answer matters.

Three quantities decide the architecture. Latency sets what can be controlled remotely. Throughput and metering set what can be moved. Availability sets how long the site must survive alone. All three are properties of the link, and all three feed back into the compute, storage and power budget at the site.

Choosing the Link — GEO, LEO, Cellular and Radio

The propagation floor is physics and deserves to be stated separately from the measured number. A GEO satellite at 35,786 km costs about 119 ms one way, so a GEO round trip cannot fall below roughly 240 ms however good the modem is; the 500–700 ms operators quote is that floor plus ground-segment and processing delay. A LEO satellite at 340–550 km costs under 2 ms one way, and the 25–60 ms measured round trip is almost entirely network and ground-segment overhead. That difference is the whole reason LEO displaced GEO for interactive workloads.

Two selection rules follow. First, no control loop may close across any of these links. A 25 ms round trip is still twenty-five milliseconds too slow for a 250 microsecond motion cycle, so safety, interlocks and motion stay local and the link carries setpoints and reports. Second, hybrid is the normal answer rather than the exception: a private LTE or public 4G path for bulk transfer alongside a satellite path for base connectivity gives each medium the duty cycle it is good at.

Latency, Handover and the Availability Budget

A link specification that quotes only average throughput hides the two events that actually break remote systems.

Handover comes first. A LEO satellite passes overhead in minutes, so the terminal re-points or switches beams repeatedly through the day. The gaps are short — tens of milliseconds to a couple of seconds — but they arrive unpredictably, and any session that assumes one persistent connection will see resets. This is the problem delay-tolerant networking was built for: the Bundle Protocol (RFC 9171) treats a disrupted path as normal and stores custody at each hop instead of pretending the connection survived.

Weather comes second. At Ka band, heavy rain can add 10 dB or more of attenuation over the clear-sky link budget — a factor of ten in received power — and wet snow on a radome does the same. Systems that matter are specified on a rain-fade margin rather than on the best day's throughput, and either accept a lower availability figure or carry a second path.

Availability then sets the local storage number, which is the part most remote projects get wrong.

Bandwidth Budget and Store-and-Forward Sizing

The arithmetic that sizes the storage is the outage, not the day. If a site produces 260 GB of raw video a day and retains 30 days, the local array is roughly 8 TB before RAID overhead and spare capacity. If the uplink requirement is 1 GB of event material a day, the link only has to carry 1 GB — but the site still has to survive the link being down. A prudent buffer is the longest outage the operator will tolerate, doubled for recovery: a fortnight of queued events and a week of retained raw video is a reasonable starting posture for an unattended installation.

Two mechanisms make the mismatch manageable. Event-driven capture replaces continuous streaming — inference runs on the node, and only the frames around a detection are kept and queued. And batched uplink windows move bulk data when the constellation geometry or the LTE cell is favourable, which is a scheduler problem rather than a bandwidth problem.

Sizing the On-Site Hardware

The terminal changes the power budget more than the compute does. A LEO flat-panel terminal draws tens of watts continuously and more while transmitting, a VSAT block-up converter carries its own load, and both must keep running through exactly the outage the site is designed to survive. Off-grid sites therefore size solar and battery around the terminal's continuous draw plus the compute's duty cycle, not around a nameplate peak — the same two-number discipline that governs any industrial enclosure, applied to a load the site cannot switch off. And a satellite link has no place in a safety function: never let a trip, a shutdown or a door interlock depend on it.

Rules for a Remote Deployment

• Decide at the edge and transmit the conclusion; treat raw video as a local asset, not a network feed.
• Close every control loop locally and keep the link out of the safety path entirely.
• Specify the link on latency, metering and rain-fade margin rather than on best-case throughput.
• Size local storage for the outage window and size the link for the daily delta; they are different numbers and both are needed.
• Expect handover and fade to break sessions, and use store-and-forward and delay-tolerant patterns instead of assuming a persistent connection.
• Budget continuous power for the terminal, and remember it must keep running when the grid does not.
• Design the enclosure and mounting for the environment — wide temperature, sealing, accurate pointing and an unobstructed sky view — because a mis-pointed terminal looks exactly like a service outage.
• Meter the bytes and alert on anomalies; an unmetered link is where remote projects quietly overspend.

QSCompute supplies the compute and storage half of that architecture: fanless and wide-temperature industrial PCs, ARM gateways with dual-WAN failover, Jetson-based edge systems, and wide-temperature industrial storage sized for a store-and-forward link. Send us the site, the workload and the link you have, and we will size the node that fits behind it.