Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Mon, 21 Apr 2025 15:37:46 GMT

Just to mention:

In the meantime, the modem firmware 2.0.2 for the nRF9161/51 reports, if the network supports CP-RAI and/or AS-RAI. Very helpful, as in too many case too much time is lost in tests and the network is just not supporting RAI.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Mon, 25 Sep 2023 07:37:46 GMT

Good question. I usually don't close it so I don't have the answer. When I do some testing again, I will check it.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Michal Mühlpachr — Mon, 25 Sep 2023 07:16:51 GMT

Thanks for update.
Does it apply to closing UDP socket also?

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Fri, 22 Sep 2023 14:26:34 GMT

Just an update:

mfw 1.3.5, NCS 2.4.2

Doing some comparison tests with TCP and UDP, I stumbled over a nice update to TCP/AS-RAI.

If you enable AS-RAI (AT%REL14FEAT=0,1,0,0,0 + AT%RAI=1) closing the TCP socket seems to already trigger SO_RAI_NO_DATA. In networks with AS-RAI my modem gets idle in 2-3s after closing. In networks without AS-RAI it takes about 10-12s (that depends on the network setting of the provider).

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Fri, 26 May 2023 10:41:03 GMT

Michal Mühlpachr

> E.g. if you send UDP packet using socket API, you will not get an error in all cases, when the packet was not sent by the device.

Just if you are still interested in this topic:

Bug report: Non-blocking send fails with EWOULDBLOCK even though poll returned POLLOUT

There in a comment of today:

> Yes, EAGAIN is returned even for DGRAM sockets. In any case, I am not aware of any situations where the messages are "swallowed up" by the modem and never get sent.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Sun, 23 Apr 2023 16:35:58 GMT

> Does queue based socket API layer have any insight into immediate link layer properties?

My understanding of that implementation was, that it "couples the layers". You pass two messages via "sendto" and then "SO_RAI_NO_DATA", then the two messages are sent and SO_RAI_NO_DATA is applied afterwards (I think, that was somewhere written here in the forum). Not sure, what actually happens. My experience is focused on the coap request/response pattern and so I use SO_RAI_ONE_RESP. And since updating my implementation using SO_RAI_NO_DATA additionally, it works also for Vodafone/Germany 26202 LTE-M/AS-RAI. For my use-cases (at least this year), that's fine and already an improvement.

Seems to be the next question to add details about that relation of the messages and the "SO_RAI" options to the documentation :-).

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Michal Mühlpachr — Sun, 23 Apr 2023 14:25:54 GMT

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/421890"]In my experience from other systems, that helps a lot for congestion control. It prevents the system from dropping messages internally. [/quote]

Of course, but it does not address all states.

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/421890"] An error code may have a better chance.[/quote]

Does queue based socket API layer have any insight into immediate link layer properties?

It is not a good API pattern to intermix queue and immediate approach in one API.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Sun, 23 Apr 2023 07:01:09 GMT

> in other systems (e.g. Linux) you get only info regarding socket buffer (SOCK_DGRAM in case of UDP) is ready for another send with poll/POLLOUT, but that is not info regarding datagram was actually sent.

In my experience from other systems, that helps a lot for congestion control. It prevents the system from dropping messages internally. I don't know, if that is implemented by the modems socket implementation. Unfortunately, such stuff is missing in the documentation.

> One option can be to add LTE link layer API

My impression about such extensions and redesigns is more, that they don't happen. At least not without a huge commercial project requesting it. Therefore, as I wrote, I would be happy if it starts with reporting errors, even if that has also still some drawbacks.

I guess, even a more complete documentation will take several weeks. And I don't see, that a redesign will happen this year. An error code may have a better chance.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Michal Mühlpachr — Sat, 22 Apr 2023 13:31:21 GMT

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/421874"]In other cases/systems, using "poll" with POLLOUT does the job[/quote]

In other systems (e.g. Linux) you get only info regarding socket buffer (SOCK_DGRAM in case of UDP) is ready for another send with poll/POLLOUT, but that is not info regarding datagram was actually sent.

DGRAM socket API is not suitable for link layer control.

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/421874"]Without an alternative proposal I don't see, that a discussion about the weakness and flaws helps.[/quote]

It helps to make clear what are the flaws and what is missing. In other words, what should be handled by extended API.

One option can be to add LTE link layer API (it could be made also with socket approach by adding special socket type aka LTE link layer or just add special LTE link layer API exposing all LTE under the hood details) and bring control, status info, events, data transport capabilities there.

It would not break the current higher-level TCP/UDP API and it will bring lower link-level control to applications, that can implement energy-efficient data transport.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Sat, 22 Apr 2023 08:26:38 GMT

> I agree, but socket API does not have that general quality and so such an approach would require wider API redesign.

Yes, it has some flaws. They are caused by a compromise not to block calls for an actual later outcome. But that seems to be more common. I'm not sure, if the modem's "nrf specific socket" API returns errors on poll, but on other implementations that works.

The point with a "redesign" would be the timeline. I would guess, it will take that long, that for many it will never come ;-). And I still miss an alternative proposal.

> why you are asking for notifications about packets actually sent.

No, I don't ask. I tired to explain, why RRC idle will not help for your bulk transfer. But for now I don't plan to use a bulk-transfer over UDP. In other cases/systems, using "poll" with POLLOUT does the job, but I don't know, if that is implemented in the "nrf socket". Maybe, once in the future, I would try to switch NSTART-2 or 4 for a coap blockwise FOTA, but not for now and not with more pending messages as a small couple.

So all in all:

Without an alternative proposal I don't see, that a discussion about the weakness and flaws helps. At least in my awareness quite a lot are common to that and will benefit from the error codes more then they suffer from things, which are not working with that approach.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Michal Mühlpachr — Fri, 21 Apr 2023 22:12:27 GMT

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/421850"]But to return error, if something doesn't work as expected, is for me a well API designed. And that fix should not be blocked by a single application.[/quote]

I agree, but socket API does not have that general quality and so such an approach would require wider API redesign.

E.g. if you send UDP packet using socket API, you will not get an error in all cases, when the packet was not sent by the device.

Overloading socket API by passing signalization regarding L2 Link Layer over L3 Network Layer API is not a good approach.

Socket API insufficiency is also the reason, why you are asking for notifications about packets actually sent.
But there is a catch, because there could be more than one UDP packet sent (on the way in modem), so you would need to identify to what exact packet is a notification about packets actually sent related.
And there is not any packet id that could be used for that.

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/421850"]I guess you request a different API.[/quote]

Yes, because there is a mix of layers in one API (socket API overloading).

SO_RAI_* is Link layer related, SO_SILENCE_ALL is also not related to UDP or TCP either, etc.

The current socket API is also the reason, why there is no reasonable way, how to provide the information required for bulk transfer timing implementation - power consumption optimized congestion control.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Fri, 21 Apr 2023 19:24:56 GMT

> if it is a breaking error (e.g. socket is not connected)

In combination with setsockopt SO_RAI_NO_DATA it's not breaking. In that case it is not applied, but the other functions are working. It is very much the same, as if it doesn't work, because Rel 13 CP-RAI is used implicit.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Fri, 21 Apr 2023 19:20:54 GMT

That affects only SLM. And for that it's very easy, to keep the wrong OK, even if setsockopt returns an error.

But to return error, if something doesn't work as expected, is for me a well API designed. And that fix should not be blocked by a single application.

I guess you request a different API. Without an alternative proposals, I don't see, that this would be available soon. But return an error for setsockopt should be not too hard, even if SLM will then not benefit.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Michal Mühlpachr — Fri, 21 Apr 2023 18:48:34 GMT

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/421845"]I assume, you mean at the AT-cmd level of that application?[/quote]

Yes.

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/421845"]I don't use the "Serial LTE Modem", so if other feel, that an error causes trouble there, then it should be very easy to swallow a returned error in that application.[/quote]

SLM returns just OK or ERROR. In case of ERROR it would not be clear if it is a breaking error (e.g. socket is not connected) or a non-breaking error like a feature is not supported by the network.

So there would not be an easy way how to distinguish whether to swallow or not swallow error.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Fri, 21 Apr 2023 18:39:35 GMT

> Serial LTE Modem

That's one application among a lot.

> there is no easy way to distinguish breaking/non-breaking error

I assume, you mean at the AT-cmd level of that application?

AS-RAI uses "setsockopt", which already defines to return errors. The current implementation actually returns error codes, e.g. if the UDP socket is not connected, you get a -1 and errno of 121 (EDESTADDRREQ) for SO_RAI_NO_DATA. Returning an error in cases, where the selected RAI option is not supported by the network is more a bugfix according the expected behavior then an API break.

I don't use the "Serial LTE Modem", so if other feel, that an error causes trouble there, then it should be very easy to swallow a returned error in that application.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Michal Mühlpachr — Fri, 21 Apr 2023 17:45:53 GMT

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/421818"]In my opinion it is not "the best possible way" to swallow a SO_RAI_ONE_RESP or SO_RAI_NO_DATA in the case it is not supported. Either returning an error code[/quote]

Error code would trigger AT command flow redesign for Serial LTE Modem application since there is no easy way to distinguish breaking/non-breaking error. I understand, that for API level it is not an issue, but a feasible solution should consider broader use cases than just API.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Fri, 21 Apr 2023 15:06:09 GMT

To mention what works and what works not in the documentation would have saved a lot of time, at least for me.

In my opinion it is not "the best possible way" to swallow a SO_RAI_ONE_RESP or SO_RAI_NO_DATA in the case it is not supported. Either returning an error code or the actual RAI mode supported by the network would enable users to write better applications and understand the network features.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Didrik Rokhaug — Fri, 21 Apr 2023 14:39:30 GMT

Hi,

Dejan is currently on vacation, so I have taken over this ticket.

Is there anything that is still unclear?

I'll see what I can do regarding a sample or more documentation on how to use RAI.

Best regards,

Didrik

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Mon, 17 Apr 2023 13:03:08 GMT

To "ignore" SO_RAI_NO_DATA is for some customers not "nothing" ;-).

My feeling is, there are very different understandings, what should happen.

For Nordic it seems to be "the best possible way" to not report, if a requested RAI option is effective or not.

For developer, which want to implement energy efficient applications, "the best possible way" would be at least an error-code, if a requested RAI option is not effective. A "smart mapping" of not supported options into implicit working options (e.g. "SO_RAI_ONE_RESP" with Rel. 14 AS-RAI into "SO_RAI_NO_DATA" after receiving a incoming data) would be an improvement. Or at least a documentation, where it get's clear, that SO_RAI_ONE_RESP and SO_RAI_NO_DATA are intended to be used together, if it's unclear, which RAI version you get.

All in all:

Your customers are spending so much time in your "best possible way" of not reporting details, that this gets very expensive.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

dejans — Mon, 17 Apr 2023 11:52:09 GMT

Hi,

[quote user="michalm"]What about SO_RAI_NO_DATA in this case?[/quote]

Nothing should happen with SO_RAI_NO_DATA.

Best regards,
Dejan

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Michal Mühlpachr — Mon, 17 Apr 2023 11:22:06 GMT

[quote userid="111786" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/420727"]Our customers do not need to know which RAI is supported or which is enabled (if any).[/quote]

We are your customer and we need to know that for troubleshooting purposes.

Knowing that and reporting that to our backend occasionally brings insight about operator/transport in use and allows battery lifetime estimation (based on communication power usage estimation). The modem do not provide information about "power consumed" unfortunately, so we do not have any other possibility how to estimate battery lifetime in case power consumption key drivers are unknown.

How would you suggest estimating energy consumed by the modem without knowing those details?

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Achim Kraus — Mon, 17 Apr 2023 11:03:03 GMT

> It is enough to configure last_packet/one_resp/no_data socket option

That is exactly not the case! Someone need to know, that using one_resp or no_data doesn't work reliable, these options must be used together.

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

dejans — Mon, 17 Apr 2023 10:51:38 GMT

Hi,

[quote user="michalm"]is there API way to detect whether network is R13 or R14, weather AS-RAI or R14 features are supported?[/quote]

Our customers do not need to know which RAI is supported or which is enabled (if any). It is enough to configure last_packet/one_resp/no_data socket option based on the situation in application and modem will use it in the best possible way depending on network's RAI support. Simply set the socket options to the best of application knowledge. There is no need for knowing other possible sockets in use when setting socket options for one socket because modem has common understanding of all sockets. In addition, it is not necessary to know which protocol (TCP or UDP) is used because the protocols are handled below the socket interface.

Best regards,
Dejan

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Michal Mühlpachr — Sat, 15 Apr 2023 16:04:17 GMT

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/420570"]This is mixed up and the sayings are moving ("fallback" is now "implicitly used").[/quote]

if I understand, the description is consistent with the previous ticket. AS-RAI and CP-RAI are used simultaneously if the operator supports them (priority undefined by standards, EPC implementation dependent, but usually AS-RAI has precedence). When AS-RAI is enabled on the modem but the operator does not support it, the modem attempts to use CP-RAI.

BTW is there API way to detect whether network is R13 or R14, weather AS-RAI or R14 features are supported?

RE: Please consolidate nRF9160 documentation about CP-RAI and AS-RAI

Michal Mühlpachr — Sat, 15 Apr 2023 15:50:36 GMT

[quote userid="5203" url="~/f/nordic-q-a/98544/please-consolidate-nrf9160-documentation-about-cp-rai-and-as-rai/420612"]Isn't it your experience, that this doesn't work?[/quote]

Yes, it is, I'm just making sure I understand this correctly.