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]

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 !

[Håkon Alseth]

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

[Achim Kraus]

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

[Achim Kraus]

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