SO_RAI_NO_DATA still does not cause RRC release

RE: SO_RAI_NO_DATA still does not cause RRC release

Achim Kraus — Mon, 17 Apr 2023 10:46:02 GMT

> UDP is non-reliable protocol.

UDP is the MOST reliable base for an upper protocol running over cellular modems using NB-IoT! The most serious upper protocols based on UDP do a much better job with NB-IoT and are much more reliable than TCP when running over NB-IoT.

TCP handles "congestion control" and "message drops" internally, but that depends a lot on additional messages and the timings. The generally assumed times are far away from the times of NB-IoT and that causes then a lot of retransmissions. So the only thing you get reliable using TCP over NB-IoT is a lot more data ;-)

> Typically, the assumption could be made that single UL UDP has left the modem when modem switches to RRC_IDLE.

For a useful congestion control of the radio layer, the event, that a message is sent by the radio layer helps a lot. Other modems offer that.

Using the RRC Idle event doesn't really help in that case. RRC IDLE is reached, if no more data is to be exchanged. That's either indicated by RAI (therefore all this discussion) or when the network's RRC Active Timer expires. It's not usable for the mentioned bulk transfer.

I guess, if you ask the modem developers, there is a number of messages, which are queued and send one after the other. But the exact implementation is not documented. And for many applications it's better to have a feedback, how fast actually the messages are sent in order to do the queuing in a more specific way in the application. Maybe using POSIX poll with POLLOUT works, but AFAIK, that is missing in the documentation.

RE: SO_RAI_NO_DATA still does not cause RRC release

Michal Mühlpachr — Mon, 17 Apr 2023 10:18:51 GMT

[quote userid="111786" url="~/f/nordic-q-a/97767/so_rai_no_data-still-does-not-cause-rrc-release/420706"]UDP is non-reliable protocol. Therefore, the information that UDP message left the modem would not guarantee anything or give any additional information. Typically, the assumption could be made that single UL UDP has left the modem when modem switches to RRC_IDLE.[/quote]

Yes, UDP is non-reliable as any datagram, but available information for data transfer timings has to be passed to the application.
Assumption can not be made on RRC_IDLE, because in such case link speed could not be utilized, i.e. such an approach wastes energy.

For good energy management, it is essential to know whether packet dropping occurs/does not occur in the device, as this information is inherently available to the device.
Another possibility is a statistical estimation, which needs to be based on the current line rate, which is known by the modem but not by the application, which needs to do the transmission timing, so the modem has to pass the information about the current line rate.

How does the application know that the packet is not dropped in the modem?

How does the application know what the current line rate is?

RE: SO_RAI_NO_DATA still does not cause RRC release

dejans — Mon, 17 Apr 2023 09:40:39 GMT

Hi,

[quote user="michalm"]Do I understand well, that ONE_RESP with R14 AS-RAI is not useful at all for power consumption optimization?[/quote]

This is correct. This is the reason for the recommendation that NO_DATA should be used after receiving the response.

Best regards,
Dejan

RE: SO_RAI_NO_DATA still does not cause RRC release

dejans — Mon, 17 Apr 2023 09:37:06 GMT

Hi,

UDP is non-reliable protocol. Therefore, the information that UDP message left the modem would not guarantee anything or give any additional information. Typically, the assumption could be made that single UL UDP has left the modem when modem switches to RRC_IDLE.

Best regards,
Dejan

RE: SO_RAI_NO_DATA still does not cause RRC release

Michal Mühlpachr — Fri, 14 Apr 2023 20:25:53 GMT

[quote userid="5203" url="~/f/nordic-q-a/97767/so_rai_no_data-still-does-not-cause-rrc-release/420392"]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.[/quote]

Clever idea, I'll use that, thanks.

RE: SO_RAI_NO_DATA still does not cause RRC release

Michal Mühlpachr — Fri, 14 Apr 2023 20:22:00 GMT

I am interested in that also, because there is not ANY signaling to the application, that send buffers are free to obtain another datagram. In case of bulk transfer through UDP, the application has to estimate the actual link transfer rate only based on lost datagrams. That is an extremely unfriendly technique for power saving. The application should be aware, whether the next datagram to be sent will or will not be dropped inside the device.

RE: SO_RAI_NO_DATA still does not cause RRC release

Michal Mühlpachr — Fri, 14 Apr 2023 20:12:40 GMT

[quote userid="111786" url="~/f/nordic-q-a/97767/so_rai_no_data-still-does-not-cause-rrc-release/419798"]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.[/quote]

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

RE: SO_RAI_NO_DATA still does not cause RRC release

dejans — Fri, 14 Apr 2023 14:45:46 GMT

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

RE: SO_RAI_NO_DATA still does not cause RRC release

Achim Kraus — Fri, 14 Apr 2023 07:04:30 GMT

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

RE: SO_RAI_NO_DATA still does not cause RRC release

Michal Mühlpachr — Fri, 14 Apr 2023 00:29:31 GMT

[quote userid="5203" url="~/f/nordic-q-a/97767/so_rai_no_data-still-does-not-cause-rrc-release/416497"]

"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).

[/quote]

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?

RE: SO_RAI_NO_DATA still does not cause RRC release

Achim Kraus — Wed, 12 Apr 2023 07:18:05 GMT

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?

RE: SO_RAI_NO_DATA still does not cause RRC release

Achim Kraus — Tue, 11 Apr 2023 17:15:27 GMT

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

RE: SO_RAI_NO_DATA still does not cause RRC release

dejans — Tue, 11 Apr 2023 15:50:43 GMT

Hi,

[quote user="AchimKraus"]In which case is a device able to use R14 AS-RAI with SO_RAI_ONE_RESP?[/quote]

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.

[quote user="AchimKraus"]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?[/quote]

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.

[quote user="AchimKraus"]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?[/quote]

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

RE: SO_RAI_NO_DATA still does not cause RRC release

Achim Kraus — Fri, 31 Mar 2023 21:19:02 GMT

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?

RE: SO_RAI_NO_DATA still does not cause RRC release

dejans — Fri, 31 Mar 2023 17:16:29 GMT

Hi,

[quote user="AchimKraus"]Telekom 26201, NB-IoT, AS-RAI?, ONE-RESP => working[/quote]

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

[quote user="AchimKraus"]Telekom 26201, NB-IoT, AS-RAI?, NO-DATA => not working[/quote]

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

RE: SO_RAI_NO_DATA still does not cause RRC release

dejans — Fri, 31 Mar 2023 16:58:02 GMT

Hi,

[quote user="AchimKraus"]

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

[/quote]

The trace show that R14 AS-RAI is supported.

[quote user="AchimKraus"]26202, LTE-M, AS-RAI, ONE_RESP => not working[/quote]

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

RE: SO_RAI_NO_DATA still does not cause RRC release

Achim Kraus — Wed, 29 Mar 2023 10:18:27 GMT

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

devzone.nordicsemi.com/.../trace_2D00_2023_2D00_03_2D00_29_5F00_NB_2D00_IOT_2D00_ONE_2D00_RESP.bin

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

devzone.nordicsemi.com/.../trace_2D00_2023_2D00_03_2D00_29_2D00_NB_2D00_IoT_2D00_RAI_2D00_NO_2D00_DATA.bin

RE: SO_RAI_NO_DATA still does not cause RRC release

Achim Kraus — Tue, 28 Mar 2023 15:14:18 GMT

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

devzone.nordicsemi.com/.../trace_2D00_2023_2D00_03_2D00_29_2D00_LTE_2D00_M_2D00_AS_2D00_RAI_2D00_ONE_5F00_RESP.bin

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

devzone.nordicsemi.com/.../trace_2D00_2023_2D00_03_2D00_29_2D00_LTE_2D00_M_2D00_AS_5F00_RAI_2D00_NO_5F00_DATA.bin

RE: SO_RAI_NO_DATA still does not cause RRC release

dejans — Tue, 28 Mar 2023 14:21:28 GMT

Hi,

[quote user="AchimKraus"]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?[/quote]

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

RE: SO_RAI_NO_DATA still does not cause RRC release

Achim Kraus — Mon, 27 Mar 2023 15:41:34 GMT

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

RE: SO_RAI_NO_DATA still does not cause RRC release

dejans — Mon, 27 Mar 2023 14:01:14 GMT

Hi,

[quote user="AchimKraus"]

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.

[/quote]

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

RE: SO_RAI_NO_DATA still does not cause RRC release

Achim Kraus — Mon, 27 Mar 2023 11:29:50 GMT

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

RE: SO_RAI_NO_DATA still does not cause RRC release

Achim Kraus — Mon, 27 Mar 2023 11:27:16 GMT

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

devzone.nordicsemi.com/.../as_5F00_rai_5F00_no_5F00_data_5F00_26201.pcapng.gz

devzone.nordicsemi.com/.../as_5F00_rai_5F00_no_5F00_data_5F00_26202.pcapng.gz

RE: SO_RAI_NO_DATA still does not cause RRC release

dejans — Mon, 27 Mar 2023 11:17:56 GMT

Hi,

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

Best regards,
Dejan

RE: SO_RAI_NO_DATA still does not cause RRC release

dejans — Mon, 27 Mar 2023 11:15:26 GMT

Hi,

[quote user="AchimKraus"]So, in my test, SO_RAI_ONE_RESP is working only with NB-IoT, and SO_RAI_NO_DATA with LTE-M.[/quote]

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

Best regards,
Dejan