802.11n Protection Mechanisms: Part 2
By CWNP On 08/13/2007 - 10 Comments
Dual CTS bit in the HT IE:
When this feature is used, beacons in a BSS have the "Dual CTS Protection subfield" set to 1. Stations will then start every TXOP with an RTS frame addressed to the AP. The AP responds to this RTS with two CTS frames. If the RTS is an STBC frame, then the first CTS is an STBC frame back to the station and the second CTS is a non-STBC frame back to the station. This assures that all STBC and non-STBC stations receive the CTS and set their NAVs accordingly. NAVs are set to cover the entire transmission process (as always), including both CTS transmissions (which is new).
CF-End Frames:
This frame type, previously unused due to a lack of PCF implementations, can now be used in contention environments as a NAV reset tool. When Dual-CTS is enabled and a station doesn't have any data to transmit when it obtains a TXOP, the station can truncate (cut it short, thus giving back its remaining time) its TXOP by sending a CF-End frame. When receiving a CF-End frame with its BSSID as the destination address, the AP may resond by sending dual CF-End frames - one using STBC, one using non-STBC. This resets everyone's NAV in the BSS. Does anyone else notice the fact that with these two mechanisms, you could cause an AP to DoS its own BSS? :-(
L-SIG TXOP protection ("PHY Layer Spoofing")
In OFDM frames (clause 17), the PPDU header consists of short training fields, long training fields, and a SIGNAL field. Inside the SIGNAL field is the LENGTH subfield. In a non-HT format frame, this subfield, called L_LENGTH in 802.11n, indicates the length of the PSDU in octets in the range 1-4095. This value is used by the PHY to determine the number of octet transfers that occur between the MAC and the PHY.
When the 802.11n frame format is HT Mixed (keeping in mind that there are only HT Mixed format (HT_MF) and HT Greenfield format (HT_GF)), the LENGTH subfield is used along with RATE subfield to control the duration that non-HT STAs defer transmission equaling a period of time corresponding to the length of the HT PPDU (or the L-SIG Duration when L-SIG TXOP protection is used). To restate, when using an HT Mixed format preamble, the Rate subfield in the Legacy OFDM Signal field (L-SIG) field of HT frame headers is always set to 6 Mb/s. The Length subfield of the L-SIG field of HT frames with an HT Mixed format PHY preamble always contains a value that (together with the Rate subfield) represents a duration corresponding to the length of the rest of the PPDU, with a few exceptions. This is "PHY Layer Spoofing."
An HT STA must indicate whether it supports L-SIG TXOP Protection in its L-SIG TXOP Protection Support capability field in Association Requests and Probe Responses.
The AP determines whether all HT stations associated with its BSS support L-SIG TXOP Protection and indicates this in the L-SIG TXOP Protection Full Support field of its HT Information Element. This field is set to 1 only if the L-SIG TXOP Protection field is set to 1 by all HT station in the BSS.
A station is not allowed to transmit a frame using L-SIG TXOP Protection directed to a recipient that does not support L-SIG TXOP Protection. When the station is associated with an AP, support at a recipient that is associated with the same AP is indicated if the L-SIG TXOP Protection Full Support field is set to 1 in the HT Information element broadcast in Beacons transmitted by the AP with which the stations are associated. L-SIG TXOP support at the recipient may additionally be determined through examination of HT Capability elements exchanged during association.
Under L-SIG TXOP Protection operation, the L-SIG field with an HT mixed format PHY preamble represents a duration value equivalent to the sum of:
a) the value of Duration/ID field contained in the MAC header, and
b) the duration remaining in the current packet (from the end of the symbol containing the L-SIG field to the end of the last symbol of the packet).
The maximum value of L_LENGTH is 4095 octets.
Non-HT stations are not able to receive any PPDU that starts during the L-SIG duration. Therefore, no frame may be transmitted to a non-HT station during an L-SIG protected TXOP. L-SIG TXOP Protection should not be used and the implementers of L-SIG TXOP Protection are advised to include a NAV based fallback mechanism, if it is determined that the mechanism fails to effectively suppress non-HT transmissions. How this is determined is outside the scope of the standard.
The figure below (Example of L-SIG Duration Setting) illustrates an example of how L-SIG Durations are set when using L-SIG TXOP Protection. An L-SIG TXOP protected sequence starts with an initial handshake, which is the exchange of two short frames (each inside a HT MM PPDU) that establish protection. RTS/CTS is an example of this. Any initial frame exchange may be used that is valid for the start of a TXOP, provided the duration of the response frame within this sequence is predictable. The term L-SIG TXOP protected sequence includes these initial frames and any subsequent frames transmitted within the protected duration.
An HT station is allowed to transmit a CF-End when the TXOP is not completely used by the TXOP owner, in a BSS whose beacon contains an HT Information element with the Operating Mode field set to 0. This will reset the NAV at the HT station. An HT STA using L-SIG TXOP protection should use an accurate prediction of the TXOP duration inside the Duration/ID field of the MAC header to avoid inefficient use of the channel capability. If the initial frame handshake succeeds (i.e., upon reception of a response frame with L-SIG TXOP Protection addressed to the TXOP holder), all HT mixed format PPDUs transmitted inside an L-SIG TXOP Protection protected TXOP must contain an L-SIG Duration that extends to the endpoint indicated by the MAC Duration/ID field.
Part 1 of this series can be found here.
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.
0 Responses to 802.11n Protection Mechanisms: Part 2
Subscribe by EmailThere are no comments yet.
<< prev - comments page 1 of 1 - next >>
Leave a Reply
Please login or sign-up to add your comment.