nrf9160 mqtt keep alive longer than 30 minutes not working

Hi Oyvind,

I had given up on this until I had to come back to it just recently.

Please find attached the Uart output with debug enabled. I just cannot get the keep-alive period longer than 30 minutes to work. I have even test disabled PSM, using edrx, using PSM of 5 minutes etc. to try and keep the connectiion with LTE network active. I also checked with Bell and Rogers support they both informed me that they do not put any such limitation on keeping the connection open. Bell also confirm that their IP lease time should be more than 4 hours and longer so the 30 minutes time out does not work.

I was just thinking about how gps also does a cold-start if fixes are requested more than 30 mintues apart. Is there anything in the modem fw that resets the connection, closes the socket or clears the memory?

I am using mfw: 1.2.3 

sdk 1.6

Regards

Noaman

Hello Noaman, 

Please note that due to Easter Holiday, our tech support team is lower staffed than normal, and a delay in answers must be expected.

First of all, from the logs you have provided I see the following

PSM Settings: +CPSMS: 1,,,"00100100","00000001"

CEREG: +CEREG: 5,1,"D6E4","086B9411",7,,,"11100000","11100000"

Your network does not provide PSM, i.e. GPS would not work if not setting modem function to e.g. Flight Mode. 

Stratosphere said:

I just cannot get the keep-alive period longer than 30 minutes to work.

Could you please explain what keepalive you are referring to, MQTT or the network? 

The MQTT server you are connecting to, does this use TLS? Have you verified that the MQTT server does not disconnect device?

We will need a modem trace for more information.

Kind regards;
Øyvind

user77062 said:

Your network does not provide PSM, i.e. GPS would not work if not setting modem function to e.g. Flight Mode. 

...

I tried many configurations both with and without PSM. This output i shared is where i disable PSM.

user77062 said:

Could you please explain what keepalive you are referring to, MQTT or the network? 

As per the title of the ticket, I am referring to MQTT keepalive of more than 30 minutes.

user77062 said:

The MQTT server you are connecting to, does this use TLS? Have you verified that the MQTT server does not disconnect device?

I have tried both with and without TLS, the result is no different. 
I know my mqtt server does not disconnect because I have tried keepalive to the same server on ESP32 as well and desktop Mqtt client and they both keep the connection.

Modem trace as well as other files are attached.

Stratosphere said:

I know my mqtt server does not disconnect because I have tried keepalive to the same server on ESP32 as well and desktop Mqtt client and they both keep the connection.

Is the ESP32 connecting via cellular or WiFi? 

mqtt keep alive longer than 30 minutes

Can you provide some information for why you want to have 30 minutes keepalive? This for our developers to understand what you are trying to achieve. 

oys said:

Please note that due to Easter Holiday, our tech support team is lower staffed than normal, and a delay in answers must be expected.

Hi Oyvind,

I have attached the updated modem trace.

once again: keepalive is 40 minutes

mqtt publish freq: 40 min

modem fw: 1.2.3

ESP is connecting via Wifi. I have confirmed with Bell that connections of any sort are not being reset or terminated by them in 30 minutes. IP lease time is also in hours/days not in minutes.

I do not want 30 minute keep alive. I want >12 hour keepalive. Our use-case for asset tracking requires 12 hours pings on idle and more frequent pings on motion. so we could be sending 5-10 pings on a daily basis for typical application. I do not want to establish a new connection every time as it adds up on power consumption as well as data requirements on reconnection especially on TLS. TLS session caching does reduce data consumption and connection time but it is still more than what a keepalive duration of 12 hours would allow us to acheive.

Thanks for providing the update. 

Just to clarify, has Bell or Rogers support confirmed the NAT timeout on the network? NAT timeout is considered as a "chain", meaning that you are only "as strong as the weakest link" - i.e. if your one of your network chains has a lower than 350 seconds, that will be the NAT timeout for this specific network/APN.

Perhaps GSMA's Whitepaper on Improving Energy Efficiency for Mobile IoT. can offer some insight on this. 

Kind regards,
Øyvind

Thanks for providing the update. 

Just to clarify, has Bell or Rogers support confirmed the NAT timeout on the network? NAT timeout is considered as a "chain", meaning that you are only "as strong as the weakest link" - i.e. if your one of your network chains has a lower than 350 seconds, that will be the NAT timeout for this specific network/APN.

Perhaps GSMA's Whitepaper on Improving Energy Efficiency for Mobile IoT. can offer some insight on this. 

Kind regards,
Øyvind