HT capabilities IE

HT capabilities IE

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

Hi,

quick question, I can't seem to read that from the draft, is the HT
capabilities IE supposed to be constant when, say, sent from an AP in
every beacon? Most fields look very constant, but e.g. the SM power save
mode might not be?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: HT capabilities IE

[Tomas Winkler]

On Wed, Oct 8, 2008 at 12:01 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Hi,
>
> quick question, I can't seem to read that from the draft, is the HT
> capabilities IE supposed to be constant when, say, sent from an AP in
> every beacon? Most fields look very constant, but e.g. the SM power save
> mode might not be?

SM has to be changed using action frame by the spec IIRC

Tomas

Re: HT capabilities IE

[Tomas Winkler]

On Wed, Oct 8, 2008 at 2:40 PM, Tomas Winkler <tomasw@gmail.com> wrote:
> On Wed, Oct 8, 2008 at 12:01 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> Hi,
>>
>> quick question, I can't seem to read that from the draft, is the HT
>> capabilities IE supposed to be constant when, say, sent from an AP in
>> every beacon? Most fields look very constant, but e.g. the SM power save
>> mode might not be?
>
> SM has to be changed using action frame by the spec IIRC

Sorry, wrong answer in, this is only the STA side.

There is whole section about Legacy HT coexistence when connection
parameters changes. But  I didn't spent time on it much so I would
have to look into the spec myself
Tomas

RE: HT capabilities IE

[Nils Bagge]

My humble opinion is yes, the HT capabilities field should be constant,
from the perspective of a typical AP.

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.

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. 

Nils

-----Original Message-----
From: linux-wireless-owner@vger.kernel.org
[mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Johannes Berg
Sent: Wednesday, October 08, 2008 5:02 AM
To: linux-wireless
Cc: Tomas Winkler
Subject: HT capabilities IE

Hi,

quick question, I can't seem to read that from the draft, is the HT
capabilities IE supposed to be constant when, say, sent from an AP in
every beacon? Most fields look very constant, but e.g. the SM power save
mode might not be?

johannes

Re: HT capabilities IE

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

On Wed, 2008-10-08 at 15:30 +0200, Tomas Winkler wrote:
> On Wed, Oct 8, 2008 at 2:40 PM, Tomas Winkler <tomasw@gmail.com> wrote:
> > On Wed, Oct 8, 2008 at 12:01 PM, Johannes Berg
> > <johannes@sipsolutions.net> wrote:
> >> Hi,
> >>
> >> quick question, I can't seem to read that from the draft, is the HT
> >> capabilities IE supposed to be constant when, say, sent from an AP in
> >> every beacon? Most fields look very constant, but e.g. the SM power save
> >> mode might not be?
> >
> > SM has to be changed using action frame by the spec IIRC
> 
> Sorry, wrong answer in, this is only the STA side.
> 
> There is whole section about Legacy HT coexistence when connection
> parameters changes. But  I didn't spent time on it much so I would
> have to look into the spec myself

Alright, thanks. I think I have it covered differently now anyway. Will
have to revisit that anyway.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: HT capabilities IE

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

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. 

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.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: HT capabilities IE

[Nils Bagge]

> 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.
> 
> Johannes


Well, upon a more careful reading of 11.2.3, the second paragraph would
seem to indicate that some kind of protection/wake-up is required prior
to a multi-spatial stream transmission, if the receiver is in dynamic SM
power save mode. The 'protection' frame that is received, is received by
a single RX chain. It is suggested to use an RTS/CTS. The other RX
chains are powered-on after the RTS is received. 

You could use an RTS/CTS, as suggested. I suspect there are more
efficient ways to kickoff the TXOP, and the 4th paragraph suggests that
any frame with matching RA will wake up all the RX chains for the
duration of the TXOP. That is probably the way to go, assuming you can.

If the STA is in static power save, it simply cannot receive 2+ spatial
stream MCS's, until it exits that mode.

So, I guess, yes, it does matter after all. 


Nils

Re: HT capabilities IE

[Tomas Winkler]

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

RE: HT capabilities IE

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

On Thu, 2008-10-09 at 10:41 -0500, Nils Bagge wrote:
> > 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.
> > 
> > Johannes
> 
> 
> Well, upon a more careful reading of 11.2.3, the second paragraph would
> seem to indicate that some kind of protection/wake-up is required prior
> to a multi-spatial stream transmission, if the receiver is in dynamic SM
> power save mode.

Indeed, I was reading that as "beginning of the frame" rather than
"beginning of the frame sequence". Sorry.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]