There's a particular kind of problem that only exists when you're far from land. Your VSAT terminal drops lock during a rain fade. The backup Iridium link is saturated by a crew member streaming video in their cabin. The ECDIS needs a chart update, the engine telemetry platform is throwing alerts it can't upload, and the bridge is trying to make a VoIP call to the port agent. Everything is fighting for bandwidth on a connection that costs more per megabyte than most people spend on their monthly mobile plan.
This is the operational reality of maritime and remote-site connectivity. It's a fundamentally different engineering problem from terrestrial networking, and it punishes assumptions that work perfectly well on land. The physics are different. The economics are different. The failure modes are different. And the consequences of getting it wrong are measured in safety incidents and operational shutdowns, not just help desk tickets.
VSAT: the workhorse you love to hate
Geostationary VSAT has been the backbone of maritime communications for decades. A Ku-band or C-band antenna tracking a satellite 35,786 kilometers above the equator, delivering anywhere from 2 Mbps to 50 Mbps depending on how much you're willing to spend and which ocean you're sailing across.
VSAT works. It works in the middle of the Pacific. It works in the Arabian Sea. It works during a North Atlantic crossing in February, although "works" needs an asterisk during heavy precipitation. The coverage is genuinely global for the major constellations (Intelsat, SES, Eutelsat, Telesat) and the technology is mature. Stabilized antenna platforms from Intellian, Cobham, and others have gotten remarkably good at maintaining lock on a geostationary bird while the vessel rolls through 15-degree swells.
The problems with VSAT are well-documented but worth restating because they define the constraints every maritime network design has to work within.
Latency. A GEO satellite at 35,786 km altitude means roughly 600 milliseconds round-trip time. That's physics. The speed of light through 143,000 km of space (up, down, up, down). You can optimize the TCP stack, use acceleration appliances, and deploy protocol-specific workarounds, but you cannot make the signal travel faster. VoIP over 600ms of latency is technically possible and practically miserable. Video conferencing ranges from awkward to unusable depending on the codec and how much both parties are willing to tolerate talking over each other.
Cost. Maritime VSAT pricing has dropped significantly over the past decade, but "significantly cheaper than it used to be" still means expensive by any terrestrial standard. Committed information rates, contention ratios, fair-use throttles, and overage charges create a cost structure that requires active management. Leave a Windows Update running unthrottled over a maritime VSAT link and you'll feel it in the next invoice.
Weather sensitivity. Ku-band VSAT is susceptible to rain fade. Signal attenuation caused by precipitation in the path between the antenna and the satellite. C-band is more resilient to weather but requires a larger antenna, which isn't always practical on smaller vessels. Rain fade events are typically short-lived, but "short-lived" is cold comfort when it happens during a critical VoIP call with a client or a port authority.
Antenna maintenance. A stabilized VSAT antenna is a mechanical system exposed to one of the harshest environments on earth. Salt spray, UV exposure, constant vibration, and temperature extremes all take their toll. The radome cracks. The feed horn corrodes. The motors wear. And every maintenance event requires either a port call to a location with a qualified technician or flying someone to the vessel. Neither of which happens quickly or cheaply.
The LEO revolution: real progress, different trade-offs
Starlink Maritime changed the conversation. A flat-panel phased-array antenna, dramatically lower latency (typically 25-60ms), and throughput that frequently exceeds 100 Mbps on download. For crew welfare and general internet usage, it's a genuine step change. Seafarers who spent years rationing email access can suddenly video-call their families. That alone justifies the technology.
OneWeb, now part of Eutelsat, offers a competing LEO constellation with a different architecture. Fewer satellites at a higher orbit (1,200 km vs. Starlink's 550 km), using parabolic antennas rather than phased arrays, and targeting enterprise and government customers with managed-service SLAs rather than consumer-grade best-effort.
But LEO isn't a simple replacement for GEO VSAT, and treating it as one leads to design decisions you'll regret.
Reliability characteristics are different. A GEO VSAT link tracks a single stationary satellite. Barring rain fade or equipment failure, the link is persistent. A LEO constellation requires constant handoffs between satellites as they pass overhead at orbital velocity. Each handoff is a potential micro-interruption. The phased-array antenna has to electronically steer between satellites every few minutes. In dense constellation coverage, this works seamlessly most of the time. In sparse coverage areas (high latitudes, certain ocean regions) handoff gaps can last seconds or longer. For web browsing, that's imperceptible. For a live telemetry stream or a VoIP call, it's a dropped connection.
Regulatory fragmentation. Starlink Maritime operates under different regulatory authorizations in different waters. Flag state licensing, coastal state restrictions, and ITU coordination requirements create a patchwork of coverage authorizations that doesn't align neatly with shipping routes. A vessel transiting from one regulatory zone to another may lose LEO service entirely for a portion of the voyage. The regulatory situation is evolving, but it's far from resolved.
Service level commitments. Most LEO maritime services are currently best-effort. That's fine for crew welfare. It's not fine for safety communications, operational telemetry, or any application where you need a guaranteed minimum bandwidth. The enterprise-grade LEO services with committed bandwidth and SLAs exist (OneWeb/Eutelsat's maritime offering, for example), but they come at a price point that makes the comparison with VSAT less dramatic than the headline numbers suggest.
Hybrid architectures: the only honest answer
The correct architecture for most maritime and remote operations is not VSAT or LEO. It's VSAT and LEO and, where available, cellular. Managed as a unified system with intelligent traffic steering.
A well-designed hybrid maritime WAN looks something like this:
Primary path: LEO (Starlink or OneWeb) for general internet traffic, crew welfare, and latency-sensitive applications like VoIP and video. The low latency and high throughput make it the best option for the majority of traffic by volume.
Secondary path: Ku-band or C-band VSAT as a guaranteed-bandwidth fallback. Safety communications, critical operational data, and any traffic with SLA requirements route over VSAT. When the LEO link degrades or enters a coverage gap, VSAT absorbs the overflow for priority traffic.
Tertiary path: L-band (Iridium or Inmarsat) for absolute last-resort connectivity. Low bandwidth, high cost, but globally available and highly resilient. This carries GMDSS safety traffic and minimum operational communications when everything else fails.
Opportunistic path: 4G/5G cellular via a multi-SIM router for near-shore and port operations. When a vessel is within 20-30 nautical miles of land (varies by terrain and cell tower placement), cellular often provides the best performance of all available options. Software updates, large data transfers, and bandwidth-heavy operations should be scheduled for these windows.
The intelligence layer (the thing that makes this a system rather than four separate connections) is the SD-WAN or WAN optimization platform that manages path selection, traffic prioritization, and failover. We'll get to where SD-WAN falls short in a moment, but the concept is sound: classify traffic by application, assign it to the appropriate path based on real-time link quality, and fail over automatically when conditions change.
The vessel network: harder than it looks
Maritime connectivity discussions tend to focus on the satellite link, as if getting bandwidth to the vessel is the whole problem. It's half the problem. The other half is what happens to that bandwidth once it's on board.
Segmentation is not optional. A vessel network needs to separate, at minimum, three distinct traffic domains: safety and navigation systems (ECDIS, AIS, GMDSS), operational systems (engine telemetry, cargo monitoring, fleet management), and crew welfare (personal internet, entertainment, communications). These domains should be on separate VLANs with firewall rules between them. A compromised crew device should never be able to reach the navigation systems. This isn't theoretical paranoia. IMO resolution MSC.428(98) on maritime cyber risk management makes this an explicit requirement, and classification societies are increasingly auditing for it.
Bandwidth allocation requires a heavy hand. On a vessel with 25 crew members sharing a 20 Mbps LEO link, one person streaming Netflix in 4K will consume the entire connection. Fair-use policies, per-user rate limiting, application-level traffic shaping, and time-based access controls are all necessary. Crew members need to understand the policies, and the policies need to be enforced technically, not just by memo. The best systems we've seen provide crew with a transparent dashboard showing their usage, their remaining allocation, and current link status. Transparency reduces complaints more effectively than policing.
VoIP over satellite is a special kind of terrible. Without optimization, VoIP over VSAT sounds like two people shouting across a canyon with a half-second delay. The conversation degrades into both parties talking simultaneously, then both going silent, then both starting again. It's technically a working call and practically useless. Proper optimization involves: dedicated bandwidth allocation for voice traffic with strict QoS (DSCP EF marking, priority queuing), a SIP-aware session border controller that handles the latency compensation, jitter buffers tuned for satellite (150-200ms minimum, not the 60ms that works on terrestrial links), and (critically) moving voice traffic to the LEO path whenever it's available. VoIP over a 40ms LEO link is a completely different experience from VoIP over 600ms GEO. This single application is often the strongest practical argument for hybrid VSAT+LEO architectures.
Video surveillance backhaul is a bandwidth trap. A modern vessel might have 30-40 IP cameras for security, safety, and operational monitoring. Locally, they stream to an NVR at full resolution (4-8 Mbps per camera, H.265 encoded. Trying to backhaul all of that to shore over satellite would consume your entire connection and then some. The solution is selective backhaul: low-resolution streams or motion-triggered clips for shore-side monitoring, with full-resolution footage stored locally and transferred in bulk during port calls or periods of high-bandwidth connectivity. Event-driven alerts) man overboard, unauthorized access, fire detection (get immediate priority transmission at whatever resolution the link supports.
)Remote sites: the same physics, different scenery
Offshore oil and gas platforms, remote mining operations, construction sites in undeveloped regions, scientific research stations. These environments share the fundamental challenge of maritime connectivity without the added complication of constant movement. The satellite footprint doesn't shift, but everything else applies: expensive bandwidth, limited maintenance access, harsh environmental conditions, and networks that need to work without a specialist on site.
Remote mining operations add their own wrinkles. The site evolves constantly as extraction progresses. What was the pit floor last month is now a haul road, and the Wi-Fi access point that was covering the loading area is now behind a 40-meter rock face. Mesh networks with relocatable nodes, hardened for dust and vibration, become essential. Fixed infrastructure gets buried, run over, or blasted. Anything at the edge of the network needs to be treated as expendable and replaceable without specialized skills.
Oil and gas platforms have the most demanding requirements: safety-critical systems that cannot share bandwidth with general traffic, regulatory mandates for specific communication capabilities, and operational technology (OT) networks running SCADA and DCS systems that are allergic to latency and extremely sensitive to unauthorized access. The IT/OT convergence that's challenging enough on land becomes genuinely dangerous when the network connecting a gas detection system to a shutdown controller is sharing infrastructure with the accommodation block's Wi-Fi.
IoT and telemetry from remote sites present an interesting bandwidth optimization problem. Individual sensor readings are tiny (a few bytes each. But a modern mining operation or oil platform has thousands of sensors reporting temperature, pressure, vibration, flow rates, equipment status, and environmental conditions. The aggregate telemetry stream is modest (typically a few hundred kilobits per second), but it needs to be persistent and reliable. MQTT over a satellite link with store-and-forward capability for outages is the standard pattern. The telemetry data needs to get through even when crew welfare bandwidth is throttled or the primary link is degraded. A queuing architecture that accumulates readings during outages and bursts them when connectivity returns is essential) but the timestamps have to be preserved, because a pressure reading from 30 minutes ago means something very different from one taken right now.
Remote manageability: the non-negotiable requirement
You can't send an engineer to a vessel that's in the middle of a 14-day Atlantic crossing. You can't helicopter a technician to an offshore platform during a storm. You can't drive to a mining site that's a day's journey from the nearest town with an airport.
Every piece of network equipment deployed in a maritime or remote environment needs to be remotely manageable. That means: out-of-band management access that doesn't depend on the primary network path, remote firmware updates with rollback capability, automated monitoring with alerting (not just SNMP traps that nobody's watching, but genuine integration with a 24/7 NOC), and configuration management that allows changes to be staged, tested, and deployed without physical access.
The network also needs to be self-healing where possible. Automatic failover between WAN links should not require human intervention. If the LEO terminal reboots, the traffic should shift to VSAT without anyone pressing a button. If a switch in the engine room fails, the spanning tree should reconverge without someone climbing down three decks to the equipment closet. Zero-touch provisioning for replacement equipment is ideal. If a crew member has to swap a failed access point, the replacement should pull its configuration automatically once connected.
Most critically, the network needs to be buildable and maintainable by people who aren't network engineers. On a vessel, the IT-literate person might be the second officer. On a remote site, it might be an electrician who's been given "the IT stuff" as an additional responsibility. The design has to account for this. Port labeling has to be idiot-proof. Documentation has to live on the network itself, not in a SharePoint site that requires the network to work in order to access it. Procedures need to be step-by-step with photographs, not assumptions about CLI proficiency.
SD-WAN in maritime: useful but limited
SD-WAN vendors have started marketing maritime solutions, and the core concept is sound: abstract the WAN transport, apply policy-based traffic steering, centralize management. On land, where you have multiple broadband connections with similar characteristics, SD-WAN works well. At sea, the transport options have wildly different characteristics (40ms LEO vs. 600ms GEO vs. 3,000ms L-band, with bandwidth ranging from 200 Mbps to 0.5 Mbps) and most SD-WAN platforms weren't designed for that spread.
The specific limitations we encounter repeatedly:
- Probe-based link quality assessment fails over satellite. SD-WAN platforms typically send periodic probes to measure latency, jitter, and packet loss. Over a GEO link, the probe results show 600ms latency, and the platform marks the link as degraded or unusable compared to the LEO path. But 600ms is normal for VSAT. The link is working perfectly. The thresholds need to be tuned specifically for satellite transport, and most out-of-the-box configurations aren't designed for it.
- TCP optimization conflicts. Many SD-WAN platforms include built-in TCP acceleration. Maritime deployments typically also run dedicated WAN optimization appliances (Riverbed, Silver Peak/Aruba, Hughes) that do their own TCP acceleration. Running both simultaneously creates protocol conflicts, double-encoding, and performance that's worse than either solution alone. You need to decide which layer handles optimization and disable it on the other.
- Bandwidth-aware application steering is coarse. An application classified as "video conferencing" gets the same treatment whether it's a critical management call or a crew member on a personal video chat. Maritime environments need more granular classification. By source VLAN, user group, and time of day, not just application signature.
SD-WAN is a useful component of a maritime network architecture. It's not a sufficient one. The platform needs significant customization for maritime transport characteristics, and it needs to be layered with dedicated WAN optimization, bandwidth management, and content filtering that understands the specific constraints of satellite connectivity.
Regulatory requirements: the invisible constraint
Maritime communications aren't just an operational consideration. They're a regulatory one. The International Maritime Organization (IMO), through SOLAS Chapter IV, mandates specific communication capabilities for vessels based on the sea areas they operate in. GMDSS (Global Maritime Distress and Safety System) requirements dictate that certain communication channels must be available at all times, independent of commercial connectivity. This isn't optional and it isn't negotiable.
Beyond GMDSS, flag state regulations impose additional requirements. Cybersecurity guidelines from IMO resolution MSC.428(98) require ship operators to incorporate cyber risk management into their safety management systems. Classification societies (Lloyd's, DNV, Bureau Veritas, ClassNK) publish their own cyber security notation requirements that increasingly include network architecture standards, segmentation requirements, and access control specifications.
For remote oil and gas installations, the regulatory framework is equally demanding. HSE requirements mandate specific communication capabilities for emergency response. Environmental monitoring data may need to be transmitted in near-real-time to regulatory bodies. And in many jurisdictions, SCADA and safety-instrumented systems have prescriptive network isolation requirements that override any desire for convergence or cost optimization.
The network designer ignores these requirements at the operator's peril. And the requirements need to be understood at design time, not discovered during a flag state inspection or classification society audit.
Getting it right
Maritime and remote-site network design rewards thorough requirements gathering and punishes shortcuts. The stakes are higher, the constraints are tighter, the economics are harsher, and the recovery time from a bad design decision is measured in weeks or months, not hours.
The organizations that do this well share a few characteristics. They treat connectivity as critical infrastructure, not an IT amenity. They invest in proper hybrid architectures rather than betting on a single technology. They segment ruthlessly. They design for remote management from day one. They plan bandwidth budgets the way they plan fuel budgets. With allocation, monitoring, and consequences for waste. And they test their failover scenarios before they're in a situation where the failover actually needs to work.
The technology keeps improving. LEO constellations are getting denser, VSAT terminals are getting smarter, and bandwidth costs are falling. But the fundamental challenge remains: you're trying to build reliable, secure, manageable networks in places that are designed by nature to destroy equipment and defeat connectivity. That requires engineering discipline, not just equipment spend.