When/How is a BLE GATT Notify/Indicate is send on physical layer

Question

I read the bluetooth core spec. V4.2 /BLE (..)

The communication in connection state is always master initiated, slave returns data afterwards. The master here is a GATT client talking to GATT server (peripheral device).

I do not understand the GATT Feature "notify" respectively how it works via the lower layers when the master always has to request before sending data.

Someone knows how it works ?

Answer 1

BLE is timeslotted. In connected state, there are connection events that happen periodically, with an interval called connectionInterval .

Each connection event is master initiated, which means the master sends the first packet within the connection event.

In order to keep the connection alive, slave has to send a packet (and get it acknowledged) at least once every supervisionTimeout . There are other timeouts that make the slave respond before that anyway, one of which is the slaveLatency , ie the number of connection events a slave can ignore before having to respond to master (even if not responding is not a cause for disconnection, it can cause other problems in the protocol, and thus disconnections). On the other hand, master should send a packet on each connection event.

connectionInterval , slaveLatency and supervisionTimeout are the timing part of the connection parameters in the spec. Connection interval ranges from 7.5 ms to 4 seconds, slaveLatency from 0 (then slave should respond on every connection event) to the number of connection events corresponding to supervisionTimeout / 2. (See 6.B.4.5.1 for the full definition)

So, basically, any payload (including GATT notifications) is queued in the slave or master's stack buffers until the next connection event happens. Whatever the direction (slave to master or master to slave), party has to wait for the next connection event to sends its packets.

Inside a given connection event, each party sends a packet in turn, optionally without any useful payload, until nobody has nothing to send any more. (See 6.B.4.5.6)

That means a notification is queued at most for connectionInterval , if radio gets the packet transmitted on the first try.

That's why connection parameters have to be negotiated properly, and that's also why they are different depending on the device type. For instance, a HID (mouse, keyboard, remote control) is generally allowed to connect with a connection interval under 10 ms, while heart rate monitor usually gets a connection interval over a second.