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

[dejans]

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

[droberson]

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

[dejans]

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

[droberson]

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

[dejans]

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

[droberson]

Hey Dejan,

dejans said:

Is your intention to put device into PSM mode and then sleep for 3 minutes, send some data and repeat sleeping and sending sequence?

Answer: Yes

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

dejans said:

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.

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 is skipped altogether
# by using RAI
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

[dejans]

Hi Derek,

droberson said:

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

There should not be any issue waking up early.

droberson said:

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

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

[droberson]

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