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]

> Does SO_RAI_NO_DATA work in both CAT-M1 cases or only in one as shown in your table?

Only in one, with 26202 it works, with 26201 it doesn't. The setup is the same for both.

I've prepared some captures of both.

With 26201 there is an additional "MeasurementReport". Both shows a "RRCConnectionReconfiguration", but the "SO_RAI_NO_DATA" is always set after receiving the "Application Data" so a can't see the relation to that.

 

as_rai_no_data_26201.pcapng.gz

as_rai_no_data_26202.pcapng.gz

[Achim Kraus]

> AS RAI cannot be used if network does not support it.

That's again just simplified.

The impression is: AS RAI is not AS RAI, there are flavors.

If AS RAI with SO_RAI_ONE_RESP works, but in the same network SO_RAI_NO_DATA doesn't work, there is more to say than that.

[dejans]

Hi,

Achim Kraus said:

I'm located in Germany, using a nRF9160-DK v1.1.0, SICA B1A, mfw_nrf9160_1.3.4, ncs-2.3.0 my results are:

	SO_RAI_ONE_RESP	SO_RAI_NO_DATA
Telekom 26201, NB-IoT	yes	no
Telekom 26201, CAT-M1	no	no
Vodafone 26202, NB-IoT	yes	no
Vodafone 26202, CAT-M1	no	yes

So, in my test, SO_RAI_ONE_RESP is working only with NB-IoT, and SO_RAI_NO_DATA with LTE-M.

For me this requires a real clarification from Nordic, which combinations are intended to work or not. It may be "clear reading a couple of 100 pages of 3GPP", but if that outcome is documented, that would help the most users much more.

Could you provide information how you tested AS RAI functionality? Could you please confirm that networks mentioned in your table support RAI?

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

Best regards,
Dejan

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

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

In this case, R14 AS-RAI is not enabled but R13 CP-RAI is used.

Achim Kraus said:

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

UE is never asked from the network for the RAI support. Therefore, UE never signals to the network whether it supports AS-RAI or not. As a result, R14 AS-RAI is not enabled from the network to the UE.

Best regards,
Dejan

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