Understanding SN and NESN in a BLE Link Layer packet

In my previous video looking at connection data captured via a BLE sniffer, I missed explaining two bits in the data that can be confusing to understand. The bits are the SN and NESN in the LL data packet.

A few notes to better understand these bits:

  • NESN and SN are used for data flow and making sure data is not missed (ACKs and NACKs).
  • NESN and SN are looked at independently
  • When the device sends a packet, the NESN is the next expected SN from the other side in the next packet coming back.
  • When the device receives a packet it looks at NESN (next expected sequence) and compares it to the previous SN it sent. If they’re different that means it’s an ACK (and the other side received and accepted the previous packet correctly). If they’re the same that means that the sender NACK’ed the previous packet (either didn’t receive it or rejected it because of lack of buffer space) which triggers a resend of the previous data it had sent.
  • The device also looks at the SN, and if it was the same as the previous NESN (expected sequence number from the other side) it sent, then it’s expected data. Otherwise, that means the data is old and can be discarded.

If you look at the above capture:

  • The first packet sent (packet #689), the Master sends SN set to 0, and the next expected sequence number (NESN) set to 0.
  • In this case, it is expecting a response from the Slave with SN set to 0.
  • Master receives a packet (#690) with SN set to 0, which is expected (new data).
  • However, the packet has NESN set to 0, which means it did not receive the previous packet with SN set to 0 (indicated in the ACK status which is “Unexp. NESN”)
  • This triggers the Master to resend the packet it previously sent.
  • The re-sent packet is packet #691.
  • This time it sends the packet with SN set to 0 (same packet it sent before), but with NESN set to 1 (since it correctly received the Slave’s packet with SN set to 0)
  • You can see this happens again with packet #692 and the Master ends up resending the data (packet #693).

Hopefully, this provides a good explanation of these bits and how they’re used for data flow control.

Leave a Comment