1. Remaining issues regarding power save
June 2007
Remaining issues regarding power save
Date:
Authors:
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

2. Abstract Quick status summary on power save related comments
June 2007
Abstract
Quick status summary on power save related comments
49 comments are still open.
“Topic by topic” discussion is needed to resolve these comments.
Suggested topics to be discussed
1) Power save and Routing interaction
2) How to transmit broadcast/multicast frames
3) TSPEC in Mesh ?
4) APSD editorial
5) Simplify Power Management
6) Definition of sync mode.
7) Utilization of ATIM window
8) More on APSD...
9) Miscellaneous
Kazuyuki Sakoda

3. 1) Power save and Routing interaction
June 2007
1) Power save and Routing interaction
Affected CIDs
180, 5679, 1500, 3537, 3944, 492, (705, 1857)
Summary of these comments
Explicitly address the issue of the effect of power management mode on route stability.
Consider the sub-modes on power save (route discovery active or not).
Need to define a new message to carry the power save mode information.
Clarify Power save related “capability bit”.
If it is certain that specific multicast addresses are not intended for PS MP's, the implementor should have the option to turn off buffering for this traffic.
(Make PS support mandatory.)
Kazuyuki Sakoda

4. 2) How to transmit broadcast/multicast frames
June 2007
2) How to transmit broadcast/multicast frames
Affected CIDs
4263, 781, 108, (782, 1895, 2230, 3440, 4647)
Summary of these comments
The main issue with the IBSS power-saving is that knowledge of the power-saving state of your peers is imprecise, based in receiving broadcast information... This causes my knowledge of the receiver's power-saving state to be the wrong one.  Suggest not to use broadcast ATIM frames.
Suggest replacing broadcast notification with a unicast notify/acknowledgement to increase reliability and convergence time.
What is " short broadcast or multicast frame" ?  Only short broadcast frames are allowed to transmit during ATM window of sync MPs.
(MIB attribute “dot11shortMulticastFrameLengthLimit” is missing.)
Kazuyuki Sakoda

5. 3) TSPEC in Mesh ? Affected CIDs Summary of these comments
June 2007
3) TSPEC in Mesh ?
Affected CIDs
4261, 1093, 4450, 1090, 1100, 3951
Summary of these comments
TSPEC is only defined for use between a STA and its AP.
Description on TS operation is completely missing.
Should the MP provide an admissions control guarantee, similar to the guarantee made by an AP to a STA for a traffic stream or access category, or is the purpose of a TSPEC limited to establishing state used in PS operations?
Since its unclear how TS are suspended, the section on TS reinstatement is unnecessary.
Kazuyuki Sakoda

6. 4) APSD editorial Affected CIDs Summary of these comments
June 2007
4) APSD editorial
Affected CIDs
563, 565, 783
Summary of these comments
Periodic APSD vs Scheduled APSD Aperiodic APSD vs unscheduled APSD
How does an MP determine if neighbors in a mesh support scheduled and unscheduled APSD?
Another issue
QSE(WMM) SG is going to amend the base standard regarding 11e. QSE(WMM) SG is likely to amend some part of APSD. Should we add detailed description on APSD as a part of 11s, or should we point the APSD part of the base standard ?
Kazuyuki Sakoda

7. 5) Simplify Power Management
June 2007
5) Simplify Power Management
Affected CIDs
567, 4264,
Summary of these comments
The section on power management needs simplification as it is confusing.
I predict it will *never* interoperate reliably. Please, please, please simplify.
Kazuyuki Sakoda

8. 6) Definition of Sync Mode
June 2007
6) Definition of Sync Mode
Affected CIDs
683, 5681, 3927, 3928, 4451, 1501
Summary of these comments
What is an unsynchronizing MP?
Please define unsynchronizing MP without ambiguity. If necessary, please modify the corresponding sections.  Sync discussion is ongoing, in parallel Define “independent sync” and “Mesh sync” ?
What happens if the MP finds multiple MP as neighbors which maintains different mesh TSF, DTIM interval, or ATIM window ?
All sync MPs adopt the same parameters, which may not be true in a heterogeneous network.
 Is global parameter adoption a good approach for mesh ?
Kazuyuki Sakoda

9. 7) Utilization of ATIM window
June 2007
7) Utilization of ATIM window
Affected CIDs
4262, 1994, 5665,
Summary of these comments
The ATIM window is going to be awfully busy.
Any short frame should be able to send during the ATIM period.
Each unsynchronizing MP has its own ATIM window, and it does not need to wake up until the ATIM window expiration.
Kazuyuki Sakoda

10. 8) More on APSD ... Affected CIDs Summary of these comments
June 2007
8) More on APSD ...
Affected CIDs
564, 1995, 2001, 566,
Summary of these comments
Include text to explain how MDA and Scheduled APSD will be used together.
Describe mechanisms for PS_poll or U-APSD triggering mechanism.
Unscheduled APSD is not that useful for mesh [as is also indicated in the draft] and therefore it should not be mentioned in the draft.
Kazuyuki Sakoda

11. 9) Miscellaneous CID1998 CID2002 CID4452 CID1479 CID3571, 3947
June 2007
9) Miscellaneous
CID1998
The node shall be able to return to PS, if the transmitted frames are not received by the receiver.
CID2002
The MP should be able to return to sleep as soon as possible. Replace the last word in line 7 page 199 to: "earlier".
CID4452
Modify the sentect to "A mesh point that transitions to the wake state and sucessfully transmitts a beacon should remain awake for the remainder of the beacon interval after the ATIM window.“
CID1479
Obviously, a mesh point must transition to awake if it has traffic to transmit. Replace "may" with "must“.
CID3571, 3947
All broadcast traffic are sent in DTIM interval. This means that a lot of the mesh messaging will be concentrated in this period. This may create unacceptable collision which may destroy the mesh.
Kazuyuki Sakoda

12. 9) Miscellaneous (Cont’d)
June 2007
9) Miscellaneous (Cont’d)
CID4265
The way to specify default values for parameters is in the MIB, not informative text.
CID3572
Explain the rationale for selecting these values.
Kazuyuki Sakoda