Presentation on theme: "Target Wake Times Date: Authors: July 2012 Month Year"— Presentation transcript:
1 Target Wake Times Date: 2012-07-12 Authors: July 2012 Month Year doc.: IEEE yy/xxxxr0July 2012Target Wake TimesDate:Authors:Matthew Fischer, et al.John Doe, Some Company
2 Authors: July 2012 Month Year doc.: IEEE 802.11-yy/xxxxr0 Matthew Fischer, et al.John Doe, Some Company
3 Authors: July 2012 Month Year doc.: IEEE 802.11-yy/xxxxr0 Matthew Fischer, et al.John Doe, Some Company
4 July 2012IntroductionLong-sleeping low power devices need to minimize power consumptionCall these long-sleepers Z-class devicesContention for medium at wake time can cause excessive power consumptionContention between Z-class devicesContention with H-class devicesH-class = high throughput devicesPropose mechanisms to reduce contention among H and Z class devicesMinimize wake time for Z-class devicesMatthew Fischer, et al.
5 Power Consumption Z-class STA wake to find busy network Month Yeardoc.: IEEE yy/xxxxr0July 2012Power ConsumptionZ-class STA wake to find busy networkPotentially excessive Listen, Receive, Transmit timeWake and wait for access, wait for RX Beacon, wait for other usersCompetition with other waking Z STA and H STADeferral and collision delayCauses increased power consumption, decreased battery lifeProposed solutions:Minimize probability of Z-Z competitionExplicitly spread the Z-class devices apart in time using Target Wake Times (TWT)Minimize probability of Z-H competitionCreate Z-class-only operating windows of timeZ-class access windows follow UTIM = Uplink TIMMatthew Fischer, et al.John Doe, Some Company
6 Distributing Wake Times July 2012Distributing Wake TimesTo minimize possibility of busy network upon wake:Spread out Z-clientsReduced probability of busy medium at wake timeMinimizes wake to transmit latencyAlso minimizes collision probabilityMinimizes interference between Z class and other classesWorks well when all clients are low traffic and well-spreadBest when H-class are forced to waitNeed mechanism for spreading out clientsAP control of wake timesPropose:Requested Wake TimeTarget Wake TimeMatthew Fischer, et al.
7 Propose a New Element = TWT July 2012Propose a New Element = TWT1B2B8BIEIDLengthRTTWTMWDWiMRT = Request TypeSuggestion, Demand, AP accepts, offers alternative for TWTRelative vs Absolute TSF referenceExponent for WiMFlow Direction bit, Flow ID, Flow Type (Request vs NoReq)TWT = Target Wake TimeRelates to TSF, i.e. units are usec, 64 bitsABSOLUTE or RELATIVE value, depending on RT indicationMWD = Minimum Wake Duration (x32 usec)WiM = Wake Interval MantissaMantissa for required wake interval for indicated directionExchanged during Association – always initiated by clientCan also be sent in MGMT Action frame to update during associationCan send more than one IE, e.g. one for each direction, accommodates multiple phases and periodsNot restricted to use by Z-class STAMatthew Fischer, et al.
8 TWT IE RT field July 2012 CRQ TWTC ABS DIR FT FID WIEXP 1 3 4 5 6 7 9 456CRQTWTCABSDIRFTFIDWIEXPCRQ = Client Request0 = AP Response1 = Client RequestTWTC = TWT Command000b = client NULL suggestion (let AP choose wake time)001b = client suggestion, AP accepts client suggestion010b = client demand, AP accepts client demand011b = Reserved100b = Reserved101b = AP alternative suggestion110b = AP alternative demand111b = AP Rejects TWT setupABS = Absolute0 = Relative TSF value (i.e. NEXT TBTT + TWT value)1 = Absolute TSF valueDIR = Flow Direction0 = Client to AP1 = AP to ClientFT = Flow Type0 = Request driven – e.g. Client must send POLL or Trigger1 = No Request necessary – e.g. AP transmits without first hearing Poll or Trigger, or uplink TX (client transmits)FID = Flow ID, RA-TA pair unique (not directionally unique)WIEXP = Wi ExponentWake Interval Exponent, i.e. Wi = WiM x 2 ^ WiEXPMatthew Fischer, et al.
9 Beacon Power Consumption July 2012Beacon Power ConsumptionZ-class power consumptionIncludes time spent waiting for and receiving long slow BeaconPrefer to eliminate beacon receptionWith TWT, not necessary to wake for BeaconSTA Wakes at TWT and transmits after cursory CCA checkSince Beacon was skipped, TSF adjustment neededOption 1:Create ACK Frame that includes partial TSF value = T-ACKE.g. ACK with 3 Bytes of TSF_LSBPotentially also signals operating information changeI.e. suggestion to wake for and receive a beacon for updated informationOption 2:DL Frame contains TSF informationMatthew Fischer, et al.
10 BA With Management ACK AMPDU contents rules July 2012BA With Management ACKAMPDU contents rulesCurrently allows MGMT Action NoAck to be included with DATA framesDesire ACK-able MGMT Action frameE.g. to deliver :NEXT TWTTSFBeacon Change NotificationAdd MGMT Action (regular ACK) frame to AMPDU contentsOne frame allowedACK with MGMT ACK bit in BA frameUse one of the many reserved bits in the BA frameMatthew Fischer, et al.
11 ACK for Mgmt Action frame within AMPDU July 2012ACK for Mgmt Action frame within AMPDUB5New Bit MGMT_ACKA reserved bit within the BA Control field conveys ACK status for the maximum one ACK-able MGMT Action frame in an AMPDUMatthew Fischer, et al.
12 July 2012T-ACK vs MGMT TSFComparison of location for TSF information for waking deviceWithin AMPDU inside of MGMT Action frameAllows for maximum information transferE.g. TWT + TSF + Beacon Change notification + other mgmt signalingSimple, direct, limited additional PHY or MAC overheadWithin T-ACKAdditional information has direct impact on size of ACKAP can choose amount of information to includeVariable sized ACK = DUR estimation problem?TSF information can be used by any waking STAMatthew Fischer, et al.
13 Power Comparison Compare: July 2012Power ComparisonCompare:PS-Poll /U-APSD (traditional mechanism using TIM signaling)TIM-mediated UL slottingTWTMatthew Fischer, et al.
14 Power Consumption Profiles July 2012Power Consumption ProfilesAccess delayLookup + Access delaySleepWakeBeaconULBADLBASMLMRMLM/RMTMRMLM/RMRMTMSMBaseline PS-POLLSlot delaySleepWakeBeaconULBADLBASMLMRM?MTMRMRMTMSMBeacon-based accessSleepWakeULBADLBASMLMTMRMRMTMSMTWT-based accessSlide 14Matthew Fischer, et al.
15 July 2012Sensor Battery Life900 mAh BatteryMatthew Fischer, et al.
16 July 2012Straw PollDo you support adding to the specification framework document an item to include a mechanism to set wake times and intervals for clients?Matthew Fischer, et al.