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.

1 Comment

  1. Avatar Anon on December 2, 2019 at

    This is helpful, thanks. The spec is confusing (and really, imprecise) in vol 6 section 4.5.9 because it often speaks of “the” SN/NESN bits without specifying whether they correspond to a transmitter or receiver. It should really prefix all discussion of the SN/NESN bits with “the transmitter’s” or “the receiver’s” to avoid this confusion.

    And now that I understand, like you say, the SN/NESN bits really correspond to two independent channels: M->S and S->M (which again, the spec should clarify). That is, the master’s sent SN bit is compared with the slave’s local NESN bit for the M->S direction, and the slave’s sent SN bit is compared with the master’s local NESN bit. These two “transmit paths” are independent, e.g. as you show in your example above, the slave could fail to receive any packet from the master (thus keeping the master’s SN and slave’s NESN bits constant), while the master could be successfully receiving every packet from the slave.

Leave a Comment