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