Keep socket open indefinitely

[Eizens]

Hello, Modem firmware is 1.3.5 and SDK version is 2.5.0. 

I am using Nrf9160 DK to evaluate a cellular network to control, for example, LED remotely.

At the moment I am trying to achieve this using a simple socket. Nrf91 connects to the server through a socket and listens for data. This works fine, but after some time (1h or more) socket stops working. As I understand someone in the network drops the connection due to inactivity. I tried simple RCC idle mode and eDRX mode, both cases had similar behavior.

What could be the industry standard approach to this problem while trying to minimize power consumption? How for example smart light bulbs keep connection with the server?

Do I need to send periodic keep-alive messages? Or use some different protocol?

[helsing]

Hello Eizens,

This is covered in DevAcademy Lesson 4 – Reading buttons and controlling LEDs over MQTT. Please let us know if you run into any issues.

[helsing]

Also check out the lesson on Power saving techniques in the course.

[Eizens]

Hello,
Thank you for the answer. I checked the links and implemented the MQTT.

A little bit about my application: I am developing a sort of electronic lock. This means the user should be able to open the lock anytime. Meaning my device must always have an open connection with the backend server.

MQTT uses a keep-alive mechanism to keep the underlying TCP socket open. I have read that in some applications the default MQTT keep-alive period is 60 seconds, but for battery-powered devices, the 60-second keep-alive consumes too much power. The measured current is around 2.5mA (my setup uses RCC idle, no eDRX or PSM). 

So to decrease the device's power consumption, I tried longer MQTT keep-alive values. With my local cellular network provider SIM I could get a reliable connection using a 1 hour MQTT keep-alive period. In this case, the measured current was around 400uA, which is acceptable. If I increased the keep-alive period any more, I would lose connection. (By the way iBASIS SIM card using data roaming connected to the same local network had only max 5 minute reliable keep-alive period)

But using these long keep-alive periods I am running the risk - if the connection is lost, I won't know this for 1 hour. In the electronic lock case, this could be a bad user experience. 

So as I understand I don't have a better option? This means the best option is to find a balance between reliable keep-alive value and power consumption. Could you say this is a normal practice? Maybe you have experience with long MQTT keep-alive periods usage in real-world applications?

[Charlie]

Hi Eizens,

Eizens said:

But using these long keep-alive periods I am running the risk - if the connection is lost, I won't know this for 1 hour. In the electronic lock case, this could be a bad user experience. 

This is really a design choice for your lock application. There are some factors like below may have influence on the choice.

How frequent the cellular connection will have problem?

How long time you expect to find the device lost connection, and how long time you can fix the issue, then how long time you think customer will not feel bad from issue appear to fix?

For the cellular connection issue, this could be aware from both nRF9160 and network operator side, you may check with your operator if there is API for this kind of notification.

I also want to remind you we have a Matter: Door lock — nRF Connect SDK 2.6.0 documentation (nordicsemi.com) sample available here.

Best regards,

Charlie