How to configure DTLS and CoAP idle timeout in nRF9160?

[Bjorn191023]

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

[Markus Tacker (he/him)]

Have you confirmed with your network provider that they actually support the idle timeout times that you are looking to achieve?

Networks will keep the UDP NAT rules for bidirectional communication up only for a limited time and what you describe does actually look more like you are hitting these limitations.

[Tiago Costa]

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.

[Achim Kraus]

Just as outlook:

Once draft-ietf-tls-dtls-connection-id may get more adopted, many DTLS/CoAP problems caused by NATs will disappear. Using Eclipse/Californium you may have a preview of that (if you use Eclipse/Leshan its a question to configure it). The downside of today is, that this requires to use an application level client and the modem just for UDP transfer.

[Tiago Costa]

Thanks for pointing that out! I'm not sure if connection ids also apply to server-to-client interactions as I could only find examples of client-to-server session resumption.

In case connection ids should work for server-to-client interactions, after some tests, it seems that my current Mobile Network Operator NAT does not seem to support handling of connection ids, so after the NAT timeout period my nrf9160 client can no longer receive requests from the LwM2M server until the next registration update.

I believe DTLS session resumption is enabled in the nrf9160 SDK 1.4.2 that I'm currently using for testing, although I'm not entirely sure, and I have enabled connection ids in my Leshan test server.

[Achim Kraus]

Using CID "replaces the resumptions". Nothing in the middle must support it, only the clients and servers. As long, as the client starts the communication after a quiet period, the server will be able to "update the client's ip-address" and send messages back.

Only, if the server initiates the communication after the quiet period, that doesn't work. That seems to be a general issue for IP, even for TCP. Once the "route/connection" is gone, you can't reestablish it from the server, if the client has no known reachable address.

[Tiago Costa]

Thanks for clarifying. Yes, that is the issue I'm facing, as the server initiates communication after the quiet period. I've wrongly interpreted that the connection id could be implemented at the NAT infrastructure somehow and overcome this limitation. But since that's not the case and because I need my clients to be always reachable by the server at all times, I'll need to keep sending packets to prevent the NAT timeout unfortunately.

[Achim Kraus]

Yes, if that's the requirement, your device will never sleep :-).

(AFAIK, some providers offers "private network setups", where the addresses are more sticky/static. But that depends on your provider and your contracts.)