PSM active time not Correct

RE: PSM active time not Correct

Achim Kraus — Fri, 02 Dec 2022 07:56:20 GMT

> Have you any experience with lwm2m?

That's a couple of years ago. Lwm2m uses CoAP, and I have much more recent experience with CoAP (and DTLS 1.2 CID).

> if so, do you know if producing your own server is possible and worthwhile?

Let me split that:

- developing an "own server": I think, the efforts are underestimated. If it's not clear, that you only need a smaller lwm2m subset, I think you will need to spend much more time than expected. It depends also on the programming language you want to use.

- run an "own server": there are some open source projects (e.g. eclipse/leshan), but AFAIK, they don't offer a "out-of-the-box" service, so that may also end up in developing something on your own. It also requires knowledge about running such an UDP service.

So, I guess, it will take too much efforts. At least to begin with lwm2m, I would rather start with one of the offered services and see, how that develops.

(I'm one of the developers behind "Eclipse/Californium", a very common CoAP/DTLS 1.2 java implementation, also used for leshan. Therefore I'm mainly using Californium to run my own services.)

RE: PSM active time not Correct

Hkhan7861 — Fri, 02 Dec 2022 06:55:31 GMT

Good day

I tried what you said using "SO_RAI_NO_DATA" and still wasn't successful. Due to the device needing to be extremely low power, a UDP based protocol is going to make more sense i think. Have you any experience with lwm2m? if so, do you know if producing your own server is possible and worthwhile?

Thank you in advance,

Hassan.

RE: PSM active time not Correct

Achim Kraus — Thu, 01 Dec 2022 08:35:44 GMT

Just to mention:

UDP for it self lucks "reliability". So you usually need a protocol on top of that, which implements something as "retransmission". CoAP/RFC 7252 is one common solution. You may combine it with DTLS (for now 1.2) and hopefully the merged DTLS 1.2 extension "Connection ID" gets available for zephyr as well. It was merged these day in mbedtls and will take some time until it's available in zephyr.

Just in the case, you want to have a "preview", you may also have a look at my demo-client (using the Eclipse stack Californium for the server side, and tinydtls on the nRF9160 device).

zephyr coaps client

As addition option, you may check, if

Access stratum Release Assistance Indication instead of Control plane Release Assistance Indication works for you. It requires your network operator to support Release 14 features. using SO_RAI_NO_DATA e.g.3s after you finished your communication, may have a chance. I had no success using SO_RAI_NO_DATA , but according that comments, there should be no general issue.

RE: PSM active time not Correct

Hkhan7861 — Thu, 01 Dec 2022 08:08:30 GMT

Thank you !

I am trying to contact my provider as we speak and we cannot shorten that time I will be moving toward a UDP based protocol. Again, thank you for the assistance.

Kind regards,

Hassan.

RE: PSM active time not Correct

Achim Kraus — Wed, 30 Nov 2022 20:14:57 GMT

Just to mention:

Using a UDP based protocol makes using RAI possible and that shortens the "RRC (in)actvitiy time" a lot. If you have a LinkeIn account, see

LinkedIn - Enlit Europe - nRF9160 Demo

(that's really a brilliant value!)

RE: PSM active time not Correct

Achim Kraus — Wed, 30 Nov 2022 20:02:25 GMT

GSMA NB-IoT Roaming Features April-2022 Landscape

Contains a list for several countries. I consider, the "RRC inactivity timer" is the "RRC activity timer" in that document.

RE: PSM active time not Correct

Håkon Alseth — Wed, 30 Nov 2022 15:28:00 GMT

Hi,

The trace shows that you have a successful PSM, with TAU=30 minutes and ActiveTime=2 seconds.

After approx. 60+2 seconds since your last TCP transaction, you are getting an RRC release from the network (ie. entering PSM).

Kind regards,

Håkon

RE: PSM active time not Correct

Hkhan7861 — Wed, 30 Nov 2022 12:12:26 GMT

Good day

I built a simple project in order to do the modem trace with PSM. Thank you in advance!

devzone.nordicsemi.com/.../Modem-Trace_2800_PSM_2900_.bin

RE: PSM active time not Correct

Håkon Alseth — Wed, 30 Nov 2022 09:41:15 GMT

Hi,

The RRC inactivity timer usually ranges in the seconds to a couple of minutes, and is set by the network you're connecting to. 60 seconds is quite commonly used.

Kind regards,

Håkon

RE: PSM active time not Correct

Hkhan7861 — Wed, 30 Nov 2022 09:04:50 GMT

Good day

I was not able to do the trace due to the project goals changing. I would just like to ask, if the issue is in fact the RRC inactivity timer, what is the shortest time that anybody as seen. I would like to know to help me decide if it is worthwhile to change our approach.

Kind regards,

Hassan

RE: PSM active time not Correct

Hkhan7861 — Thu, 24 Nov 2022 14:16:52 GMT

Good day

I must apologize for not getting back to you sooner. I will reply as soon as I can. Thank you !

Kind regards,

Hassan

RE: PSM active time not Correct

Achim Kraus — Wed, 23 Nov 2022 19:23:31 GMT

> I think it may be something in my configurations and i'll have a look now.

I use

CONFIG_NRF_MODEM_LIB_TRACE_ENABLED=y

in the prj.conf. I disable the logging, but I'm not sure, if that helps. I select then "trace DB" in the "Trace Collector V2 preview v0.3.6" for my mfw. Using the nRF9160-DK it works quite well.

RE: PSM active time not Correct

Achim Kraus — Wed, 23 Nov 2022 09:59:16 GMT

Yep, I also can't read that trace.

I'm looking forward to a readable one.

As you see in the other comments, the main question, which decides, in which parts and function you need to look further, is if the delay occurs in RRC connected or RRC idle.

RE: PSM active time not Correct

Hkhan7861 — Wed, 23 Nov 2022 09:49:57 GMT

Good day

I have tried to enable tracing but I ran into some errors when doing so. I think it may be something in my configurations and i'll have a look now. I have ran the trace collector and will upload the file now. I hope that it can be of help. Thank you again!devzone.nordicsemi.com/.../trace_2D00_2022_2D00_11_2D00_23T09_2D00_31_2D00_05.277Z.bin

RE: PSM active time not Correct

Achim Kraus — Wed, 23 Nov 2022 09:15:34 GMT

> mqtt_simple

TCP injects additional messages into the radio transmission and that mixes up RAI.

if possible, enable tracing and you will see a lot more details.

> the device goes straight to power saving

That makes me wondering. Anyway, please first try to verify, if your device is in RRC connected or idle when getting delayed.

RE: PSM active time not Correct

Achim Kraus — Wed, 23 Nov 2022 08:57:03 GMT

> In cases where a re-transmit occur

It's even worse, because TCP injects also TCP-ACK-messages into the radio traffic. That happens even much more frequently than retransmissions. Control Plane RAI is just not the right tool for that.

Using AS RAI may help, but unfortunately, with the nordic socket API, you can't use it after close, and close itself uses also more than just 2 radio messages.

RE: PSM active time not Correct

Achim Kraus — Wed, 23 Nov 2022 08:49:17 GMT

Not sure, if mixing things helps.

According GSMA Energy Efficiency I see three phases

- RRC connected, terminated by RAI (user) or RRC inactivity timer (network)

- RRC idle, terminated by "PSM active timer" (requested by user, assigned by network)

- power sleeping, terminated by MO data sending (user), or TAU (requested by user, assigned by network)

From your sayings so far, your device is in idle and delayed switching to power sleeping.

If that is true, neither RAI nor RRC inactivity timer should be the cause.

If the device instead is in RRC connected and even the switch to RRC idle is delayed, then RAI or RRC inactivity timer applies.

Therefore, please first try to provide a trace, or ensure using the events, that we all have the same and verified information.

(Using RAI isn't that easy. It may be not supported, you never wrote, which protocol you use, TCP based or UDP based. With that, I would appreciate to precise the actual states in your case and not try to introduce new things, which may be just not related to your case.)

RE: PSM active time not Correct

Håkon Alseth — Wed, 23 Nov 2022 08:41:11 GMT

Hi,

Our recommendation is to not use RAI with TCP based protocols, that will give you a unwanted behavior.

In cases where a re-transmit occur, it is close to impossible for the application to fully handle that scenario at this time. You can read more about that in this thread:

MQTT service cannot work when RAI is set

Kind regards,

Håkon

RE: PSM active time not Correct

Hkhan7861 — Wed, 23 Nov 2022 08:16:37 GMT

I've begun experimenting with the "AT%%XRAI=3" command to exit RRC idle faster but i'm experiencing some very strange behavior. I added the command after I publish something using the mqtt_simple sample and the device goes straight to power saving but then after 30 seconds, exits power saving mode again. 60s after it exits power saving mode, it enters power saving mode mode again. This makes me think that I used the RAI command at the wrong place. The goal is to publish something every ten minutes. Any help would be appreciated thank you !

RE: PSM active time not Correct

Achim Kraus — Tue, 22 Nov 2022 13:30:24 GMT

> I tested a 0s active time and the %XMONITOR command shows a 0s active time.

Then it's not that "active time" ;-)

> The offset happens consistently.

In my experience, then it's not the HPPLMN search, especially, if your device is not "roaming".

All in all, the information is not matching. Do you know, how to enable the "trace"? if so, I guess such a trace would help to see, if the device spends the extra time in RRC connected or RRC idle. Alternatively, you may log the LTE_LC_EVT_RRC_UPDATE event to see, if the 60s are spend in RRC Connected or Idle.

RE: PSM active time not Correct

Achim Kraus — Tue, 22 Nov 2022 13:24:04 GMT

> My device is not in roaming as well.

If that's the case, then a HPPLMN search should not be the issue.

RE: PSM active time not Correct

Achim Kraus — Tue, 22 Nov 2022 13:21:23 GMT

> highly likely the "RRC inactivity timer"

That would be true, if the device stucks in RRC connected. But

> The device is probably stuck in RRC idle for 60s before entering power saving mode.

indicates, that the device enters RRC idle.

RE: PSM active time not Correct

Håkon Alseth — Tue, 22 Nov 2022 12:41:40 GMT

Hi,

If the issue is that you're seeing a delay of 60 seconds before the power consumption goes to PSM level (ie. < 10 uA), the issue is highly likely the "RRC inactivity timer" which is set by the network itself.

This is explain here by Jonathan:

RE: nRF9160-DK - sometimes busy for 1 minute before entering PSM

Kind regards,

Håkon

RE: PSM active time not Correct

Hkhan7861 — Tue, 22 Nov 2022 08:19:24 GMT

Also, I see that I could try using the command "AT+COPS" in manual selection. However, I would like to do this inside my code. I know this may a be longshot but if you have done it before could you tell me what could possibly be wrong.

nrf_modem_at_cmd(response2, sizeof(response2), "AT+COPS=1",2,"REDACTED");

RE: PSM active time not Correct

Hkhan7861 — Tue, 22 Nov 2022 06:55:46 GMT

HI Achim

I tested a 0s active time and the %XMONITOR command shows a 0s active time. The offset happens consistently. I haven't had any occasions where the offset is any less. I suspect it is similar situation to the link I added. My device is not in roaming as well.

Kind regard,

Hassan