On 2016-08-01 18:57, Ben Greear wrote:
On 08/01/2016 02:29 AM, Johannes Berg wrote:
Sure.. First use case will be to help with the problem of legacy
client devices that roam across multiple APs. It is a classic
enterprise Wi-Fi AP problem, often managed by a "network controller"
unit that is connected to all the APs.
The problem is how to handle seamless handoff of clients between
multiple APs while maximizing the client throughput and minimizing
disruption of IP application services like VoIP calls and video
streaming. A legacy client will often hold onto an AP association,
even down to 1 Mbps as it roams away. Instead, if the AP can
recognise that the client RSSI (and therefore throughput) is poor, it
can "drop" the Tx power significantly (just to that client) such that
it forcesthe client to look for a better, closer, and therefore
higher-throughputassociation. It would "give it a kick" without
blacklisting it. It just needsto hold the power low for the small
amount of time it takes to convince it to go away.
Not sure that *works* since implementations may just compare beacon
signal strength and hold on to the AP based on that, but it does seem
like a reasonable use case.
How is that better than just kicking the station deliberately and/or
refusing to send frames to it at all?
Ben, deliberately kicking out the station can potentially cause the
black
listing behaviour on the client side and results in connection failures.
Each
client handles the kickout logic differently. Reducing the tx power,
causes the
station to trigger its roaming algorithm.
How would this interact with automatic adjustment though?
Johannes,
In the case of manual intervention by user, the firmware will check
three
values - regulatory domain, automatic tx power and user entered value.
System
will always cap to the minimum of these values and see to that we do not
exceed
the regulatory power limits.
If there are no more comments I will resent this patch series after
rebase.
Thanks,
Ashok
johannes
--
To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
