Objectives of Explicit Feedback rules May 2006 doc.: IEEE 802.11-06/0xxxr0 July 2006 Objectives of Explicit Feedback rules Date: 8-Jul-06 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>. Authors: Solomon Trainin et. al. Solomon Trainin et. al.

Authors: July 2006 May 2006 doc.: IEEE 802.11-06/0xxxr0 Solomon Trainin et. al. Solomon Trainin et. al.

May 2006 doc.: IEEE 802.11-06/0xxxr0 July 2006 Introduction The Explicit Feedback allows the requester to get channel information between its own transmitter and the responder’s receiver Requester sends sounding frame that is used by responder to measure the channel The Requester requests the channel information from the responder responder sends the channel state information to Requester in responding frame The draft already defines some parameters, formats and rules for Explicit Feedback but interoperability is still questionable We see that some rules can be seen in a different way by different people Some cases are not covered Before we can properly define details, we ought to see how the basic Explicit Feedback flow coexists with other protocol rules Main Explicit Feedback aspects See if there are contradictions with protocol rules Not at all, minimally, slightly, significantly? Agree on what we want to solve, drop or leave the solution suboptimal Solomon Trainin et. al. Solomon Trainin et. al.

What is covered in this submission May 2006 doc.: IEEE 802.11-06/0xxxr0 July 2006 What is covered in this submission Basic Explicit Feedback Features and Flows Sounding types Responding types Relation between Sounding, Feedback Requests and Responses Timing constraints Sounding, Request and Response in TxOP, zero length TxOP NAV protection issues Response related capability (in SIFS time or out of TxOP) MM/GF grouping Not touched in this presentation - how the channel information is coded in the response Solomon Trainin et. al. Solomon Trainin et. al.

Relation between Sounding and Feedback Request July 2006 Relation between Sounding and Feedback Request An activation of the sounding bit is used for PHY as well for MAC signaling The receiver’s PHY uses this signal to start related measurement/calculation of the related response The receiver’s MAC shall understand this signal as a Feedback Request, no need for the Feedback Request in the HTC anymore The Explicit Feedback Request can be combined with the MRQ The HTC field of the sounding (announcement) packet contains the CSI/Steering field to define the response’s type Control frame wrapper shall be used for announcement sent by non-HT PPDU This control frames is of new subtype control frame wrapper subtype to not confuse the non-HT devices Solomon Trainin et. al.

May 2006 doc.: IEEE 802.11-06/0xxxr0 July 2006 Sounding Types Channel measurement shall be performed only a packet where the Sounding bit is activated Sounding Types Frame with no extension HT-LTFs Staggered frame ZLF Under explicit beamforming each ZLF shall be preceded by an MPDU with announcement bit set Solomon Trainin et. al. Solomon Trainin et. al.

July 2006 Feedback Response The Time Stamp in Response reflects the Sounding packet arrival The Responder capabilities are advertised in the information element Responding capabilities Immediate: the responder is capable of sending the response SIFS after sounding PPDU or within an aggregate in the same TXOP Delayed: the responder shall not send the response in the same TXOP but shall send the response in its own TxOP These capabilities can be combined Relation between MCS and explicit feedback response If the response contains the Steering Vector the MCS shall be related to this particular SV If the response contains H the MCS is related to the sounding frame The MFB field of “all ones”= no feedback can be used when the responder cannot submit the MCS The CSI capable STA can be un-capable of the MCS feedback Solomon Trainin et. al.

Responding types Immediate capability May 2006 doc.: IEEE 802.11-06/0xxxr0 July 2006 Responding types Immediate capability The response depends on the (A)- MPDU type of the requestor’s sounding PPDU if MAC response is expected (CTS, ACK, BA) the feedback response shall be aggregated with the MAC response otherwise the response shall be sent SIFS after sounding PPDU If the ZLF sounding is used the feedback response will follow the ZLF, however the MAC response will follow the PPDU that contains related MAC request If the responder is not able submit the aggregated or immediate CSI/Steering response in SIFS time after end of the sounding packet it may submit the response aggregated with one of the following ACK/BA in the same TxOP. The requester shall continue transmitting if the PHY_RXSTART.indication does not occur during the ACKTimeout interval after end of the sounding packet and if the TxOP remaining is long enough Delayed capability– out of the Requester TxOP Solomon Trainin et. al. Solomon Trainin et. al.

Timing to get feedback during TxOP>0 May 2006 doc.: IEEE 802.11-06/0xxxr0 July 2006 Timing to get feedback during TxOP>0 Long NAV with CF-End is in use TxOP >0 can contain entire feedback sequence, ZLF as well Requester and Responder are responsible for NAV integrity – the response shall not exceed the TxOP remainder The responder shall not respond with feedback if there is not enough time reminded in the TxOP The responder shall not aggregate the feedback response with the ACK or BA if there is not enough time reminded in TxOP to deliver the aggregated response Requester uses worst case parameters to estimate the duration of response: Basic MCS Mixed Mode Maximum grouping size (new capability) Solomon Trainin et. al. Solomon Trainin et. al.

Timing to get feedback during TxOP=0 July 2006 Timing to get feedback during TxOP=0 TxOP =0 Limited to a single sequence, CF-End allowed The sequence may include protection sequence like RTS/CTS and/or self CTS or equivalent using the tunnel subtype, single ZLF, single feedback, single A-MPDU and BA Solomon Trainin et. al.