Every remote site that sends readings over a cellular modem sits on a data plan, and for telemetry that plan looks nothing like the phone plan in your pocket. Machine-to-machine plans are built around tiny, frequent transfers rather than video and browsing, so they are usually pooled across a whole fleet of SIMs and measured in kilobytes rather than gigabytes. This guide explains how those plans are structured, how to estimate the monthly bytes a site will burn from its poll rate and payload size, why protocol overhead dominates when the payloads are small, and how reporting only on change keeps the bill under control.
Telemetry data plan in one line: A cellular telemetry data plan is the machine-to-machine (M2M) or IoT subscription that gives an RTU or gateway its cellular connectivity, typically sold as a shared pool of bytes across many low-usage SIMs with a per-device cap and overage charges past the pool. Because telemetry payloads are small and frequent, the cost driver is the total number of bytes moved per month, which you estimate from how often each site transmits and how large each message is, including protocol overhead. Reporting by exception, larger reporting intervals, and lean payloads all shrink the byte total and therefore the plan.
Consumer cellular plans assume one person moving large amounts of data, so they are priced per line in gigabytes. Telemetry is the opposite: hundreds or thousands of devices each moving a trickle. To fit that pattern, M2M providers sell pooled plans where every SIM in the account draws from one shared monthly bucket of data. A site that has a busy month can borrow headroom from quieter sites, and the operator manages a single aggregate number rather than tuning each line. This averaging is what makes fleet connectivity affordable, because the pool is sized for typical combined usage instead of the worst case on every device.
Within a pool there are usually two controls that matter for cost. The first is the pool size itself, the total bytes included before overage begins. The second is an optional per-device cap that stops any single misbehaving SIM from draining the whole pool, which protects you when a modem gets stuck in a reconnect loop or a firmware bug starts chattering. When combined usage exceeds the pool, the carrier charges overage, and overage rates are typically far higher per byte than the included allowance, so a single runaway device can turn a small pool into a large invoice.
Because telemetry SIMs are cheap individually but numerous, the practical risk is not one site being expensive, it is a systemic change that lifts every site at once, such as a firmware update that doubles the reporting rate. That is why operators watch pool consumption as a trend rather than a monthly total, and why per-device caps and alerts are worth setting even when the pool has spare room today.
The budget for a site starts with two numbers: how many bytes travel in a single report, and how many reports happen in a month. Multiply them and you have the rough application-layer traffic. If a site sends a message every five minutes, that is twelve messages an hour, roughly two hundred and eighty-eight a day, and around eight and a half thousand a month, before you count anything the network wraps around each message. Halving the reporting interval to every ten minutes roughly halves that count, which is why the interval is the single biggest lever on the bill.
The trap is that the payload you see in your protocol is not the payload the carrier meters. Every message is wrapped in transport and network headers, and on cellular there is also signalling to keep the radio connection alive. For a control system exchange of only a few dozen bytes of actual values, the headers and connection setup can be several times the size of the data itself. So a naive estimate based only on register counts will understate real usage, sometimes badly, and the smaller and more frequent your messages are, the worse the understatement gets.
A workable method is to measure rather than guess: put a device on a plan, let it run its normal schedule for a representative period, and read the actual bytes from the carrier portal, then scale that per-device figure across the fleet. Measurement captures the retransmissions, keep-alives, and reconnects that a spreadsheet ignores, and it gives you a realistic per-site number to multiply out and to compare against the pool you are paying for.
When telemetry feeds a cloud SCADA platform, the data plan becomes a running operating cost that scales with the number of sites, so the design choices that reduce bytes pay back every month. The most effective is reporting by exception: instead of transmitting every scan on a fixed clock, the field device sends a value only when it moves past a deadband or when a heartbeat timer expires. A tank level that barely changes overnight might send a handful of updates instead of hundreds, and the historian still sees the full picture because nothing meaningful was omitted. Fast sampling can stay local while transmission stays sparse.
Protocol choice and message design matter almost as much. A lean binary protocol with compact framing moves the same information in fewer bytes than a verbose text format, and batching several points into one report amortises the fixed header cost across more useful data instead of paying it per point. Where a connectionless transport is acceptable, avoiding repeated connection handshakes saves the overhead of opening and tearing down a session for each tiny exchange, which is a large fraction of the traffic when the exchange is small.
A cloud platform like Merobix helps close the loop by exposing per-site data behaviour to the people who pay for the plan. When operators can see which sites report most often and correlate that with pool consumption, they can retune deadbands and intervals on the noisy sites, catch a modem that has started chattering, and keep the fleet inside its pool. The connectivity bill stops being a fixed mystery and becomes something you can manage the same way you manage any other field asset.
It depends almost entirely on how often the site transmits and how large each message is once network overhead is added, not just on the size of the values themselves. A site reporting a small payload every few minutes commonly lands in the low megabytes per month, while a site reporting only on change can use a fraction of that. The reliable way to know is to run the device on its normal schedule and read the actual bytes from the carrier portal rather than estimating from register counts.
A pooled plan lets many low-usage SIMs share one monthly byte allowance, so busy sites can draw on the headroom left by quiet ones and the pool is sized for combined typical usage rather than the worst case on every line. Because telemetry devices each move very little data, averaging them across a pool is far cheaper than buying a per-line allowance big enough to cover each one individually. Per-device caps then stop any single runaway SIM from draining the shared pool.
Report-by-exception transmits a value only when it changes past a set deadband or when a periodic heartbeat is due, instead of sending every scan on a fixed clock. For slow-moving signals like tank levels or temperatures this can cut the number of messages dramatically, and each message avoided saves not only its payload but the network overhead wrapped around it. The historian still receives every meaningful change, so you lose resolution on flat data you did not need while keeping detail on the events that matter.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.