Verifying nRF9160 going into PSM

[zabdielfavela]

Hi everyone

We're developing an IoT device with an nRF9160 embedded in it. We're trying to make sure we're implementing PSM.

We set our preferred values for TAU as you can see in the next image. And in our code we call lte_lc_psm_req(true);  when configuring the modem.

We understand that the network is overriding the TAU values.

From this I can tell that TAU is 180 min and Active Timer is disabled.

My questions are:

1. Will my modem go into sleep mode immediately? 

2. How can we verify that my modem is sleeping?

Any information that will help us broaden our knowledge will be appriciated.

Regards.

[Albrecht Markus Schellenberger]

zabdielfavela said:

First of all, thank you for your reply.

My pleasure, Zabdiel :-) I’m glad I can help.

zabdielfavela said:

I truly appriciate your time and effort to help me understand these concepts.

Yes, there is a lot of information available and sometimes it’s not that easy to find the specific parts needed. So let me try to narrow it down a little bit for you:

zabdielfavela said:

1. Is there any chance that the device could enter PSM even if it doesn't have a valid Active Time?

No. If the network doesn’t assign a valid <Active-Time> to the UE, PSM is not allowed. With that said, some networks allow an active time of zero, corresponding to the value 000 00000.

zabdielfavela said:

2. What is the difference between CEREG and XMONITOR?

+CEREG basically is the network registration status. You can configure it subscribe unsolicited result codes, meaning that the modem will send +CEREG updates if something has changed. +CEREG will feedback the <Active-Time> negotiated with the network during registration, but to read the <Periodic-TAU> value you should use %XMONITOR. This due to that <Periodic-TAU> is used in different formats.

%XMONITOR are the configured modem parameters. It is similar to +CEREG, but as already mentioned, will give you some extra information regarding <Periodic-TAU>. For mfw > 1.2.x, the <Periodic-TAU-ext> will show the actual negotiated PSM time, and as confusing as this might be, the value doesn’t necessary match the <Periodic-TAU> value of +CEREG. This is why the description of <Periodic-TAU> in +CEREG also states “The configured value of T3412 can be read with the %XMONITOR command.”.

zabdielfavela said:

3. To verify that my modem is sleeping you suggested %XMODESLEEP. Is this command similar or related to Modem sleep and TAU prewarning notifications (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.1/nrf/libraries/modem/lte_lc.html?highlight=config_lte_psm#enabling-power-saving-features) ??? 

Yes. The LTE link controller basically is a wrapper that in the end uses AT commands to send and receive information to and from the modem. So there are two ways to go, either you use AT commands directly with your application, or you make help of the e.g. the LTE link controller library. Which way you might want to choose depends a bit on your use case, preferences and needs. If you would like to do the latter, I generally refer to and recommend its documentation, as it covers most of the use cases. Otherwise, see next point.

zabdielfavela said:

4. Do you have some sample code that uses %XMODESLEEP?

We do not have any concrete example here, but you can for instance use our AT Client or Serial LTE modem application to try this. Let me give you a terminal output example with the AT Client:

*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
The AT host sample started
AT+CEREG=5
OK
AT%CESQ=1
OK
AT%XMODEMSLEEP=1,1000,60000
%XMODEMSLEEP: 4,0
OK
AT+CFUN=1
%XMODEMSLEEP: 4,0
OK
%CESQ: 59,2,25,3
+CEREG: 2,"7AA9","01444000",7
+CEREG: 1,"7AA9","01444000",7,,,"00001010","11000001"
AT%XMONITOR
%XMONITOR: 1,"","","24201","7AA9",7,20,"01444000",177,6400,58,43,"","00001010","11000001","01011111"
OK
%CESQ: 255,0,255,0
%XMODEMSLEEP: 1,1151979975

Otherwise, if you want your application to communicate directly with the modem using AT commands, you can us the AT interface of our modem library.

I hope my answer will help you.

Regards,

Markus

[zabdielfavela]

Thanks again for your prompt reply.

My team and I redacted the attached document that describes PSM as we understand it. We would appreciate if you read it and pointed out any gaps in our understanding.
We also came up with more questions:

1. What happens when we send data before the periodic TAU timer is up? Will the TAU timer restart or will it continue with the remaining time from the previous cycle?
2. We’ve come up with an indirect way to detect modem transition into PSM. First we subscribe to RSRP notifications. Next, we query the signal connection status (CSCON). And if the connection state is IDLE, then we judge sudden signal values of 255 as modem entering deep sleep.
   Do you think our method detects PSM accurately?
3. In one of your replies you said: “If the network doesn’t assign a valid <Active-Time> to the UE, PSM is not allowed.”
   We understand that receiving either invalid TAU or Active timer means that PSM is not allowed. Is there another way to verify that network doesn’t support PSM? If we receive valid timer values, should we assume PSM is supported? If not, is there a way to verify PSM is supported?

I want to thank you once again for your help.

Regards,

Zabdiel

PSM Understanding and questions.pdf