Delivery order of BLE indications/notifications

[Campbell Young]

Hi,

I am wanting some information about any guarantees on the ordering of queued notifications and indications. According to https://devzone.nordicsemi.com/f/nordic-q-a/11979/further-details-of-buffering-notifications-and-indications if I queue a notification before an indication, I should receive the notification before the indication on the other side. However, that's not what I see.

My notification queue is 30 long, and I fill up this queue. Then, after filling it, I queue an indication to be sent. I get about 4 `BLE_GATTS_EVT_HVN_TX_COMPLETE` events, and then I get `BLE_GATTS_EVT_HVC`, after which I get the remaining 26 `BLE_GATTS_EVT_HVN_TX_COMPLETE` events. The remote end observes the same order.

This seems to contradict the linked question, so I'm confused about what's going on here. Is that question referring to indications and notifications on the same characteristic? In my case I am using two different characteristics within the same service.

I am using S140 if that matters.

Thanks

[run_ar]

Hi,

What queue are you placing the packets in? I do not think it is possible to configure the SD with more than 7 TX buffers per connection. Are you sure you are not placing the packets in different additional buffers so the order it is placed in the actual tx buffers are changed?

[Campbell Young]

I am queueing packets via sd_ble_gatts_hvx whose size is set by hvn_tx_queue_size in a call to sd_ble_cfg_set. The indications are queued in an application queue, although for the purpose of this issue it is only one element long, and so is queued directly via sd_ble_gatts_hvx after the notifications have been queued via the same method.

I queue notifications until sd_ble_gatts_hvx returns an error. Once I get BLE_GATTS_EVT_HVN_TX_COMPLETE I try queueing again until all notifications are queued. Once they're queued, I then queue the indication.

Hope that makes sense!

Code for configuring queue size:

ble_cfg_t ble_cfg;
memset(&ble_cfg, 0x00, sizeof(ble_cfg));
ble_cfg.conn_cfg.conn_cfg_tag = APP_BLE_CONN_CFG_TAG;
ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size = CFG_BLE_HVX_QUEUE_LEN;
err_code = sd_ble_cfg_set(BLE_CONN_CFG_GATTS, &ble_cfg, ram_start);

[run_ar]

Are you doing this in cycles? I.e. you send 30 notifications then you send a indications, then repeat? If you do, you most likely get the BLE_GATTS_EVT_HVC from the first 30 notification in the next sequence of notifications. I.e you will be able to send notifications even if you have a pending indication. So unless you wait for the BLE_GATTS_EVT_HVC before you start sending the next sequence of notification I would expect the BLE_GATTS_EVT_HVC to come somewhere in the next notification sequence, as it takes some time for the application layer to process indications.

[Campbell Young]

Nah, I queue all notifications (about 200) then after the last one is queued, I queue the indication. When the remote end gets the indication, it will check if all the expected notifications were received. However, because the indication is coming before the notifications, it thinks packets are missing. Those missing packets arrive after the indication, so they do eventually get sent. For the purpose of this issue, there is only a single cycle happening. e.g. queue all notifications, queue indication, then stop.

[run_ar]

What peer/ central device are you testing with? Can you capture a sniffer log of this procedure to check the on air sequence?