Suggested comment resolution on Power save clause May 2007 Suggested comment resolution on Power save clause Authors: Date: 2007-05-17 Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Kazuyuki Sakoda et.al.

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.

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.

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.

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.

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.

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.

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.

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

Suggested changes to the draft spec May 2007 Suggested changes to the draft spec　 After: 11A.11 Power Management in a Mesh (Optional) 11A.11.1 Overview 11A.11.2 MP Power Management modes 11A.11.3 Initialization of Power Management in mesh 11A.11.3.1 Initialization of Power Management of unsync MP 11A.11.3.2 Initialization of Power Management of sync MP 11A.11.4 Receive operation for MPs in Power Save mode 11A.11.4.1 Receiving frames from unsync MP 11A.11.4.2 Receiving frames from sync MP 11A.11.4.3 Receive operation using APSD 11A.11.5 Transmit operation for MPs transmitting to MPs in Power Save 11A.11.5.1 Operation of power save supporting unsync MP 11A.11.5.2 Operation of power save supporting sync MP 11A.11.5.3 Operation of APSD supporting MP 11A.11.6 Power management with APSD Kazuyuki Sakoda et.al.

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

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

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

References The proposed text is available : May 2007 References The proposed text is available : 11-07-0549-06-000s-Suggested-Comment-Resolution-on-Power-Save-Clause. Kazuyuki Sakoda et.al.

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.

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.

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.

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.