Remaining issues regarding power save June 2007 Remaining issues regarding power save Date: 2007-06-13 Authors: Kazuyuki Sakoda

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

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

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

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

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

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

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

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

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

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

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