Mesh GATT Proxy: Skipped connection events?

[JeremyHiatt]

We are observing unexpectedly low throughput on the Mesh GATT Proxy service. Specifically, the Nordic device (acting in the GATT server role) is only sending one PDU on every other connection event even when it has multiple packets queued up. This is observed through timestamps where the latency between notifications is twice the expected connection interval. Also, when we capture the BLE connection with a sniffer device, we see an intervening connection event with no data exchanged in between each event that does send a PDU. The apparent problem is that the "TX complete" event (BLE_GATTS_EVT_HVN_TX_COMPLETE) from the SoftDevice does not fire until two connection events have occurred, even though only one is used to actually exchange data (again, that can be confirmed via the sniffer). The net result is that we only get half the expected throughput. Our connection interval is typically ~250ms, but the GATT notifications are only going out every ~500ms.

Model: NRF52832

Mesh SDK Version: 3.1.0

SoftDevice Version: s132

BLE SDK Version 15.2.0

[Kenneth]

Hi,

Sorry for the late answer. I am not familiar with BLE mesh, but I can understand what is happening here.

The softdevice scheduling is shown here:
https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/priorities_and_events_intro.html

The third priority show that low energy roles (central and peripheral) and radio timeslot with high priority can have the same priority level. When there are roles on the same priority, then it's "first come, first served" principle (e.g. whoever ask first for a specific time in future will get it). Based on this, to avoid that low energy roles is little impacted by a timeslot, then make sure that the requested timeslot is shorter (e.g. you can for instance try in this case <200ms) than the connection interval of the low energy role (in this case ~250ms). This should ensure that when the low energy role have completed it's own event, and request it's next event (that is ~250ms in the future), then the timeslot have not yet scheduled this specific time.

Best regards,
Kenneth

[JeremyHiatt]

Hi Kenneth,

Thanks for your reply, but I'm not entirely sure I follow what you mean. Is there any sort of logging that can be enabled for the SoftDevice to indicate how timeslots are allocated?

One thing I should say that I didn't mention before is that the behavior seems to be independent of the exact connection interval chosen, though I haven't experimented with that many different parameters.

Also, I want to clarify that while the intervening connection event is not used to send a GATT PDU, I can see on the sniffer that the device does not skip the connection event entirely. It sends an "empty PDU" (that's how it's labeled in Wireshark) which I believe indicates that it has no data to send to the central. I would think that if it's a timeslot priority issue then it would not send anything at all on that connection event, no?

I've included a screenshot below from Wireshark capturing with the Nordic BLE sniffer. Note how the mesh proxy PDUs are only sent every other connection event and "empty PDUs" are exchanged on the intervening events.

[Kenneth]

Sometimes a picture says more than text, and I believe you can disregard my comment about priority issue between scanning and peripheral role.

Based on your screenshot I think the case here is that the BLE_GATTS_EVT_HVN_TX_COMPLETE happens after the specific packet have been ack'ed by the link layer. In this case this happens indirectly due to the empty packets exchange you can see every other interval (this is due to each packet contains a sequence number, and based on the sequence number the peripheral can after receiving the empty packet know the previous sent notification have been fully received by the central and it thereby notify the BLE_GATTS_EVT_HVN_TX_COMPLETE event to the application).

I suspect the problem in your case is that you are only writing 1 notification every BLE_GATTS_EVT_HVN_TX_COMPLETE event, you can write several and you do not need to wait for BLE_GATTS_EVT_HVN_TX_COMPLETE event before sending the next notification. This is for instance also shown in the message sequence chart:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s112.api.v7.2.0/group___b_l_e___g_a_t_t_s___h_v_n___m_s_c.html

Best regards,
Kenneth

[JeremyHiatt]

Hi Kenneth,

Ok, if I understand correctly, you're saying the problem is that the Central won't send any packet that indicates to the SoftDevice that its prior packet was received until the subsequent connection event.

Thank you for the suggested change. However, I should point out that the code responsible for interacting with the SoftDevice to enqueue the GATT proxy PDUs comes from the Nordic-provided Mesh SDK, and my impression is that it would take a significant rewrite in order to behave as you suggest. I know that this portion is open-source but I'm not eager to undertake that sort of significant change on our own.

1) Is it in any way possible for the BLE_GATTS_EVT_HVN_TX_COMPLETE to come back sooner without having to wait for a second connection event? For example, is there anything that could be done differently on the Central side?

2) Does Nordic have any plans to update the mesh SDK to fix this throughput issue? As it stands it seems like a significant limitation.

[Kenneth]

Hello,

With the help from the mesh team I have learned the following:

This was fixed in SDK v4.0.0. The stack now starts queuing as many notifications as possible within a connection event. I think this was missed from the release notes.

The relevant code changes can be seen here and elsewhere in this file:
https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/79d0f3f49b6dd7f3af1bf9a49a8d7f0651fc71b0/mesh/gatt/src/mesh_gatt.c#L403 

We would strongly recommend you to upgrade to the latest available SDK version as it will provide you with several improvements and bug fixes. The current latest SDK is v4.2:
https://infocenter.nordicsemi.com/topic/struct_sdk/struct/sdk_mesh_latest.html 

Best regards,
Kenneth