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?

3
  • Is your device battery powered (and thus battery efficiency is primordial) or do you have an external power source? Also, do you have full control over the server-side TLS termination? Is this your server, with no reverse proxy or load balancer or the like before it?
    – jcaron
    Commented Mar 30, 2020 at 23:52
  • How large is a single data event? And since you are not worried about latency, how could you batch updates?
    – hardillb
    Commented Mar 31, 2020 at 9:17
  • @jcaron the device is externally powered, but I am interested in adding battery power in the future. We do have control over the server, but that's another dev, not me personally Commented Apr 1, 2020 at 15:24

2 Answers 2

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.

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.

2
  • I've read that TLS sessions will expire after 300 seconds of inactivity - does this mean I need to resume the TLS session within every 300 seconds or I will need to go through the full process of creating a new session? Commented Apr 1, 2020 at 15:21
  • @ChrisFernandez This is the default session expiration value in openssl, but you can override it (though depending on what software you use at either end, this may or may not be easy). See security.stackexchange.com/questions/182618/…
    – jcaron
    Commented Apr 1, 2020 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.