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.

[Achim Kraus]

> What would be a reasonable timeout for step 2?

Depends on you requirements. I use 60s. In many cases, it's about 2-3s, in rare cases up to 15s, in very rare cases it was up to 60s. My consideration was, that the very rare cases left for the 60s don't cost too much energy, because the 15s will almost be enough. And for the very rare cases I decide to go for "works" instead of " save energy". I didn't made the experience, that after the 60s it moves to RCC Connected in a couple of seconds, so there I wait for longer until I retry the whole. I don't stop the modem, but I also don't retransmit the coap-message and fail the request instead.    

[helsing]

Hi Allard,

We will take a look at your questions and get back to you.

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