Controller fails to complete Subrate Update procedure upon receipt of first ACK

[Omri]

The Application create connection as Central with the following parameters:

connection interval = 10 ms
slave latency = 0
supervision timeout = 3000 ms

After connection established, the application execute the following Subrate request command:

const struct bt_conn_le_subrate_param params = {
.subrate_min = 17,
.subrate_max = 17,
.max_latency = 0,
.continuation_number = 0,
.supervision_timeout = 300,
};

bt_conn_le_subrate_request(conn, &params);

The Controller (NCS 2.8.0) is observed to fail to exit subrate transition mode upon receipt of the first ACK from the Peripheral. 

The procedure completes only when a second ACK is received from the Peripheral 17 x Connection_Inteval later, where 17 is the Subrate_Factor.

Regards,

Omri

[dejans]

Hi,

Which boards and specific samples did you use for testing?

The Controller (NCS 2.8.0) is observed to fail to exit subrate transition mode upon receipt of the first ACK from the Peripheral. 

Which controller do you use?

Best regards,
Dejan

[Omri]

We use nRF5340 Audio dk and our application is based on the nrf5340_audio sdk application.

the application build under NCS v2.8.0 as a Unicast Client (Central).

The nRF5340 is connected to hearing aids.

The controller which run on the network core is build using the ipc_radio sdk application.

[dejans]

Hi,

Can you provide application logs and sniffer trace?

Best regards,
Dejan

[Omri]

Table Mic_1 0 7 0 0 0 3 9_Power Cycle_No Phone_filtered (3).btt

Attached Ellisys trace file. 

Please see markers #13 and #14

[dejans]

Hi,

Thank you for providing Ellisys trace file. We will look into it. I expect to get back to you by the end of the week.

Best regards,
Dejan

[dejans]

Hi,

As far as we can see, the first (not the second) ACK from NXP peripheral happens 17 CIs later and SoftDevice Controller behaves according to the specification. Peripheral does not respond at all in events 541 to 557. This statement from the Core specification might have been misunderstood on the peer side:

When the Peripheral receives this PDU it shall immediately switch to the new subrate base event, subrate factor, continuation number, Peripheral latency, and supervision timeout.

Not even SUBRATE_IND gets acknowledged before closing the event and switching to new subrating parameters, and this never gets satisfied:

After the Central transmits this PDU for the first time during a Connection Subrate Update procedure, it shall enter subrate transition mode. The Central leaves subrate transition mode when it receives the Link Layer acknowledgment for the PDU and then uses the new subrate base event, subrate factor, continuation number, Peripheral latency, and supervision timeout.

During subrate transition mode, the Central shall retransmit the PDU on all connection events which are subrated connection events based on the old subrate base event and subrate factor or are subrated connection events based on the new subrate base event and subrate factor (ignoring Peripheral latency)

Best regards,
Dejan

[Omri]

Thanks Dejan,

I forwarded your response to our client and they confirm your finding.

You can close this ticket.