BLE transmission concurrency

[AmiguelS]

Hello! When two devices, Peripheral/Server and Central/Client, try to send Notifications and Write Commands, respectively, to each other at the maximum capable rate, who will transmit when? Consider an nRF5188 and an Android device that support 4 packets per connection interval, and both want to use the four available packet slots. Who transmits in what slot?

[RK]

All BTLE communications are Central TX, Peripheral TX ... etc, that's the basic communications protocol. So there's no room for doubt, the central will send its first packet in its first transmission, then the peripheral will send its first packet and so on. They'll continue sending packets for as long as the connection window is open, marking them appropriately with the 'more data' flag, dealing with any retransmissions, and then continue where they left off at the next connection interval. If at any point one side 'runs out' of packets to send but the other side is still indicating it has more data, it will send empty packets in its slot and the comms will continue.

[AmiguelS]

So in a 4 packets for connection interval communication, the Central always sends 2 packets, and the same applies to the Peripheral, even if the packets are empty. Is that it? Where is this mentioned on the specification?

[RK]

4 isn't mentioned anywhere because that's an implementation detail, not part of the spec. The Central..Peripheral..Central.. sequence is in the basic BTLE communication protocol in the BTLE chapter in the spec which also covers the over the air format and the headers (where the sequence flags and 'more data' flags live).

And no the central doesn't always send 2 and the peripheral 2, they might send 1 each if they have nothing to say, or the peripheral may send nothing at all if it has nothing to say and is taking advantage of slave latency. The only important point is the central starts first, they alternate packets, and they stop at some point before the end of the connection window and wait for the next one. That may be 1, 2, 4, 6 or many more packets, depending on the implementation, and the length of the window negotiated.