GATTS Handle Value Indication - packet retry interval

[eyalasko]

Hi,

What is the timing of the indication retry mechanism (SDK14.2, nRF52832) ?

• App use sd_ble_gatts_hvx() to schedule message for sending
• At the next connection interval (T0) the message is xmitted (Peripheral-->Central)
• The Central's stack should ACQs (at GATT level?) the received message on T1. This triggers BLE_GATTS_EVT_HVC on peripheral side
• If the (GATT level) ACQ fails, the peripherals stack retries sending the message for 30 seconds (link1& link2)

My question are:

1. What is the time limit (connection intervals) to receive the acknowledge before retrying sending?
   e.g. - Does the peripheral expect 'GATT level ACQ' within 1/2/3/4/other connection intervals  ?
2. If this time limit is reached, how/can the app be notified that the 1st xmit attempt failed ?
3. Will the stack retry xmitting immediately (next CI) after the aforementioned time limit has reached?
4. Referring to Kristin's answer in link2 above - is it correct that a single LINK LAYER ACK resets the supervision timeout counter?
   (e.g. if supervision timeout is set to 10 sec, is it sufficient to have a single connection interval go through every 9.9 sec to keep the link connected forever?)

Thanks in advance for any response

[Susheel Nuguru]

What is the timing of the indication retry mechanism (SDK14.2, nRF52832) ?

BLE_GATTS_EVT_TIMEOUT which is 30 seconds according to the spec. See Vol 3 (Host) - Part F (ATT) - 3.3.3 (Transaction).

In our SDK examples we normally do a disconnect on this timeout instead of doing a retry. You can change this behavior by doing a retry of sending the indication instead of doing a disconnect.

1) could be anything between next connection interval to 30 seconds, hard to say as this will be based on the quality of connection you have, which is in turn based on your surroundings.

e.g. - Does the peripheral expect 'GATT level ACQ' within 1/2/3/4/other connection intervals  ?

No, it does expect to get an ACK in 30 seconds.

2. With indication you get  BLE_GATTS_EVT_TIMEOUT and the app knows that the attempt failed. With notifications you will not know this in the GATT level.

3) I am now confused as to which level of ACK you are talking. There are two levels of acknowledgement that happens. First is the link layer level packet acknowledgement based on SN and NESN. The other is the GATT level acknowledgement which needs to done and received by application explicitly. In the LL , any packet miss will be immediately known when the peer NACK a packet and the packet is re transmitted again. But in GATT level it will take 30 seconds to know that the indication packet or any other write with response has been lost.

[eyalasko]

Hi Aryan, 

So the 'Normal' Indication sequence as I understand it goes as follows:

1. Peripheral calls sd_ble_gatts_hvx() to schedule an Indication packet to the next connection interval
2. GATT 'hands' the packet to the LL to be sent out on the next CI
3. On next CI the LL transmits the packet to the central. Peripheral BLE_GATTS_EVT_HVN_TX_COMPLETE evet fired (?)
4. LL successfully transmits (LL ack'ed) the packet to the central. Peripheral BLE_GATTS_EVT_HVC evet fired (?)

Is this sequence correct ?

if LL xfer above (stage 3) does not get LL ack (stage 4), will the LL retry sending the packet?

In such case does the app notified by an event (before the 30 sec elapses) ?

=========================

My other question on the original post (question 4) refers to the condition that leads to BLE_GAP_EVT_TIMEOUT (Supervision timeout, correct?)

Assuming, for example, connection interval of 20ms (50/sec) and supervision timeout = 10 sec. Will BLE_GAP_EVT_TIMEOUT be triggered after 50(CI/sec) * 10(sec) = 500 missed LL packets ?

What if LL packet goes through and acknowledged after 499 missed ones. Will the supervision timeout be deferred for another 10 sec (500 missed CIs)?

Thanks for your prompt response

[Susheel Nuguru]

sorry for the late reply,

1) Correct

2) correct

3) BLE_GATTS_EVT_HVN_TX_COMPLETE is used only for notification and not for indication. For indication you will get BLE_GATTS_EVT_HVC when the peer has confirmed that the indication has been received. The timings of this depends on peer but should happen within 30 seconds of transmission of Indication else a BLE_GATTS_EVT_TIMEOUT is received on the peripheral side. It is upto the application how it wants to handle the timeout. In our SDK examples, we do a disconnect from peer, but you can change this code easily to try to retransmit the indiation packet again.

 

eyalasko said:

In such case does the app notified by an event (before the 30 sec elapses) ?

no, app will only be notified after the timeout has occurred and not before that.  

eyalasko said:

Assuming, for example, connection interval of 20ms (50/sec) and supervision timeout = 10 sec. Will BLE_GAP_EVT_TIMEOUT be triggered after 50(CI/sec) * 10(sec) = 500 missed LL packets ?

supervision timeout is link layer specific. That is if your peripheral is not getting any replies to its sent packet at the link layer level, then after the supervision timeout, the link gets disconnected.

You seems to be mixing up two things. 

1) The link layer keeps sending dummy packets to peer every CI to check that the peer is ACKing/NACKing those packets. This is different from 

2) peer responding to Indication.

The peer might be in a state that it is able to send keep the connection by responding to the LL packets but the app on the peer is too busy to respond to the indication received. 

So the supervision timeout happens due to non responsive nature in the LL level communication and the BLE_GATTS_EVT_TIMEOUT could happen due to app on the peer being too busy to respond in time or being unresponsive.

[eyalasko]

Thanks.

So the supervision timeout (in the example above) shall occur after losing 500 dummy LL packets sequentially ?

If a single dummy packet is ack'd after 499 have been lost, will it reset the supervision timeout counter (until 500 dummy packets are lost is sequence) ?

[Susheel Nuguru]

yes, your understanding above is correct.

The packets doesn't necessarily need to be dummy packets, they could have some data also. But I think you get the point now.