Parameter meanings in 2022-05-04 LPWAN Coverage doc, PSM and eDRX columns?

[tedhavelka]

Hello Devzone,

My name is Ted, and I recently came across a 2022 May 4 LPWAN Coverage document on one of Nordic Semi's technical guides.  The specific guide is titled iBases ESIM International Coverage Update.  But I am confused by the meaning of the value pairs in the right most four columns.  Looks like these are in units of seconds, which makes sense for at least the two columns number 9 and 10 from left, where "PSM T3412 and T3324" appears above these columns.

What do these values represent?  Are these maximum supported timer periods, and shorter periods are possible?  In what way do these values define which periodic Tracking Area Update (periodic-TAU), Active Time and eDRX values we can expect to be granted in our given geographies?

Some background to these questions:

I've posted some related tickets to this question recently:  87176, 87451, 87734, but I am still having trouble obtaining any non-zero T3412 and T3324 timer values.  I'm working in a large metropolitan area with population of roughly two million, between Seattle and the Bay Area on United States west coast.  At least one of the major Mobile Network Operators listed in the United States rows of the LPWAN coverage document operates in our city.  Given this I surmise that at least for LTE-M type network registration I should be able to see my nRF9160 based device be granted some valid periodic-TAU and Active Time values.

Per ticket 87451 I am performing the AT command sequence to first turn off modem, then request a PSM, then turn modem on:

AT+CFUN=0

AT+CPSMS=1,,,"00010010","00001111"   . . . periodic-TAU of 180 minutes, active time ( 2 sec * 15 ) = 30 seconds

AT+CFUN=1

Entering these commands by hand there is plenty of delay, so I am confident the modem is off by the time I enter my PSM values to request from the MNO.  I check modem status and granted values as per the above linked Devzone tickets, namely by issuuing AT+CFUN?, AT+CEREG=5 followed by AT+CEREG?, AT%XMONITOR.  Command AT+CGDCONT? tells me whether my device registered with any network or not.  I almost never see either full name or short name of the MNO, two parameters which AT%XMONITOR returns.

I have tried multiple different values for periodic-TAU and Active Time.  I'm searching for ones which local MNO will grant.

Command AT+CEREG? consistently returns "11100000", "11100000" as its last two fields.  This looks like bad news to me.  Until I can learn correct AT command sequence, and confirm or disconfirm local network provider support I cannot enjoy the battery-enabling low power support touted as one of the nRF9160's greatest design features.  All clarifying help to these questions appreciated!

- Ted

[Albrecht Markus Schellenberger]

Hello Ted,

What do these values represent?  Are these maximum supported timer periods, and shorter periods are possible?

Referring to the nRF91 AT Commands section. T3412 is the Tracking Area Update timer, while T3324 is the Active Time timer. This should be the minimum values, but since each carrier has their own standards & requirements, I’m not a hundred percent sure, though.

Command AT+CEREG? consistently returns "11100000", "11100000" as its last two fields.  This looks like bad news to me.  Until I can learn correct AT command sequence, and confirm or disconfirm local network provider support I cannot enjoy the battery-enabling low power support touted as one of the nRF9160's greatest design features.  All clarifying help to these questions appreciated!

Could you please provide me with a full application log starting from device boot, including AT+CPSMS configuration, +CEREG notifications level 5 and a %XMONITOR update after the device has connected to the network?

Thanks & regards,

Markus

[tedhavelka]

Good evening / good morning Albrecht,

Just to let you know, while I am still at the start of learning LTE modem configuration and practical uses I am familiar with the purpose of the two nRF9160 modem timers T3412 and T3324.  The bit-wise configurations available to set various periodic-TAU periods and Active Time periods implies to me that end users of the nRF9160 and celular networks are supposed to have ranges of timing values from which to choose.  This would support varying power constraint needs, and connectivity / end user update expectations for a product out in a given geography.

The last four columns in the coverage document are poorly labeled.  There's mention of timers T3412 and T3324, but no explanation what the single value pairs represent in those columns.  Also no explanation what it means when a table cell in these columns is left blank.

My team has reached out to iBasis support to ask about this.  If we find clarity on these questions I'll be sure to update our ticket 87980 here.

Regarding a full application log, I'll see what I can do.  A little background:  I'm running firmware on a custom board.  Firmware is built against ncs v1.6.1, which includes Zephyr RTOS release 2.6.0.  We got everything working in the aws_iot sample app and added functionality beyond that.  So we're confident that we can do a lot of the "normal power" LTE-M based activities, sensing, building and sending MQTT packets, and seeing those packets reach an AWS cloud account.

For app logging my limitation right now is that I bring out UART2, not UART0 on a couple of 1v8 to 3v3 level shifted pins.  We had trouble finding a 1v8 version FTDI cable, so I'm limited where I can connect a terminal emulator to our board under development.  Using UART2 I don't get to directly see the messages which are automatically generated by the modem.  The modem appears to be automatically configured to use UART0.  That is where I would otherwise see modem notices to which I subscribe.  Keypress input to UART0 is consumed by the AT command handler library when that's enabled.  On my alternate UART2 I can see responses when I call Nordic library API routine named `at_cmd_write()`, and capture the command result in a char buffer.  But you are asking for a capture of activities which are happening at start time and otherwise without my direct or application space intervention.

Though I tried a few weeks to get RTT link working during Devzone ticket 85747, I have never been able to see RTT work.  I believe that is another way I could see the full app log.  I program and debug with a Segger JLink.  I have Segger's command line tools installed in /opt/SEGGER/JLink_V760g, and others of them such as the debugger function correctly.  Resolving my RTT challenge will be for another Devzone ticket.

What I can do is configure the present IOs for UART0 and send you what I can see there.  But this leads me to the question, is it true that no matter the modem's state there is an AT command sequence I can issue to cause the modem to negotiate PSM values of my choosing?

This is the key question I pose in ticket 87734.  It looks like I must ask, is there some start up AT command sequence I do not normally see, which could make it impossible to configure the modem to negotiate a new, arbitrary set of PSM values on its next power up event?

To be clear, I recognize that for modem "to negotiate" PSM settings and "to receive" them are two different things.  I can only ask for how to properly negotiate them, which apparently occurs only at registration time with the mobile network operator (MNO) and at end of periodic tracking update period.  It is up to the MNO to provide them or not.

As we develop our product firmware we expect to move further away from sample app code.  We anticipate not only needing, but getting to write our own AT command sequence code.  So we need to know what might be well summarized in a state machine type diagram:  how to get the modem to point of negotiating for our device's best PSM values.  Can the Devzone Team share a document or instruction which covers this?  I've already shared excerpts of my manual AT command sequences, and I thought the feedback here was that I was "doing it right" in the latest iteration.  But sounds like there may be further conditions or a caveat to this.

Thank you for your help so far.  Working on the app log capture . . .

- Ted

[Albrecht Markus Schellenberger]

Hello Ted,

tedhavelka said:

But this leads me to the question, is it true that no matter the modem's state there is an AT command sequence I can issue to cause the modem to negotiate PSM values of my choosing?

Yes. Referring to the documentation of +CPSMS.

tedhavelka said:

It looks like I must ask, is there some start up AT command sequence I do not normally see, which could make it impossible to configure the modem to negotiate a new, arbitrary set of PSM values on its next power up event?

No. You have to decide for yourself if your application configures PSM values via +CPSMS before or after setting the modem to normal operation mode. My recommendation would be before. As the documentation states:

The command configuration is stored to NVM approximately every 48 hours and when the modem is powered off with the +CFUN=0 command.

Meaning, once configured and stored in the NVM, the modem will negotiate the same PSM values during each connection attempt.

tedhavelka said:

So we need to know what might be well summarized in a state machine type diagram:  how to get the modem to point of negotiating for our device's best PSM values.  Can the Devzone Team share a document or instruction which covers this? 

PSM is a 3GPP standard, hence we do not provide own documentation regarding this topic. The values depend primarily on each individual use case and more important if the carrier supports them.

Regards,

Markus

[tedhavelka]

Hi Albrecht,

Thank you for the further help.  With all respect, I don't think my original question has been fully answered.  Nordic's Guide on iBasis International Coverage links to a document which summarizes celular coverage information of iBasis across multiple countries.  I asked what the number pairs mean in the last four columns of this document.  You replied that these might be the minimum values.  I am testing this now, making sure I program my nRF9160, ncs v1.6.1 based device to ask for nearest equal or greater periodic-TAU and active time values for USA, Los Angeles region, and carrier AT&T, per the values in second to final row, column nine.

If these values are minimums, this would for example make the minimum supported periodic-TAU period, for USA, Los Angeles region, AT&T carrier, a period of 43 hours.  "156000 sec, 30 sec" are the value pair I read for this locale and carrier.  That seems awfully long as a minimum periodic Tracking Area Update.

Given this, would you please confer with others on your team to see whether anyone knows with certainty what these values mean?

Part of my reason to press this question, AT+CPSMS set command describes a bit-wise encoding which provides 256 possible timer values.  If the coverage doc "T3412 and T3324", and "eDRX" columns are minimum values, that can greatly reduce the number of PSM value combinations I must test.  Also, if those are supported minimums as opposed to maximums, or some other meaning, that can tell me at which end of the ranges of PSM values T3412 and T3324 to begin testing values.

I think that AT command reference is helpful and very descriptive in some regards.  A shortfall for me however, is that in the case of AT+CPSMS notes there, the document does not describe in more basic, plain language that the modem will only negotiate for PSM settings when it registers with a Mobile Network Operator.  It would be helpful, and take only a little more space to add a paragraph which highlights the common sense use cases of AT+CPSMS.  That is, end users and developers are most likely going to need to issue AT+CPSMS while the modem is powered off.

Would be useful also to note that if the modem is on, there will be some longer maybe undetermined wait time before the modem reaches a registration event again.  That event at which the modem has a chance to negotiate user requested PSM settings.

Only mention this for efficiency:  it has taken several days and several posts and exchanges within Devzone posts just to reach this basic learning level on my part.  I think the AT+CPSMS and a few other commands there could benefit from a little more practical context, how and when to apply those commands.  Especially when there are modem state dependencies for some commands to function as desired.

Thanks for reading through all my long winded replies.  Will watch here for updates . . . good weekend to you, Albrecht!

- Ted

[tedhavelka]

PS:  a further wrinkle in my questions about how to correctly request PSM values lies in the presence of two forms of value representation for Nordic modem timer T3412:  periodic-TAU and periodic-TAU extended bit-config encodings.  From this 2022 May 2 reply to my earlier ticket, and the AT+CPSMS command definition I  understand my requests for PSM to be expressing periodic-TAU in extended format.

This is to say, running modem firmware 1.3.1 am an necessarily requested periodic-TAU values in their extended format.  But it is possible the MNO may only grant the lesser periodic-TAU, whose config bits are decoded by a different table.

Again referring to ticket 87451, 2022 May 2 reply the values which AT+CEREG? returns will include only periodic-TAU extended.  That is, I must also issue AT%XMONITOR to see whether the older period-TAU was granted, correct?

I think a Nordic Devzone guide to cover one or two practical ways to determine PSM availability would be useful.  Developers on nearly every continent are now working with Nordic Semi's latest radio components.  I've got to be one of many who are facing this and similar challenges.

- Ted