Bluetooth coexistence notes

Some devices share a physical antenna between the 802.11 wireless and the bluetooth device. In doing this, they need to communicate somehow to "negotiate" access to the antenna. They both need to not transmit over each other; they need to not be trying to receive whilst the other is transmitting, and there needs to be some kind of priority mechanism to give 802.11 and bluetooth a fair share of antenna time.

There's a small number of devices which implement a shared bluetooth and 802.11 antenna:

Coexistence mechanism

All but the most recent devices have an external bluetooth chip and are connected via GPIO lines and a simple signalling mechanism.

Starting with the AR???? NIC (something after the AR9485), a message based protocol (MCI) allows for a much more useful signalling protocol.

Unfiled Notes

From the ath9k mailing list:

BTCOEX protocol in ath9k can be of 3 types: 2-wire, 3-wire and MCI.

All chips in the pre-AR9003 family have separate WLAN and BT devices as part of the same board. In a 2-wire connection between the devices, they are marked as BT_ACTIVE and WLAN_ACTIVE. BT_ACTIVE is driven by the BT device and WLAN_ACTIVE by the WLAN device, obviously.

If the Bluetooth device is expecting to TX or RX, it asserts BT_ACTIVE. If WLAN traffic has been prioritized over BT traffic, WLAN_ACTIVE is asserted and Bluetooth traffic is "stomped".

Now, the means of "prioritizing" traffic is done based on "weights". For each combination of BT_PRIORITY/BT_[TX|RX], weights are programmed in the HW. The same is done for WLAN. So, when the card is operational and BT_ACTIVE is asserted and if there is current WLAN traffic, the HW checks if the weight of the BT traffic is lower than WLAN and if so, continues to transmit WLAN frames. If BT priority is higher, the HW will *abort* WLAN traffic like there was a collision. I'd assume that at this point, backoff will kick in.

2-wire doesn't have BT_PRIORITY, so traffic classification is very primitive and coexistence is not optimal. 3-wire is much better and the best of the breed is the MCI based scheme implemented in AR9462 and AR9565. These two chips, unlike other WLAN+BT cards like WB195, WB225, WB197 etc. are *combo* chips and hence have a complex system of message-passing to exchange information between the BT-core and WLAN. MCI is built on 3-wire, so it uses the same lines at a basic level.

Now, these lines (either 2 or 3) are connected by GPIOs at the WLAN side. They can be programmed as either input or output and the GPIO number is fixed for each card. The WLAN-driven line WLAN_ACTIVE is configured as output and the signals coming in from BT are configured as input. The actual pin numbers can be found in ath9k_hw_btcoex_init_scheme().

This is only the basic picture - there are a lot of other components which interact with each other to provide a more dynamic algorithm to distribute airtime between WLAN and BT. Most of the stuff is in gpio.c and btcoex.c

---

So the weight table for Kite/Kiwi:

wait_beacon

qcu_priority

rx_clear

wlan level

0

0

0

wlan_weight[0:1]

0

0

1

wlan_weight[3:2]

0

1

0

wlan_weight[5:4]

0

1

1

wlan_weight[7:6]

1

0

0

wlan_weight[9:8]

1

0

1

wlan_weight[11:10]

1

1

0

wlan_weight[13:12]

1

1

1

wlan_weight[15:14]

bt_priority

bt freq

bt_tx_rx

bt_level

0

0

0

bt_weight[0:1]

0

0

1

bt_weight[3:2]

0

1

0

bt_weight[5:4]

0

1

1

bt_weight[7:6]

1

0

0

bt_weight[9:8]

1

0

1

bt_weight[11:10]

1

1

0

bt_weight[13:12]

1

1

1

bt_weight[15:14]

wait_beacon is whether we're waiting for a beacon in STA mode. No idea how this works in hostap mode, but see below. qcu_priority is whether it's a low or high queue priority. Any queue above the "queue threshold" value in one of the BT config registers (see the source) is a high priority queue and is 1 here. rx_clear is whether we're busy

bt_priority - the bt priority line bt_freq - no idea bt_tx_rx - whether the BT module is transmitting (3 wire only I guess, irrelevant for 2 wire)

I hope that's enough to get started on what you're trying to achieve. Please share your results!

---

Yes, "WLAN_ACTIVE" here is just both TX and RX activity.

---

No, wifi stomping occurs with both 2-wire and 3-wire.

BT_PRIORITY just gives the MAC the ability to tell the difference between high priority TX and any bt activity requiring the air, so the MAC can then choose a weight based on differnet kinds of BT inputs.

If all you have is two wire, then you don't get separate weight table entries for different kinds of BT transmissions.

---

dev/ath_hal(4)/BluetoothCoex (last edited 2013-06-11T07:32:28+0000 by AdrianChadd)