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
> 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
On Wed, Oct 8, 2008 at 2:40 PM, Tomas Winkler <[email protected]> wrote:
> On Wed, Oct 8, 2008 at 12:01 PM, Johannes Berg
> <[email protected]> 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
On Thu, Oct 9, 2008 at 11:54 AM, Johannes Berg
<[email protected]> 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
On Wed, Oct 8, 2008 at 12:01 PM, Johannes Berg
<[email protected]> 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
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
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: [email protected]
[mailto:[email protected]] 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
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
On Wed, 2008-10-08 at 15:30 +0200, Tomas Winkler wrote:
> On Wed, Oct 8, 2008 at 2:40 PM, Tomas Winkler <[email protected]> wrote:
> > On Wed, Oct 8, 2008 at 12:01 PM, Johannes Berg
> > <[email protected]> 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