Why not always use Proprietary PSM instead of regular PSM?

[droberson]

To preface:

• nRF9151DK
• Modem firmware: mfw_nrf91x1_2.0.2
• nRF Connect SDK / Toolchain: 2.9.0
• Terminal app: PuTTY
• Carrier: Verizon and T-Mobile
• Device application will always initiate the data connection

Hello,

I have a few questions about PSM. I am new to PSM, eDRX, and CAT-M in general.

Question 1: Why not use proprietary PSM all the time for devices that always initiate the data connection instead of using standard PSM on the network?

It seems like using proprietary PSM all the time instead of network PSM would eliminate cases where poor cellular coverage or roaming results in the network not granting PSM mode to the modem.

Question 2: Is there documentation from Nordic that details which PSM method is better, and the pros and cons of each?

The only documentation I see is in the AT command reference guide, which is minimal: https://docs.nordicsemi.com/bundle/ref_at_commands_nrf91x1/page/REF/at_commands/intro_nrf91x1.html 

The application for the product I am currently working on will send a chunk of data to a server every 3 minutes. The modem should enter its lowest power state between these 3-minute intervals after sending the data.

Thanks,

Derek

[droberson]

Hey Dejan,

I have returned to the office. I do not have a roaming SIM that doesn't support PSM, unless the SIMs included with the nRF9151DK do not support PSM?

Is there no other way to test proprietary PSM fallback?

Thanks,

Derek

[droberson]

Hey Achim,

Thanks for the info! I have reached out to our eSIM OEM regarding write cycles in PSM. I will update this post when I get an answer.

Thanks,

Derek

[droberson]

I managed to test PSM fallback by using a CAT-1 T-Mobile SIM. If you have a CAT-! T-Mobile SIM that uses the APN "fast.t-mobile.com", this APN does not support PSM as confirmed to me directly by T-Mobile.

To enable proprietary PSM, I simply defined CONFIG_LTE_PROPRIETARY_PSM_REQ=y in my prj.conf. This will send the appropriate AT commands to enable this feature automatically on modem power up.

Test results:

CONFIG_LTE_PROPRIETARY_PSM_REQ=n

CONFIG_LTE_PROPRIETARY_PSM_REQ=y

The small current spikes between the large spikes are a 5 second watchdog feed. Other than that, between each 5 second spike, the PSM floor current is ~2.77 uA just like regular PSM granted by the network.

Cool beans!

Edit: Forgot to mention that T-Mobile confirmed to me today that their network does not support RAI (Release assistance indication) as I observed during my testing. Per T-Mobile:

"It seems that the feature is not enabled either for NB-IoT. I asked the RAN team to investigate it and they will add it to the list of features to test and deploy."

Derek

[Achim Kraus]

"T-Mobile ... does not support RAI (LTE-M) ... not enabled either for NB-IoT".

Here in (south) Germany, 26201 (Telekom T-Mobile Germany) offers:

26201 NB-IoT CP-RAI

26201 LTE-M no RAI

[droberson]

Ah, that's good to know! Maybe their comment is specific to USA, which I am located. During my testing, I could see that RAI was not occurring by looking at the current consumption graph after my application uploaded all data and closed the socket. High current was being drawn for the entire RRC inactivity timeout period (~5 seconds) before entering PSM. When using a Verizon SIM, I could see RRC inactivity timeout take about ~2 seconds instead of the full 5 configured by the network, indicating that RAI was working.