1. Target Wake Times Date: 2012-07-12 Authors: July 2012 Month Year
doc.: IEEE yy/xxxxr0
July 2012
Target Wake Times
Date:
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 2012
Introduction
Long-sleeping low power devices need to minimize power consumption
Call these long-sleepers Z-class devices
Contention for medium at wake time can cause excessive power consumption
Contention between Z-class devices
Contention with H-class devices
H-class = high throughput devices
Propose mechanisms to reduce contention among H and Z class devices
Minimize wake time for Z-class devices
Matthew Fischer, et al.

5. Power Consumption Z-class STA wake to find busy network
Month Year
doc.: IEEE yy/xxxxr0
July 2012
Power Consumption
Z-class STA wake to find busy network
Potentially excessive Listen, Receive, Transmit time
Wake and wait for access, wait for RX Beacon, wait for other users
Competition with other waking Z STA and H STA
Deferral and collision delay
Causes increased power consumption, decreased battery life
Proposed solutions:
Minimize probability of Z-Z competition
Explicitly spread the Z-class devices apart in time using Target Wake Times (TWT)
Minimize probability of Z-H competition
Create Z-class-only operating windows of time
Z-class access windows follow UTIM = Uplink TIM
Matthew Fischer, et al.
John Doe, Some Company

6. Distributing Wake Times
July 2012
Distributing Wake Times
To minimize possibility of busy network upon wake:
Spread out Z-clients
Reduced probability of busy medium at wake time
Minimizes wake to transmit latency
Also minimizes collision probability
Minimizes interference between Z class and other classes
Works well when all clients are low traffic and well-spread
Best when H-class are forced to wait
Need mechanism for spreading out clients
AP control of wake times
Propose:
Requested Wake Time
Target Wake Time
Matthew Fischer, et al.

7. Propose a New Element = TWT
July 2012
Propose a New Element = TWT 1B 2B 8B
IEID
Length RT
TWT
MWD
WiM
RT = Request Type
Suggestion, Demand, AP accepts, offers alternative for TWT
Relative vs Absolute TSF reference
Exponent for WiM
Flow Direction bit, Flow ID, Flow Type (Request vs NoReq)
TWT = Target Wake Time
Relates to TSF, i.e. units are usec, 64 bits
ABSOLUTE or RELATIVE value, depending on RT indication
MWD = Minimum Wake Duration (x32 usec)
WiM = Wake Interval Mantissa
Mantissa for required wake interval for indicated direction
Exchanged during Association – always initiated by client
Can also be sent in MGMT Action frame to update during association
Can send more than one IE, e.g. one for each direction, accommodates multiple phases and periods
Not restricted to use by Z-class STA
Matthew Fischer, et al.

8. TWT IE RT field July 2012 CRQ TWTC ABS DIR FT FID WIEXP 1 3 4 5 6 7 9 4 5 6
CRQ
TWTC
ABS
DIR FT
FID
WIEXP
CRQ = Client Request
0 = AP Response
1 = Client Request
TWTC = TWT Command
000b = client NULL suggestion (let AP choose wake time)
001b = client suggestion, AP accepts client suggestion
010b = client demand, AP accepts client demand
011b = Reserved
100b = Reserved
101b = AP alternative suggestion
110b = AP alternative demand
111b = AP Rejects TWT setup
ABS = Absolute
0 = Relative TSF value (i.e. NEXT TBTT + TWT value)
1 = Absolute TSF value
DIR = Flow Direction
0 = Client to AP
1 = AP to Client
FT = Flow Type
0 = Request driven – e.g. Client must send POLL or Trigger
1 = 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 Exponent
Wake Interval Exponent, i.e. Wi = WiM x 2 ^ WiEXP
Matthew Fischer, et al.

9. Beacon Power Consumption
July 2012
Beacon Power Consumption
Z-class power consumption
Includes time spent waiting for and receiving long slow Beacon
Prefer to eliminate beacon reception
With TWT, not necessary to wake for Beacon
STA Wakes at TWT and transmits after cursory CCA check
Since Beacon was skipped, TSF adjustment needed
Option 1:
Create ACK Frame that includes partial TSF value = T-ACK
E.g. ACK with 3 Bytes of TSF_LSB
Potentially also signals operating information change
I.e. suggestion to wake for and receive a beacon for updated information
Option 2:
DL Frame contains TSF information
Matthew Fischer, et al.

10. BA With Management ACK AMPDU contents rules
July 2012
BA With Management ACK
AMPDU contents rules
Currently allows MGMT Action NoAck to be included with DATA frames
Desire ACK-able MGMT Action frame
E.g. to deliver :
NEXT TWT
TSF
Beacon Change Notification
Add MGMT Action (regular ACK) frame to AMPDU contents
One frame allowed
ACK with MGMT ACK bit in BA frame
Use one of the many reserved bits in the BA frame
Matthew Fischer, et al.

11. ACK for Mgmt Action frame within AMPDU
July 2012
ACK for Mgmt Action frame within AMPDU B5
New Bit MGMT_ACK
A reserved bit within the BA Control field conveys ACK status for the maximum one ACK-able MGMT Action frame in an AMPDU
Matthew Fischer, et al.

12. July 2012
T-ACK vs MGMT TSF
Comparison of location for TSF information for waking device
Within AMPDU inside of MGMT Action frame
Allows for maximum information transfer
E.g. TWT + TSF + Beacon Change notification + other mgmt signaling
Simple, direct, limited additional PHY or MAC overhead
Within T-ACK
Additional information has direct impact on size of ACK
AP can choose amount of information to include
Variable sized ACK = DUR estimation problem?
TSF information can be used by any waking STA
Matthew Fischer, et al.

13. Power Comparison Compare:
July 2012
Power Comparison
Compare:
PS-Poll /U-APSD (traditional mechanism using TIM signaling)
TIM-mediated UL slotting
TWT
Matthew Fischer, et al.

14. Power Consumption Profiles
July 2012
Power Consumption Profiles
Access delay
Lookup + Access delay
Sleep
Wake
Beacon UL BA DL BA SM LM RM
LM/RM TM RM
LM/RM RM TM SM
Baseline PS-POLL
Slot delay
Sleep
Wake
Beacon UL BA DL BA SM LM RM ?M TM RM RM TM SM
Beacon-based access
Sleep
Wake UL BA DL BA SM LM TM RM RM TM SM
TWT-based access
Slide 14
Matthew Fischer, et al.

15. July 2012
Sensor Battery Life
900 mAh Battery
Matthew Fischer, et al.

16. July 2012
Straw Poll
Do 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.