aws_iot MQTT subscriber keep alive

[tedhavelka]

Hello Devzone,

I'm writing to ask about how long a device running Nordic's aws_iot sample app (sdk-nrf 1.6.1 based, Zephyr 2.6.0 based) may be in a "radio idle" state, and the device still wake the radios and be able to receive messages to which its firmware has subscribed?

On a Thingy91 board I'm running an amended version of sdk-nrf v1.6.1 sample app `aws_iot`.  The original publishing to a project default AWS topic works.  I've also been able to publish to some custom topics which I created in an AWS cloud account.  I have an MQTT broker enabled in the cloud account.  An MQTT test client is available and functioning there too.

On the side of firmware and Thingy91, I added a couple of topic strings to the routine which subscribes at firmware start up time.  This too is working, but only for a limited duration time.  That is, I can start the firmware on the Thingy91.  It's publishing to one or two topics at an interval of 15 seconds, and in this frequent publishing mode I can manually send messages from the cloud to the Thingy91 indefinitely.  When I increase the firmware's "radio idle" period, I begin to lose subscription reception at about five minutes idle period.

In the app prj.conf file, I see no mention of PSM (power savings mode?) settings.  There are a couple of refs to this nRF9160 power configuration parameter group in a .config file in my project's build folder.  But to my knowledge I am not completely powering anything off at this point.

There is periodic message which alternately reads:

`RRC:  Connected

    .

RRC:  idle`

These pairings appear whether the Thingy91 at my desk is yet receiving cloud published messages or not. 

Publishing to the cloud seems to work across longer intervals of radio idle time.  Messages from the cloud -- after the first minute or so of firmware run time -- appear at the Thingy91 just after it publishes to the cloud.  I assume this reflects that the radio is turning on briefly to publish, and at this time there's some standard MQTT client check or handshake, where the Thingy91 firmware queries for whether there are messages queued in its subscribed topics.  Is this correct understanding?

All messages from the cloud stop however, when my firmware does not publish for about five minutes or longer.  Then I must reset the Thingy91 to see two-way MQTT communications resume.

There seems to be some type of time out at work here.  Should I be looking for some kind of keep alive parameter other than `CONFIG_MQTT_KEEPALIVE`?

- Ted

[Charlie]

Hi Ted,

I'm writing to ask about how long a device running Nordic's aws_iot sample app (sdk-nrf 1.6.1 based, Zephyr 2.6.0 based) may be in a "radio idle" state, and the device still wake the radios and be able to receive messages to which its firmware has subscribed?

The "radio idle" state length is the parameter "RRC inactivity timer", which is decided by the Cellular IoT network you used. According to Online Power Profiler for LTE, most operators use 7 seconds. You can check with a PPK like a demo from User guide (LTE), or ask your cellular network provider.

When I increase the firmware's "radio idle" period, I begin to lose subscription reception at about five minutes idle period.

Which configuration have you modified since this can not be controlled by UE? Did you actually modify CONFIG_LTE_PSM_REQ_RPTAU? 

In the app prj.conf file, I see no mention of PSM (power savings mode?) settings. 

You can change PSM settings through Kconfig Menu or add and modify following lines to prj.conf:

CONFIG_LTE_PSM_REQ_RPTAU="00000011"
CONFIG_LTE_PSM_REQ_RAT="00100001"

Is this correct understanding?

Should I be looking for some kind of keep alive parameter other than `CONFIG_MQTT_KEEPALIVE`?

This is correct understanding as long as the MQTT connection is ALIVE. nRF9160: AWS IoT sample document mentions that NAT timeout could also affect. I found another case that has very similar symptoms as your issue, and it was solved by changing to another network.

Best regards,

Charlie