Linux wireless drivers development
 help / color / mirror / Atom feed
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

      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