Why not always use Proprietary PSM instead of regular PSM?

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

  • Hey Dejan,

    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.

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

  • 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

  • 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

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

  • 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

Related