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.

[Bjorn191023]

Hi,

I have tested another operator with LTE-M and I see the same behavior. That indicates it's not an operator problem...of course, both operators could have the same problem, but less likely.

I hope Nordic can guide me how to configure the session idle timeout.

BR / Björn

[Didrik Rokhaug]

Hi.

I'll have to talk to the R&D team to be able to answer you properly.

However, I can confirm that CONFIG_NET_SOCKETS_DTLS_TIMEOUT will not affect anything when socket offloading is enabled.

I am not able to find any references to CONFIG_NET_APP_DTLS_TIMEOUT, so I can not comment on that.

I'd also appreciate a modem trace, so that we can rule out any network related problems.

[Didrik Rokhaug]

Hi, and sorry for the long wait.

I have not gotten any answers to your questions from our developers yet.

However, you might be interested in this ticket: https://devzone.nordicsemi.com/f/nordic-q-a/58817/nrf9160-lwm2m-with-mbedtls

At the end of the last reply, I suggest a method that might let you use a non-offloaded IP stack. Note that we have not tested that, so I can not guarantee that it works.

But, if it does work, you should then be able to use the Kconfig options that you have found.

Did you get a reply from your network operator?

While they might have different timeouts, the timeouts we have seen are typical <1 minute. SO I would not dismiss the possibility that the problem is caused by the networks NAT policy.

[Bjorn191023]

Hi Didrik,

Thanks for your response.

Didrik Rokhaug said:

I have not gotten any answers to your questions from our developers yet.

Ok, let me know when you hear something. I am interested in 1) what are the default timeouts in the modem and 2) can they be changed

Didrik Rokhaug said:

At the end of the last reply, I suggest a method that might let you use a non-offloaded IP stack. Note that we have not tested that, so I can not guarantee that it works.

Sorry, this is not an option for us. We dont have enough flash.

Didrik Rokhaug said:

Did you get a reply from your network operator?

No

Didrik Rokhaug said:

While they might have different timeouts, the timeouts we have seen are typical <1 minute. SO I would not dismiss the possibility that the problem is caused by the networks NAT policy

Yes, you are right. I will approach them to rule out the possibility. 

BR / Björn 

[Didrik Rokhaug]

Hi.

First of all, I am sincerely sorry for the long wait (again).

As the modem is delivered as a compiled application, only runtime configuration is possible. FOr the LTE stack, this is done through AT commands, while for the IP stack it is done through socket options. You are therefore limited to the socket options that can be set through bsdlib.

When it comes to the application level protocols, those run on the application core and can be configured by Kconfig or replaced/rewritten partially or fully.

[Didrik Rokhaug]

According to the modem team, the modem team makes no assumptions about the validity of the session.

It is up to the server to check if the session is still valid. If it is not, the server will respond with an error. However, that error might get lost due to the NAT timeout I have already mentioned.