From: "Tomas Winkler" <tomasw@gmail.com>
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: "Nils Bagge" <nbagge@bandspeed.com>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: HT capabilities IE
Date: Thu, 9 Oct 2008 18:33:27 +0200 [thread overview]
Message-ID: <1ba2fa240810090933x2e473416i2d5c9120128c8ead@mail.gmail.com> (raw)
In-Reply-To: <1223546085.22490.29.camel@johannes.berg>
On Thu, Oct 9, 2008 at 11:54 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2008-10-08 at 10:33 -0500, Nils Bagge wrote:
>> My humble opinion is yes, the HT capabilities field should be constant,
>> from the perspective of a typical AP.
>
> Yeah I totally agree.
>
>> Practically speaking, I doubt that an AP would want to toggle SM power
>> save at all, let alone on a per-beacon basis, as historically power
>> consumption is not as critical at the AP vs. at the client.
>
> True.
>
>> But, if you want to be 'green'... (I can see how this would benefit a
>> 'low power AP') The only problem I see is with the AP entering 'static
>> SM power save'. You might run into interoperability trouble with varying
>> behavior of client STA's, due to different interpretations of the
>> standard or assumptions. It wouldn't surprise me if some clients ignore
>> changes to the HT capabilities IE once associated, or if some ignore the
>> SM power save field in beacons entirely. Hence, they could transmit a
>> 2-stream MCS which would not be decodable with a single RX chain.
>>
>> Theoretically, the only SM power save mode I'd recommend for an AP is
>> dynamic SM power save.
I would say that recommended mode is SM disabled, Dynamic only in case
u want to be green.
> Right, but if you enter dynamic SM PS then it doesn't matter much
> anyway, does it? I mean, there's no protection requirement in that case,
> is there? Or am I reading it wrong? I _think_ I will handle the SM PS
> change in mac80211, but I'm not entirely sure right now.
If AP announce dynamic it requires STA to precede SM packet with
legacy one preferable RTS.
See the iwlagn implementation
Tomas
prev parent reply other threads:[~2008-10-09 16:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-08 10:01 HT capabilities IE Johannes Berg
2008-10-08 12:40 ` Tomas Winkler
2008-10-08 13:30 ` Tomas Winkler
2008-10-09 9:49 ` Johannes Berg
2008-10-08 15:33 ` Nils Bagge
2008-10-09 9:54 ` Johannes Berg
2008-10-09 15:41 ` Nils Bagge
2008-10-10 9:17 ` Johannes Berg
2008-10-09 16:33 ` Tomas Winkler [this message]
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=1ba2fa240810090933x2e473416i2d5c9120128c8ead@mail.gmail.com \
--to=tomasw@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=nbagge@bandspeed.com \
/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