[ath9k-devel] Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

Hello Adrian,? ? ? Thanks for your response. Currently with 2-wire coexistence, BT has higher priority when compared to WiFi. You had shared the following different bitfields that can be configured with different weights:
WLAN:-wait_beacon | qcu_priority| rx_clear | wlan level
BT:-
bt_priority | bt freq | bt_tx_rx | bt_level

I have the following queries, please help:
1. ?wait_beacon:- WLAN client is waiting for a beacon from AP, this bit will be set. If the weights during this state is kept the highest, then even if BT wants to use the medium (BT_ACTIVE = 1), WLAN will always attempt to catch the beacon. Am I correct in my understanding??
2. What happens if BT wants to transmit during this time when wait_beacon = TRUE; will the BT transmission be suppressed?
3. Regarding "bt_tx_rx". As I understand, bt_tx_rx = 1 when BT is transmitting and bt_tx_rx = 0 when BT is receiving; am I correct? How can BT module communicate if it will be transmitting or receiving to WLAN module? Because BT_PRIORITY will only indicate High or Low priority.
4. Currently the WLAN_ACTIVE line indicates only Tx activity from WLAN. Is there any way to indicate only Rx activities (E.g. Beacon reception etc) ?
5. ?Regarding your comment on dynamically changing weights. AR9287 and the BT chipsets are separate and connected to a Host controller running linux. ?As for different states of BT, if there is a need for different weights, I do not think at runtime the weights can be changed (by sending a command from BT to Host and then weight change from Host to WLAN)as we might not be able to meet the short timings. WHat is your opinion on this?

 Thanks & regards
Sandeep.

    On Monday, 28 March 2016 4:13 AM, Adrian Chadd <[email protected]> wrote:
 

 On 27 March 2016 at 09:43, sandeep suresh <[email protected]> wrote:
> Dear Experts,
>
> WiFi-BT Coexistence:
> To let wireless LAN systems coexist with Bluetooth system, a hardware Packet
> Traffic Arbiter (PTA) scheme is used. Here PTA is based on 2-wire
> coexistence , BT_ACTIVE and WL_ACTIVE. When BT wants to use the medium, it
> will assert the BT_ACTIVE line, during which WLAN cannot perform any
> transactions. When WLAN is in client mode, during this assertion period
> waiting for a packet from WLAN router (AP) to be received , WLAN packet will
> be lost !!! Let us call this window during which WiFi being stomped? by BT
> as stomping window. WLAN device in client mode considered here is based on
> AR9287 chipset and let us call this as Apple accessory
>
> Bonjour discovery:
> Apple devices connect to the same WiFi router to which the Apple accessory
> is also connected. Apple device is also connected in WiFi client mode.? In
> order to determine other clients (Apple compatible) in the same network, it
> performs Bonjour discovery which is based on mDNS broadcast.
>
> Concern/Query:-
> The mDNS query is a broadcast query received from Apple device and sent by
> the WiFi AP to the WiFi network (to which the apple accessory is also
> connected) only once. The period of reception of this broadcast query can
> coincide with the stomping window. Hence the broadcast query can be lost by
> Apple accessory. This might result in discovery, pair verify (later) from
> apple devices to fail. Apple devices implement a back-off strategy and as
> per this the next discovery will be after 10s of minutes. During this long
> period the WiFi client based apple accessory will be offline!!!!

> Is the understanding and concern correct? If so, how can this be solved via
> ath9k drivers and/or settings in WiFi AP?

Well, sure. I mean, the bluetooth coexistence code is just designed to
ensure that they stomp predictably and can be controlled. I didn't
think the pair/discovery would take so long though, so I'd go and
figure out what's going on there.

You can set up the weights and stomping preference for controlling
bluetooth and wifi. I think at the moment ath9k (and freebsd) just use
a static weight matrix and prefer bt? I forget.

There's some extensions to 802.11 (802.11aa, at least) which allows
for reliable multicast. That means it gets replicated to each device
that asks for it, and it gets ACKed/retransmitted/etc. I don't know of
anything open source that implements all of that.



-adrian


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20160329/1c2cd180/attachment.htm