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@xxxxxxxxxxxxxxx [mailto:linux-wireless-owner@xxxxxxxxxxxxxxx] 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
