Link Adaptation

Link Adaptation

By CWNP On 09/18/2007 - 13 Comments

The complexity of 802.11n rate adaptation has given birth to the concept of Modulation Coding Scheme (MCS).  MCS includes variables such as the number of spatial streams, modulation, and the data rate on each stream.  Radios establishing and maintaining a link must automatically negotiate the optimum MCS based on channel conditions and then continuously adjust the selection of MCS as conditions change due to interference, motion, fading, and other events.  There are 77 MCSs each for 20 MHz and 40 MHz channels in the current 802.11n draft, with eight of them (all for 20 MHz channels) being mandatory for 802.11n compliance (Section 20.6, Table n82).  Link Adaptation is the 802.11n methodology of a transmitter and receiver working together to help each other understand which modulation and code scheme (MCS) is optimal given the current environment.

 

With 802.11n Link Adaptation, there are two roles assigned: MCS Feedback Requesters (MFB Requesters) and MCS Feedback Responders (MFB Responders).  MFB Requesters can request MCS estimates (estimates of which MCS is best used in the current environment) using the MRQ field in +HTC frames (those frames with the HT Control field added), and MFB Responders can use the MFB field in +HTC frames to provide the requested MCS estimate.

The HTC Field is structured as follows:

Bit 0 - Reserved
Bit 1 - TRQ (Training Request)
Bits 2-5 - MAI (MCS Request or Antenna Selection Indication)
Bits 6-8 - MFSI (MFB Sequence Identifier)
Bits 9-15 - MFB/ASELC (MCS Feedback and Antenna Selection Command/Data)

The MAI Subfield is structured as follows:

Bit 2 - MRQ (MCS Request)
Bits 3-5 - MSI (MCS Request Sequence Identifier)

There are two types of responses an MFB Responder can provide to an MFB Requester: Immediate and Unsolicited.  Immediate Response allows the MFB Responder to answer an MCS feedback request within the same TXOP as the request.  Unsolicited requires that the MFB Responder obtain its own TXOP so that it can send a response to the MFB Requester.

When the MRQ field is set to 1 in an MCS Request (which means MCS feedback is requested by the MFB Requester), the MSI field contains a sequence number in the range 0-6 that identifies the specific request.  The MFB Responder includes the received MSI value in the MFSI field of the corresponding response frame.  In the case of a delayed response, this allows the MFB requester to correlate the MCS Feedback with the related MCS request.  When the MFB Responder provides unsolicited MCS feedback, it sets MFSI to 7.  When a responder responds immediately, it may set the MFB to ‘all ones’ to indicate that the requested feedback is not available.

If the HT Control field is included in more than one frame (i.e., more than one +HTC frame) within the same PPDU, the MRQ field and the MSI field in each +HTC frame should be set to the same value.  The appearance of more than one instance of an HT Control field with the MRQ field set to 1 within a single PPDU will be interpreted by the receiver as a single request for MCS feedback.  If the HT Control field is included in more than one frame within the same A-MPDU, the MFB Responder may provide the MFB corresponding to different MFSI values in different frames.

After the MCS estimate computation is completed, the MFB Responder includes the MCS feedback in the MFB field in the next transmission of a frame addressed to the MFB Requester that includes an HT Control field.  The value of the MFSI is set to the MSI value from the MCS request.  When the MFB Requester sets the MRQ field to 1 and sets the MSI value to a value that matches the MSI value of a previous request for which the MFB Responder has not yet provided feedback, the MFB Responder discards or abandons the computation for the MRQ that corresponds to the previous use of that MSI value.  Stations that set the MCS Feedback field to 0 in the HT Extended Capabilities field of the HT Capability element that they transmit do not respond to MRQs.

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.