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

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. 

  • Hi,

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

    Best regards,
    Dejan

  • Thanks!

    Also for the answers in the other discussion.

  • Hi,

    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.

    There is no fallback to CP-RAI. CP-RAI applies only to NB-IoT and makes use of SO_RAI_LAST and SO_RAI_ONE_RESP. CP-RAI is added to signaling when RAI is enabled, supported by the network, and appropriate socket options are used.

    R14 AS-RAI and SO_RAI_ONE_RESP does not give any desired result (on both NB and M1).

    R14 AS-RAI with SO_RAI_LAST works if AS-RAI is enabled on the network side (both NB and M1).

    R14 AS-RAI with SO_NO_DATA works if AS-RAI is enabled on the network side and UE has no more data to send (both NB and M1).


    Regarding the combination of R14 AS-RAI and R13 CP-RAI in case of NB-IoT:

    - If AS-RAI is not enabled on the network side, then CP-RAI is implicitly used and both SO_RAI_LAST or SO_RAI_ONE_RESP are used accordingly.

    - If AS-RAI is enabled on the network side and SO_RAI_LAST is used, then either CP-RAI or AS-RAI triggers the release. Both are signaled to the network, and which takes precedence is undefined.

    - If AS-RAI is enabled on the network side and SO_RAI_ONE_RESP is used, then CP-RAI is used implicitly, and triggers the release. AS-RAI is not used.


    If the application insists on using SO_RAI_ONE_RESP and wants RAI to work on both NB and M1 then the application has to also use SO_RAI_NO_DATA after receiving the response packet. This
     ensures in case of M1 that at least R14 AS-RAI is attempted after receiving the response and it does not cause harm on NB although it is unnecessary.


    Best regards,
    Dejan

  • OK, I give up.

    This is mixed up and the sayings are moving ("fallback" is now "implicitly used").

    The resulting table, as I understand it:

    RAi option AS-RAI AS-RAI using CP-RAI implicit (fallback)
    RAI_SO_LAST works works
    RAI_SO_ONE_RESP doesn't work works
    RAI_SO_NO_DATA works doesn't work

    I would guess, for offering a easy to use and understand API, it will be very easy to map RAI_SO_ONE_RESP for AS-RAI also "implicit" to RAI_SO_NO_DATA after receiving the next datagram. Not sure, but maybe RAI_SO_LAST is already the result of using implicit RAI_SO_NO_DATA after sending the last  datagram.

    An extension of LTE_LC_EVT_PSM_UPDATE with AS-RAI active in network would be very useful. As well as error codes for setsockopt (e.g. "-ENOTSUP" for RAI_SO_NO_DATA, if the network doesn't support it) will help a lot.

  • - If AS-RAI is not enabled on the network side, then CP-RAI is implicitly used and both SO_RAI_LAST or SO_RAI_ONE_RESP are used accordingly.

    What about SO_RAI_NO_DATA in this case?

    The rest seams clear to me, even though it's a little convoluted ;-)

    Thanks for the explanation.

Related