PSM active time not Correct

[Hkhan7861]

Good Day

I have enabled power saving on my nrf9160dk and am using NBIOT.  In doing so I found that there was a 60 sec offset to what I selected and what I wanted the active time to be.  IN doing some research I came across this question :  https://devzone.nordicsemi.com/f/nordic-q-a/87330/nrf9160-not-setting-requested-active-time 

The device is probably stuck in RRC idle for 60s before entering power saving mode.  This answer was never really solved and wanted to know if anybody found a way around this or if I will have to contact my provider?  If so, what would i need them to changed?

Kind regards,

Hassan

[Håkon Alseth]

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

[Achim Kraus]

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

[Hkhan7861]

Good day 

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

Modem Trace(PSM).bin

[Håkon Alseth]

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

[Achim Kraus]

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.

[Achim Kraus]

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!)

[Hkhan7861]

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.

[Achim Kraus]

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.

[Hkhan7861]

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.

[Achim Kraus]

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