BLE Packet retransmission at link layer

[kpreiss]

Hi,

We are seeing some odd behavior when running in the peripheral role connected to a central device.  Occasionally, it appears the central device needs to retransmit a packet done at the Bluetooth level, not application level.  From our captured sniffer trace, the retransmission occurs because no acknowledgement is sent by the peripheral.  The application running as peripheral, however, ends up processing both the original packet and the re-transmitted packet.  This particular behavior we have observed running the SDK 15.3 on an nrf53832 processor but we are also running an nrf5340 processor with the nrf Connect SDK v2.4.x.

Our questions are as follows:

1) When does the BLE stack release a received packet over the air to the application?  Does it actually delay one connection interval to release the packet confirming the peripheral ACK?

2) Do the SDK 15.3 and nrf Connect SDK provide a method to indicate the packet is a retransmitted packet or even an unacknowledged packet?

Below is a sniffer capture of the re-transmission.  I'm assuming it re-transmitted because the peripheral does not appear to have ACKd the packet.

Thank you.

[kpreiss]

Hi Edvin,

We use a command response protocol so we see two responses being transmitted back to the central, one for the initial packet (*line 12128 ) and another for the retransmitted packet (line 12130).  It's very possible there is a problem with how we're reading the data out of the BLE stack.  However, I was trying to understand how the stack releases re-transmitted packets to the application layer.  Does the below diagram make sense?

[Emil Lenngren]

The arrow in your diagram does not make sense.

In the first connection event, the peripheral presents a received packet from the central immediately to its upper layer. An ACK is then sent immediately (after exactly 150 µs) to the central. The central may or may not receive this.

In the next connection event, the central will retransmit the previous packet if it did not receive an ACK. If the peripheral received the same packet previously (i.e. it detects it is a retransmit), it will not deliver the packet to its upper layer. If it has not seen this packet before, it will deliver it to its upper layer. An ACK is then sent immediately (after 150 µs). The central may or may not receive this.

As soon as the central receives an ACK, it will release/free the buffer held for this packet, and move on to sending the next packet in the queue (or an empty packet, if empty).

I have very hard to see that the issue you have would be due to a bluetooth stack bug in the logic above, as retransmissions are extremely common and this would have been caught during testing. There is probably some other issue with the code you have, maybe that you unintentionally send your notification packet from the peripheral twice due to some other reason?

[kpreiss]

Thanks for clarifying that Emil!  That makes perfect sense.