How much bandwidth does a remote site need? Enough committed capacity to carry operational traffic at peak concurrency, with a separate burst allowance for everything else. Most manned industrial sites we size land between 1 Mbps and 25 Mbps committed. Unmanned assets sit far below that, often under half a megabit.
What moves that number is how many people and machines are active at the same moment, a count that on most sites sits well below the headcount on the manifest. At shift change on a rig, a 4 Mbps link with a real committed rate and sensible shaping will usually hold up where a 20 Mbps best effort link struggles. Remote site bandwidth sizing goes wrong in two familiar ways: a large number bought because large feels safe, or a cheap shared plan whose shape suits a different kind of traffic. The method below works from the applications upward to a figure you can hand to a provider.
How do you calculate bandwidth for a remote site?
Work through it in this order. Starting with a number and working backwards is how most quote requests arrive, and what comes back is a price with no design behind it.
- Build a traffic inventory by application. List every application that will cross the link, name who uses it, and note whether it runs constantly or in bursts.
- Split operational traffic from welfare traffic. Operational is what the site exists to do: telemetry, ERP, email, calls with head office, camera feeds. Welfare is crew and camp internet, and it needs its own service class and queue.
- Work out concurrency. Of 80 people on site, how many are on a video call at 09:00 local time? Usually three or four.
- Decide which end of the day you are counting. A monthly average from an existing link has to be multiplied up: on a manned site the busy hour typically lands two and a half to three times the daily average. A count of concurrent sessions already describes the peak, so that total takes a discount, because the sessions never all top out together.
- Set the committed information rate (CIR). This is the floor your operational traffic must never drop below, and the contract should name it as a figure in Mbps.
- Set the burst separately. Burst absorbs the patching window and whatever the camp is streaming after dinner.
VSAT capacity planning lives or dies on that inventory, and it is the step people skip. The list does not have to be elaborate. Twenty minutes with a spreadsheet and the site network diagram usually surfaces applications nobody had counted: a cloud backup, or a camera added for a contractor. Where the list keeps growing, our satellite network design and professional services team does the same job with measurement behind it.
What does each application actually use?
These are the figures we start from. They come off live sites, so treat them as typical ranges, and the voice and video rows already count header overhead. Codec choice and camera settings move them. Satellite bandwidth per user depends on which applications that user touches, so the table goes by application.
| Application | Typical rate per session | Direction | Most sensitive to |
|---|---|---|---|
| SCADA or telemetry polling | 5 to 50 kbps | Mostly upstream | Packet loss and latency |
| Voice call, compressed codec | 30 to 100 kbps | Symmetric | Jitter |
| Video call, standard definition | 400 to 700 kbps | Symmetric | Jitter and loss |
| Video call, 1080p | 1.5 to 3 Mbps | Symmetric | Throughput and jitter |
| Remote desktop or thin client | 150 kbps to 1.5 Mbps | Asymmetric | Latency |
| Email and ERP sync | 50 to 300 kbps per user, bursty | Mixed | Very little |
| CCTV offload, one 1080p stream | 2 to 4 Mbps continuous | Upstream | Throughput |
| Operating system patching | 200 MB to 6 GB per device | Downstream | Nothing, if scheduled |
| Crew streaming, one HD session | 3 to 5 Mbps | Downstream | Throughput |
Patching is the thing that quietly breaks the link
Forty laptops pulling a 1.5 GB cumulative update is 60 GB of traffic, roughly thirteen hours of a fully saturated 10 Mbps service, and it arrives unannounced on a Tuesday evening while the night shift is filing a report. Antivirus definitions do the same weekly on a smaller scale.
Buying more capacity does fix this, and it costs more every month than any of the alternatives. A local caching server at the site will serve most of those 60 GB once. Add a scheduled window between 01:00 and 05:00 and a hard rate limit on the update class, and the traffic takes only what nothing else wants. Shaping policy of this kind is set up alongside the routing on an SD WAN and traffic shaping over satellite deployment.
Latency, throughput and jitter are three separate problems
Throughput is how much you can move per second. Latency measures the round trip for a single packet, and jitter is the variation in that round trip from one packet to the next. Extra throughput helps those two only on a link busy enough for packets to sit in a queue.
A geostationary link carries a round trip of roughly 550 to 650 ms, most of it propagation to the satellite and back, with modem and network processing making up the rest. Medium orbit constellations typically land between about 130 and 180 ms, and low orbit services usually run 30 to 70 ms, depending on the constellation and how loaded the cell is. No amount of Mbps shortens the propagation delay. If the ERP screen takes four seconds to redraw on a quiet link, the problem is latency and application chattiness, and the answers are a protocol accelerator or a move to low latency LEO and MEO capacity. Adding Mbps to a latency complaint is a common and expensive misdiagnosis.
Voice and video care about jitter above all else, while telemetry and control traffic are more sensitive to loss. Bulk transfers sit happily at 600 ms of delay as long as throughput holds. Satellite latency and jitter therefore need their own line on the monitoring dashboard, reported separately from utilisation, because that is the pair a voice complaint gets checked against.
What does a 20 to 1 contention ratio really deliver?
A satellite contention ratio is sold as though it were a quality rating. Underneath it is a division sum. Buy 10 Mbps on a 20 to 1 shared pool, divide the headline rate by the ratio, and you get 500 kbps, which is the share the pool can sustain if every site pulls at once. Whether that 500 kbps is guaranteed to you depends on the contract, because plenty of shared plans quote a ratio and do not commit to a floor at all.
At 03:00 on a Sunday you will very likely see the full 10 Mbps. In the busy hour the floor is whatever the contract says, and on a well managed beam a site might still see 2 to 3 Mbps.
Two questions settle it. What is the CIR in Mbps, and what is the measured busy hour throughput on that beam over the last ninety days? A vague answer to the second is itself an answer. Beam performance varies by region, so read the satellite coverage maps and beam footprints for the country you operate in. Where a site cannot tolerate that variability, a dedicated SCPC satellite link removes contention from the space segment, leaving the teleport backhaul and internet breakout to size, at a higher monthly cost.
Committed rate by site type: four common profiles
The committed rate below covers operational traffic only. Welfare is listed separately because it should be shaped separately, and the figures are ranges, since the CIR versus burst split shifts with how much of the work is cloud hosted.
| Site profile | People on site | Committed rate | Welfare allocation | Burst ceiling |
|---|---|---|---|---|
| Unmanned wellhead, pump station or repeater | 0 to 2 visiting | 128 to 256 kbps | None | 1 to 2 Mbps |
| Exploration camp or survey team | 10 to 15 | 1 to 3 Mbps | 3 to 5 Mbps shaped | 10 Mbps |
| Offshore vessel or drilling unit | 60 to 120 | 5 to 8 Mbps | 10 to 15 Mbps shaped | 30 to 50 Mbps |
| Producing mine or regional field office | 200 to 400 | 15 to 25 Mbps | 40 to 60 Mbps shaped | 100 to 150 Mbps |
Unmanned sites tend to attract far more capacity than they ever use. A pad with two pressure transmitters and a flow computer runs happily on a reliable 256 kbps, which is what a small IoT and OT satellite connectivity service is built to deliver.
At the other end of the table, a producing site with 300 people tends to be undersized within a year of go live, because camera counts and cloud application use only ever climb. Sizing for remote mining operations has to assume that growth, and the burst ceiling column is where the assumption lives. The same applies on energy and oil and gas sites.
A worked example, from application list to committed rate
Take an offshore construction vessel, ninety people on board, twenty two of them in operational roles. The list below counts concurrent sessions in the busy hour, so the peak ratio in step 4 has nothing to multiply. The total takes a discount on the way through, because these six items never reach their ceiling in the same second.
- Machinery telemetry and vessel monitoring, continuous: 120 kbps
- Six concurrent voice calls at 90 kbps: 540 kbps
- Two concurrent 1080p video calls with shore: 3 Mbps
- Eight concurrent remote desktop sessions at 400 kbps: 3.2 Mbps
- Email and ERP sync, 22 users at the 50 kbps bottom of the table range: 1.1 Mbps
- Two CCTV streams at the 2 Mbps bottom of the table range: 4 Mbps
Add those and you get 11.96 Mbps for the moment when everything runs at once. Discount by 0.7 for the fact that it never quite does and the working figure is 8.37 Mbps, so call it 8 Mbps of committed capacity for the operational class, with the burst pool covering the rare alignment.
Two rows are worth pausing on. Budget the email line at 600 kbps, which is 27 kbps a user and under the table floor, and half a megabit leaves the raw total, 0.35 Mbps after the discount. Put the two CCTV streams at 1.5 Mbps between them and another 2.5 Mbps goes. Neither slip looks dramatic written down, yet together they take the working figure from 8.37 Mbps to 6.27 Mbps, and that is the gap people feel at 08:00 when everybody opens their mail client. Maritime and offshore vessel connectivity is unforgiving about that kind of rounding.
Crew welfare is a separate sum. Ninety people with evening concurrency around 25 percent gives 23 sessions at an effective 500 kbps each, so 11.5 Mbps, which becomes a 12 Mbps shaped ceiling with fair queuing and a daily volume quota. Above both sits a 40 Mbps burst ceiling for patch windows and survey transfers. The order is therefore 8 Mbps committed, 12 Mbps shaped welfare and 40 Mbps burst, which gives a provider three separate things to price. A shared Ka band service carries that burst ceiling for very little. On a dedicated carrier it costs a great deal, which is where a hybrid satellite design starts to make financial sense.
How do you validate the sizing after go live?
Everything above is a hypothesis until the link carries real traffic. The first ninety days will tell you whether the inventory was honest.
- Take a baseline in week one, before users settle into habits.
- Report the 95th percentile of the busy hour, since monthly averages hide almost every problem worth knowing about.
- Watch committed rate breaches and router queue depth alongside utilisation. A link at 60 percent utilisation with a full priority queue is in trouble, and the utilisation figure will not show it.
- Measure latency and jitter continuously against a fixed target, so a satellite problem can be told apart from an application problem.
- Pull the top talkers list weekly for the first month. It is usually a cloud backup that someone enabled without telling anyone.
- Resize whenever headcount, camera count or a cloud application rollout changes, and treat the renewal date as a deadline for the review, never the trigger.
A workable rule of thumb: if the 95th percentile sits above 80 percent of the committed rate for more than about two hours a day, the site is undersized, and if it never crosses 35 percent the contract should be reshaped at the next review. That feedback loop is where remote site network design actually happens. Our 24/7 NOC and support team reports these figures monthly, and the review is often where a customer finds their first saving.
What to do next
Write the traffic inventory before asking anyone for a price. It gives you a way to read the proposals that come back and something specific to ask about committed rate and queue policy. Send us the inventory and the site profile and we will size it against real beam performance. Talk to our engineering team and bring the application list.
