1. Suggested comment resolution on Power save clause
May 2007
Suggested comment resolution on Power save clause
Authors:
Date:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Kazuyuki Sakoda et.al.

2. Abstract Reviewed Comments labeled as “Power Save”
May 2007
Abstract
Reviewed Comments labeled as “Power Save”
There are 102 open comments regarding “Power Save”.
It is better to break them down to more detailed sub-categories.
Following slides present :
Suggested detailed issue identifier for “power save” related comments.
Suggested draft text refinement policy on power save clause.
Kazuyuki Sakoda et.al.

3. Suggested sub-categories for power save issues
May 2007
Suggested sub-categories for power save issues
“Power save - editorial” [37]
While not as an editorial comment, comments suggest the better explanation.
Comments suggesting to restructure the document regarding power save clause.
“Power save - clarification” [10]
Comments invoking some clarification.
“Power save - ATIM parameter” [02]
Comments on how to advertise ATIM window size parameter.
“Power save - ATIM window” [03]
Comments on the particular issue on ATIM window.
“Power save - APSD” [15]
Comments regarding APSD type of power saving.
“Power save - sync parameter” [06]
Comments on how to deal with sync MP’s parameters.
“Power save - MIB” [05]
Comments on the lack of MIB attribute.
“Power save - general” [21]
Comments which seems to need some discussion to resolve.
“Power save - other” [03]
Comments seem to be belonging to other category.
Kazuyuki Sakoda et.al.

4. 2 Steps approach for resolving comments
May 2007
2 Steps approach for resolving comments
Step 1:
Focus on cleaning up and restructuring the power save clause, so that we can make common understanding of the mechanisms easily.
Try NOT to include controversial technical changes.
Step 2:
With clearer text, identify the issue (meaning the root of the issues) more easily, and resolve issues in accordance with the deep depth technical discussion.
Kazuyuki Sakoda et.al.

5. Suggested sub-categories for power save issues
May 2007
Suggested sub-categories for power save issues
“Power save - editorial” [37]
While not as an editorial comment, comments suggest the better explanation.
Comments suggesting to restructure the document regarding power save clause.
“Power save - clarification” [10]
Comments invoking some clarification.
“Power save - ATIM parameter” [02]
Comments on how to advertise ATIM window size parameter.
“Power save - ATIM window” [03]
Comments on the particular issue on ATIM window.
“Power save - APSD” [15]
Comments regarding APSD type of power saving.
“Power save - sync parameter” [06]
Comments on how to deal with sync MP’s parameters.
“Power save - MIB” [05]
Comments on the lack of MIB attribute.
“Power save - general” [21]
Comments which seems to need some discussion to resolve.
“Power save - other” [03]
Comments seem to be belonging to other category.
Focused comments
in this proposal
As a first step
comments which could be resolved by 07/319, 07/320.
Kazuyuki Sakoda et.al.

6. Summary of comments focused to resolve with this proposal
May 2007
Summary of comments focused to resolve with this proposal
Many of the comments identified as “Power save - editorial” or “Power save - clarification” request to clean up the text.
What the Power Save capability bits in Mesh capability indicate?
What is meant by “power save support”?
What happens if MP changes its power management mode?
How the ATIM window will be used?
Suggest to change the document structure.
MAP behavior and MP behavior is mixed up.
Power save mode and power save support is mixed up.
Text refers to inappropriate information elements.
Informative text should not be present in the main body of the standard.
Does LWMP process “association” ?
Some editorial suggestions...
Kazuyuki Sakoda et.al.

7. Suggested refinement policy (1st step)
May 2007
Suggested refinement policy (1st step)
1. Explicitly define two roles:
Power save supporting MP: MP which is communicating with MP in power save mode. Power save supporting MP may or may not be in power save mode.
Power saving MP: MP which is in power save mode. Power saving MP can establish/maintain peer link only with power save supporting MPs.
2. Reduce “Power Save Capability” bits
Only “Power Save Support” bit presents in capability field.
No need to advertise “power saving capability”. MP may transit to Power Save mode, only if all the peer MPs are Power Save Supporting MP.
Kazuyuki Sakoda et.al.

8. Suggested refinement policy (1st step)
May 2007
Suggested refinement policy (1st step)
3. Supply missing description
Need to articulate the PS mechanism as a technical specification.
There are many missing description in the current draft.
4. Reorganize the power save clause
Make it more “structured” text.
Explain the behavior of unsync MP and sync MP independently.
Explain the behavior of “power save supporting MP” and “power saving MP” independently.
Explain the APSD mechanism independently.
Kazuyuki Sakoda et.al.

9. Suggested changes to the draft spec
May 2007
Suggested changes to the draft spec
Before:
11A.11 Power Management in a Mesh (Optional)
11A Overview
11A Basic approach
11A Initialization of power management within a mesh
11A MP power state transitions
11A Frame transmission
11A Power management operation with APSD
11A TS Reinstatement
11A Beacon broadcaster power save mode
Kazuyuki Sakoda et.al.

10. Suggested changes to the draft spec
May 2007
Suggested changes to the draft spec　
After:
11A.11 Power Management in a Mesh (Optional)
11A Overview
11A MP Power Management modes
11A Initialization of Power Management in mesh
11A Initialization of Power Management of unsync MP
11A Initialization of Power Management of sync MP
11A Receive operation for MPs in Power Save mode
11A Receiving frames from unsync MP
11A Receiving frames from sync MP
11A Receive operation using APSD
11A Transmit operation for MPs transmitting to MPs in Power Save
11A Operation of power save supporting unsync MP
11A Operation of power save supporting sync MP
11A Operation of APSD supporting MP
11A Power management with APSD
Kazuyuki Sakoda et.al.

11. Suggested changes to the draft spec (Cont’d)
May 2007
Suggested changes to the draft spec (Cont’d)
11A Overview
Utilization of the power save capability bit and power management bit.
Brief overview of the entire power save mechanism.
11A MP Power Management modes
Definition of Active mode and Power Save mode.
Mode transition between active mode and power save mode.
11A Initialization of Power Management in mesh
Procedure which needs to be done to initialize power management.
11A Initialization of Power Management of unsync MP
Procedure necessary for unsync MP
11A Initialization of Power Management of sync MP
Procedure necessary for syncMP
Kazuyuki Sakoda et.al.

12. Suggested changes to the draft spec (Cont’d)
May 2007
Suggested changes to the draft spec (Cont’d)
11A Receive operation for MPs in PS mode
Power state transition of power saving MP
11A Receiving frames from unsync MP
How to receive frames from unsync MP
11A Receiving frames from sync MP
How to receive frames from sync MP
11A Receive operation using APSD
How to receive frames using APSD mechanism
11A Transmit operation for MPs transmitting to MPs in PS mode
Frame transmission rules for power save supporting MP
11A Operation of power save supporting unsync MP
Frame transmission rules for unsync MP
11A Operation of power save supporting sync MP
Frame transmission rules for sync MP
11A Operation of APSD supporting MP
Frame transmission rules using APSD mechanism.
Kazuyuki Sakoda et.al.

13. Suggested changes to the draft spec (Cont’d)
May 2007
Suggested changes to the draft spec (Cont’d)
11A Power management operation with APSD
Additional rules for APSD type of operation.
11A Aperiodic APSD
Rules for unscheduled APSD type of operation.
11A Periodic APSD
Rules for scheduled APSD type of operation.
Kazuyuki Sakoda et.al.

14. References The proposed text is available :
May 2007
References
The proposed text is available :
s-Suggested-Comment-Resolution-on-Power-Save-Clause.
Kazuyuki Sakoda et.al.

15. Delta between doc549r3 and doc549r6
May 2007
Delta between doc549r3 and doc549r6
The “Power Save Support” is renamed by “Power Save Support Enabled”.
The normative definition of “power save supporting MP” and “power saving MP” is removed from clause 3,“Definition”.
Annex T.10 is removed.
Miss-underlined text is corrected.
Some more editorial correction is made.
Kazuyuki Sakoda et.al.

16. 2 Steps approach for resolving comments
May 2007
2 Steps approach for resolving comments
Step 1:
Focus on cleaning up and restructuring the power save clause, so that people can easily understand the power save mechanism.
Try NOT to include controversial technical changes.
This is what the document(doc549) is trying to address.
Step 2:
With clearer text, identify the issue (meaning the root of the issues) more easily, and resolve issues in accordance with the deep depth technical discussion.
Kazuyuki Sakoda et.al.

17. Provision for the next step
May 2007
Provision for the next step
Remaining issues:
Impact of power save to routing protocols
We understand that RFI group has concerns regarding power save.
We would like to get detailed description of the major concerns, so that we can provide an analysis or quantitative results to address your concerns.
We would like to set up a meeting with RFI group at PM2 session today, if possible.
Coordination between beaconing mechanisms and PS
Whether there is an interaction between beacon broadcasting and power save.
If so, we need to define the interaction how beacon broadcast and power save work together, in terms of reliable PS operation.
Editorial changes after terminology in synchronization is finalized
Some technical details are still needed to be worked out
APSD
How we should define APSD in mesh or should not.
Kazuyuki Sakoda et.al.

18. May 2007
Motion
Move to accept the resolution to CID92, 93, 109, 110, 774, 775, 780, 1091, 1092, 1465, 1466, 1471, 1472, 1473, 1474, 1480, 1924, 1996, 2000, 2003, 2094, 3437, 3609, 3767, 3926, 3931, 3934, 3935, 3938, 3941, 3945, 3948, 4453, 4596, 5592, 5597, 5667, 5674, and 5680, as proposed in document 11-07/0549r6.
Moved by:
Second by:
Result (Yes/No/Abstain):
Kazuyuki Sakoda et.al.