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]

> Could you provide information how you tested AS RAI functionality?

Well, the difference in the test is to either call setsockopt with SO_RAI_ONE_RESP before sending an request and receiving an response, or to call setsockopt with SO_RAI_NO_DATA after the response. What should someone make wrong in the setup, which makes the one working, but the other not?

> Could you please confirm that networks mentioned in your table support RAI?

If e.g. Vodafone 26202 NB-IoT doesn't support AS RAI, why does then SO_RAI_ONE_RESP work? Isn't the point, that in some cases SO_RAI_ONE_RESP works, and in other SO_RAI_NO_DATA. But not both, SO_RAI_ONE_RESP and SO_RAI_NO_DATA, in the same case?

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

Let's see, what other users report.

All together:

There is nothing a user could provide, which is not already provided.

I guess, this mystery can only be enlightened by Nordic.

[dejans]

Hi,

Achim Kraus said:

If e.g. Vodafone 26202 NB-IoT doesn't support AS RAI, why does then SO_RAI_ONE_RESP work? Isn't the point, that in some cases SO_RAI_ONE_RESP works, and in other SO_RAI_NO_DATA. But not both, SO_RAI_ONE_RESP and SO_RAI_NO_DATA, in the same case?

There are 2 mechanisms for RAI - R13 RAI which works on control plane (and it is practically supported everywhere) and AS-RAI which has both user and control plane data. In NB-IoT case, both RAI are in use, which means that in case R14-AS RAI is not found, R13 RAI is used. Cat-M1 only supports R14 AS-RAI, and this is the only option that can be used. Typically, when both R13 and R14 RAI are supported, R14 AS-RAI takes precedence.

The trace from initial question has been taken from NB-IoT with no PDU for which control plane RAI could be applied. This leaves only R14 AS-RAI as a possible option. Since AS-RAI is not supported by the network, then no RAI is possible. It does not really matter whether SO_RAI_ONE_RESP or SO_RAI_NO_DATA is used because there is no way of reporting anything to the network.

Best regards,
Dejan

[Achim Kraus]

Thanks!

And that fallback to R13 RAI supports also the "setsockopt" but not the parameter SO_RAI_NO_DATA?

And, if Vodafone 26202 LTE-M works with  SO_RAI_NO_DATA, why doesn't it work with SO_RAI_ONE_RESP?

Edited:

To my very surprise, this morning Vodafone 26202 LTE-M works with SO_RAI_ONE_RESP as well.

:-) More edited: :-)

That "success" was only a short one. It was the result from some configuration "leftovers" (switching between XRAI and RAI). It didn't work for a second request. And it doesn't work with a clean setup.

Therefore the captures:

26202, LTE-M, AS-RAI, ONE_RESP => not working

trace-2023-03-29-LTE-M-AS-RAI-ONE_RESP.bin 

26202, LTE-M, AS-RAI, NO_DATA => working

trace-2023-03-29-LTE-M-AS_RAI-NO_DATA.bin

[Achim Kraus]

I also prepared traces for Telekom 26201, NB-IoT, AS-RAI.

According GSMA Mobile IoT Roaming Features Final 08.09.2022 NB-IoT 26201 supports AS-RAI. Let me know, if the traces show the opposite.

Telekom 26201, NB-IoT, AS-RAI?, ONE-RESP => working

trace-2023-03-29_NB-IOT-ONE-RESP.bin

Telekom 26201, NB-IoT, AS-RAI?, NO-DATA => not working

trace-2023-03-29-NB-IoT-RAI-NO-DATA.bin

[dejans]

Hi,

Achim Kraus said:

26202, LTE-M, AS-RAI, NO_DATA => working

The trace show that R14 AS-RAI is supported.

Achim Kraus said:

26202, LTE-M, AS-RAI, ONE_RESP => not working

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.

Best regards,
Dejan

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

[dejans]

Hi,

If you use SO_RAI_NO_DATA with SO_RAI_ONE_RESP, you would not need to know when UDP packet has been sent.

Best regards,
Dejan

[Michal Mühlpachr]

dejans said:

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.

Do I understand well, that ONE_RESP with R14 AS-RAI is not useful at all for power consumption optimization?