Open Radar

 
Summary:
Given an iOS device and an accessory that is connected over Bluetooth LE (as slave) to the iOS device (as master): the accessory can send a "Connection Parameter Update Request" over the Signaling L2CAP channel, to ask the iOS device to change the connection parameters, for example to save power or to make the connection more responsive.

iOS will always send a "Connection Parameter Update Response" message, accepting the request if the requested parameters conform to the Bluetooth Design Guidelines as set by Apple (https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf, chapter 3.6 Connection Parameters).

However, the update request does not always take effect. According to the Bluetooth 4.0 specification: "If the LE master Host accepts the request it shall send the connection parameter update to its Controller."

This does not appear to happen in this edge case: If a previous update request is still in progress (for example, if both controllers are still waiting for the "instant" to arrive): a "Connection Parameter Update Response" accepting the request will be sent, but no matching LL_CONNECTION_UPDATE_REQ follows in this case. A LL_CONNECTION_UPDATE_REQ will only follow for the previous request.

Steps to Reproduce:
1. Connect an accessory to an iOS device over Bluetooth LE
2. Let the accessory request a connection interval of 600ms, 0 slave latency and 6000ms supervision timeout.
3. Wait for the LL_CONNECTION_UPDATE_REQ to be received by the accessory.
4. Let the accessory request a connection interval of 24ms, 0 slave latency and 600ms supervision timeout.
5. Immediately hereafter, let the accessory request a connection interval of 600ms, 0 slave latency and 6000ms supervision timeout.
6. Observe that a "Connection Parameter Update Response" is received, accepting the request.
7. Observe that a LL_CONNECTION_UPDATE_REQ happens for the 24ms request, but not for the final 600ms request.

Expected Results:
In step 7. it's expected that the last request (600ms interval) is applied, since it has been accepted by the host (iOS) in step 6.

Actual Results:
LL_CONNECTION_UPDATE_REQ does not happen for the final set of requested parameters (600ms connection interval, 0 slave latency and 6000ms supervision timeout).

The connection stays in the high-power set (24ms interval) that was requested before the final set.

Version:
iOS 9 beta 1

Notes:


Configuration:
iPhone 5 (A1429)

Attachments: