Long PSM delay problem in NB-IoT mode

RE: Long PSM delay problem in NB-IoT mode

Hakon — Thu, 24 Apr 2025 10:39:44 GMT

[quote user="RoryL"]I suggest to consider if a shorter default timeout could be used or enabled in the future?[/quote]

Hello,

thanks for the suggestion. Can you please make a separate ticket for this to have it formally submitted as a feature request?

RE: Long PSM delay problem in NB-IoT mode

RoryL — Tue, 08 Apr 2025 05:50:41 GMT

Just to follow up on this fault report - after further investigation I found that the long PSM sleep delay (~300s) only happened when connected to a certain cell ID. It didn't happen when connected to other NB-IoT cell IDs from the same location. After sharing the problem with our network provider they agreed that one of their (3) suppliers had a fault in their equipment. This is why our devices sometimes did not receive "RRCConnectionRelease-NB" from the network. In the last month they have now fixed this and the problem isn't happening any more (PSM takes about 1s with CP-RAI instead of ~300s).

If possible I would still like to hear confirmation from Nordic Semi about the 300s PSM delay from the modem (v1.3.6) when this fail condition existed. This is a very long default idle timeout - that is very hard on a battery. I suggest to consider if a shorter default timeout could be used or enabled in the future?

RE: Long PSM delay problem in NB-IoT mode

Achim Kraus — Thu, 12 Sep 2024 05:44:37 GMT

[quote userid="135740" url="~/f/nordic-q-a/114576/long-psm-delay-problem-in-nb-iot-mode/502214"]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.[/quote]

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"

RE: Long RRC idle delay problem in NB-IoT mode

RoryL — Thu, 12 Sep 2024 04:21:54 GMT

Yes sorry - I should have said I am concerned by the time is it is taking for PSM (sleep) mode, not the time to RCC idle. And for my use-case it should normally take 20s - from RRC inactivity timer (20s) + Active timer (0s).

I understand on your comments regarding RAI. The above problem happens when I leave AT%XRAI=0 (I only mentioned that I once tried AT%XRAI=3 to see if it made a difference, and it did, but I would need to use this feature properly, and I really want to understand why the PSM (sleep) delay can be 4.5min (while AT%XRAI=0).

RE: Long RRC idle delay problem in NB-IoT mode

RoryL — Thu, 12 Sep 2024 04:08:02 GMT

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.

RE: Long RRC idle delay problem in NB-IoT mode

Achim Kraus — Mon, 09 Sep 2024 09:19:23 GMT

Reading your ticket again, I'm not sure, which period you complain about.

RRC active => RRC idle : that's RAI.

(That will be indicated by +CSCON=1 or +CSCON=0)

RRC idle => psm sleeping: that's psm active timer and the sometimes the HPPLMN network search.

(That will be XMODEMSLEEPING after +CSCON=0).

For the RAI:

Without RAI the modem usually switchs to +CSCON=0 after a short couple of seconds without traffic.

With RAI, if you use "AT%XRAI=3, with CONFIG_COAP_SEND_CONFIRMABLE=y" that works only if you send one request (I see a couple of requests in the capture, not only one) and no retransmission occurs (that's the case starting with record 199 in the first capture with 10m). Otherwise, it may fail. RAI means your application assists the modem to release the connection. With "AT%XRAI=3" you inform the modem, that you expect 1 response. But if you send a couple of requests, that assistance misleads the modem. The same applies, when a retransmission occurs, because you receive also more than just on response (even if coap does the deduplication for you). May be that causes then pretty large delays. That's out of my experience, though I use RAI coupled to the CoAP transmission state in order to prevent such "miss assistance". E.g. transfer of a couple of messages => disable RAI, enable it with the last one. Rentransmission, disable RAI for that exchange.

RE: Long RRC idle delay problem in NB-IoT mode

Achim Kraus — Mon, 09 Sep 2024 07:52:19 GMT

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.