A Field Guide to Wireless LANs for Administrators and Power Users

MAC/PLCP Interactions

The PLCP is used to specify certain properties of the subsequent frame, most importantly its speed (which is intimately related to the modulation that is used to transmit the digital data over the inherently analog WM). By using PLCP, each transmitted PSDU is endowed with a label that lets it be transmitted at any of the valid speeds in the Operational Rate Set as specified by the AP.

The short-format PLCP header was introduced as an optional performance-enhancing feature in the IEEE 802.11b-1999 standard. The forthcoming IEEE 802.11g standard, if approved, will be the first 2.4 GHz PHY to mandate support for the short-format PLCP header.^[14] The usage of the optional Short Preamble primarily affects the efficiency of sending Data frames, since that type of frame will tend to dominate the traffic mix within any BSS.

^[14] IEEE 802.11a-1999 specifies a PLCP structure that is not directly comparable to the DSSS PLCP header, although its high-performance nature did cause the specification to require a PLCP header that was temporally shorter than that used in the DSSS PHYs.

STAs that use the Short Preamble option can spend more of their time sending data, and less time waiting to do so, so in that regard its use will improve the aggregate throughput of a BSS. Three things must happen for any frame within a BSS to be sent using short-format PLCP headers: 1) all the STAs must support the short PLCP header format, 2) the AP must enable the usage of the short PLCP header format, and 3) all the STAs must choose to use it (once the AP has permitted it, the STA is still free to transmit any of its frames with long-format PLCP headers).

The Beacon must be understandable by any PHY operating in the 2.4 GHz band, so it must be transmitted using the least-common-denominator PLCP header format; in other words, Barker/DBPSK modulation (at a rate of 1 Mbps) with a long PLCP preamble. The Beacon's Capability Information IE indicates whether the Short Preamble may be used within its BSS. The Association Response, Reassociation Response, and Probe Response MMPDUs also contain a Capability Information IE, which are also used to convey the same information.

For backward compatibility with DSSS PHYs (1 Mbps Barker/DBPSK and 2 Mbps Barker/DQPSK), Beacon MMPDUs must be transmitted using the long-format PLCP header. The original IEEE 802.11-1999 standard, which specified the 1 and 2 Mbps DSSS RF PHYs, only specified the long-format PLCP preamble, so the Beacons must still use the long-format PLCP preamble in IEEE 802.11b-1999 and IEEE 802.11g-2003, to maintain backward compatibility with any DSSS PHY devices that may be present in the BSS.

However, even in a BSS in which the usage of Short Preambles is permitted, all the frames are not necessarily transmitted in that mode. Beacons are still sent using Long Preambles, and any IEEE 802.11b STA that wants to do so can use the Long Preamble. The indication from the AP (in the Beacon and Probe Response MMPDUs) that Short Preamble mode is enabled is not a directive that all STAs that support Short Preamble mode must send all their frames in that mode. The AP is giving permission, not issuing an order.

Moreover, even when the AP allows STAs to send frames with the short-format PLCP header, all STAs must be prepared to receive a frame preceded by the long-format PLCP header. At a minimum, this will be the Beacon MMPDUs from the AP. In addition, any STAs that roam into this BSS cannot know in advance that the AP has enabled short-preamble mode, so any MMPDUs that newly arrived STAs transmit during the authentication and association phases will have to be sent in long-preamble mode, at least until the STA discovers that it is permitted to use Short Preamble.^[15]

^[15] Such a discovery would only be relevant to a STA that is capable of using the short-format PLCP header, since legacy STAs will not know how to interpret that bit in the Capability Information IE and will ignore it

There is effectively a "preamble echo rule" that states that a response-MMPDU must be sent with the same type of preamble as the request-MMPDU that triggered the response-MMPDU. MMPDUs are sent between the AP and a STA, and those that are not request/response must be sent with the long-format PLCP header. For Data frames, how can the AP ensure that a STA which is only capable of using Long Preamble will be able to talk to a STA that supports Short Preamble PLCP headers?

The answer is quite simple. As soon as an AP associates with a long-format-only STA, it clears the "short-format PLCP header is ok" bit in its Beacon and Probe Responses. If the AP did not do this, the legacy STAs would not be able to participate in the MAC sub-layer access protocol, which depends on all the STAs being able to glean the Duration from each frame it can hear, either in the MPDU or MMPDU header, or in the RTS/CTS exchanges, in order for the operation of the Virtual Carrier Sense mechanism (in particular, the Network Allocation Vector (NAV)). The short PLCP preamble sounds like noise to a long-format-only PHY, so that PHY will not be able to make sense of the Duration field in the PSDU (MPDU), nor will it be able to tell that a valid IEEE 802.11 transmission is in progress. Also note that a short-preamble STA can recognize either preamble format, so there is no problem receiving long-preamble Beacons (or any other frame preceded by a long-format PLCP header), even if a STA is configured to transmit its frames with short-format PLCP headers.

Support for Short Preamble is optional-to-implement in IEEE 802.11-1999 DSSS PHYs and IEEE 802.11b-1999 HR/DSSS PHYs (CCK and PBCC at 5.5 and 11 Mbps), but mandatory-to-implement in IEEE 802.11g-2003 ER-PHYs (PBCC and CCK-OFDM; pure OFDM has its own distinct form of PLCP header; IEEE 802.11a-1999 uses the same form of PLCP header format that is unique to OFDM, and since it cannot interfere with STAs operating at 2.4 GHz, there is no need to be backward compatible with them…although ER-PHYs based on OFDM may use an optional protection mechanism known as "CTS-to-Self" as one way to alert nearby STAs that an unintelligible transmission is imminent).

However, in the IEEE 802.11g-2003 standard, even though Short Preamble support is mandatory-to-implement, Short Preamble PLCP headers are still optional to use; the AP decides whether it is safe to do so. Due to the improved throughput, this feature is likely to be enabled by default for transmitted data frames as long as all STAs in a BSS support the short-format PLCP header.

Even though this feature is not required to be enabled, just supported, in practice, it is likely that many APs that support IEEE 802.11g-2003 will enable the use of short preambles as a default configuration. In IEEE 802.11g-based networks, the Beacon is still transmitted with the Long Preamble. The standard allows for a mode in which all STAs in a BSS must support the Short Preamble, since there is an error message that may be used by an AP at Association time to indicate to a STA that its association was denied because it did not support the short-format PLCP preamble.

A Usage of the CTS Control Frame: CTS-to-Self

This optional mechanism is designed to advise DSSS- or HR/DSSS-STAs that a transmission is ongoing, so that they will properly update their NAVs and not transmit during the ERP (i.e., OFDM) transmission. This mechanism is potentially useful because ERP-STAs may be exchanging frames using a modulation (e.g., PBCC, OFDM) that may be undetectable by the DSSS- or HR/DSSS-STAs. In a small BSS, without hidden nodes, this mechanism would suffice to alert pre-ERP^[16] STAs that a legitimate frame transmission was about to commence, even if the frame would be undetectable to the pre-ERP STAs.

^[16] For clarity, the author will temporarily refer to DSSS and HR/DSSS STAs as pre-ERP STAs.

To keep the pre-ERP STAs from thinking it is safe to transmit, they need to be made aware that a frame is being transmitted, whether or not they can actually interpret its modulation while it is being transmitted. This mechanism, within certain limitations to be described later, allows all STAs to modify their NAVs so that they cannot transmit while the ERP-STA's frame is in progress. This feature is defined in IEEE 802.11g-2003, Clauses 7.2.1.2, 9.2.11, and 9.7.

The CTS-to-Self MAC Control frame is only generated by ERP-STAs if the AP has signaled "protected mode" in its Beacon or Probe Response MMPDUs, which indicates to ERP-STAs (i.e., IEEE 802.11g-2003 STAs) that pre-ERP STAs (i.e., IEEE 802.11-1999 or IEEE 802.11b-1999 STAs) are present. The AP is allowed to turn protected mode off (even though it knows that some pre-ERP STAs are present) if it senses that the pre-ERP STAs are not sending much traffic. The AP has real-time discretion over this decision…there is no absolute rule on when protected mode shall be used.

It is clearly true that for every associated STA, the AP must be within range of that STA. From the STA's perspective, it is in range of the AP, and other STAs may be in range of that STA as well. If an ERP-STA has sent a CTS-to-Self MAC Control frame, we can assume that the AP has received it, and knows what it means. Of course, we are assuming that the AP is capable of understanding both HR and ERP transmissions. (The CTS-to-Self MAC Control frame is transmitted using CCK modulation, so any pre-ERP STA can hear and understand it.)

In Figure 6-8, the coverage area of the AP is shown with a solid line bordering its coverage area, and the coverage areas of the ERP and non-ERP STAs are indicated with different types of dashed lines.

As mentioned previously, all the STAs are in range of the AP. In addition, in Figure 6-8 both STA₂ and STA₃ are within range of STA₁'s radio and thus can hear its transmissions. The other two STAs (STA₄ and STA₅) are both out of range of STA₁ (since they are outside of its coverage circle). Consequently, both STA₄ and STA₅ will not be able to hear any frame that is sent by STA₁, including any CTS-to-Self MAC Control frame. For the following example, let's presume that STA₁ does indeed send a CTS-to-Self MAC Control frame.

All STAs, including ERP-STAs and any older pre-ERP STAs, within range of STA₁'s radio will understand the meaning of the CTS-to-Self MAC Control frame and update their NAVs accordingly. All the STAs will see this CTS frame as a normal CTS…only STA₁ knows that it sent a CTS-to-Self MAC Control frame. STAs do not need to keep state on whether they have seen an RTS Control frame in order to know if a CTS Control frame is a response to an RTS or a CTS-to-Self message. They must simply process the CTS Control frame statelessly. All STAs within range of STA₁ regardless of whether they are pre-ERP or ERP STAs will update their NAVs (because the CTS-to-Self MAC Control frame is transmitted using a modulation that every STA within range should be able to understand).

Now, what about STA₄ and STA₅? This is different from a normal all-HR-STA hidden node scenario. It isn't a requirement that all MPDUs be preceded by an RTS/CTS exchange. In fact, each STA may have an RTS-threshold that can allow short unicast frames to be sent without using the RTS/CTS mechanism. When not using RTS/CTS, a STA senses the medium (only when its NAV permits it to transmit), and if the medium is not busy and its NAV permits it to transmit, then it simply does so. The MPDU is sent with the duration value in the D/I field set large enough to incorporate 1) the expected time to transmit the MPDU, and 2) the expected time to receive the corresponding ACK.

An out-of-range STA may send a data frame or an RTS while it is unaware that the AP is busy exchanging a frame with another STA. The frame from the out-of-range STA will interfere with the AP's transmission to or from the other STA that's life. The way that such hidden-node collisions are normally avoided is by preceding the data exchange with an RTS/CTS exchange, so that all STAs will know how long to stay idle to accommodate the frame associated with the STA that sent the RTS.

In the case of frames arriving from the DS, the AP sends the RTS to the destination STA and it is the RTS that all the STAs will hear the STA responds with a CTS, and only the STAs within range of the destination STA's radio will hear the CTS from that STA. This is not a problem, because the RTS frame from the AP had its D/I field set to cover the entire duration of the RTS/CTS exchange, the frame transmission, and the transmission of the resulting ACK. Since all the STAs will hear the RTS, they will all update their NAVs so that none will attempt to transmit while the current exchange is in progress.

In the normal hidden node case (i.e., two wireless STAs communicating through a common AP with a third STA that is also in range of the AP but is out of range of at least one of the two communicating STAs), the AP sends the CTS in response to an RTS. The CTS is heard throughout the BSS, even though the RTS is only heard within range of the STA that sent it. Hearing the CTS from the AP allows all the STAs in the BSS to update their NAVs to prevent them from transmitting during the current frame.

Unfortunately, the CTS-to-Self MAC Control frame is not heard throughout the BSS (the AP does not forward such messages; if it did, this hidden node problem would be somewhat less acute;^[17] however, the reason why CTS-to-Self exists in the first place is to improve throughput, and if the STA had to wait for the AP to echo a CTS-to-Self message, then that would reduce the throughput).

^[17] It's still possible for a new STA to pop up after the CTS was transmitted and send a frame that would then interfere with the frame that had been protected by either the RTS/CTS exchange, or by the CTS-to-Self message.

What if STA₄ or STA₅ sends a frame that "collides" with STA₁'s frame transmission? The AP would not receive the complete frame from STA₁, so it cannot send an ACK back to STA₁. Eventually, STA₁ will time out and try again. Likewise, the interfering node will not get whatever response was appropriate to the frame it tried to send (i.e., if it sent an RTS, it would be expecting a CTS; or if it sent a Data frame, it would be expecting an ACK), so it will also eventually give up and try again as well. This event is treated like any other frame collision event both STAs will choose a random back-off interval and try again at their next opportunity.

The CTS-to-Self procedure isn't perfect, but since faster modulations tie up the medium for as much as 80 percent less time (for a given packet size), it might be reasonable to suppose that the mechanism needn't be perfect. A 1500-octet IP packet becomes a 1536- or 1542-octet IEEE 802.11 frame, which takes about as much time to transmit at 54 Mbps as a 320-octet frame takes at 11 Mbps. Moreover, the CTS-to-Self mechanism isn't mandatory, and the IEEE 802.11g standard does still permit the use of RTS/CTS if desired. However, while the RTS/CTS exchange would seem to be sufficient to alert the BSS to the impending transmission (provided that the RTS and CTS are transmitted using a modulation that all HR- and ERP-STAs can understand), the RTS/CTS exchange incurs the cost of additional latency before an ERP-STA can begin to send data. This latency significantly reduces the maximum throughput that can be achieved.

Given that the CTS-to-Self mechanism can only be used by ERP-STAs, another issue is. When the STA should generate such a frame? It is a given that the AP must have enabled protected mode, but the STA needn't send an RTS before its frame. There does not appear to be any standards-based way to force the STA to use either RTS/CTS or CTS-to-Self, so this looks like a choice that implementers are free to make; this freedom extends all the way to legitimately ignoring the possibility of implementing CTS-to-Self.

The main reason to implement CTS-to-Self is that if the BSS is small, and if most of the STAs are in range of each other, then the CTS-to-Self mechanism, coupled with the fact that the frame transmission times are shorter (due to the faster speeds), means that a STA that uses CTS-to-Self may see higher throughput. If a STA detects a collision after it had sent a CTS-to-Self, the implementation might choose to infer that there are hidden nodes and it is not safe to use CTS-to-Self for a while.

This behavior (of using collisions to infer the existence of hidden nodes) is not specified in the IEEE 802.11g-2003 standard, either as a mandate or a recommendation, but anyone who tries to implement CTS-to-Self should probably define their own decision tree governing the usage of this feature, since blindly enabling it all the time will not always give the best throughput. CTS-to-Self doesn't help throughput at all in a busy BSS that is large enough such that a significant fraction of the nodes are hidden relative to each other. The goal of any implementation should be to provide the end user with the best possible throughput. Again, CTS-to-Self is not mandatory, and it is perfectly reasonable to avoid implementing it.