• State Not Answered
  • Replies 40 replies
  • Subscribers 69 subscribers
  • Views 3899 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 311053
Options

nrf9160 - lwm2m_Client (queue mode)

Hkhan7861

Good day

I am currently trying to a create a lwm2m client to use with my custom board.  When I have queue mode enabled and the device is sleeping, i use the lwm2m_send function and get a very high power consumption.  I have found  that the program hangs before getting this on the logging:

[00:19:30.532,806] <inf> net_lwm2m_engine: Connected, sock id 0

I have also attributed this to:

zsock_connect(client_ctx->sock_fd, &client_ctx->remote_addr, addr_len) 
when the client attempts to re-establish a connection   (lwm2m_engine_connection_resume), this function takes a while to complete it causes the high power consumption.  For a better understanding, I will post the power consumption while using and not using queue mode:
I have noticed that in queue mode,  a registration update is triggered.  However, the high power consumption occurs during the above mentioned process.  Is there a way that I can avoid as queue mode is essential for my project as I would like to send requests from the server while the device is sleeping.
Thank you in advance
Kind regards,
Hassan
Parents Reply Children
  • 0 in reply to Hkhan7861

    Hi Hassan,

    I've been in discussions with one of our developers, who has done some testing. The tests don't entirely reflect your specific application of course, but they give an indication.

    Short version first: Our developer thinks that the main "mistake" given this protocol stack is using just 4 seconds for the coap ack init time:

    I propose next changes to customer configs because of NB-IoT

    CONFIG_LWM2M_QUEUE_MODE_UPTIME=30
    Back to original. Setting to 5 seconds may cause more problems so I would keep that to 30 seconds.

    CONFIG_COAP_INIT_ACK_TIMEOUT_MS=15000
    original 4 sec may affect re-send flow with bigger packet.


    Longer version:

    what you are seeing is likely not a bug but a consequence of the chosen protocols. There might be some room for improvement (with the above), but NB-IoT in particular is just slower than LTE:

    nb-iot is slow when you need to send bigger packets
    eDRX and RAT times are double longer at nb-iot than LTE
    some server may have aggressive timeouts which are not optimal for nb-iot

    With the bandwidth limited NB-IoT, you may sometimes have unfortunate combinations of timeouts and retransmissions in the various layers of the protocol stack (UDP, DTLS, CoAP, LwM2M), when a packet inevitably gets lost, which can make things take longer or even get stuck. The first half hour of this video goes into it a bit: https://www.youtube.com/watch?v=f7GOX3pMsGo

    So if you are able to, it could make a big difference if you switched away from NB-IoT - but I assume you've already considered it (the Kconfig options you shared earlier suggest that you have tried LTE-M earlier, is that right?). I know that support for LTE varies from country to country, and you might have good reasons to use nb-iot (If you want to reach far indoors, for example).

    Further: Would you have the ability to update your application to NCS v2.5.0? In conjunction with modem fw 1.3.5, it includes support for "Connection ID" (CID) in DTLS, which would cut down the number of transmissions needed by using an ID instead of IP addresses as identifiers.

    The developer strongly recommends you to update if you can:

    Connection ID enable will save 3 message from 5. So then wakeup causes only 2 message from client LwM2M registration update and Send. That will make a huge difference. Now DTLS session resume sends 3 messages total + LwM2M update, and real data is the 5th message

    Here is client wakeup for registration update diffrence with Connection ID with client default config + overlay-cid.conf + overlay-nbiot.conf


    So CID will cut update wakeup and reg update to half

    I hope these suggestions are useful to you. Sorry for not keeping you updated during the process!

    Best regards,

    Raoul

  • 0 in reply to Raoul

    Hi 

    Thank you for the extensive explanation we fully appreciate it.  Unfortunately in South Africa, NBIOT is the only service we have available to us.  I will update to the newer SDK and make the changes accordingly.  I would just like to know how would i enable CID in the sample?  Is it as simple as a configuration or is it already enabled ?

    Kind regards,

    Hassan 

  • 0 in reply to Hkhan7861

    Hi Hassan,

    Hkhan7861 said:
    Thank you for the extensive explanation we fully appreciate it.

    Thanks!

    Hkhan7861 said:
    I would just like to know how would i enable CID in the sample?  Is it as simple as a configuration or is it already enabled ?

    Good question. I should have mentioned that since the developer had already shared the relevant Kconfig options for CID with me. But, I just realized that the changes to the LwM2M stack in v.2.5.0 are so significant that they received their own section in our migration guide:

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/releases_and_maturity/migration/migration_guide_2.5.html#recommended-changes

    I would start out by consulting that, since migration is what you'll be doing. Among other things, it links to the options in this file: https://github.com/nrfconnect/sdk-nrf/blob/v2.5.0/samples/cellular/lwm2m_client/overlay-dtls-cid.conf

    The developer originally highlighted the following options:

    CONFIG_LWM2M_CLIENT_UTILS_DTLS_CID=y
    CONFIG_LWM2M_RD_CLIENT_STOP_POLLING_AT_IDLE=y

    CONFIG_LWM2M_RD_CLIENT_SUSPEND_SOCKET_AT_IDLE=y     (is mandatory with CID, but I see you have that enabled).

    # Optimize powersaving by using tickless mode in LwM2M engine
    CONFIG_NET_SOCKETPAIR=y
    CONFIG_LWM2M_TICKLESS=y

    But if there's more in the migration guide, I would add that too.

    The tickless mode is new with NCS v2.5.0 too. I know you've been waiting long with this case, but I think it's fortunate that these power saving options still released in time for your schedule!

    Best regards,

    Raoul

  • 0 in reply to Raoul

    Hi Raoul  I have written the same code for a thingy91.  When using the same sim card we tested the signal difference between the thingy91 and our custom board using modem commands.  Our custom board has better signal.  However queue mode and registration updates do not hang at all.  This means that it is just our custom board behaving like this and the cause is not NB-iot. Do you have any idea what is causing this.  Could it be somethig in the board files? Considering that the program for the two boards are exactly the same we can't seem to understand what in the board files could possibly be causing this.

    Kind regards,

    Hassan

Related