• State Not Answered
  • Replies 11 replies
  • Subscribers 76 subscribers
  • Views 2553 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 296176
Options

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

Parents Reply Children
  • 0 in reply to Achim Kraus

    Sorry for the late response.

    Achim Kraus said:
    At least using RAI with NB-IoT results in much shorter connect times. For now I only use the general "%XRAI". That offers two modes (one without response, one with, see %XRAI set ).

    Thanks a lot that worked for me too. I tried it on NB-IoT in combination with MQTT. I also wanted to try RAI on MQTT, because in my opinion it is a much cleaner solution, but I couldn't find out how to use RAI on MQTT without modifiing the source code of the Zephyr MQTT library.

    In the next step I will try RAI on NB-IoT in combination with CoAP. I still didn't manage to test it because we have an issue on our CoAP server at the moment.

    Achim Kraus said:
    The results you may see here NB-IoT with RAI .

    In the description under "General Considerations for LTE-M/NB-IoT" there is the sentence:

    With that, the usage to send data is split into two phases:

    • network reregistration after PSM on wakeup
    • exchanging messages

    Is there really a reregistration phase on every send data phase? I thought the PSM mode makes a reregistration phase unnecessary, doesn't it?

  • 0 in reply to Christian22

    > because in my opinion it is a much cleaner solution

    For me that depends on what you mean by "cleaner". Easier because the application benefits more from messaging (do you use it just to transmit data to the cloud? Or really subscribe/publish with other devices?)? In my experience, the most application benefit much more from request/response (application level response). For some functions, which takes longer, that may be reduced by sending the response also just as "received, processing started". Anyway, as your wrote, it's opinion.

    > Is there really a reregistration phase on every send data phase?

    No, the text refers to a "reregistration at the network" once per PSM wakeup, so once per hour in the shown case. The text also describes the situation in summer 2022 in south Germany. Repeating those test in September 2022 showed, that now all MNO allows to use also larger times for PSM. I currently work on an update, hope I can publish this until end of next week.

    > RAI on MQTT

    I tried to use it with HTTPS, but that also comes with issues. AFAIK, RAI works in "low-level-nb-iot- messages". Though TCP exchanges many application unaware IP messages (e.g. TCP ACKs), it will be hard to really benefit from it (searching the forum you find many struggling, but I didn't find one, which does it really successful). The next decision to make would anyway be, if the connection should/could be closed or must be kept open. If the connection is not closed, then the next question after that will be, how long does your device sleep. If the other peer sends you data (that peer doesn't know, that your devices is sleeping), and gets no TCP ACKs, I guess that one will even close the connection.

    (If you really want to stick to TCP, I guess eDRX may be better, but may also not work "out-of-the-box". According nRF9160 - Absolute maximum ratings it takes about 37 µA instead of 2.7 µA in PSM.)

    It seems to be really irritating, that Nordic on the one side seems to stick on MQTT/TLS/TCP, but doesn't provide too much real facts nor help for really "best practice" using it. It gets then completely ridicules, if the presented measurements are then all done for UDP (LTE-M vs NB-IoT Field Test). Looks like in many other companies: the cloud developer wants TCP, but the device requires UDP. If the management doesn't decide to go either for larger batteries and pay a little more for the SIM-card, or to switch to use UDP, then products will never have a chance to make it to the "streets".

  • 0 in reply to Achim Kraus

    Thans again for your very helpful answers.

    Achim Kraus said:
    For me that depends on what you mean by "cleaner". Easier because the application benefits more from messaging (do you use it just to transmit data to the cloud? Or really subscribe/publish with other devices?)?

    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). And with %XRAI it is even worser than with RAI because %XRAI is only a high level command and can not be used like RAI as you mentioned above. So in my opinion the potential of MQTT in combination with %XRAI is very limited when it comes to optimized power consumption. 

    Our first step is only to transmit data to the cloud. The next step then would be to receive data from the cloud. It is not yet clear if we want to do it also asynchronously using eDRX.

    Achim Kraus said:
    No, the text refers to a "reregistration at the network" once per PSM wakeup, so once per hour in the shown case. The text also describes the situation in summer 2022 in south Germany. Repeating those test in September 2022 showed, that now all MNO allows to use also larger times for PSM. I currently work on an update, hope I can publish this until end of next week.

    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 I'm wrong, but I always thought it is the idea behind the PSM mode to avoid re-registrations at the network?

    Achim Kraus said:
    Looks like in many other companies: the cloud developer wants TCP, but the device requires UDP. If the management doesn't decide to go either for larger batteries and pay a little more for the SIM-card, or to switch to use UDP, then products will never have a chance to make it to the "streets".

    Exactly, that's why I compare them with reference to our requirements. 

  • 0 in reply to Christian22

    > 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.

  • 0 in reply to 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.

Related
Terms of service