How to configure DTLS and CoAP idle timeout in nRF9160?

Question

Hi, 
 We have a working LwM2M device based on nRF9160 and NRF Connect SDK 1.1. When we run with a short register-update period (30 seconds) on a NB-IoT network it works. When we increase the register-update period to 5 minutes it times out every time and the L2M2M client reconnects the DTLS session and LwM2M session. This is not acceptable. 
 I guess there is an idle timeout on lower level, e.g. CoAP or DTLS!? I have offloaded the IP stack incl DTLS to the modem. How can I configure the DTLS idle timeout (if any)? How can I configure the CoAP idel timeout (if any)? 
 BR / Björn

Achim Kraus · Accepted Answer

In difference to one year ago, DTLS 1.2 Connection ID is published as RFC9146 . 
 I spent some time last year in implementing the feature as well for Eclipse/tinyDtls - feature branch Connection ID . And since June this year (2022), I also published a simple demonstration client for zephyr and the Thingy:91 see zephyr-coaps-client . It also considers the "RRC connection" delays (mainly happens with NB-IoT) for the DTLS and CoAP timeouts. All together very efficient and reliable. 
 It still only works, if the device initiates the communication. And it's not LwM2M, only CoAP. 
 Anyway, if you're interested in a preview of DTLS 1.2 CID, try it out.

Tiago Costa · Answer

I've have recently ran into the same issue: since the mobile network operator is implementing a timeout for UDP NAT rules, I could not extend the LwM2M register update beyond 120 seconds in my case. However, this would mean the nrf9160 would consume a significant amount of overhead data just to keep the connection alive. 
 The best solution, as far as I'm aware at the moment, is to increase the LwM2M register update period to save mobile data and periodically send UDP packets (with no payload) to the socket less than 120 seconds apart (or whatever the UDP NAT timeout period is for a given operator). This seems to be enough to keep the socket alive at the operator side and avoid the NAT timeout issue, while minimizing the overhead data usage.