SO_RAI_NO_DATA still does not cause RRC release

[Michal Mühlpachr]

Issue is related to  RE: NRF_SO_RAI_NO_DATA does not cause RRC release in SLM/nrf9160 without send 

Just after AT#XSOCKETOPT=1,50 modem should negotiate RRC Release, but it is not the case.

NCS v2.3 nrf9160_1.3.4

Serial LTE Modem, prj.conf changes:
CONFIG_SLM_START_SLEEP=y
CONFIG_SLM_WAKEUP_PIN=6
CONFIG_SLM_INDICATE_PIN=2
CONFIG_SLM_DATAMODE_URC=y
CONFIG_SLM_EXTERNAL_XTAL=y
CONFIG_NRF_MODEM_LIB_TRACE=y

Modem Trace: trace-2023-03-15T22-56-29.105Z.bin

AT dialogue and PPKII measurements:

[PPK2] DUT Powered, Measurement started
   0.13 <RESET> Wed Mar 15 23:56:33 2023
   1.01 [PPK2] 100k/s AVG   4.02 mA    Max  28.6  mA
   1.25 <INDICATE transition> -> High
   2.03 [PPK2] 100k/s AVG   2.21 mA    Max  29.8  mA
   3.01 [PPK2] 100k/s AVG   0.002mA    Max   0.009mA
   4.02 [PPK2] 100k/s AVG   0.002mA    Max   0.008mA
   4.26 <WAKEUP>
   5.02 [PPK2] 100k/s AVG   1.11 mA    Max  24.5  mA
   5.60     [RX] Ready
   5.60 [TX] AT
   5.61     [RX] OK
   5.61 [TX] AT+CFUN=0
   5.77     [RX] OK
   5.77 [TX] AT%MDMEV=1
   5.78     [RX] OK
   5.78 [TX] AT%XPOFWARN=1,30
   5.80     [RX] OK
   5.80 [TX] AT%XTEMPHIGHLVL=60
   5.81     [RX] OK
   5.81 [TX] AT%HWVERSION
   5.81     [RX] %HWVERSION: nRF9160 SICA BQA
   5.81     [RX] OK
   5.81 [TX] AT%SHORTSWVER
   5.83     [RX] %SHORTSWVER: nrf9160_1.3.4
   5.83     [RX] OK
   5.83 [TX] AT#XSLMVER
   5.83     [RX] #XSLMVER: "2.3.0","2.3.1-8622ee1c632e"
   5.83     [RX] OK
   5.83 [TX] AT%XSYSTEMMODE=0,1,0,0
   5.85     [RX] OK
   5.85 [TX] AT%REL14FEAT=1,1,1,1,0
   5.86     [RX] OK
   5.86 [TX] AT%RAI=1
   5.86     [RX] OK
   5.87 [TX] AT%REDMOB=1
   5.88     [RX] OK
   5.88 [TX] AT%XDATAPRFL=0
   5.89     [RX] OK
   5.89 [TX] AT+CEPPI=1
   5.90     [RX] OK
   5.90 [TX] AT%XNETTIME=1
   5.91     [RX] OK
   5.91 [TX] AT+CNEC=24
   5.92     [RX] OK
   5.92 [TX] AT+CMEE=1
   5.93     [RX] OK
   5.93 [TX] AT%XSIM=1
   5.94     [RX] OK
   5.94 [TX] AT+CEREG=5
   5.95     [RX] OK
   5.95 [TX] AT+CSCON=1
   5.97     [RX] OK
   5.97 [TX] AT+CGEREP=1
   5.97     [RX] OK
   5.97 [TX] AT%XTIME=1
   5.99     [RX] OK
   5.99 [TX] AT%XMODEMSLEEP=1,500,10240
   6.00     [RX] OK
   6.00 [TX] AT+CPSMS=1,,,"00111000","00000000"
   6.00     [RX] %XMODEMSLEEP: 4
   6.00     [RX] OK
   6.01 [TX] AT%XBANDLOCK=1,"0000000000000000000000000000000000000000000000000000000000001000000010000000100010011010"
   6.02 [PPK2] 100k/s AVG   4.64 mA    Max  37.1  mA
   6.02     [RX] OK
   6.03 [TX] AT+COPS=1,2,"23003"
   6.05     [RX] OK
   6.05 [TX] AT+CGDCONT=1,"IP","hardwario.com"
   6.05     [RX] OK
   6.05 [TX] AT+CFUN=1
   6.10     [RX] OK
   6.11     [RX] %XMODEMSLEEP: 4,0
   7.01 [PPK2] 100k/s AVG  27.2  mA    Max  48.0  mA
   7.02     [RX] %XSIM: 1
   7.02 [TX] AT+CGSN
   7.02     [RX] 352656106109476
   7.02     [RX] OK
   7.02 [TX] AT+CIMI
   7.03     [RX] 901288000012723
   7.03     [RX] OK
   8.01 [PPK2] 100k/s AVG  35.5  mA    Max  65.8  mA
   9.00 [PPK2] 100k/s AVG  39.3  mA    Max  66.5  mA
  10.01 [PPK2] 100k/s AVG  19.2  mA    Max  62.9  mA
  11.02 [PPK2] 100k/s AVG   1.89 mA    Max   2.53 mA
  12.03 [PPK2] 100k/s AVG   1.89 mA    Max   2.50 mA
  13.01 [PPK2] 100k/s AVG   1.89 mA    Max   2.51 mA
  13.46     [RX] +CEREG: 2,"AE38","000AC51F",9
  14.01 [PPK2] 100k/s AVG   4.55 mA    Max  55.8  mA
  14.16     [RX] +CSCON: 1
  15.02 [PPK2] 100k/s AVG  33.2  mA    Max 290mA
  16.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  17.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  18.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.1  mA
  19.01 [PPK2] 100k/s AVG  33.1  mA    Max  47.8  mA
  20.01 [PPK2] 100k/s AVG  33.2  mA    Max  46.5  mA
  21.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  22.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.2  mA
  23.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  24.02 [PPK2] 100k/s AVG  33.3  mA    Max  46.1  mA
  24.43     [RX] +CGEV: ME PDN ACT 0,0
  24.43     [RX] +CNEC_ESM: 50,0
  24.43     [RX] %MDMEV: SEARCH STATUS 2
  24.44     [RX] +CEREG: 5,"AE38","000AC51F",9,,,"00000000","00111000"
  24.44 [TX] AT+COPS?
  24.45     [RX] +COPS: 1,2,"23003",9
  24.45     [RX] OK
  24.45 [TX] AT%XCBAND
  24.46     [RX] %XCBAND: 20
  24.46     [RX] OK
  24.46 [TX] AT+CEINFO?
  24.46     [RX] +CEINFO: 0,1,C,8,1,-87,18
  24.46     [RX] OK
  24.46 [TX] AT+CGDCONT?
  24.47     [RX] +CGDCONT: 0,"IP","hardwario.com","10.0.0.157",0,0
  24.48     [RX] +CGDCONT: 1,"IP","hardwario.com","",0,0
  24.48     [RX] OK
  24.48 [TX] AT#XDATACTRL=40
  24.48     [RX] %XTIME: ,"32305122655540",
  24.49     [RX] OK
  24.49 [TX] AT#XSOCKET=1,2,0
  24.49     [RX] #XSOCKET: 0,2,17
  24.50     [RX] OK
  24.50 [TX] AT%CONEVAL
  24.51     [RX] %CONEVAL: 0,1,7,54,24,42,"000AC51F","23003",493,6447,20,0,0,16,2,1,114
  24.51     [RX] OK
  25.00 [PPK2] 100k/s AVG  33.0  mA    Max 148mA
  25.65 [PPK2] ====== SUM: ATTACH   0.157uA/h during  25.6  s ======
  26.73 [TX] AT#XCONNECT="192.168.168.1",20000
  26.73     [RX] #XCONNECT: 1
  26.73     [RX] OK
  26.73 [TX] AT#XSOCKETOPT=1,50
  26.74     [RX] OK
  27.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.2  mA
  28.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  29.00 [PPK2] 100k/s AVG  33.4  mA    Max  46.3  mA
  30.01 [PPK2] 100k/s AVG  33.0  mA    Max  46.2  mA
  31.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.3  mA
  32.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.1  mA
  33.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.1  mA
  34.01 [PPK2] 100k/s AVG  33.5  mA    Max  46.4  mA
  35.02 [PPK2] 100k/s AVG  32.8  mA    Max  46.3  mA
  36.00 [PPK2] 100k/s AVG  33.6  mA    Max  46.2  mA
  37.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.2  mA
  38.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.1  mA
  39.01 [PPK2] 100k/s AVG  33.6  mA    Max  46.5  mA
  40.00 [PPK2] 100k/s AVG  32.6  mA    Max  46.0  mA
  41.01 [PPK2] 100k/s AVG  33.7  mA    Max  46.1  mA
  42.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.2  mA
  43.02 [PPK2] 100k/s AVG  33.6  mA    Max  46.6  mA
  44.02 [PPK2] 100k/s AVG  33.7  mA    Max  48.2  mA
  45.02 [PPK2] 100k/s AVG  32.7  mA    Max  45.9  mA
  45.49     [RX] +CSCON: 0
  45.49     [RX] %XMODEMSLEEP: 1,86399999
  45.49 [TX] AT#XSLEEP=2
  45.49     [RX] OK
  46.00 [PPK2] 100k/s AVG  16.5  mA    Max 194mA
  47.02 [PPK2] 100k/s AVG   0.017mA    Max   0.023mA
  48.01 [PPK2] 100k/s AVG   0.017mA    Max   0.023mA
  49.03 [PPK2] 100k/s AVG   0.017mA    Max   0.023mA
  50.02 [PPK2] 100k/s AVG   0.017mA    Max   0.023mA

[Achim Kraus]

Maybe, it's easier to use SO_RAI_LAST and a own "empty message".

At least in the past versions, the idea with SO_RAI_NO_DATA seems to be the same, sending a last empty message with NO_RESPONSE. Therefore you have to "connect" the udp socket in order to tell the stack, where to send this injected empty message.

Just because you use a 90128 SIM:

Do you know the HPPLMN search interval of your SIM card? Not that you get too surprised by some additional power consumption from that function (see HPPLMN search - reason unknown , it explains, why Nordic will always search for such a 9xxxx network.) By the way, did your modem ever report that 90128 network (see nRF9160 - who's device has seen/reports a network with a global PLMN starting with 9 ).

[Michal Mühlpachr]

SO_RAI_LAST and an own "empty message" works as workaround.
But SO_RAI_NO_DATA should still be fixed.

As you can see from AT dialogue, UDP socket is "connected" (without any IP traffic).
As you can see from modem trace, stack is not sending any empty message after SO_RAI_NO_DATA.

HPPLMN search does not apply because Vodafone CZ uses 90128 for home NB IoT (all Vodafone CZ NB IoT SIMs are 90128 - i.e. "roaming"), so it is the highest priority PLMN already.

Since SO_RAI_NO_DATA  and SO_RAI_ONE_RESP work reliably like a charm, I see no reason why SO_RAI_LAST should struggle with  HPPLMN search  or another corner strange causes. You can see from LTE RRC/NAS signaling (Modem Trace) that it is not the case also.

[Michal Mühlpachr]

I am sorry, correction:
Since SO_RAI_LAST and SO_RAI_ONE_RESP work reliably like a charm, I see no reason why SO_RAI_NO_DATA  should struggle with  HPPLMN search  or another corner strange causes. You can see from LTE RRC/NAS signaling (Modem Trace) that it is not the case also.

[Achim Kraus]

Sorry, my writing was misleading. 

The topic SO_RAI_NO_DATA or SO_RAI_LAST is separated from the HPPLMN search.

Last year I also wasn't able to get SO_RAI_NO_DATA working. I read "somewhere", that the implementation of SO_RAI_NO_DATA will use "SO_RAI_LAST with an injected/additional empty message", but that may be wrong. We will see, if it works once upon a day.

> HPPLMN search does not apply because Vodafone CZ uses 90128 for home NB IoT (all Vodafone CZ NB IoT SIMs are 90128 - i.e. "roaming"), so it is the highest priority PLMN already.

"COPS?" reports in your log PLMN 23003, and not 90123. I understand of course your writing and your interpretation, I share that. But, if you read carefully the link to the other discussion I provided, you will see, Nordic has a different interpretation! Since mfw 1.3.2 Nordic DOES a HPPLMN search for the "90123", because "23003" is not the same. It depends now mainly on your search interval, how often that happen. And you select the bands, so the search may be faster. But again, Nordic decided with mfw 1.3.2 to search for the "90123", if "23003" is reported as PLMN.

My IMSI starts with 90140 and my reported PLMN was 26201. With a search interval of 2h, I can see such a HPPLMN search every 2h. Unfortunately, you don't get events for that, you only see the larger power consumption and the "sleep event" is delayed (in my case about 60s).

 

[Michal Mühlpachr]

Achim Kraus said:

"COPS?" reports in your log PLMN 23003, and not 90123. I understand of course your writing and your interpretation, I share that. But, if you read carefully the link to the other discussion I provided, you will see, Nordic has a different interpretation! Since mfw 1.3.2 Nordic DOES a HPPLMN search for the "90123", because "23003" is not the same. It depends now mainly on your search interval, how often that happen. And you select the bands, so the search may be faster. But again, Nordic decided with mfw 1.3.2 to search for the "90123", if "23003" is reported as PLMN.

My IMSI starts with 90140 and my reported PLMN was 26201. With a search interval of 2h, I can see such a HPPLMN search every 2h. Unfortunately, you don't get events for that, you only see the larger power consumption and the "sleep event" is delayed (in my case about 60s).

Thank you for letting me know, I was not aware of the change in mfw 1.3.2.

I believe, HPPLMN search does not take place in case of modem lock, it is in the AT flow:
AT+COPS=1,2,"23003"
Do you have another experience?

BTW modem reports always 23003 by COPS?
SIM HPPLMN search interval is 10 hours.
SIM EF OPLMNwAcT is a strange list of various Vodafone country networks.

Can you explain "sleep event" is delayed (in my case about 60s) please?

[Achim Kraus]

> I believe, HPPLMN search does not take place in case of modem lock, it is in the AT flow:
> AT+COPS=1,2,"23003"
> Do you have another experience?

You're right! I overseen, that you lock the provider. With a locked PLMN I haven't observed HPPLMN searches. To lock the PLMN is the from Nordic recommended way to prevent HPPLMN searches (there was also one statement with the opposite, but the last was, lock the PLMN to prevent HPPLMN searches, if that is possible for your use-case).

> Can you explain "sleep event" is delayed (in my case about 60s) please?

I log a couple of modem events and measure some times. If the time from "RRC idle" to "enter sleep" is significant larger than the actual PSM RAT, then something prevents the modem from "enter sleep" in time. One of such "something" is a HPPLMN search.

Anyway, your original ticket was about AS-RAI.

If you read my comments and the answers from dejans, there is a lot implemented in the back, which should ensure the function, but seems for me to be not that easy to understand. I opened therefore an other ticket .

Requesting AS-RAI, connecting the socket and using "SO_RAI_LAST" or both "SO_RAI_ONE_RESP" and "SO_RAI_NO_DATA" works in my networks with both, AS-RAI and CP-RAI fallback. But for cases, where  SO_RAI_ONE_RESP/SO_RAI_LAST doesn't match the application's expectation, it can't work. I checked the function with the PPK II and the time, between the last data (sent or received) and "RRC idle".

(In my experience it's again important to analyze the modem events. And, as I wrote in other tickets, it would help a lot, if the modem events would be more complete, e.g. a event which reports a HPPLMN search. Or in this case, extending the "PSM Update" with more details.) 

 

[Michal Mühlpachr]

Achim Kraus said:

I log a couple of modem events and measure some times. If the time from "RRC idle" to "enter sleep" is significant larger than the actual PSM RAT, then something prevents the modem from "enter sleep" in time. One of such "something" is a HPPLMN search.

Clever idea, I'll use that, thanks.