1. Resolutions of the Remaining Power Management Comments
Month Year
doc.: IEEE yy/xxxxr0
July 2009
Resolutions of the Remaining Power Management Comments
Date:
Authors:
Jarkko Kneckt, Nokia
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
July 2009
Abstract
The presentation describes resolutions for the remaining power management related comments.
The remaining power management comments are CIDs: 5, 141, 343, 393, 398, 538, 727 and 795.
Jarkko Kneckt, Nokia
John Doe, Some Company

3. July 2009
CID 5
CID 5 is editorial comment requesting that very generic name power mode will be renamed to mesh power mode
Proposal to accept the comment:
Mesh power mode is more specific name
This comment is left over, other similar comments are already solved, CID 207 is the same comment and it proposes the same resolution
The normative text is given by 11-09/672r2.
Jarkko Kneckt, Nokia

4. July 2009
CID 727
CID 727 requests MLME-MeshPOWERMGT.confirm primitive to have resultCode to report the status of the operation
Proposal to accept the comment:
Wit the resultCode, the MLME-MeshPOWERMGT.confirm has the same format as MLME-POWERMGT.confirm in infrastructure mode
This comment is left over. Similar comment is already solved, CID 272 is the same comment and it proposes the same resolution
The normative text is given by 11-09/672r2
Jarkko Kneckt, Nokia

5. July 2009
CID 343
The CID 343 reads: “Power Save level field and RSPI field should be placed in the QoS Control field, since power save is more related to link control. Mesh Control field should be used for multihop related functions. QoS control field has a lot of reserved field”
The comment is related to frame formats
The ad hoc group in Montreal May 2009 saw value on using the reserved part of the QoS Control field, but on the other hand the use of these bits would change their traditional meaning and trigger more comments in the next ballot
Perhaps the best solution is to have a straw poll to select the most favorable option
Jarkko Kneckt, Nokia

6. July 2009
CID 343
Straw Poll:
Option 1: Lets have RSPI and mesh power save level in Mesh Control field
Option 2: Lets have RSPI and mesh power save level in QoS Control field
QoS Control Field
Mesh Control Field
Bit 0 -3
Bit 4
Bit 5-6
Bit 7
Bit 8
Bit 9
Bit
TID
EOSP
Ack Policy
A-MSDU Present
Mesh Power Save Level
RSPI
Reserved
Jarkko Kneckt, Nokia

7. July 2009
CID 393
CID 393 says: “It is unclear how the reverse direction grant (defined in 11n) is treated in terms of the peer service period.”
Recommended to add the following to the end of clause 11C : Reverse Direction Grant (RDG) shall not be used when the receiver of the TXOP operates in light or deep sleep mode and is not a transmitter in service period toward the transmitter in the TXOP.
The change ensures that the granted mesh STA has receiver available for the transmission
Jarkko Kneckt, Nokia

8. CID 398 CID 398 is related to annex V.4.5
July 2009
CID 398
CID 398 is related to annex V.4.5
The sentence reads: “Mesh STAs shall maintain synchronization among neighbor mesh STAs." However, the definition or criteria for the synchronization is not described.
The same clause gives a definition for synchronization maintenance according to neighbor offset protocol:” Mesh STAs in deep sleep mode might not receive Beacon frames of peer mesh STAs, but mesh STAs shall maintain synchronization among neighbor mesh STAs. Neighbor offset protocol imposes the maintenance of TSF offset values between neighbor mesh STAs, which generally requires the reception of Beacon frame or Probe Response frame. The simplest way to maintain the synchronization is that the mesh STAs in deep sleep mode listen to the neighbor mesh STA’s Beacon frame for certain periods and check the TSF offset value.
Recommended to reject the CID 398 and use the text in the same annex to explain the synchronization maintenance
Jarkko Kneckt, Nokia

9. July 2009
CID 538
The CID 538 reads: “The Mesh TIM would be improved if it reflected 11v changes to the TIM for MBSSID etc”
In May 2009 meeting, the mesh TIM element was replaced by TIM element
The v TIM enhancement contain possibility to include information for multiple BSSs, i.e. the same element contains information for multiple infrastructure networks
Recommended resolution: Reject the comment.
The focus of the s standard is to describe the basic operation logic of the MBSS. It is assumed that one mesh STA operates in one MBSS at a time and simultaneous use of multiple MBSS with the same MAC address is not considered
Jarkko Kneckt, Nokia

10. July 2009
CID 795
CID 795 is related to criteria for listening time of the beacon frame
The commenter proposes implementation dependent wait time to receive beacon frame and to use Group Delivery Idle Time to control only the reception of the group addressed frames
If the Beacon frame may be received only during the Group Delivery Idle Time, the synchronization maintenance, i.e. TSF or TBTT adjustments may cause failure in Beacon reception
Recommended to accept the comment
The following slide shows an example
Jarkko Kneckt, Nokia

11. CID 795 In the example Mesh STA 2 is receiving beacons from mesh STA 1
July 2009
CID 795
Original Beacon TX time
TBTT change
Beacon
Beacon
Beacon
Mesh STA 1
Mesh STA 2
Time
Group Delivery Idle Time
Group Delivery Idle Time
Group Delivery Idle Time
Not received beacon
In the example Mesh STA 2 is receiving beacons from mesh STA 1
Mesh STA 1 changes its TBTT
Mesh STA 2 does not notice the change and because the transmitted beacon does not fit into Group Delivery Idle Time, the Mesh STA 2 does not receive it
Efficient recovery logic from missed beacons requires that mesh STA may listen to the media at any time which is in contradiction with the Group Delivery Idle Time definition
Jarkko Kneckt, Nokia

12. July 2009
References
802.11s D3.02
11-09/672r2
Jarkko Kneckt, Nokia