1. Objectives of Explicit Feedback rules
May 2006
doc.: IEEE /0xxxr0
July 2006
Objectives of Explicit Feedback rules
Date: 8-Jul-06
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Authors:
Solomon Trainin et. al.
Solomon Trainin et. al.

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

3. May 2006
doc.: IEEE /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.

4. What is covered in this submission
May 2006
doc.: IEEE /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.

5. 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.

6. May 2006
doc.: IEEE /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.

7. 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.

8. Responding types Immediate capability
May 2006
doc.: IEEE /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.

9. Timing to get feedback during TxOP>0
May 2006
doc.: IEEE /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.

10. 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.