• State Not Answered
  • Replies 30 replies
  • Subscribers 69 subscribers
  • Views 5230 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 305943
Options

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

Achim Kraus

Knowing, that the AS-RAI implementation is experimental, I would still prefer to have more documentation about the details.

I already asked for these details in an other issue (see Details of AS-RAI and CP-RAI fallback ) but for me there are still some gaps.

The above referred thread discussed, that requesting to use Rel. 14 AS-RAI, the modem falls back to Rel. 13 CP_RAI, if AS-RAI isn't supported by the network provider. So far, so good. The nasty point seems to be, that you can't use this fallback without knowing that, because the supported options seems to differ for AS-RAI and CP-RAI and a function to see, that the modem decided to fall back, is missing.

My results (the trace are provided in the referred thread):

With Rel. 14 AS-RAI only the SO_RAI_NO_DATA seems to work, with SO_RAI_ONE_RESP I had no success.

With requesting Rel. 14 AS-RAI, but fallback to Rel. 13 CP-RAI, SO_RAI_NO_DATA doesn't work, but SO_RAI_ONE_RESP is now working.

My questions:

1. Please document, which options are working in which mode (SO_RAI_NO_DATA, SO_RAI_LAST, SO_RAI_ONE_RESP combined with Rel. 14 AS-RAI, AS-RAI fallback to CP-RAI).

2. Is it possible the check, if the modem falls back to Rel. 13 CP-RAI? Especially, if the first question shows, that there are no common supported options, such a function helps to implement a working application.

Thanks in advance. 

Parents
  • 0

    Hi,

    I have asked internally. I will get back to you by Monday next week at the latest.

    Best regards,
    Dejan

  • 0 in reply to dejans

    Thanks!

    Also for the answers in the other discussion.

  • 0 in reply to Achim Kraus
    Achim Kraus said:
    In other cases/systems, using "poll" with POLLOUT does the job

    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.

    Achim Kraus said:
    Without an alternative proposal I don't see, that a discussion about the weakness and flaws helps.

    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.

  • 0 in reply to Michal Mühlpachr

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

  • 0 in reply to Achim Kraus
    Achim Kraus said:
    In my experience from other systems, that helps a lot for congestion control. It prevents the system from dropping messages internally.

    Of course, but it does not address all states.

    Achim Kraus said:
    An error code may have a better chance.

    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.

  • 0 in reply to Michal Mühlpachr

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

  • 0 in reply to 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.

Reply Children
No Data
Related