Release assistance indication (RAI)

[ced27]

Hi Supportteam,

i am trying to use Release Assistance Indication (RAI) to shorten the RRC-Connected using nRF9160 DK.

I'm enabling REL14FEAT with the following AT commands before LTE-connection:

   AT%REL14FEAT=0,1,0,0,0

I then created a socket and configured with the option:

err = setsockopt(sock, SOL_SOCKET, SO_RAI_NO_DATA , NULL, 0);

In my prj.conf file i set:

CONFIG_LTE_RAI_REQ_VALUE="3"

Here is how the current draw looks like:

Here is the pcap and raw trace:

Modem Trace Interaktion.pcapng

trace-2022-01-06T10-48-30.560Z.bin

Is that which i have done realistic? What are the factors to consider when using RAI?

Thanks in advance

Best regards,

Cedric

[Didrik Rokhaug]

Hi,

When using CONFIG_LTE_RAI_REQ_VALUE="3" the lte_lc library will set AT%XRAI=3. That will inform the network that after every packet, we expect one response, and then we want to be released. This is what happens in your trace.After sending a packet and getting a response, the RRC connection is released, and when you want to send a new packet, it is reestablished. In the end, you end up using more energy than if you had just left it open the whole time.

I also don|t know if the rel 14 feature AS RAI works in NB-IoT, but you need to sned AT%RAI to enable it first anyway. Also note that AS RAI (%RAI) and CP RAI (%XRAI) should not be mixed.

In the end, RAI is very hard to use correctly, especially with protocols with retransmissions (which DTLS might have). And, when used incorrectly can cause increased latency and power consumption.

Best regards,

Didrik

[ced27]

Hi Didrik,

thanks for your respond.

In my application i used lte_lc_rai_req() to enable RAI. Should I send AT%RAI=1 explicitly also to enable RAI?

Which socket option is mostly suitable to be able to shorten the RRC-Connected?

Best regards,

Cedric

[Didrik Rokhaug]

lte_lc_rai_req() sends the value you configured with CONFIG_LTE_RAI_REQ_VALUE (3). 

But yes, to use AS RAI, you must send AT%RAI=1 yourself. But again, I must point out that I am not sure if AS RAI works with NB-IoT.

And, again, you must be really careful with how you use it, otherwise you end up with unnecessary RRC signalling.

[ced27]

Hi Didrik,

thanks for your respond once again.

Since you aren't sure if AS RAI works with NB-IoT and RAI only works in NB-IoT.

Let say i configure  CONFIG_LTE_RAI_REQ_VALUE = "4" , meaning this time i am using CP RAI (AT%XRAI=4) . This will inform the network that after every packet, i expect no response. Meaning after sending a packet, the RRC connection is released. 

For doing so, i have to create a socket and configure it with an or options. Which option(s) is/are in your opinion most suitable?

Depending on CONFIG_LTE_RAI_REQ_VALUE = "4" and the option(s) being used, in what ways will it affect the targeted result? Will i be able to shorten RRC-Connected? 

Can you please give me your thoughts on that.

Best regards,

Cedric

[Didrik Rokhaug]

No socket options are used when using CP RAI.

Instead, you use the %XRAI AT command to set a flag which will be sent with any future packets, until you manually clear or change the flag with the %XRAI command again.

The problem is that you don't really know when a packet has left the modem. 

E.g. in a scenario where you are sending two UDP packets, not expecting any response:

1. You send() the first packet, but the network doesn't allocate the resources needed for the packet to be sent.

2. You set %XRAI=4

3. You send() the second packet.

4. The modem sends the first packet on the air, with the RAI flag asking the network to release it because it has nothing more to send.

5. The network releases the device

6. You set %XRAI=0, 

7. The modem asks for an RRC connection to send the second packet

8. The RRC connection is established, and the second packet is sent, without the RAI flag.

9. After the RRC connection timeout (often ~10s) the device is released.

Granted, this is an absolute worst case scenario, but it shows how easy it is for the use of RAI to go wrong, and cause the exact opposite of what you want. In the above example, the device is not released early after the second packet, but must instead use extra power on setting up the RRC connection again after the first packet.

The situation becomes even more complex if you are using a protocol with retransmissions.

However, if you still want to use RAI, you must make sure that you set %XRAI=3 or 4 (whatever fits your protocol and use case).

You must also remember to clear the flag before you start a new transaction, if there are more packets involved.

[ced27]

Hii Didrik Rokhaug,

thanks for wonderful explanation.

Just to make sure i have understood. Just let me make small recap:

For my use case, i will use %XRAI= 4 and my protocol is CoAP with DTLS. So when i send my first packet, i set the flag with %XRAI=4 and then before i send the second packet, i have to first clear the previous flag with %XRAI=0. Afterward i can send the second packet by setting the flag again and before sending the third packet, i should clear the flag again and the cycle continues. Ist that correct?

Best regards,

Cedric

[Didrik Rokhaug]

No. You only want to set the %XRAI flag before the last message you send.

If you set it earlier, you will only get unnecessary RRC connection teardowns and setups.

You should then clear the flag again before you start sending new packets.

[ced27]

Hi Didrik,

thanks for the respond.

This means i only set the flag once (before the last message i send) and before i start sending new packets, i clear the flag. Meaning after that no flag is to be set or clear again, is that correct?

Best regards,

Cedric

[Didrik Rokhaug]

For each time you send packets clear the flag first, start sending, before you send the last packet set the flag, then send the last packet.

But, as I have tried to say, the problem is that you don't know when the modem actually sends the packets on the air, so you still risk unnecessary RRC signalling.

[ced27]

Thanks very much Didrik. All these informations will really help me.

Best regards,

Cedric