1 / 12

Remaining issues regarding power save

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

seth-padilla
Télécharger la présentation

Remaining issues regarding power save

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 • 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 • 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 • 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 • 563, 565, 783 • Summary of these comments • Periodic APSD vs Scheduled APSDAperiodic 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 • 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 • 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 • 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 • 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 • 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) • 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

More Related