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.

[Achim Kraus]

Hi Dejan,

all examples use the same application setup code.

I don't see, how the application should know the extra info, which explains the result. But without that extra info it seems to be impossible to implement a working application. 

26202, with AS-RAI

4 days ago you wrote:

> Modem supports AS RAI and that includes both SO_RAI_ONE_RESP and SO_RAI_NO_DATA.

Now you write.

> The issue here is that since R14 AS-RAI, SO_RAI_ONE_RESP + UDP transmission does not trigger signaling from UE to the network which could accelerate connection release. After receiving response, UE should use SO_RAI_NO_DATA socket option to the socket in order to tell the socket that there is no more data expected.

In which case is a device able to use R14 AS-RAI with SO_RAI_ONE_RESP?

If, in difference to your comment 4 days ago, R14 AS-RAI doesn't support SO_RAI_ONE_RESP, how does the application know, that the device didn't fallback and SO_RAI_ONE_RESP must not be used?

26201, fallback to CP-RAI

> UE is never asked from the network for the RAI support.

The device uses the same setup as for ONE-RESP, which is working. Is SO_RAI_NO_DATA working with CP-RAI? If not, how does the application know, that the modem fallback to CP-RAI and the application must not use SO_RAI_NO_DATA?

[dejans]

Hi,

Achim Kraus said:

In which case is a device able to use R14 AS-RAI with SO_RAI_ONE_RESP?

ONE_RESP + UDP does not deliver the expected result with R14 AS-RAI, since the R14 AS-RAI has no capability to signal such combination. With AS-RAI, the UE can only inform the network "more data expected". It is in R16 when 3GPP defines AS-RAI to be at the same expression level as CP-RAI.

Achim Kraus said:

If, in difference to your comment 4 days ago, R14 AS-RAI doesn't support SO_RAI_ONE_RESP, how does the application know, that the device didn't fallback and SO_RAI_ONE_RESP must not be used?

Application has no way of finding this out. A safe way to use R14 AS-RAI so that the same code works with M1 and NB is to always issue setsockopt() with NO_DATA after receiving the reply UE is waiting for.

Achim Kraus said:

The device uses the same setup as for ONE-RESP, which is working. Is SO_RAI_NO_DATA working with CP-RAI? If not, how does the application know, that the modem fallback to CP-RAI and the application must not use SO_RAI_NO_DATA?

CP-RAI is only available with NB-IOT. 
If the UE does setsockopt() with ONE_RESP, sends data and after receiving a response from the network does setsockopt() with NO_DATA, the UE may trigger AS-RAI related BSR=0 signaling to the network (depending on whether the UE has uplink grant to do this or not). In this case, either CP-RAI or AS-RAI triggers the immediate release although the UE does not know which one of the two caused the release to happen.

Best regards,
Dejan

[Achim Kraus]

Hi Dejans,

using both ONE_RESP and NO_DATA looks more like a work-around and in my opinion requires explicit documentation.

best regards

Achim

[Achim Kraus]

Using both, SO_RAI_ONE_RESP and SO_RAI_NO_DATA , it works now with Rel 14 AS-RAI and the fallback to Rel 13 CP-RAI. Nice.

I don't use the SO_RAI_LAST, but there I miss a event as "message sent", in order to use then the SO_RAI_NO_DATA.

Is there a possibility to check, if a UDP message was actually sent?

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