Role of Active Time in PSM requests, granted values?

Hello Devzone Community,

I am continuing my long trek toward single-microamp operation of an nRF9160 based, custom board.  On the LTE modem front I am making `AT+CPSMS=` requests per the instructions at https://infocenter.nordicsemi.com/topic/ref_at_commands/REF/at_commands/nw_service/cpsms_set.html.  In general my nRF9160 based modem is not granted PSM values, at least not ones I request.  But in some attempts I am granted a non-zero, apparently valid periodic-TAU value, at least according to a Devzone engineering reply to my recent earlier Devzone ticket 87176.

Since posting ticket 87176 I have run multiple tests requesting a range of periodic-TAU values (a different one in each test), and a range of Active Time values.  Most of the time my device is not granted either periodic-TAU or Active Time.  This brings me to new questions:

Question (1)  in setting PSM values which provide single-microamp SiP (9160) operation, is Active Time required to be granted, or is a non-zero enabled periodic-TAU setting sufficient?

It looks like the timer for Active Time remains disabled following the various settings requests I send via LTE modem and the command `AT+CPSMS`.

Question (2)  Is leftmost printed PSM bit most significant or least significant in the final three quoted values reported by `AT%XMONITOR`?

You may notice in ticket 87176 the second response to my case there speaks to the network carrier granting my device a 54 minutes periodic-TAU value.  When I parse the bits on scratch paper, following Nordic's CPSMS_SET documentation linked just above here, I arrive at two different periodic-TAU values.  My figured periodic-TAU values differ no matter which bit I treat as the most significant bit:

01001001

010:  treating these as bits 8,7,6 "timer value unit" gives ten hours,

01001:  treating these as timer (count down) value gives 9, 

Ten hours * 9 equals 90 hours.  This doesn't match Devzone Hakon's (~2790 pts) reply that we are granted 54 minutes periodic-TAU.



Reading bit significance the other way:

100:  bits 8,7,6 now represent timer value unit of 30 seconds,

10010:  bit 5..0 now represent 18.

Half a minute * 18 equals 9 minutes periodic-TAU.

When AT%XMONITOR returns a string like this,

%XMONITOR: 5,"AT&T","AT&T","310410","900C",7,12,"050B8210",391,5110,33,25,"","00001000","11100000","01010100"

. . . it is critical that I know which bit in the final three bit fields is MSB, and which LSB.  Much of the time these values are reported as "11100000".  When left most bit is most significant, per AT+CPSMS "set" documentation this represents that the periodic-TAU timer is disabled.  I'm told this mean PSM is not supported by a given celular provider.  Reading bits from right as MSB to left results in a periodic-TAU of 70 minutes ( 7 timer value * 10 minute timer value unit ), not 54 minutes.

Clear answers to these two questions will help much.  Thanks ahead of time for insight and help the Devzone team can offer on this issue!

- Ted

Parents
  • Hi,

    Question (1)  in setting PSM values which provide single-microamp SiP (9160) operation, is Active Time required to be granted, or is a non-zero enabled periodic-TAU setting sufficient?

    If PSM is granted by the network, you will be given a valid Active Time.

    "When the UE wants to use the PSM it shall request an Active Time value during every Attach and TAU/RAU
    procedures. If the network supports PSM and accepts that the UE uses PSM, the network confirms usage of PSM by
    allocating an Active Time value to the UE." 3GPP TS 23.682

    Question (2)  Is leftmost printed PSM bit most significant or least significant in the final three quoted values reported by `AT%XMONITOR`?

    You may notice in ticket 87176 the second response to my case there speaks to the network carrier granting my device a 54 minutes periodic-TAU value.  When I parse the bits on scratch paper, following Nordic's CPSMS_SET documentation linked just above here, I arrive at two different periodic-TAU values.  My figured periodic-TAU values differ no matter which bit I treat as the most significant bit:

    Here things get a bit more complicated, and it ("it" being how to read AT commands) also depends on which modem FW version you are using. From the %XMONITOR response, it looks like you are using 1.3.0 or newer. So the following will be based on mfw v1.3.0.

    %XMONITOR: 5,"AT&T","AT&T","310410","900C",7,12,"050B8210",391,5110,33,25,"","00001000","11100000","01010100"

    In the above response (in mfw 1.3.0), the three last parameters will be "Active Time", "Periodic TAU extended" and "Periodic TAU", in that order.

    Before we continue, a quick comment on +CEREG responses. The "Periodic TAU" field in +CEREG responses is referred to as "Periodic TAU extended". This is due to how it is named in the 3GPP specification. It should not be confused with the "Periodic TAU" field in the %XMONITOR responses, despite having the same name.

    The same is also true if you are using a modem fw older than 1.3.0. Then the "Periodic TAU" field in the %XMONITOR response refers to the "Periodic TAU extended" value in newer modem fw versions.

    The encoding of the three fields are different, but for all three the first 3 bits (when read from left to right) will be the unit, and the last 5 will be the value. The Active Time is encoded as a GPRS timer 2 information element. The Periodic TAU extended field is encoded as a GPRS timer 3 event. And the Periodic TAU field is encoded as a GPRS timer information element. However, the encoding of the GPRS timer 2 and GPRS timer values are the same.

    This means that both the Active Time, and the Periodic TAU values are decoded according to this table:

    Active Time: "00001000"
    Unit: "000" = multiples of 2 seconds
    Value: "01000" = 8
    
    So the Active Time becomes 8 * 2s = 16 seconds
    

    Periodic TAU: "01010100"
    Unit: "010" = multiples of decihours (6 minutes)
    Value: "10100" = 20
    
    So the Periodic TAU becomes 20 * 6m = 120 minutes = 2 hours

    The Periodic TAU extended on the other hand is decoded with this table:

    Periodic TAU extended: "11100000"
    Unit: "111" = deactivated
    Value: "00000" = 0/Not relevant

    As for which one you should use of the extended and non-extended Periodic TAU values: If the extended version is not deactivated, you should use that, and ignore the non-extended version.

    However, not all networks have started to use the extended version yet, and will use the non-extended version instead. So if the Active Time is set, and the extended version is deactivated, you should use the non-extended version to see your Periodic TAU interval.

    . . . it is critical that I know which bit in the final three bit fields is MSB, and which LSB.  Much of the time these values are reported as "11100000".  When left most bit is most significant, per AT+CPSMS "set" documentation this represents that the periodic-TAU timer is disabled.  I'm told this mean PSM is not supported by a given celular provider.  Reading bits from right as MSB to left results in a periodic-TAU of 70 minutes ( 7 timer value * 10 minute timer value unit ), not 54 minutes.

    Note that +CPSMS also only use the extended version of the timers. You can therefore not use the table given in the +CPSMS documentation to calculate the value of the non-extended version given by %XMONITOR.

    Best regards,

    Didrik

Reply
  • Hi,

    Question (1)  in setting PSM values which provide single-microamp SiP (9160) operation, is Active Time required to be granted, or is a non-zero enabled periodic-TAU setting sufficient?

    If PSM is granted by the network, you will be given a valid Active Time.

    "When the UE wants to use the PSM it shall request an Active Time value during every Attach and TAU/RAU
    procedures. If the network supports PSM and accepts that the UE uses PSM, the network confirms usage of PSM by
    allocating an Active Time value to the UE." 3GPP TS 23.682

    Question (2)  Is leftmost printed PSM bit most significant or least significant in the final three quoted values reported by `AT%XMONITOR`?

    You may notice in ticket 87176 the second response to my case there speaks to the network carrier granting my device a 54 minutes periodic-TAU value.  When I parse the bits on scratch paper, following Nordic's CPSMS_SET documentation linked just above here, I arrive at two different periodic-TAU values.  My figured periodic-TAU values differ no matter which bit I treat as the most significant bit:

    Here things get a bit more complicated, and it ("it" being how to read AT commands) also depends on which modem FW version you are using. From the %XMONITOR response, it looks like you are using 1.3.0 or newer. So the following will be based on mfw v1.3.0.

    %XMONITOR: 5,"AT&T","AT&T","310410","900C",7,12,"050B8210",391,5110,33,25,"","00001000","11100000","01010100"

    In the above response (in mfw 1.3.0), the three last parameters will be "Active Time", "Periodic TAU extended" and "Periodic TAU", in that order.

    Before we continue, a quick comment on +CEREG responses. The "Periodic TAU" field in +CEREG responses is referred to as "Periodic TAU extended". This is due to how it is named in the 3GPP specification. It should not be confused with the "Periodic TAU" field in the %XMONITOR responses, despite having the same name.

    The same is also true if you are using a modem fw older than 1.3.0. Then the "Periodic TAU" field in the %XMONITOR response refers to the "Periodic TAU extended" value in newer modem fw versions.

    The encoding of the three fields are different, but for all three the first 3 bits (when read from left to right) will be the unit, and the last 5 will be the value. The Active Time is encoded as a GPRS timer 2 information element. The Periodic TAU extended field is encoded as a GPRS timer 3 event. And the Periodic TAU field is encoded as a GPRS timer information element. However, the encoding of the GPRS timer 2 and GPRS timer values are the same.

    This means that both the Active Time, and the Periodic TAU values are decoded according to this table:

    Active Time: "00001000"
    Unit: "000" = multiples of 2 seconds
    Value: "01000" = 8
    
    So the Active Time becomes 8 * 2s = 16 seconds
    

    Periodic TAU: "01010100"
    Unit: "010" = multiples of decihours (6 minutes)
    Value: "10100" = 20
    
    So the Periodic TAU becomes 20 * 6m = 120 minutes = 2 hours

    The Periodic TAU extended on the other hand is decoded with this table:

    Periodic TAU extended: "11100000"
    Unit: "111" = deactivated
    Value: "00000" = 0/Not relevant

    As for which one you should use of the extended and non-extended Periodic TAU values: If the extended version is not deactivated, you should use that, and ignore the non-extended version.

    However, not all networks have started to use the extended version yet, and will use the non-extended version instead. So if the Active Time is set, and the extended version is deactivated, you should use the non-extended version to see your Periodic TAU interval.

    . . . it is critical that I know which bit in the final three bit fields is MSB, and which LSB.  Much of the time these values are reported as "11100000".  When left most bit is most significant, per AT+CPSMS "set" documentation this represents that the periodic-TAU timer is disabled.  I'm told this mean PSM is not supported by a given celular provider.  Reading bits from right as MSB to left results in a periodic-TAU of 70 minutes ( 7 timer value * 10 minute timer value unit ), not 54 minutes.

    Note that +CPSMS also only use the extended version of the timers. You can therefore not use the table given in the +CPSMS documentation to calculate the value of the non-extended version given by %XMONITOR.

    Best regards,

    Didrik

Children
  • Hello Didrik,

    Thank you for this detailed answer set and thorough explanation.  During the past week I have been testing further with some modified firmware branches, attempting to request and be granted extended periodic-TAU and Active Timer settings.  While I have learned some things -- and your info helps a lot -- I have made little practical headway.  Let me be sure I have the salient details correct from your reply nine days ago:

    (1)  AT+CPSMS=". . ." sets the value of periodic-TAU extended which the modem will request

    (2)  AT+CEREG? reports Active Time and periodic-TAU extended as its final two parameters

    (3)  AT%XMONITOR reports Active Time, periodic-TAU extended, periodic-TAU as its final parameters

    Is this summary correct?

    I happen to be running with modem firmware version 1.3.1, and I understand older modem firmware versions produce slightly different AT command responses.

    Given trouble I have encountered as I attempt PSM requests, in ticket 87734 I asked whether there is some additional AT command sequencing I must employ either before, around, or after I issue AT+CPSMS="...".  From Devzone Engineers reply to this ticket I learned that I must call AT+CPSMS= while the LTE modem is powered down, that is, with AT+CFUN=0. 

    Question - Is it correct to say that only as Nordic's LTE modem in the nRF9160 goes through its power up, boot time sequence, that the modem is able to negotiate PSM with network operator?

    I have noticed another thing in AT%XMONITOR reported values.  Much of the time, AT%XMONITOR returns for me a string like the following:

    %XMONITOR: 5,"","","310260","3558",7,12,"02BDF917",397,5035,42,40,"","11100000","11100000","01001001"

    The final value here is the now-for-me infamous fifty four minutes periodic-TAU, the only possibly valid PSM periodic-TAU I have been able to observe over several days.  But there were one or two times where %XMONITOR returned:

    %XMONITOR: 5,"AT&T","AT&T","310410","900C",7,12,"050B8210",391,5110,29,21,"","00110000","11100000","00110000"

    Fields two and three read "AT&T", a known network operator or provider name.  In the absence of LTE modem having established a named provider like this, is my hardware only connected to a celular tower?  Connected but not yet registered on a celular network?

    I am unsure of the correct terms and "pieces", named network elements here.  It looks like AT%XMONITOR returns <full_name> and <short_name> of operator in fields two and three.  Please forgive my possibly poorly worded question.  I am wondering though whether I cannot update and change PSM values because my nRF9160 based hardware is connected to a local tower but does not report any operator full name or short name?

    If you can clarify these questions I believe I'll be able to determine the sequence(s) of AT commands I must issue and to which respond, in the situations I encounter on west coast of North America.

    Thank you much for your help thus far, Didrik.  Will continue on and await next reply.  Stay safe,

    - Ted

  • tedhavelka said:

    (1)  AT+CPSMS=". . ." sets the value of periodic-TAU extended which the modem will request

    (2)  AT+CEREG? reports Active Time and periodic-TAU extended as its final two parameters

    (3)  AT%XMONITOR reports Active Time, periodic-TAU extended, periodic-TAU as its final parameters

    Is this summary correct?

    Yes. Although, it might be more precise to say that AT+CPSMS sets the periodic-TAU value the modem will request in the "periodic-TAU extended format". And then the network replies with either the extended or the non-extended version.

    tedhavelka said:

    From Devzone Engineers reply to this ticket I learned that I must call AT+CPSMS= while the LTE modem is powered down, that is, with AT+CFUN=0. 

    Question - Is it correct to say that only as Nordic's LTE modem in the nRF9160 goes through its power up, boot time sequence, that the modem is able to negotiate PSM with network operator?

    That isn't quite what my colleague said. Here are the relevant quotes:

    "at+cpsms=1,,,"00100010","00000101" should be commanded before CFUN=1. Otherwise it's not negotiated in LTE attach procedure."

    "UE negotiates the PSM usage with the network and network can approve or reject it. The negotiation is done during the registration (i.e. Attach procedure) or if PSM is configured later then UE initiates TAU procedure for the negotiation."

    When connected to a network, the device (referred to as the UE (User Equipment) in the spec) must perform Tracking Area Updates (TAUs) at regular intervals (technically, a TAU must be performed within a certain time period after the device enters RRC Idle). The device can request a specific TAU period when it first attaches (the technical word for connects) to the network, and when performing TAUs. It is then up to the network to decide which value (if any) is granted.

    So, to use as little power as possible, you should request PSM before you connect to the network. If you request PSM after connecting, the modem will perform a TAU so that it can request PSM from the network.

    In short, you can use AT+CPSMS whenever you want, but we recommend that you use it before you start searching for a network.

    tedhavelka said:
    In the absence of LTE modem having established a named provider like this, is my hardware only connected to a celular tower?  Connected but not yet registered on a celular network?

    No, you are connected to a network at that point. The operator name is optionally provided by the network. In this case, it looks like T-Mobile doesn't provide the operator name to the device.

    As for what PSM values you can get, that is fully up to the network operator, and you must try to ask them. Note that it is not uncommon that roaming devices are not granted PSM at all.

  • Hello Didrik,

    Thank you for your clarifying answers, and corrections to some of my questions.  This raises a few new questions.  Your first addressed point says that AT+CPSMS sets a value which UE will request as, among other things, periodic-TAU extended.  An MNO may grant the extended version of periodic-TAU, the original more limited version, or none at all.

    Question (1)  when granted periodic-TAU must UE firmware send a combination of AT+CEREG? and AT%XMONITOR to distinguish between which version of periodic-TAU is granted?

    In your reply on 2022 May 2, tables for periodic-TAU bit encoding and periodic-TAU extended bit encoding both give byte size fields to hold the encoded values.  If my device is granted one of these, how can I in firmware determine the version, so that firmware can then decode and determine the sleep period in seconds?  Both encoded bit fields are eight bits long, and it looks like there could be overlapping or like bit patterns between the two encodings.

    Question (2)  is LTE modem "off" mode the only mode from which to ideally request PSM?  I understand the need to request PSM before searching for a network, and before connecting.  In earlier Devzone post 86897 Albrecht Markus Schellenberger indicates that cycling LTE modem between AT+CFUN=0 and AT+CFUN=1 causes wear on an NVRAM element of the modem:

       "Turning off the modem causes NVM wear, so my recommendation is to set it into flight mode using AT+CFUN=4."

    Question (3)  may we equivalently command AT+CPSMS= while modem is in flight mode, as your team mate describes commanding while modem is completely off?  (To spare NVRAM wear)

    Maybe I should ask too, when modem is off e.g. AT+CFUN=0 then we are guaranteed to be in disconnected state?  Modem in flight mode might be connected?

    Question (final)  how do you indent parts of my previous reply with your answers, here in the web based forum post editor?  This formatting is helpful.  It gives your answers better context, especially in these longer ticket replies.

    - Ted

  • tedhavelka said:
    Question (1)  when granted periodic-TAU must UE firmware send a combination of AT+CEREG? and AT%XMONITOR to distinguish between which version of periodic-TAU is granted?

    %XMONITOR contains all information that +CEREG does, except for any potential reject causes. The advantage of +CEREG is that you can get notifications, while %XMONITOR will give you the non-extended periodic TAU value along with more information.

    As for which numbers to use, here is what I do:

    1. To see if the device were granted PSM, see if the Active Time is valid (not 1110000). Decode the Active Time to get the duration of the active time.

    2. If PSM was granted, and the extended Periodic Time paramter is set, use that one.

    3. If PSM was granted, but the Periodic-TAU-ext was disabled (11100000), use the non-extended version.

    If you want the notifications of +CEREG, this means that you only need to use %XMONITOR if the Periodic-TAU field in the +CEREG notification (which really is the extended version) is set to 11100000.

    tedhavelka said:

    Question (2)  is LTE modem "off" mode the only mode from which to ideally request PSM?  I understand the need to request PSM before searching for a network, and before connecting.  In earlier Devzone post 86897 Albrecht Markus Schellenberger indicates that cycling LTE modem between AT+CFUN=0 and AT+CFUN=1 causes wear on an NVRAM element of the modem:

       "Turning off the modem causes NVM wear, so my recommendation is to set it into flight mode using AT+CFUN=4."

    As far as I know, the only difference in the modem between +CFUN=4 and +CFUN=0 is that when you use +CFUN=0, the modem will store the current network parameters to flash. Note that if the modem is offline (via either +CFUN=4 or +CFUN=0), and you change some parameters (e.g. requested PSM parameters) they are not stored to flash unless you issue AT+CFUN=0 again.

    tedhavelka said:
    Maybe I should ask too, when modem is off e.g. AT+CFUN=0 then we are guaranteed to be in disconnected state?  Modem in flight mode might be connected?

    After you receive an "OK" response to either AT+CFUN=0, AT+CFUN=4 or AT+CFUN=20 you are disconnected from the network.

    tedhavelka said:
    Question (final)  how do you indent parts of my previous reply with your answers, here in the web based forum post editor?  This formatting is helpful.  It gives your answers better context, especially in these longer ticket replies.

    You can quote text by marking it with your mouse, then press the "Quote" button that appears.

Related