On 2016-06-28 16:18, Johannes Berg wrote:
On Tue, 2016-06-14 at 23:14 +0530, Ashok Raj Nagarajan wrote:
This patch adds support to set transmit power setting type and
transmit power level attributes to NL80211_CMD_SET_STATION in order
to facilitate adjusting the transmit power level of a station
associated to the AP.
Why would you ever need to do that manually? Please give more
explanation in the commit message.
We have minstrel-blues (which never made it into the code, but that's
just because the submitter went away) doing power adjustments, so you
need to explain why this should be necessary.
Hi Johannes,
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
forces
the client to look for a better, closer, and therefore higher-throughput
association. It would "give it a kick" without blacklisting it. It just
needs
to hold the power low for the small amount of time it takes to convince
it to
go away.
Other use cases may be
- Support a form of QoS per STA since a higher MCS rate might be
achievable, and CW delays might be reduced
- The optimal power can be negotiated (closed loop) or observed
(open
loop) for a given STA, reducing needless congestion on the
overall channel
- Reduce power to a STA that does not support certain radio
features
(e.g. 11b clients)
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
