BluetoothCoex [FreeBSD WIKI]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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:

  * WB195 - AR9285 + AR3011 bluetooth
  * WB197 - AR9287 + AR3012(?) bluetooth
  * WB222 - AR9485 + bluetooth
  * WB225 - ?
  * ? - AR9565 + ?

===== 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.

%%-%%--