From: Ashok Raj Nagarajan <arnagara@codeaurora.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 1/2] cfg80211: Add support to set tx power for a station associated
Date: Tue, 05 Jul 2016 18:01:45 +0530 [thread overview]
Message-ID: <1cb3e2cc49b433fe5ed834a33adf64b6@codeaurora.org> (raw)
In-Reply-To: <1467110918.2493.9.camel@sipsolutions.net>
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
next prev parent reply other threads:[~2016-07-05 12:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-14 17:44 [PATCH 1/2] cfg80211: Add support to set tx power for a station associated Ashok Raj Nagarajan
2016-06-28 10:48 ` Johannes Berg
2016-07-05 12:31 ` Ashok Raj Nagarajan [this message]
2016-08-01 9:29 ` Johannes Berg
2016-08-01 13:27 ` Ben Greear
2016-11-07 14:10 ` Ashok Raj Nagarajan
2016-11-07 14:18 ` Ben Greear
2016-11-15 9:31 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1cb3e2cc49b433fe5ed834a33adf64b6@codeaurora.org \
--to=arnagara@codeaurora.org \
--cc=arnagara@qti.qualcomm.com \
--cc=ath10k@lists.infradead.org \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).