Celluar Data - costs - Data Rate estimation

I’d like to understand cellular data costs…

#1 - given a purely idle device, no activity - how many bytes per month are required as ‘background noise’ and keep alive messages - heart beats etc…

#2 - Assume that my payload is about 500 bytes, with about 1500 transfers per month (roughly every 30 minutes)

#3 - I am not sure, but I believe data is sent over a TLS tunnel (aka: ssl) Is that true? (If not what is used)

I’ve read - on average, a TLS connection requires about 6.5K bytes per handshake.

Is this size roughly true for Particle’s serivice? Or is security done differently, if so how.

As an example, AWS - uses MQTT - but it it is tunnel through TLS… which
Azure uses TLS also
And IBM Watson - also

Sure you can use MQTT “payload encryption” but if it is tunneled through SSL it is the same thing.

Thus my hunch is Particle uses TLS also in the same basic way.

Thus all providers have the same basic TLS overhead.

#4 - at (500 Bytes + 6.5K) = 7K per transaction * 1500 per month, is about 10MEG per month in cellular data, or 7MEG over the free amount, is that true?

#5 - At scale (say thousands) - how does this taper off?

#1 - given a purely idle device, no activity - how many bytes per month are required as ‘background noise’ and keep alive messages - heart beats etc…

The keep-alive ping is 122 bytes every 23 minutes. Depending on what sleep more you're in there could be some reconnection overhead.

#2 - Assume that my payload is about 500 bytes, with about 1500 transfers per month (roughly every 30 minutes)

500 bytes is a good number because it fits within a Particle.publish limit of 622 bytes, which then enables...

#3 - I am not sure, but I believe data is sent over a TLS tunnel (aka: ssl) Is that true? (If not what is used)

The cloud connection is CoAP over DTLS. One of the advantage of this is that the reconnection overhead is really low, allowing the session to be resumed for under 200 bytes vs. 5-7 Kbytes for a full TLS handshake.

In general we recommend this model and transporting the data off to an external service by webhooks or SSE (server-sent-events) that way the data-intensive TLS handshake occurs on the Internet, not over cellular.

2 Likes

So - in 24 hours I’m going to pay

At least once per day…

DTLS session setup - is about 3K to 4K if I remember…
And generally requires a shared key
(I’m familiar with OpenThread)

Total 4K:

ping: 122 bytes
Pings per day 63

Total: 7K

Data 512 bytes
Data - 48 times per day

Total: 24K

So per day - (4K+7K+24K) = 35K, say 37K with a margin.

31 days per month, roughly 1.1Mbyte per month, give or take

Plus/Minus = about 90K - depending on how many times the DTLS session is restarted

these numbers seem real to you?

According to Particle’s Cellular Data Guide:

  • The 122 byte keep-alives (every 23 minutes) are only needed if no other communication has taken place. So if you send data updates at least every 23 minutes instead of every 30, you can factor those out. But, by my quick calculations, that only saves you about 150-ish bytes/day?
  • The network handshakes (powering up, reset, wake from non-standby sleep, at least once per week), can use “up to 6K”.

You’ve figured in a network handshake every day, which hopefully would not be the case. So instead of about 124Kb in handshakes per month, you’re probably only looking at about 24Kb. Maybe 30-40K if you want to be more realistic and assume you’ll have a couple of glitches here and there.

These don’t change your overall figures by a lot, but there you go.