The bytes that are not yours
A tracker sends a 60-byte report: position, time, speed, inputs. If it reports every 30 seconds while moving and every 5 minutes while parked, that is 1,368 reports a day. Multiplied out, 82,080 bytes a day: about 2.5 MB a month. That is the math people use to pick each device’s data plan.
The real math never comes out that way. With the same report, it can come to three and a half times that, or almost eighty times that.
The figures in the examples are illustrative: they come from the calculator with an assumed tracker sending 60 bytes per report, not from a bill or a measured network.
What travels with each report
The network does not bill your 60 bytes: it bills the IP packets that carry them. With TCP and the connection already open, one report is this:
- your 60 bytes, with 40 bytes of IP and TCP header;
- the server’s reply confirming it got them: a few bytes of its own and another 40 of header;
- the ACK the device sends to confirm that reply: 40 more bytes.
That is 209 bytes per report, counting keepalives, reconnections and 2 % retransmissions. A month comes to 8.6 MB instead of 2.5. Your data is 28.7 % of what you pay for; the headers alone, 38.2 %, and the ACKs, 19.1 %.
And that is still the cheap version.
Opening a connection costs more than the report
Some firmware opens a connection for each report, sends it and closes it. With TCP and no TLS, opening and closing costs 320 bytes: more than the report with everything above.
With TLS it is another scale. Before sending anything, the device and the server shake hands: they exchange certificates and keys, and that usually weighs 3 to 6 KB, mostly because of the size of the certificates (with a two-certificate RSA chain; with ECDSA it can be less than half, and if the device presents its own certificate, more). With a 4 KB handshake on every report:
| How it connects | Each report costs | MB a month | Your data |
|---|---|---|---|
| TCP, connection kept open | 209 bytes | 8.6 | 28.7 % |
| TLS, connection kept open | 286 bytes | 11.7 | 21.0 % |
| TLS, new connection per report | 4,653 bytes | 191.0 | 1.3 % |
Same device, same report, encrypted both ways: with a new connection per report it uses 16 times what it uses with the connection kept open. The TLS handshakes and records are 87.2 % of what gets paid for. In a fleet of 500 devices, that is 95.5 GB a month against 5.9 GB.
TLS is not the problem: you have to encrypt. The problem is paying for the full handshake 1,368 times a day.
Shrinking the report barely helps
The natural reaction to a high bill is to compress the report. With a new connection per report, going from 60 to 30 bytes saves less than 1 %: from 191.0 to 189.7 MB a month. With TCP and the connection kept open, the same cut saves about 15 %, from 8.6 to 7.3 MB. Before taking bytes out of the report, it is worth knowing how many bytes are the report.
What does change the math
- Keep the connection open. With TLS, from 191.0 to 11.7 MB a month. It costs keepalives, because the carrier’s network usually cuts connections that go a while without traffic, and it costs a new handshake every time the connection drops and reopens: with 24 reconnections a day instead of 6, it goes up to 14.1 MB.
- Resume the TLS session. If the device and the server resume the previous session instead of shaking hands from scratch, the handshake drops to a few hundred bytes. With a new connection per report and a resumed 400-byte handshake, a report costs 981 bytes: 40.3 MB a month instead of 191.0.
- Bundle reports. With the connection open and 10 reports per send, each report costs 137 bytes and the month, 5.6 MB. The cost is that, while moving, a report can arrive up to four and a half minutes late, and while parked, up to 45 minutes, and that keepalives weigh more, because the gaps between sends are longer: they become 27.4 % of the total.
- UDP. No connection, no TCP ACKs: 122 bytes per report and 5.0 MB a month. But those 5.0 MB are unencrypted, and UDP does not guarantee the report arrives: confirmation and resend have to go into your protocol. Encrypted with DTLS, each datagram adds about 37 bytes, and the handshake comes on top.
None of these is free. Each one trades bytes for something else: latency, complexity, guarantees. What does not make sense is choosing without seeing the math.
What the math does not see
The calculator adds up IP bytes with option-free headers, and assumes the clean case. A real network has more: TCP timestamps add 12 bytes to every packet, IPv6 adds 20, a server that is slow to reply sends its ACK separately, noticing that a connection is already dead costs retransmissions, application heartbeats weigh more than a TCP keepalive, DNS lookups cost their share, and the commands and updates the server sends are not counted. And there is something that can weigh more than all of that: some carriers round each data session up to a minimum. With many reconnections, what is billed can end up well above what was transmitted.
The way to know is to measure: a test device with a traffic capture on the server side, compared with what the carrier reports for that line over the same period.
To run the math with your own numbers, there is the cellular data calculator: it runs in the browser and shows where every byte goes, over UDP, TCP or TLS, with the connection kept open or new on every send.
Israel Negrete Lepe is an electronics engineer. Twenty-five years making different systems work together under real conditions: from the sensor, the vehicle or the transaction to the backend, the data, security and operations. Today, increasingly, edge AI.