This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Link Layer ACK vs. Write_REQ

Hello,

can anybody tell me the exact differences between a Link Layer Acknowledgement and the Acknowledgement used by a write Request? Does anybody have some statistics about packet loss that might occur if one is only using WRITE_CMD instead of WRITE_REQ? As far as I know, the Softdevice will Ack/NACK all WRITE_REQ without the possibility of doing so from within an Application. What are actual scenarios when a WRITE_REQ will be more reliable than a WROTE_CMD?

Thanks, Marius

  • I will give it a try;)

    Link Layer has this one sliding window ACK mechanism (SN+NESN bits in LL header) which ensures that low-level controller receives the message (basically that radio receiver gets it). However due to multi-layer architecture of BLE stack it's not sure that this doesn't get queued and lost/flushed by some higher layer. This isn't a big deal if you are running all upper layer on the same chip because then you are pretty much 100% sure that L2CAP+(G)ATT layers get the data and that upper APP layer is called through particular APIs (or event callback functions in Nordic Soft Device case to be very specific).

    However in case of "usual" Bluetooth system which is radio front-end + lower layer stack in one chip + HCI routing over USB or SPI or other interface to main system processor running multithreaded kernel like Linux/Android or Windows you might still want to have higher layer ACK mechanism and for that concept you have it on (G)ATT layer. (btw. you can have finally the same concept on APP layer in case you are not confident in (G)ATT implementation in your system).

    Finally to your question: we haven't run long specific stress test of Nordic stacks on nRF51 and 52 chips but from all the tests in past 4 years we haven't seen any single lost package between LL and APP layer (= in (G)ATT API of Nordic Soft Device). In other words if packet reaches destination and is decoded without any noise issues we also get it on higher layers of the stack.

Related