Advanced power save support Date: 2005-11-13 Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.

Abstract The proposal highlights some problems of the stream power save support. The proposal is relates to Req #2010 (05/0827r3) The normative text for the proposal is presented in 1072r0.

Problems in power save efficiency Optimal throughput and power efficiency is obtained if non-AP STAs need to be awake only to transmit and receive their own traffic. Retransmissions and time to receive other terminals data increase power consumption. The default EDCA parameters for high AC traffic are very good. If several terminals compete on TXOP with good parameters, it is probable the amount of transmission collisions increases. On the other hand, worse EDCA parameters reduce the priority of high AC traffic and may increase time consumption in high AC TXOP obtaining and cause priority inversion. The real time applications (VoIP) transmit frames with constant interval. If several high AC streams try to transmit data at the same time, it is probable that transmission errors will occur and the errors will reoccur from one TXOP to other.

Comparison of the automatic power save delivery (APSD) mechanisms Unscheduled and Scheduled APSD mechanisms are created for high AC real time applications power save. The main difference in mechanisms is the service period start logic: Unscheduled uses UL “trigger” frame. With trigger frame AP knows that terminal is present The terminal may avoid unnecessary awakens No scheduling possibility Scheduled starts service period between constant interval. The AP can schedule terminals to operate at different times. No mechanism to avoid unnecessary awakens AP cannot know whether the terminal listens to its transmissions

Why unscheduled APSD, why not scheduled APSD + HCCA? The most speech codecs are able to detect periods, when voice does not have any activity. For instance, AMR codec generates an audio frame in active periods at intervals of 20 ms, while during inactive periods a “DTX” frame is generated at intervals of 80 ms. If scheduled APSD is used, the non-AP STA needs to wake up for every scheduled service period. Unscheduled APSD may skip a service period, if it does not send a trigger frame. In normal calls the silence compression is used more than 50% of the call time. The reduction in overall power consumption is remarkable if the awakenings can also be reduced. The following 2 slides explain how no-AP STA may reduce the amount of service periods, when it is having UL silent compression periods. The power consumption is clearly reduced. The waking up for service periods consumes a lot of power during ongoing streams.

VoIP, normal 1 audio frame / 1 transmitted frame, no silent compression, only possible operation for scheduled APSD Audio payload in transmitted frame. Packet creation, terminal sends packets Time Packet arrival to AP Time Packet arrival to power save terminal Time = listening period Packet playout in terminal Time Audio payload in received frame.

UL silent compression, only possible for unscheduled APSD VoIP, unscheduled APSD UL silent compression, only possible for unscheduled APSD Packet creation, terminal sends packets Audio payload in transmitted frame. Time Packet arrival to AP Time Packet arrival to power save terminal The number of awakenings is halved! Time Packet playout in terminal = listening period Time Audio payload in received frame. UL Silent compression used

Example of repeating collisions Bursty TXOP obtaining start times: (Several terminals start obtain TXOP at the same time) Leads to collisions, congestions and uneven channel utilisation Probable Collision Probable Collision Simultaneous TXOP obtaining = TXOP obtaining start time = TXOP obtaining time = low AC TXOP The voice codecs or real time streams generate audio frames with the same interval. If STAs have started to obtain TXOP at the same time, this will probably happen again.

Solution for repeating errors Offered load, NAV protected times: = TXOP obtaining start time = TXOP obtaining time = high AC TXOP = low AC TXOP Distributed TXOP obtaining start times: (One terminal starts to obtain high AC TXOP at a time) Evenly loaded network, lower probability of collisions. By distributing the high AC TXOPs evenly the throughput increases and unnecessary media listening can be avoided. This allows better control to terminal power consumption in high or medium load and reliability of power save is improved. The TXOPLimit duration sets the maximum duration for a single STA to transmit data. The TXOPLimit values should be set according to the amount of high AC traffic. The distribution of the start of TXOP obtaining times reduces the risk of collisions after long low AC TXOPs, because the probability of simultaneous high AC TXOP obtaining is reduced.

The needed change to existing standard Modification to TS Info field in TSPEC. The Request schedule subfield is a single bit and is set to 1 to indicate that new schedule information is requested for the stream. If the request schedule bit is set in ADDTS.request, the AP shall reset the service start time for the stream. If AP does not support scheduling, the schedule element in ADDTS.response shall be unspecified. The non-AP and QAP should transmit data according to the schedule. The non-AP QSTA may use TSPEC fields in ADDTS.request to specify the most appropriate schedule for itself. B17 B18 23 Request Schedule Reserved 1 6

Signaling example, Non-AP QSTA originated scheduling request in stream setup Currently 802.11e does not define any mechanism how non-AP QSTA may indicate that it has a poor schedule. New indication bit is needed to ADDTS signaling that is used to request schedule change Non-AP QSTAs that operate in U-APSD or in full power, should negotiate with AP to change their data transmission times, because the change of transmission times cause easily variation to channel load and the used transmission times are no longer controlled. ADDTS.request ACK ADDTS.response ACK Non ap QSTA QAP

Signaling example, AP originated rescheduling in stream modification Schedule frame may be used by QAP to define precise operation for non-AP QSTA transmissions. QAP may use schedule frame, for instance as a reaction to triggered QoS report. No changes needed to schedule frame. Triggered QoS report ACK Schedule ACK QAP Non AP QSTA

Motion Merge substantive text from 1072/r0 into the first TGv draft. Yes: No: Abstain: