LTE_LC_RRC_MODE_CONNECTED timeout

[allard.p]

I've the following situation:

1. Send CoAP message trough send(), this causes the the nRF9160 to start RCC connection

2. Wait for RCC connected mode (LTE_LC_RRC_MODE_CONNECTED)

3. Start CoAP retransmit timers

Two questions:

- Is it possible to 'force' RCC connection without sending something trough a socket?

- What would be a reasonable timeout for step 2? I tried to extract this from the 3GPP TS 38.331 document, but I did not find the timeout.

[helsing]

- Is it possible to 'force' RCC connection without sending something trough a socket?

Why do you not just send what you plan to send? What is the issue you are working on solving? I do not think the modem could set up any RCC connection without sending something. You do not need to send IP data, an SMS, an empty UDP packet, request for PSM or eDRX parameters should also trigger an RRC connection.

[allard.p]

I'm trying to implement the 'separate response' functionality of CoAP (see https://datatracker.ietf.org/doc/html/rfc7252#section-2.2). This is used when the server does not have the time to send the response data as a 'piggyback' response, for example due to database delays or high load. The server will respond with an empty ACK message, and will send the response in a separate message.

I was trying to force the modem to listen a while longer after receiving an empty ACK message, otherwise the RCC connected timeout will occur, and the 'separate response' will be lost.

I understand this kind of behavior is not possible (?), I think I will ignore the empty ACK message, and just try again later.

[Achim Kraus]

1. don't try to use a separate response. If the server takes 2-3 seconds to send a response, I would relax the timeouts on the device. Longer times will anyway cost energy at the device.

2. if you really think, that you need longer times and separate responses, and you are also willing the "pay" the energy for that, then you need an assumption of the ratio between piggybacked and separate responses. 

2.a. use RAI (one response) already for the first exchange, expecting a high piggybacked rate. For that, set the "PSM active time" (CONFIG_LTE_PSM_REQ_RAT) to the expected timeout for a separate response (low rate). The modem checks in the RRC idle mode low frequently (see ltem-vs-nbiot-field-test-how-distance-affects-power-consumption for details), if data is available. As first time value to start, I would use your server response time + 6s. If the separate response is received, send the ACK with RAI (no response).

2.b disable RAI for the first exchange, expecting a high separate response rate. in the case of a piggy backed response, you may use the RAI (one response) and a coap-ping in order to release the RRC connection. If you only receive a empty ACK, then wait for the separate response and then send that ACK for that separate response with RAI (no response).

If you're network operator also supports AS RAI (Rel. 14), you may also try that for your message flows.  

Hope, that helps.

[helsing]

Hi Allard,

Are you using eDRX, PSM or RAI?

If we ignore current consumption for a moment: One does not need to stay in RRC Connected mode. The modem will listen for paging from the network in RRC Idle, however, the latency will somewhat increase (a typical paging interval might be 2.56s).

After a while you will get trouble with NAT timers. For UDP these are often 50-60 seconds, however, we have seen them as short as 16s. After this the timeout will have forgotten how it is routing packages to the device and the reply from the server will not reach the device.

When using eDRX, then the device will only listen for pages in Active Time, before turning the radio completely off. This way it becomes important that Active Time is long enough for the server to reply.

The network should buffer data for devices in eDRX mode or PSM, so the response from the server should arrive even if the device is in eDRX mode or PSM, as long as the response happened before the NAT timeout.