What Is Bandwidth?

Back to Blog

Bandwidth vs Latency, and Why Sites Ration It

Bandwidth is the width of the pipe - how much can flow per second - while latency is how long any one packet takes to get through. The two are independent: a link can have generous bandwidth but high latency, or low latency but little bandwidth. For SCADA, bandwidth determines how many tags, how often, and how large a payload a site can push before the link is the bottleneck.

Remote telemetry is usually bandwidth-constrained and, crucially, metered. Cellular plans bill by the megabyte and satellite data is costlier still, so a site that polls thousands of tags every second on a cellular SIM can run up a real bill. Bandwidth conservation is therefore a design goal, not an afterthought.

How Telemetry Conserves Bandwidth

The main technique is report by exception: instead of sending every tag on every scan, the RTU sends a value only when it changes beyond a deadband. A pressure holding steady generates almost no traffic; a moving value reports as it moves. This alone can cut data volume dramatically versus blind periodic polling. Protocols like DNP3 and MQTT are built around this event-driven model.

Other tactics include longer poll intervals for slow-moving process values, compact binary protocols instead of verbose ones, compression, and store-and-forward that batches buffered readings after an outage rather than reconnecting constantly. A cloud SCADA such as Merobix reads devices over efficient protocols like Modbus, DNP3, and MQTT, so an operator can tune scan rates and deadbands to fit the bandwidth and cost budget of each site.

A Worked Symbolic Data Budget

The budget is worth writing down before choosing a plan. For N tags, each report costing B bytes on the wire including protocol framing, sent every P seconds, the daily payload is roughly N x B x (86400 / P), and a month is about thirty times that, plus an overhead term O for session maintenance that exists whether or not any tag changes. Working this through for a real site, with the overhead measured rather than guessed, is the subject of estimate monthly cellular data for a SCADA site.

The algebra exposes every lever. Raise P for slow-moving values - a tank that fills over days does not need second-by-second reporting. Cut N by asking whether every diagnostic register really needs to leave the site. Shrink B by choosing a compact binary protocol over a verbose one. Or replace the periodic term entirely with an event term: with deadband-based exception reporting, a tag reports E times per day where E is driven by process activity, not by the clock, and for stable processes E is dramatically smaller than 86400 / P.

Where the Bytes Actually Go

On small-payload telemetry, the payload is often the minority of the bill. Every packet carries transport headers in both directions - and poll requests are billed traffic just like responses. Encrypted sessions add a handshake on every reconnect. Keepalives tick around the clock. Marginal links multiply everything through retransmission. The result is a floor of consumption that has nothing to do with how busy the process is, which is why two sites with identical tag lists can show very different bills.

That makes link stability a data-cost issue, not just a reliability issue: a gateway that flaps and re-establishes its session all day burns data on connection setup alone, so an antenna or signal problem shows up on the invoice before anyone notices missing data. The full toolbox - protocol choices, session tuning, and configuration hygiene - is laid out in reduce cellular data use on a SCADA gateway.

Verifying the Math Against the Meter

Three numbers should agree: the design math, the gateway's own interface counters, and the carrier portal's usage figure. When they diverge, the discrepancy is a config hunt, and the usual suspects are mundane - debug logging shipping off-site, an aggressive time-sync schedule, automatic update checks, a forgotten camera stream, or a VPN that chats constantly even when idle. The gateway counters are the referee, because they show which direction and which service the bytes belong to.

Set usage alerts at the carrier at a fraction of the plan so an anomaly surfaces mid-cycle instead of on the invoice, and treat a step-change in daily data use exactly like a step-change in a process variable: something changed, find out what and when. Sites drift - a firmware update alters keepalive behavior, someone enables verbose logging during troubleshooting and forgets it - and the meter is where the drift becomes visible.

When to Buy Bandwidth Instead of Rationing It

Conservation has a cost too - engineering hours spent shaving bytes are not free, and a configuration contorted to save data becomes fragile. When a requirement genuinely needs volume, such as high-resolution diagnostics or waveform capture around an event, the pattern is to collect at full resolution at the edge and send summaries, pulling the detailed data on demand or in scheduled batches over store-and-forward telemetry rather than streaming it continuously.

And when requirements grow structurally - more tags, faster reporting, a new data-heavy application - the right answer is often a better plan or a better link, decided with the budget math in hand. Starving a legitimate requirement produces workarounds that fail in interesting ways; the point of the data budget is knowing which side of that line a given site is on, so the money goes where the arithmetic says it should.

Frequently Asked Questions