GATT notification frame check sequence bad - time to retransmit

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
DaBr_4777916
Level 2
Level 2
25 sign-ins 10 replies posted 10 sign-ins

Trying to send a GATT notification with a payload of ~256 bytes between two BLE devices at 2Mbps.  If the devices are at a distance where the initial attempt to send the notification fails (for example, if the frame check sequence is ``bad" as indicated by a sniffer), should a packet sniffer show attempts to retransmit the notification occurring with each successive connection event until transmission succeeds (i.e. frame check sequence ``good")?  Is there any situation in which retransmission of a failed (i.e. unacknowledged) GATT notification does not occur during the very next device connection event (connection interval currently set to ~25ms), and if so, is there any firmware setting to control this time to retransmit? 

0 Likes
1 Solution

Hello,

Yes, retransmission necessarily occur in next connection event/interval after failure. Please refer to the Volume 1, part A, section 3.5.2 Scheduling and Acknowledgement Scheme in the BLE Core spec for more information.

Thanks,

P Yugandhar.

View solution in original post

0 Likes
8 Replies
Yugandhar
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 5 likes given

Hello,

BLE Data packets sent through BLE notification are not acknowledged in the application layer, but there will be acknowledgment in the link layer. This means that when the peer sends the packets, the next packet will not be sent unless the sender receives an acknowledgement at the link layer. This ensures that there are no missing packets.
The Indicate property has application-level acknowledgement, so for acknowledgement you can use Indication instead of Notification. 

 

Thanks,

P Yugandhar.

0 Likes
DaBr_4777916
Level 2
Level 2
25 sign-ins 10 replies posted 10 sign-ins

Thanks.  My question is regarding when a packet which does not receive an acknowledgement at the link layer is retransmitted so that it does receive an acknowledgement at the link layer.  Is this retransmission supposed to occur during the next interval?  For example, this Wireshark output shows the sniffed connection between two devices when a GATT notification is sent from slave to master every ~320ms https://www.dropbox.com/s/xtuff5m3kqwdqkk/2device_connection.pcapng?dl=0

at line 24678, a GATT notification with bad frame check status is followed by a GATT notification in the next connection interval (25ms later) with a good frame check status (line 24680).  However, the GATT notification at line 25030 with bad frame check status is not followed by another GATT notification in the next connection interval.  I'm asking why in this second case  I don't see an attempt to retransmit the GATT notification at line 25032.  All I'm looking for in this case is direction to documentation regarding this topic so I can assess whether or not the BLE stack is operating as expected.

0 Likes

Hello,

If a Data Channel PDU is received with an invalid CRC match, which means that the Data Channel PDU will not be acknowledged, causing the peer to resend the Data Channel PDU. Since the received Data Channel PDU has been rejected, and therefore the last sent Data Channel PDU from this device was not acknowledged and must be retransmitted.
Please refer to the Volume 6, Part B, 4.5.9 Acknowledgement and Flow Control Section in BLE core Spec5.0 for more information.

The attached wireshark logs has the UDP protocol which is not related to BLE, please share BLE logs.

Any packet transmitted must be acknowledged before the next packet is transmitted. A sniffer trace will confirm the retransmissions.

Thanks,
P Yugandhar.

0 Likes

The document you referred me to does not contain information related to timing of retransmission (e.g. next connection interval).  Is there a document containing this information?  Is the information in the BLE logs relevant to this support request (if so I'll get share the BLE logs)?

0 Likes

Hello,

 

The shared wireshark logs are not related to BLE, please share BLE logs for checking.

 

Thanks,

P Yugandhar.

0 Likes
DaBr_4777916
Level 2
Level 2
25 sign-ins 10 replies posted 10 sign-ins

Previously shared wireshark logs https://www.dropbox.com/s/xtuff5m3kqwdqkk/2device_connection.pcapng?dl=0 

contain Bluetooth Low Energy Link Layer information.  According to TI documentation (Getting Started — SmartRF Packet Sniffer 2 User Guide documentation  see Wireshark Usage section), the sniffer sends each packet to Wireshark in a UDP/IP packet which can be ignored.  If there is a document containing information related to timing of retransmission (e.g. does retransmission necessarily occur in next connection interval after failure), please let me know.

 

0 Likes

Hello,

Yes, retransmission necessarily occur in next connection event/interval after failure. Please refer to the Volume 1, part A, section 3.5.2 Scheduling and Acknowledgement Scheme in the BLE Core spec for more information.

Thanks,

P Yugandhar.

0 Likes
DaBr_4777916
Level 2
Level 2
25 sign-ins 10 replies posted 10 sign-ins

Thanks.

0 Likes