2

I have an embedded project that is transferring data from the device to my server over a TLS cellular connection. The device needs to communicate with the server only when the sensor captures some data. The data capture events vary in frequency from device to device. Higher frequency devices will peak around a few captures in a minute. Less frequent devices may go weeks between captures.

I know that there is more overhead associated with establishing a TLS connection than with resuming an existing connection. However, most of the documentation I've seen focuses on reducing latency. For my project, I am not concerned with latency, but I am very interested in minimizing total data usage, as I am billed for each byte transferred.

Are there standards or best practices in place for TLS IoT cellular communication to minimize total data usage?

Chris Fernandez
  • 121
  • 3

2 Answers2

3

Since latency is not an issue, how I would handle this scenario is by having a small intermediate flash where I dump the samples periodically and then when the the samples reach a particular size, send it to the server. And before sending you could also make use of some compression techniques which could make the data size smaller. Hope it helps.

Subbu
  • 441
  • 2
  • 3
1

A regular TLS connection does indeed have a lot of overhead at establishment time, as certificates, keys and quite a lot more data are exchanged. If you're sending a few bytes during your connection, this can easily translate to several kilobytes of actual data. There's also a bit of overhead for regular data, but you can't do much about that (other than making sure you send all the data you can in a single packet rather than in several).

One solution is to keep the TLS connection established, though depending on your chip and stack this may have implications on sleep modes (you need to keep state) and on how often you need to wake up (for the connection to stay alive), which would have an impact on battery life, if that is a consideration for you. It's then a matter of finding the right compromise for the keep alive intervals at various levels. Note that some cellular networks, using CGNAT, may time out your connection quite quickly if you don't have any traffic on it — or even if you do.

Another option is to use resumed TLS handshakes where a session ID is kept across connections to reduce the amount of data exchanged. It will not save as much data as keeping the connection established, but it should be a lot better than establishing a full connection each time.

Again, support may depend on your chip and stack. Not sure if there are limitations server-side on this, nor if this requires any explicit configuration.

TLS 1.3 introduces a few features that may help as well, so make sure both your client and server support it.

jcaron
  • 2,408
  • 5
  • 10