Case study
VSAT hub station and remote terminal operations
Remote terminals commissioned once and then expected to run unattended, on a path with permanent latency, scarce space segment, weather in the topology and no second route to fail over to.
Configuration validated before a terminal shipped, monitoring installed before handover, anything adjustable made adjustable from the hub, link budgets built with margin, and bandwidth allocated across remotes competing for one carrier.
Sites that ran unattended between planned visits, faults worked from the hub instead of by sending somebody, and hybrid designs where the backup path has actually carried production traffic.
Six years of hub station operations: administering and configuring a VSAT hub and the remote terminals working through it, where the nearest engineer to a failed site can be a day away and there is no alternate path.
The problem
Remote sites are commissioned once and then expected to run unattended. That single fact sets the price of every mistake: a fault that cannot be diagnosed from the hub is a site down for a day and a journey, not a switch port bounced in ten seconds. The path itself makes that harder in four specific ways.
- Latency is permanent. Protocols that assume a terrestrial round trip behave badly. Acceleration, window sizing and application choice matter more than raw bandwidth.
- The weather is part of the topology. Rain fade is a design input, not an incident. Link budgets are built with margin, and degradation is expected and planned for rather than treated as a fault.
- Bandwidth is genuinely scarce. Space segment costs real money, so traffic shaping and prioritisation are not optional refinements.
- There is no second path. Which means observability has to be good enough to diagnose remotely, first time.
What I did
Day to day, hub operations meant carrier and bandwidth management across remotes competing for the same space segment, commissioning and configuring new remote terminals, monitoring link quality continuously rather than on complaint, and resolving faults where the diagnostic loop is measured in hundreds of milliseconds.
The judgement calls were all about where the work happens, because at the far end of a satellite link everything is expensive.
- Configuration validated before a terminal shipped, since a mistake found at the remote costs a day rather than a minute.
- Monitoring installed before a site was handed over, not after the first complaint about it.
- Anything that might need adjusting later made adjustable from the hub.
- Carrier and bandwidth allocation managed deliberately, so no remote could quietly spend the segment the others were relying on.
- Link budgets built with margin, so weather that was expected leaves a link degraded rather than down.
The result
Remote terminals that ran unattended between planned visits, faults worked from the hub rather than by sending somebody to look at them, and bad weather that arrived as expected degradation rather than as an incident.
Every habit worth having in terrestrial networking is enforced by satellite. You document because you cannot walk over and look. You monitor thoroughly because a phone call is a poor first alert. You design conservatively because the cost of being wrong is a site down for a day rather than a switch port bounced in ten seconds.
Hybrid designs — terrestrial primary with satellite backup — are where this is most useful to a client, because the failover has to be believable. A backup path that has never carried production traffic is not a backup path.