Bluetooth Low Energy (BLE) is a radio protocol providing a reliable way of exchanging data in a variety of environments using one of the most loaded frequency bands - 2.4 GHz. Reliability of BLE communication is guaranteed on a Link layer by implementing acknowledgment rules. The acknowledgment rules require a device to retransmit the data until it is acknowledged by a peer.
BLE specification defines rules of packets acknowledgment in the 4.5.9 Acknowledgment and flow control.
BLE Packet Structure
Let's take a look at a simplified BLE packet structure.
| Header | Payload | CRC | ||
|---|---|---|---|---|
| ... | SN | NESN | Up to 251 bytes | 3 bytes |
Header contains several link-layer service fields, for our article the most interesting fields are Sequence number (SN) and Next expected sequence number (NESN). Both SN and NESN fields are just a single bit.
Packet payload contains the user-data transmitted by a device. It can have length from 0 to 251 bytes. 0-byte length empty packets are used to keep connection alive and to acknowledge data reception.
CRC field contains checksum of the packet content. A device receiving packet calculates CRC of packet content and compares it to the CRC field in the packet in order to check that the data content is not corrupted.
ACK/NAK
After verifying CRC of received packet, if the CRC is correct, the device acknowledges the packet (it is often referred to as ACK). If the CRC doesn't match, or packet was not received at all, the device doesn't acknowledge the packet (NAK or NACK).
The following rules apply when devices exchange data:
- When a device sends a packet, the NESN field indicates the SN it expects to receive from the peer in the next incoming packet.
- Upon receiving a packet, the device checks the NESN value against the SN of the last packet it sent. If they differ, it means the previous packet was acknowledged (ACK); if they are the same, it means the packet was not acknowledged (NAK), so the device must resend the previous data.
- The device also checks the SN field. If it matches the NESN value previously sent, the data is new and should be processed; if not, the data is a duplicate and can be ignored.
Example
Let's illustrate the ACK and NAK with an example of devices A and B exchanging data in a connection.
| # | Sender | SN | NESN | Payload | Peer received packet | Comment |
|---|---|---|---|---|---|---|
| 1 | A | 0 | 0 | PA1 | Yes | A sends first data packet |
| 2 | B | 0 | 1 | (empty) | Yes | B acknowledges PA1 |
| 3 | A | 1 | 1 | PA2 | No | A sends PA2, but B does not receive it |
| 4 | B | 0 | 1 | (empty) | No | B repeats last ACK (no new data received) |
| 5 | A | 1 | 1 | PA2 | Yes | A retransmits PA2 |
| 6 | B | 1 | 0 | (empty) | Yes | B acknowledges PA2 |
Conclusion
By occupying only 2 bits of PDU header SN and NESN fields provide a simple way to make BLE connection a reliable transport.
A couple of important notes:
- A device retransmitting data is not allowed to modify content of a packet which is being retransmitted. This means that if a device receives NAK packet, it must retransmit the same payload it had sent before. This principle guarantees reliable delivery of data in BLE connections.
- BLE specification provides other ways of communication between devices. Only BLE connection guarantees data delivery. Other methods, such as advertising, or isochronous streams, do not guarantee data delivery and can be used for different purposes.