Attachments (2) Download All
Nordic Case Info
  • Case ID: 332767
Options

Long PSM delay problem in NB-IoT mode

RoryL

While testing CoAP with NB-IoT I normally get PSM (sleep) delay = 20s before PSM mode is set (0.5mA with UART enabled), but after awhile PSM delay increases to ~4.5min (at 34mA) after each transmission has finished. I enabled a modem trace and the Wireshark capture shows me that when PSM delay = 20s (from RRC Inactivity timer=20s + Active time=0) then "RRCConnectionRelease-NB" message is logged just before +CSCON=0, but when the delay is ~4.5min then "RRCConnectionRelease-NB" message is missing and +CSCON=0 takes 4.5min instead of 20s.

I'm using the sample nRF Cloud multi-service app with SDK 2.6.1, Modem v1.3.6, connected to nRF Cloud (using a Spark NZ NB-IoT SIM). After this problem has happened then it sometimes recovers after next data transmission, provided I'm using a slow enough data rate (e.g. 10min). If I test this with a 2min data rate then doesn't seem to recover. In this failed mode the first Tx request always fails (probably the modem thinks it's still connected), and the re-transmit only works after it's logged a +CSCON=0, +CSCON=1 cycle (a forced reconnection recovery by the modem?).  I haven't seen this problem at all with a LTE-M SIM (where PSM delay = 10, from the network RRC inactivity timer).

As a work around I tried enable RAI (e.g. AT%XRAI=3, with CONFIG_COAP_SEND_CONFIRMABLE=y), and found it nearly always helped set PSM immediately, but not always (e.g. still got sometimes got RRC idle delay = 4.5min delay).  I've disabled location reporting in my build, but the same problem happened with the default config (overlay_coap.conf), and also when I tested using the low power build (overlay_min_coap.conf).

Some questions:

  1. Cellular coverage is normally reliable for me - so could the missing "RRCConnectionRelease-NB" be caused by: a network fault (failed to send it), or a comms error (not received), or an nRF9160 (modem or app) problem?  Are there any suggestions for how to avoid or work-around this problem?

  2. I'm curious where the 4.5min delay comes from - when +CSCON: 0 is set after this delay (with missing "RRCConnectionRelease-NB") - does the modem implement this timeout? (e.g. to ensure PSM gets set, and avoid wasting ~34mA forever)

  3. When the problem has happened - does the modem or the SDK do the recovery sequence (+CSCON:0, +CSCON:1 cycle), seen in Terminal log (2) below - for the 2min data rate, to re-establish comms?

Logs with the "RRCConnectionRelease-NB" missing problem:

1) Terminal log - 10min data rate: 4.5min RCC idle delays after 00:50:25 and 01:10:25

Wireshark capture of same events - 10min data rate: missing "RRCConnectionRelease-NB" before 4.5min RRC idle delays at line 308 (3291s), and line 361 (4491s):

8623.cms_Spark_20240903_2_nbiot_10min.pcapng

2) Excerpt of terminal log - 2min data rate. First RRC idle failed after 00:08:29, no PSM idle before the next transmission + forced recovery before each resend (00:10:36):

Wireshark capture of same events - 2min data rate: first missing "RRCConnectionRelease-NB" after line 303 (509s)

6052.cms_Spark_20240902_1_nbiot_2min.pcapng

Parents
  • 0

    Such delayed PSM may be caused by a HPPLMN network search, you may find a couple of articles here in the forum. Before 1.3.5, Nordic was even searching for global "9xxxx" networks in a HPPLMN search. If a HPPLMN network search is the case, depends mainly on your SIM card. That may come with different prio lists and is usually applied, if the device gets a MCC (country code) and has some prio PLMN in it's lists. If you have a nRF9160-DK, nRF9161-DK, or a Thingy:91 you may apply my demo client and execute the sim cmd to see, what you SIM card contains. Otherwise you may apply some "AR+CRSM" commands and decode the result on your own. See modem SIM card cmds to get some impression about that. Or you ask the SIM card provider.

  • 0 in reply to Achim Kraus

    Thank you Achim,

    I looked at several posts where HPPLMN has been mentioned before (e.g.  RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM and RE: PSM active time not Correct). My SIM card is not roaming so from the other posts it seems that the problem is not HPPLMN in my case. e.g. The %XMONITOR response shows: Registered home network (not roaming), and Active time  = 0:
    %XMONITOR: 1,"Spark NZ","Spark","53005","9903",9,28,"09BCBCE7",176,9218,52,28,"","00000000","00000110","01011110"

    Thanks also for suggesting your demo client - I'm testing on nRF9160-DK so I might take a look at that (when I get a chance). At the risk of going off topic - I'm still learning into what's needed to support a robust CoAP client (with reliable reconnect + Tx retry behaviour), and I'm not sure which sample client app will provide the best starting point to leverage?

    Our network provider has confirmed RRC inactivity timer = 20s for NB-IoT, and this is the 'normal' time I've seen it take to enable PSM (sleep) after transmission finished - e.g. this is when +CSCON=0 is logged and current drops to idle level (0.5mA with coap.conf build config)

    The problem I described above is that sometimes the current stays = 34mA for 4.5min before +CSON=0 is logged and it enters PSM (sleep) mode. And whenever this happens the wireshark capture shows that "RRCConnectionRelease-NB" is missing from the capture. So for some reason is seems my modem sometimes does not disconnect after the 20s RRC inactivity timer should have expired. I'm hoping that Nordic support will be able to take a look at the log files and comment on the questions I have raised above.

Reply
  • 0 in reply to Achim Kraus

    Thank you Achim,

    I looked at several posts where HPPLMN has been mentioned before (e.g.  RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM and RE: PSM active time not Correct). My SIM card is not roaming so from the other posts it seems that the problem is not HPPLMN in my case. e.g. The %XMONITOR response shows: Registered home network (not roaming), and Active time  = 0:
    %XMONITOR: 1,"Spark NZ","Spark","53005","9903",9,28,"09BCBCE7",176,9218,52,28,"","00000000","00000110","01011110"

    Thanks also for suggesting your demo client - I'm testing on nRF9160-DK so I might take a look at that (when I get a chance). At the risk of going off topic - I'm still learning into what's needed to support a robust CoAP client (with reliable reconnect + Tx retry behaviour), and I'm not sure which sample client app will provide the best starting point to leverage?

    Our network provider has confirmed RRC inactivity timer = 20s for NB-IoT, and this is the 'normal' time I've seen it take to enable PSM (sleep) after transmission finished - e.g. this is when +CSCON=0 is logged and current drops to idle level (0.5mA with coap.conf build config)

    The problem I described above is that sometimes the current stays = 34mA for 4.5min before +CSON=0 is logged and it enters PSM (sleep) mode. And whenever this happens the wireshark capture shows that "RRCConnectionRelease-NB" is missing from the capture. So for some reason is seems my modem sometimes does not disconnect after the 20s RRC inactivity timer should have expired. I'm hoping that Nordic support will be able to take a look at the log files and comment on the questions I have raised above.

Children
  • 0 in reply to RoryL
    RoryL said:
    I'm hoping that Nordic support will be able to take a look at the log files and comment on the questions I have raised above.

    I guess, that you will get asked to provide to full "modem-trace", not only the extracted wireshark-capture. The Cellular Monitor provides that trace under "RAW file name" with the ending ".mtrace"

Terms of service