Tracker Data Plan Sizing: Bytes per Report

Concept render

Monthly data is reports per month times on-wire bytes per report, plus handshake and keep-alive bytes, rounded up to the carrier billing increment. A CoAP header is a fixed 4 bytes and an MQTT PINGREQ is a 2-byte fixed header, but IP, transport and TLS sizes are not published here, so capture them on your own modem.

A location report can be a few fields long, and the data plan still charges for everything around it. The headers, the security layer, the handshake and the billing rounding each add to the payload. This guide gives a formula and a sheet layout you can rebuild in any spreadsheet. It uses only the sizes that the standards publish and marks every other input as yours to measure. It contains no Duobay price and no measured result.

It covers trackers for assets, vehicles and adults who know they carry the device. It is an engineering write-up of data sizing. It does not give legal advice.

Which sizes do the standards publish?

These are the facts we can quote, each from the specification itself. All pages were read on October 31, 2026.

What this article does not give you

These inputs matter for the total, and we have no verified number for them. Each is marked for you to measure.

How do you compute bytes per report and per month?

Start with one report on the wire, add the amortized handshake and the keep-alive traffic, then apply the billing rounding.

B_report  = P + H_app + H_net + H_sec

R         = T_month / T                     (reports per month)
S         = R / n                           (sessions per month)
K         = T_open / KA                     (keep-alive exchanges per month)

B_month   = R × B_report + S × HS + K × B_ping

billed (per session)  = S × ceil(B_session / I) × I
billed (per transfer) = R × ceil(B_report / I) × I

monthly cost = billed / 1,000,000 × price      (use the carrier's MB definition)

Units: P, H_app, H_net, H_sec, HS, B_ping, I and every B term are in bytes. T, T_month, KA and T_open are in seconds. R, S, K and n are counts. Price is in currency per MB. The amortized handshake per report is HS / n, so a longer session spreads the same handshake over more reports.

Worked example with symbols

We do not supply example byte counts for the headers, because a made-up number would look like a fact. These cases use symbols, and each result was recomputed from the formulas above.

• If B_report equals half of I and each report is billed alone, billed bytes per report are I, which is I / (I / 2) = 2 times the on-wire bytes.
• If B_report equals I / 4 and you hold four reports to send in one transfer, the transfer is I bytes before any shared overhead, so you pay I for four reports. That is I / 4 per report, the same as the on-wire size, and one quarter of what four separate transfers would cost at I each.
• If a session has HS = B_report and n = 1, the handshake doubles the bytes for that report. At n = 4 the handshake adds one quarter of a report to each report. At n = 10 it adds one tenth.

Fill the sheet below with your captured values and run it at least three ways: your planned reporting interval, a case where the interval is halved, and a case where sessions are shorter because the network drops them.

The sheet layout

Create one input cell for each variable in the table below, then one formula cell per row of the second table. Spreadsheet function names such as CEILING work in common spreadsheet programs.

Add a security-mode selector with four states: none, DTLS, DTLS with Connection ID, and TLS. Each state gets its own H_sec and HS from your capture. The selector lets you compare modes on the same payload.

What are the common cost traps?

These follow from the specifications quoted above and from the formula. They are engineering reasoning. None describes an incident at any company.

• A small payload sits inside a larger message. Every report carries the protocol header, the network and transport headers and any record overhead. CoAP alone starts with a fixed 4-byte header before token and options. When P is small, the fixed parts can be most of B_report, so a payload-only estimate understates the bill.
• A lost session repeats the handshake. RFC 9146 says a NAT rebinding leads to connection failure and the cost of a new handshake. If your device sleeps between reports and the carrier NAT forgets the mapping, each wake-up may pay HS again. The Connection ID extension is the documented answer, and you need to test that your stack and server support it.
• Keep-alive costs bytes while nothing is reported. An MQTT connection that stays open sends a PINGREQ every Keep Alive interval. The packet is 2 bytes by itself, and each exchange also carries network and security overhead and a reply. A short Keep Alive on a connection that reports rarely makes keep-alive a visible share of B_month.
• Large messages can fragment. RFC 7252 recommends that a CoAP message fit in one IP packet and gives 1152 bytes as a good upper bound. A report batch that grows past the path limit risks fragmentation, which the RFC advises avoiding. This is engineering reasoning from the RFC text.
• Record padding changes the size you counted. RFC 8446 lets endpoints pad TLS records. If your library pads, the on-wire size can exceed the payload you encoded. Take the size from a packet capture of the link.
• Billing rounding can dwarf a tiny report. When the increment I is larger than B_report and each report is billed alone, you pay I for every report. This is arithmetic on the formula above. Whether your carrier rounds this way is an input you must read from the plan terms.

What should you measure on your own board?

We have not captured traffic for your device, and this page reports no measured result. Run these on your own hardware and backend, then paste the numbers into the sheet.

Set the pass line from your product requirements and write down the reason for it before you run each test.

What should you ask before you choose a protocol and a plan?

Take this list to your firmware team, your connectivity provider and any supplier who proposes a design.

• What does the carrier plan document say about billing increments and minimum charges per session or per transfer, and on what date did we read it?
• Is the increment applied per session, per transfer or per day, and how does our firmware map reports onto those units?
• Which security mode do we ship, and have we captured its handshake on our own module?
• Does our stack and our server support the DTLS Connection ID, and what happens to a session after a NAT rebinding?
• How many reports do we send per session, and what in the firmware decides when a session ends?
• Is the connection held open between reports, and what Keep Alive interval does that need?
• What is the largest message we can send, and does any batching mode risk IP fragmentation?
• Who owns the SIM contract and the data pool, and who sees the usage records?
• Which numbers in our sheet come from a capture on our board, and which are still assumptions?
• Who is the person carrying the tracker, and have they been told that the device reports location? This page covers adult and asset tracking only.

If you want a connectivity budget checked against your tracker design, tell us about your device. You can also read about our LTE and GNSS tracker development.

Primary sources

All pages below were accessed on 2026-10-31. Specifications can be revised, so confirm on the live pages.

• IETF, RFC 7252, The Constrained Application Protocol (CoAP): https://www.rfc-editor.org/rfc/rfc7252.txt (accessed 2026-10-31)
• IETF, RFC 9146, Connection Identifier for DTLS 1.2: https://www.rfc-editor.org/rfc/rfc9146.txt (accessed 2026-10-31)
• OASIS, MQTT Version 3.1.1: https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html (accessed 2026-10-31)
• IETF, RFC 8446, TLS 1.3: https://www.rfc-editor.org/rfc/rfc8446.txt (accessed 2026-10-31)