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.

[dejans]

Hi,

Unless Release-14 RAI is supported by the network and enabled by the device the "immediate release" does not take place. In your case, the network did not activate AS-RAI. In addition, eNB did not request form UE to provide its capabilities. Therefore, UE did not get an opportunity to notify eNB about its support for R14 AS-RAI.

Best regards,
Dejan

[Achim Kraus]

So, if AS-RAI is not supported by the network operator, SO_RAI_LAST is working, but SO_RAI_NO_DATA not?

[dejans]

Hi,

For immediate release, SO_RAI_NO_DATA requires that AS-RAI is both supported from the network operator and enabled on the device. 

Best regards,
Dejan

[Achim Kraus]

> For immediate release, SO_RAI_NO_DATA requires that AS-RAI is both supported from the network operator and enabled on the device. 

That's the part I understand. But the question was, does SO_RAI_LAST requires less?

[Achim Kraus]

That seems to be wired, or just the specification is missing.

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.

[dejans]

Hi,

Achim Kraus said:

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

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

Best regards,
Dejan

[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

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