Why not always use Proprietary PSM instead of regular PSM?

RE: Why not always use Proprietary PSM instead of regular PSM?

Achim Kraus — Mon, 28 Jul 2025 20:33:26 GMT

Ah, I see.

I just assumed, that on PSM sleep/wakeup it writes once ... but that's just an assumption.

RE: Why not always use Proprietary PSM instead of regular PSM?

droberson — Mon, 28 Jul 2025 20:24:36 GMT

Hey Achim,

I assumed this was how you calculated it, and I was looking for a similar calculation from our eSIM OEM but they couldn't provide it. They couldn't say how many times the eSIM writes to flash on power up, and that this can vary between modem, carrier, etc. They just said that their domestic grade eSIM lifespan averages 3-5 years without providing the math to back this claim up. Frustrating in my opinion, especially from a well known large player in the eSIM space.

Thanks,

Derek

RE: Why not always use Proprietary PSM instead of regular PSM?

Achim Kraus — Mon, 28 Jul 2025 19:40:11 GMT

Thanks for the update!

[quote userid="73492" url="~/f/nordic-q-a/122653/why-not-always-use-proprietary-psm-instead-of-regular-psm/543820"]Whether this will shorten the life of the eSIM below 3 years is unknown[/quote]

I just calculated that by:

every 3 Minutes := 20 per H := 480 per Day and 175200 per Year. With the limit of 500.000 that about 3 Years.

If your eSIM has 1 Million instead of 500.000, then it's about 5.7 Years.

RE: Why not always use Proprietary PSM instead of regular PSM?

droberson — Mon, 28 Jul 2025 17:58:28 GMT

Hey Achim,

Following up on this, our eSIM OEM for this project never gave us specific numbers on the impact of PSM shutting down the eSIM every 3 minutes in regard to NVM wear of the eSIM. However, your comment about eSIM flash endurance is spot on it seems.

Our email chain with our eSIM OEM is marked as "limited distribution", so I will summarize their comments since it likely applies to any eSIM.

Modern domestic grade eSIMs have a 1 M cycle flash endurance and can last 3-5 years. Industrial grade eSIMs can have a 16 M cycle flash endurance and can last 7-10 years. Powering the eSIM on and off every 3 minutes via PSM is considered excessive and is expected to churn flash cycles from their comments. Whether this will shorten the life of the eSIM below 3 years is unknown since it is device / modem dependent according to them.

In summary, our customer has chosen to stick with the domestic grade eSIM for now. For safety, based on our eSIM OEM's comments, I would use an industrial grade eSIM for applications that power the eSIM on and off for short duty cycles such as every 3 minutes using PSM. If your duty cycle is much longer, a domestic grade eSIM is probably fine.

Thanks,

Derek

RE: Why not always use Proprietary PSM instead of regular PSM?

droberson — Mon, 28 Jul 2025 16:45:13 GMT

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.

RE: Why not always use Proprietary PSM instead of regular PSM?

Achim Kraus — Sat, 26 Jul 2025 05:14:28 GMT

"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

RE: Why not always use Proprietary PSM instead of regular PSM?

droberson — Fri, 25 Jul 2025 22:25:06 GMT

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

RE: Why not always use Proprietary PSM instead of regular PSM?

droberson — Thu, 17 Jul 2025 22:54:48 GMT

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

RE: Why not always use Proprietary PSM instead of regular PSM?

droberson — Thu, 17 Jul 2025 22:52:40 GMT

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

RE: Why not always use Proprietary PSM instead of regular PSM?

dejans — Thu, 10 Jul 2025 14:39:00 GMT

Hi Derek,

Regarding proprietary PSM testing, you could try to test it on a live network if you have roaming SIM which does not support PSM.

Best regards,
Dejan

RE: Why not always use Proprietary PSM instead of regular PSM?

Achim Kraus — Tue, 08 Jul 2025 20:45:33 GMT

At least in the past, one side effect of using PSM was the "shutdown" of the SIM. In the past it was also said, that this writes to the SIM, which is usually limited to 500.000 write cycles. If this is still the case, then your approach is in danger of killing your SIM in about 3 years.

RE: Why not always use Proprietary PSM instead of regular PSM?

droberson — Mon, 07 Jul 2025 19:23:33 GMT

Good to know, thanks!

I will be looking forward to your follow-up to the second question. Understood that there will be a delay due to vacation.

Derek

RE: Why not always use Proprietary PSM instead of regular PSM?

dejans — Mon, 07 Jul 2025 17:39:51 GMT

Hi Derek,

[quote user="droberson"]Just to confirm, there is no issue waking up early? Based on my testing, I assume there is no issue.[/quote]

There should not be any issue waking up early.

[quote user="droberson"]Lastly, is the best way to test Proprietary PSM fallback to put the modem in a shield box before RRCConnectionRelease is received? (Same question from my last comment).[/quote]

I will check this internally and get back to you. Please note that further replies might get delayed due to current vacation period.

Best regards,
Dejan

RE: Why not always use Proprietary PSM instead of regular PSM?

droberson — Mon, 07 Jul 2025 15:14:37 GMT

Hey Dejan,

[quote userid="111786" url="~/f/nordic-q-a/122653/why-not-always-use-proprietary-psm-instead-of-regular-psm/541661"]Is your intention to put device into PSM mode and then sleep for 3 minutes, send some data and repeat sleeping and sending sequence?[/quote]

Answer: Yes

Edit: You edited your post while I was writing a reply, so I have updated my comments below.

[quote userid="111786" url="~/f/nordic-q-a/122653/why-not-always-use-proprietary-psm-instead-of-regular-psm/541661"]It is possible for device to wake up from PSM and start sending data at any point. Every time device wakes up and sends data, tracking area update timer is reset.[/quote]

Just to confirm, there is no issue waking up early? Based on my testing, I assume there is no issue.

My PSM, eDRX, and RAI configuration:

# eDRX (Disabled) - Not needed. The iDRX / eDRX phase (RRC Idle mode) is skipped altogether
# by setting the Active Time (T3324) to 0
CONFIG_LTE_LC_EDRX_MODULE=n
CONFIG_LTE_EDRX_REQ_VALUE_LTE_M="0000"

# PSM (Enabled)
# Note that even though the RPTAU interval specified below is longer than the 3-minute app server session,
# this will allow the network to grant the next highest value if it doesn't support the value specified
# below (Currently set to 1 hour)
CONFIG_LTE_LC_PSM_MODULE=y
CONFIG_LTE_PSM_REQ=y
CONFIG_LTE_PSM_REQ_RPTAU="00000110"  # Requested Periodic Tracking Area Update (RPTAU) Interval: 1 hour 
CONFIG_LTE_PSM_REQ_RAT="00000000"    # Requested Active Time (Time in RRC Idle state) - 0 (Don't need to listen)

# RAI (Enabled) - Nordic says it should not be used for TCP connections:
# https://devzone.nordicsemi.com/f/nordic-q-a/89109/use-rai-in-mqtt_simple
#
# However, I have found anecdotal evidence that it does work in the more recent modem
# firmware versions and Nordic SDK:
# https://devzone.nordicsemi.com/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/447268
#
# To verify this, I enabled modem trace and confirmed that the RRCConnectionRelease event occurred
# only after every data session was complete.
CONFIG_LTE_LC_RAI_MODULE=y
CONFIG_LTE_RAI_REQ=y

For using RAI, I do not specify SO_RAI in my socket options when sending data, or anywhere for that matter. It seems to automatically trigger as soon as I close the socket, which is what I want.

Testing with a Power Profiler Kit 2, I can see my configuration working as expected, including RAI.

3-minute interval:

Note: The small spikes are expected as they are the app core waking up to feed a watchdog every 5 seconds.

PSM floor:

RAI is triggered after socket close:

I haven't had a chance to test with Proprietary PSM fallback yet. I will be out of office starting tomorrow and won't be able to test it until I return next week.

Lastly, is the best way to test Proprietary PSM fallback to put the modem in a shield box before RRCConnectionRelease is received? (Same question from my last comment).

Thanks,

Derek

RE: Why not always use Proprietary PSM instead of regular PSM?

dejans — Mon, 07 Jul 2025 14:54:40 GMT

Hi Derek,

PSM interval can be requested but it is determined by the network. The interval specifies how long device can sleep before it needs to perform TAU. It is possible for device to wake up from PSM and start sending data at any point. Every time device wakes up and sends data, tracking area update timer is reset.

Best regards,
Dejan

RE: Why not always use Proprietary PSM instead of regular PSM?

droberson — Fri, 04 Jul 2025 22:01:44 GMT

Hey Dejan,

Good to know! I will test PSM fallback in the coming days with a shield box.

Question: I guess while the modem is uploading data, I can close the shield box before the network issues RRC Release and then see it fall back to proprietary PSM? If this won't work as a valid test case, please let me know.

I have successfully implemented regular PSM in my project. One thing I noticed though is that some Nordic documentation states that the smallest PSM requested interval is 10 minutes:

Source: https://www.youtube.com/watch?v=n2dLagfST44

Timestamp: 8:13

Question: Since my device sends data to the server every 3 minutes, will this be an issue or violate some cell network rules? Is there some rule that says PSM must be used for a minimum of 10 minutes consecutively?

It is my understanding that the modem can wake up early before the TAU timer expires without any negative effect from the network or from a power consumption standpoint, correct?

Thanks,

Derek

RE: Why not always use Proprietary PSM instead of regular PSM?

dejans — Fri, 04 Jul 2025 11:30:50 GMT

Hi Derek,

It is important that no downlink traffic is coming to the device. Device behaves as unreachable from the network side and any potential downlink traffic could cause new registration and extra signalling. As long as there is no downlink data, there should be no concern.

Proprietary PSM is intended to be used in specific use cases where ordinary PSM is not allowed by the network (home or roaming) and connection is always initialized by the device.

When modem fails to enter PSM mode, it can automatically fallback to proprietary PSM but this needs to be configured separately. This can be done either by enabling CONFIG_LTE_PROPRIETARY_PSM_REQ or by calling lt_lc_proprietary_psm_req(). To use proprietary PSM, PSM needs to be configured using AT+CPSMS and proprietary PSM must be enabled using AT%FEACONF.

Best regards,
Dejan

RE: Why not always use Proprietary PSM instead of regular PSM?

droberson — Thu, 03 Jul 2025 18:18:30 GMT

Hey Dejan,

Thanks for the link! I came across this link at some point and lost / forgot about it. Been doing a lot of research the past few days.

In regard to my use case detailed above, it looks like the potential downsides from your link of using Proprietary PSM are the following:

1. If the cellular network notices the device is in proprietary PSM mode, it can "perform local deregistration for the device, which would lead to a new registration and extra signaling when the device wakes up. The operator can take some unwanted actions if a large number of devices are constantly unreachable when there is downlink data to be sent to the devices."

2. The Tracking Area Update (TAU) timer T3412 is typically "shorter when PSM is not used."

Edit: I will need to test that if when PSM is disabled, that the TAU timer doesn't get set to less than 3 minutes. Otherwise, this will require a shorter PSM interval or re-registration each time the modem wakes up to send data.

This leads to the following additional questions:

Question 3: In regard to downside #1 highlighted above, if there is no "downlink data" pushed from a client server, then #1 is of no concern, correct?

Question 4: What happens when the modem fails to enter PSM mode due to poor cellular connectivity or roaming, does the modem use the proprietary PSM mode as a fallback? If so, is this operation automatic so long as PSM is enabled or is there some other configuration needed by me?

Thanks,

Derek

RE: Why not always use Proprietary PSM instead of regular PSM?

dejans — Thu, 03 Jul 2025 12:24:56 GMT

Hi Derek,

Proprietary PSM is used when network does not allow regular PSM. Please refer to proprietary PSM documentation. In proprietary PSM mode it is expected that device always initiates data connection.

Best regards,
Dejan