Android 6.0 Marsmallow BLE : Connection Parameters

问题:

The Bluetooth Low Energy connection parameters management seems to have changed in Android 6.

I have a BLE Peripheral device who needs to use some specific connection parameters (notably, the connection interval), and I want to use the minimum connection interval allowed by the BLE specification (i.e. 7,5ms).

The Android SDK doesn't allow to choose it from the BLE GAP Central (the smartphone) side, so the proper way to do it is to make my GAP Peripheral device send a L2CAP Connection Parameter Update Request after the GAP connection is made.

The parameters I request are:

• conn interval min : 7,5ms
• conn interval max : 7,5ms
• slave latency : 0
• supervision timeout : 2000ms

This worked as expected with all Android devices I've been testing, from 4.3 to 5.x : after sending the L2CAP Connection Parameter Update Request, my device receives a L2CAP Connection Parameter Update Response with 0x0000 (accepted), followed by a LE Connection Update Complete event where I can see that the requested connection parameters have well been taken into account.

Now, with a Nexus 9 tablet or with 2 different Nexus 5 devices, all having Android 6.0.1, I can see that the the L2CAP Connection Parameter Update Request is always rejected (I receive a L2CAP Connection Parameter Update Response with 0x0001 (rejected)). Then I receive a LE Connection Update Complete event where I can see that the requested connection parameters have NOT been taken into account.

I've been trying this with 2 different implementations on the Peripheral side (one with ST Microelectronics' BlueNRG, one with Nordic Semiconductor's nRF52), both with the exact same result.

Then, after more testing : I have tried different parameter sets, changing the conn interval max (I kept other parameters the same). Here is what I found :

• with conn interval max = 18.75ms, update request was accepted with interval set to 18.75ms
• with conn interval max = 17.50ms, update request was accepted with interval set to 15.00ms
• with conn interval max = 15.00ms, update request was accepted with interval set to 15.00ms
• with conn interval max = 13.75ms, update request was accepted with interval set to 11.25ms
• with conn interval max = 11.25ms, update request was accepted with interval set to 11.25ms
• with any other conn interval max value below 11.25ms, I get rejected.

So the observation is that something has clearly changed with the way Android 6's BLE stack handles the connection parameters. But there doesn't seem to be any kind of information or documentation to confirm that.

My observations lead to a conclusion that the minimum connection interval allowed is now 11.25ms (which actually fits my needs) instead of 7.5ms in earlier Android versions. But having found it empirically, I'd want to be sure that I'm not missing some other constraints/rules or if that minimum would not be dynamic, depending for example on the current battery level...

What would be great would be to have the equivalent of Apple's Bluetooth Design Guidelines (cf. §3.6) to set things clear on how an LE Peripheral should deal with this topic.

Is anyone having the same issue or is aware of some more helpful information from Google ?

回答1:

Compare method connectionParameterUpdate() from GattService.java in AOSP 6.0.1_r17 vs AOSP 5.1.1_r14. In both instances, call goes all the way to Buedroid in BTA_DmBleUpdateConnectionParams() in bta_dm_api.c with same params.

6.0:

    switch (connectionPriority)
    {
        case BluetoothGatt.CONNECTION_PRIORITY_HIGH:
            minInterval = 9; // 11.25ms
            maxInterval = 12; // 15ms
            break;

        case BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER:
            minInterval = 80; // 100ms
            maxInterval = 100; // 125ms
            latency = 2;
            break;
    }

5.1:

    switch (connectionPriority)
    {
        case BluetoothGatt.CONNECTION_PRIORITY_HIGH:
            minInterval = 6; // 7.5ms
            maxInterval = 8; // 10ms
            break;

        case BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER:
            minInterval = 80; // 100ms
            maxInterval = 100; // 125ms
            latency = 2;
            break;
    }

This might be a part of the answer to your question. Although BLE allows down to 7.5ms CI, I cannot speculate why link layer would not switch to lower CI on request by peripheral. I don't know if any part of android code controls outcome of negotiations with peripheral device.

回答2:

Google has not provided any documentation about the Bluetooth LE stack changes concerning connection parameter changes even though there have clearly been some in Android 6.

My experience with it has been the same as your own, that being that 11.25ms is now the fastest connection interval allowed in Android 6+.

My educated guess as to why they don't release documentation is that many manufacturers put their own BLE stacks into their phones (the BLE on Samsung and HTC behave differently from vanilla Android).

One other observation I have made that caused a great deal of problems is that Android 6+ will change the connection parameters 2 to 6 times before settling on the requested parameters.

I observed that after requesting a connection parameter update interval of 800ms to 1100ms, I saw the initial interval come back at 7.5ms, that then jumped to 48.75ms and then jumped to the 1098.75ms I requested. Then I subscribed to notifications on one of my services and the connection interval again jumped back to 7.5ms and then back to 1098.75ms. After this, it stabilized at 1098.75ms for the duration of the connection.

These tests were run on a Nexus 6 with Android 6.0.1

Obviously, some very strange things are happening on the Android 6 BLE stack.

回答3:

Google guys made a mistake in one of recent commits in Bluedroid by defining BTM_BLE_CONN_INT_MIN_LIMIT as 0x0009 which gives you 1.25ms x 9 = 11.25ms. In order to comply with standard it has to be defined as 0x0006.

回答4:

11.25 ms is the new minimum connection interval. The reason they don't allow 7.5 ms anymore is because if you stream audio over bluetooth at the same time the audio might became choppy.