On Mon, 2011-11-21 at 18:40 +0400, Ivan Bezyazychnyy wrote: > Based on the latest IEEE 802.11s standard the power saving mechanism > can be divided into the following implementation phases: > * indication of mesh STAs' power modes in frames; > * a buffering and identification sending frames in mesh STA; > * Mesh Awake Window implementation; > * Peer service periods. > > This patchset implements the phase of indication of mesh STAs' > power modes in frames. There are two types of mesh power modes: > * peer power mode: a mesh STA indicates its mesh power mode for each > mesh peering and obtains the mesh power modes of its peer mesh STAs; > * non-peer power mode: mesh station also indicates mesh power mode for > non-peer mesh stations. It determines when non-peer mesh STAs may send > Probe Request and Mesh Peering Open Request frames to the mesh STA. > > Peer power mode should be indicated with Power Management field in the Frame > Control field and the Mesh Power Save Level field in all transmitted > individually addressed Mesh Data or QoS Null frames on this link. > > Non-peer power mode should be indicated with the Power Management > field in the Frame Control field and the Mesh Power Save Level field > in the Mesh Capability field in Beacon and Probe Response frames. A > mesh STA shall also indicate its non-peer mesh power mode with the > Power Management field in the Frame Control field and the Mesh Power > Save Level field in the QoS Control field in group addressed Mesh Data > frames. > > We would appreciate comments and advice. I just did a cursory review -- I only looked at code style and general issues. I expect that Thomas/Javier will review this from a functionality POV, I have no idea if these per-station things etc. even make sense. 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
