January 2004 doc IEEE 802 11 04 0030

  • Slides: 15
Download presentation
January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Presentation on

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Presentation on Proposed Normative Text for Management Cleanup Authors: Steve Emeott, Ye Chen, Stephen Wang, Floyd Simpson Motorola, Inc. Date: January 11, 2004 Submission 1 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Addresses Ballot

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Addresses Ballot Comments • APSD power management – Comment #16 thru #23 Submission 2 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Issue Addressed

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Issue Addressed • Clarification on issues relating to the 802. 11 e power management procedures specified in Clause 11. 2 needed: – What power save mode the APSD mechanism should use during automatic delivery should be clarified – Limits in normative text on delivery behaviors during scheduled and unscheduled SP should be proposed • Facilitates co-existence of APSD (scheduled & unscheduled) and legacy power management, • Permits QAP to avoid pitfalls of delivering non-APSD traffic during APSD service periods – Refinements needed to text defining normative service period triggering behavior Submission 3 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Relevant Clauses

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Relevant Clauses in 802. 11 e Draft (6. 0) • Clause 11. 2. 1. 4, defining means of engaging APSD, triggering both scheduled and unscheduled service periods and delivering frames • Clause 11. 2. 1. 5, defining AP behaviors including buffering, delivering frames and signaling buffer status • Clause 11. 2. 1. 9, defining operating mode for non. AP QSTAs transmitting and receiving frames via APSD Submission 4 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e APSD Power

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e APSD Power Mode Issue • In Clause 11. 2. 1. 4, third paragraph, APSD is used only when the non-AP QSTA is in power-save mode, as indicated by the power management bit (set to 1). • However, in Clause 11. 2. 1. 9, the non-AP QSTA transitions to Active mode prior to schedule/unscheduled service period • The two statements contradict to each other in terms of the power state at which APSD is operated. Submission 5 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e APSD Power

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e APSD Power Mode: Proposed Behavior • APSD is only used when a non-AP QSTA is in power-save mode. The non-AP QSTA wakes up prior to schedule/unscheduled service periods, but still in powersave mode as indicated by the power management bit • Benefits – QAP can continue to buffer non-APSD frames while delivering APSD traffic, avoiding potential pitfalls of transmitting non-APSD traffic (including unadmitted traffic) during APSD service periods – Non-AP can transition to Active mode, either at the beginning of the next SP or immediately, to retrieve such frames Submission 6 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e APSD Delivery

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e APSD Delivery Issue • Delivery behavior requiring QAP to attempt to transmit all frames destined for the non-AP QSTA during a scheduled/unscheduled SP is problematic – Such normative behavior is defined in clause 11. 2. 1. 4 and in clause 11. 2. 1. 5, bullet g. • Specified behavior potentially requires QAP to deliver frames addressed to a non-AP QSTA using multiple AC or even using multiple channel access functions (e. g. HCCA and EDCA) within one service period. – Such behavior required even when initiating HCCA SP during CFP Submission 7 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Further Delivery

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Further Delivery Discussion • Some of the pitfalls in delivering all frames during a scheduled/unscheduled SP – If the QAP releases traffic to multiple channel access functions at the beginning of a SP, then properly setting the EOSP bit can be problematic • Difficult to predict which EDCA channel access function might finish accessing the channel first and when to set the EOSP bit to avoid Service Start Times of other QSTA • Complicates channel access implementation if new behaviors are required to feed back state of channel access function to scheduler – Complicates the scheduler for HCCA and EDCA because the HC should consider how much time to set aside for non-APSD traffic during SP – Permits the delivery of admitted EDCA traffic with schedule=1 at times not compatible with the schedule established by the admissions control module Submission 8 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Delivery: Proposed

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Delivery: Proposed Behavior • APSD downlink traffic delivery – The QAP shall deliver buffered frames associated with an admitted TSPEC having APSD=1 during appropriate scheduled/unscheduled service periods. The QAP shall not deliver non-APSD traffic (including unadmitted traffic) during scheduled/unscheduled SP. – Scheduled SP can be used to deliver all APSD traffic; unscheduled SP can be used to deliver only unscheduled APSD traffic. • Benefit – Straightens out most of the co-existence issue between legacy, scheduled and unscheduled power management mechanisms – Simplifies the issue of how to best set the EOSP bits at the end of a scheduled/unscheduled SP – Provides multiple power save delivery modes with which the non. AP QSTA may leverage to take full advantage of EDCA Submission 9 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Triggering Issue

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Triggering Issue • In Clause 11. 2. 1. 4, sixth paragraph, it defines that any frame from a non-AP QSTA can trigger an unscheduled SP • Such behavior is problematic because – Control (e. g. PS-Poll) or management frame should certainly not trigger an unscheduled SP – Traffic sent in an AC with ACM=0 and frames associated with a TSPEC employing scheduled delivery should not trigger an unscheduled SP • The type of frame that can trigger an unscheduled SP should be redefined Submission 10 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Triggering: Proposed

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Triggering: Proposed Behavior • The only frames that can trigger an unscheduled SP (refer as trigger frame) shall be a Qo. S-Data or Null frame associated with an uplink TSPEC having its APSD subfield set to 1 and its schedule bit set to 0 by the non-AP QSTA • Benefit – Solves the problem that too many different types of frames can trigger an unscheduled SP Submission 11 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Summary of

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Summary of Proposed Changes • During APSD scheduled/unscheduled service period, the non-AP QSTA is awake but not active – APSD is used for individual traffic flows and admitted traffic, not for the entire station • Downlink delivery – Deliver only APSD traffic during scheduled/unscheduled service period. Delivery of non-APSD traffic (including unadmitted traffic) during scheduled/unscheduled SP is not allowed – Scheduled SP can be used to deliver all APSD traffic; unscheduled SP can be used to deliver only unscheduled APSD traffic. – More Data bit and TIM are used to identify the presence of non. APSD traffic (including unadmitted traffic) in the power save buffer of a QAP. • Unscheduled SP are triggered by frames associated with a TSPEC the QAP has admitted with APSD=1, schedule=0 Submission 12 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Proposed Normative

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Proposed Normative Text Changes • All proposed changes as normative text are in document 11 -04 -0030 -00 -000 e Submission 13 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Q&A Submission

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Q&A Submission 14 Steve Emeott et. al Motorola,

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Motion To

January 2004 doc. : IEEE 802. 11 -04 -0030 -00 -000 e Motion To adopt the changes identified in document 11 -04 -0028 -00 -000 e into the current TGe Draft Yes____ No____ Abstain_____ Submission 15 Steve Emeott et. al Motorola,