Further details of buffering notifications and indications

[Carl]

Hi,

I'm using the S110 v7.10 to implement a service with an RACP, amongst other things. I'm supporting multiple transmissions per connection interval. This is working fairly well at the moment but has a minor timing issue. Before I try to fix it, I'd like a better understanding of the buffering for notifications and indications.

I've already read the following (as well as other related posts): devzone.nordicsemi.com/.../ devzone.nordicsemi.com/.../

So I realize that notifications use the "user" buffers while indications use the "system" buffers. I'm also aware that notifications are sent in a FIFO manner once queued. I assume the same applies to indications. But i'm unclear on what other guarantees, if any, are made about transmissions from these buffers. For instance:

• If I successfully queue a notification or indication using sd_ble_gatts_hvx, is it guaranteed to be sent on the next connection interval? If not, in what situations would it not be sent in this interval?
• If there are packets queued both in the user buffer and the system buffer, which get sent first?
• A specific example of the above: if I successfully queue a notification followed immediately by an indication, can I rely on a consistent transmit ordering (and what is that order)?
• Presumably the buffers are cleared if the connection is lost. If I send a notification and then the connection is lost before the notification is sent, do I get a TX_COMPLETE event (this is important if keeping track of free buffers).

As an observation, the buffering appears to be a commonly misunderstood feature (given the number of posts relating to it). It'd be good to get a detailed description of this in the API documentation.

Thanks, Carl

[Carl]

Further on the last bullet point about TX_COMPLETE. The documentation for "sd_ble_tx_buffer_count_get" suggests that buffers should be tracked from "boot time". I think they should probably be tracked on a per-connection basis instead (i.e. the counter should be reset on every new connection). This is supported by the answer for one of the other questions linked to in the question, which says that for the s120 and s130 buffers are per-link rather than global.

[run_ar]

If you successfully queue a notification or indication it is sent as soon as possible. This normally means the next connection interval if there are no restrictions on the peer (also for indications if there are no outstanding unacknowledged indications), however if you are transmitting multiple packets the amount of notifications that can be sent in one event depends on the peer as well. This means that if you queue 6 packets and the peer can only receive one, it will take 6 connection events to empty the buffer.

Buffers are served first in first out. so if you queue a notification immediately followed by an indication, the notification will be transmitted first, and the indication as soon as the notification has been received by the peer. The notification will be transmitted until it's acked by the peer (NESN and SN is incremented) or the connection times out.

If the connection is lost you will not get a TX_COMPLETE event. Instead you will get a disconnected event and can considered the buffers purged for the given connection upon receiving this event.

[Carl]

Thanks, that's a great, thorough answer.