LTE Modem keeps in connected state for a long time

[Christian22]

Hello,

I'm doing a comparison between MQTT on TCP and CoAP on UDP over NB-IoT and LTE-M. The communication to the cloud works as expected for both protocols. MQTT is used with TLS and Coap is used with DTLS.

Now the next step is to get an impression of the power consumption for both protocols in certain scenarios. But what I saw on the oszilloscope is not what I expected (see screenshot below). Every time I transmitted a packet to the cloud it took more than 10s until the modem went into the sleep mode again. But the response to a request packet has been received much earlier in case a response was expected.

What I can see in the LTE Link Monitor is that the modem outputs "+CSCON: 1"  every time the high power consumption time starts and it outputs "+CSCON: 0" every time it goes into the sleep mode again (after more than 10s).  

The picture below shows a screenshot of the MQTT communication but the same applies to CoAP.

For the test in the picture above I used PSM mode with the following configuration (eDRX has been deactivated)

• CONFIG_LTE_PSM_REQ_RPTAU = 1h
• CONFIG_LTE_PSM_REQ_RAT = 3s

From what I read in this post the reason for this behavior is that the modem is still in RRC_CONNECTED for a serveral seconds although the communication has already been finished.

https://devzone.nordicsemi.com/f/nordic-q-a/81278/early-release-assistance-indication

My questions are now:

1. Produces the missing Release Assistance Indication the behavior I discovered in my description above?
2. If yes, how can I solve the problem to get a much lower power consumption?
3. How can I enable the Release Assistance Indication in combination with TLS for MQTT and DTLS for CoAP on the nRF Connect SDK? I know there is an ICMP example (see link below) but I couldn't find "SO_RAI_ONE_RESP" in the SDK. Furthermore as described above I need a solution for TLS and DTLS.

https://github.com/nrfconnect/sdk-nrf/blob/332d2d1bc4aa335673aa0738e411aff0f2195915/samples/nrf9160/modem_shell/src/ping/icmp_ping.c#L343

For my tests I used the following setup:

• nrf9160 DK revision 1.1.0
• ncs v2.0.0
• modem firmware is mfw_nrf9160_1.3.2
• MNO is Deutsche Telekom

Thanks in advance.

Best regards,

Christian

[Hakon]

Hello,

Produces the missing Release Assistance Indication the behavior I discovered in my description above?

That is quite possible. Have you tried to enable it to see if it makes a difference?

How can I enable the Release Assistance Indication in combination with TLS for MQTT and DTLS for CoAP on the nRF Connect SDK? I know there is an ICMP example (see link below) but I couldn't find "SO_RAI_ONE_RESP" in the SDK. Furthermore as described above I need a solution for TLS and DTLS.

Using the AT command directly is also an option. This is what Stian is suggesting in the link you provided.

[Christian22]

Hakon said:

That is quite possible. Have you tried to enable it to see if it makes a difference?

Not yet but I will try it in the next few days. I will come back to you as soon as I get the first results.

Hakon said:

Using the AT command directly is also an option. This is what Stian is suggesting in the link you provided.

Is this the prefered solution?

[Achim Kraus]

> By "cleaner" I mean that I can't influence the MQTT behavior on packet level in the way I would need (without modifing the MQTT library). 

As I wrote, RAI refers to a "mobile network package layer", and with TCP that doesn't work, because TCP uses TCP-ACKs, the application is even unaware of them. Therefore I guess you even will not be able to adapt the MQTT implementation to make RAI working.

> %XRAI it is even worser

I'm not sure about the details of %XRAI. It may be worth using it, if "SO_RAI_NO_DATA" would be working and the connection gets closed. But NRF_SO_RAI_NO_DATA does not cause RRC release seems to indicate, that it doesn't work (for now). 

> From my understandig the PSM mode performs a Tracking Area Update procedure on every PSM interval if necessary but there is no need to do a re-registration procedure at the network. 

Maybe "re-registration" is the wrong term. Others use "full-attach" or "re-attach". Regardless which term is used, on any PSM wakeup I measured, it requires energy. If your experience is different, let me know.

[Achim Kraus]

I found two documents, which brings some light into the used "terms".

GSMA - TS.34 IoT Device Connection Efficiency Guidelines V8.0 see 9.11.

"Power Saving Mode is similar to powering-off the device, but the mobile device that uses
PSM remains registered with the network so there is no need to re-attach or re-establish the
network connection when the device starts transmitting or receiving data."

(I need to rewrite my page about energy consumption.)

and

GSMA - Improving Energy Efficiency for Mobile IoT

Figure 1, page 11.

"TAU / MO Data" with that, I guess, my measurements with different consumption for wake up and message exchange is caused by waiting and receiving the CoAP response. I consider to retest that once I implement "CoAP - No Server Response, RFC 7967" with my client. 

figure 2, page 12.

"Random Access RACH - wake up scan etc."

Not sure, when that happens.

[Christian22]

OK, after a few days of bugfixing now CoAP communication with RAI works as expected. I still have to investigate time into some other issues but for now I can send a CoAP request packet to the CoAP server, wait for a ACK response and set the whole nrf9160 SiP into sleep mode (PSM) right after I have received the CoAP ACK response. The same applies if I use eDRX.

I did it the following way in case other people need a hint how to start with RAI.

First, I called the following sequence at the beginning of my test application. 

lte_lc_init();
nrf_modem_at_printf("AT%%REL14FEAT=0,1,0,0,0");
lte_lc_connect();
nrf_modem_at_printf("AT%%RAI=1");

Note: the sequence above is of course only a simplified description.

After that I set the following option every time right before I sent a socket packet. Of course the "SO_RAI_ONE_RESP" option needs to be adjusted to your needs.

setsockopt(socket, SOL_SOCKET, SO_RAI_ONE_RESP , NULL, 0);

 

Note: I only tested it for NB-IoT in my region and the sequence I discribed above is not optimized.

[Achim Kraus]

Great!

In my comment above I mixed up "%RAI" (new AS-RAI) and "%XRAI" (traditional CP-RAI). So yes, "%XRAI" only works for simple UDP message exchanges, "%RAI" is more flexible.

One downside in the socketopt based implementation is, that with TCP, once the socket is closed, you can't use it anymore. So at that point I gave up to try to use it for TCP.

[Christian22]

Achim Kraus said:

One downside in the socketopt based implementation is, that with TCP, once the socket is closed, you can't use it anymore. So at that point I gave up to try to use it for TCP.

Thanks for the hint.

Achim Kraus said:

In my comment above I mixed up "%RAI" (new AS-RAI) and "%XRAI" (traditional CP-RAI). So yes, "%XRAI" only works for simple UDP message exchanges, "%RAI" is more flexible.

Only to clearfy it. As I already described in my comments above I really used "%XRAI" for TCP but only for a test application with a very restricted set of functionalities.

So I agree with you. It is as you explained above.