LwM2M: GET Requests Experiencing Timeouts After a Certain Duration

RE: LwM2M: GET Requests Experiencing Timeouts After a Certain Duration

vytautas — Thu, 05 Dec 2024 09:03:58 GMT

This was related to both the carrier (MNO) NAT timeout configuration and the one we had on our Linux server.

RE: LwM2M: GET Requests Experiencing Timeouts After a Certain Duration

Achim Kraus — Mon, 28 Oct 2024 11:56:14 GMT

I'm not an employee of Nordic. And Nordic usually ask for the modem trace (not only the capture).

RE: LwM2M: GET Requests Experiencing Timeouts After a Certain Duration

vytautas — Mon, 28 Oct 2024 11:52:48 GMT

You can use lwm2m_issue_clientside_v2.pcapng (attached above) for debugging.

RE: LwM2M: GET Requests Experiencing Timeouts After a Certain Duration

Achim Kraus — Mon, 28 Oct 2024 11:46:45 GMT

So, if you don't send data, then "DRX is not interrupted". And if you send data, it's interrupted but after a quiet phase the modem doesn't receive the data?

Then I guess you will need a modem-trace (not only the ip-capture) and someone from Nordic may need to check that.

RE: LwM2M: GET Requests Experiencing Timeouts After a Certain Duration

vytautas — Mon, 28 Oct 2024 11:33:33 GMT

[quote userid="5203" url="~/f/nordic-q-a/115803/lwm2m-get-requests-experiencing-timeouts-after-a-certain-duration/508049"]That's the assumption. But what happens, if the "second GET" (after the longer quiet phase) is not used? If you still see the RRC stuff without data, then it's not caused by downlink data.[/quote]

If no data is sent from the LwM2M server, the DRX is not interrupted. We tested the following intervals: 15 seconds (data received), 31 seconds (no data), 45 seconds (no data), 60 seconds (no data), and 85 seconds (no data). In each case, DRX was interrupted, but only at the 15-second interval did we receive IP data. In all other cases no socket events were set.

RE: LwM2M: GET Requests Experiencing Timeouts After a Certain Duration

Achim Kraus — Mon, 28 Oct 2024 06:07:43 GMT

> using CoAP may not be a suitable choice for Device Management

That depends much more on your assumptions. In general, if a device is power constraint, it's important to have short active times and long sleeping times. Also, if the device communicates in challenging radio environments, it's important to use less and short radio messages, otherwise the probability to fail is raising.

Systems, which "requires" to push data to the device, will be in conflict with the "long sleep". But if your device isn't power constraint (and maybe the SIM card is also not data-volume constraint), then you may use what ever protocol you want and push data to that always awake device at that "high costs".

But in many use-cases, the trade off between that costs (energy+data) and that ability to "push" data to the device, does not go for the "push". In quite a lot of use-cases it's OK, that the device always initiates the communication and the server is only able to send data back for a short interval, not because of the NAT (which also limits that), that's because of the energy consumption. You will need a definition, how long the device should wait for data, before it goes to sleep. And then you need to adapt the usage of RAI accordingly (signalling the modem what to expect). In that scenario, waiting for more than 30s seems to be a waste of energy in the first place.

So, in my experience, quiet a lot systems are mainly using frequent "system alive/heartbeat messages" (e.g. every hour) send to the server to indicate the system's health. That offers then the server the chance to send something back. With that, a Thingy:91 runs from it's battery for a year, exchanging every hour a message.

RE: LwM2M: GET Requests Experiencing Timeouts After a Certain Duration

Achim Kraus — Mon, 28 Oct 2024 05:49:16 GMT

> The issue appears to be that the network interrupts the DRX cycle to signal downlink traffic, but no data actually arrives.

That's the assumption. But what happens, if the "second GET" (after the longer quiet phase) is not used? If you still see the RRC stuff without data, then it's not caused by downlink data.

RE: LwM2M: GET Requests Experiencing Timeouts After a Certain Duration

vytautas — Mon, 28 Oct 2024 04:37:19 GMT

As noted above, we’ve observed that sending a message within 30 seconds of a previous operation—such as a registration or a GET request—consistently succeeds. The issue appears to be that the network interrupts the DRX cycle to signal downlink traffic, but no data actually arrives. My assumption is that if CG-NAT were dropping the tunnel, we wouldn’t be woken up at all. Could you clarify if this interpretation is accurate?

Alternatively, if this behavior is intentional, do you have experience regarding how long CG-NAT typically keeps the tunnel open? If the timeout is as short as 30 seconds, it would appear that LwM2M using CoAP may not be a suitable choice for Device Management; yet it seems to be quite popular in IoT. 😕

RE: LwM2M: GET Requests Experiencing Timeouts After a Certain Duration

Achim Kraus — Sun, 27 Oct 2024 08:53:22 GMT

> likely triggered by downlink messaging.

Maybe you verify that by tests without "GET 2"? If you see that only if you use GET 2 but not if you don't use GET 2, then the assumption will be verified. Otherwise it's just a NAT issue.