A Field Guide to Wireless LANs for Administrators and Power Users

CSMA/CA is the basic method by which wireless STAs share access to the medium. IEEE 802.11's medium access protocol was designed to tolerate frame loss due to interference (which could come from any number of sources…misbehaving or hidden IEEE 802.11 stations, 2.4 GHz cordless phones, garage door openers, Bluetooth devices, microwave ovens, lightning, etc.). Interference is a much more common phenomenon in the wireless domain; if design accommodations were not made, the throughput of the IEEE 802.11 MAC might have been significantly limited.

Wireless versus Wired MAC Protocol Design Differences

Many readers are probably familiar with CSMA/CD, which was the algorithm that was defined for the initial shared-access Ethernet. In certain circles, the term "CSMA/CD" is interchangeable with Ethernet, although strictly speaking, CSMA/CD only applies to shared-media (half-duplex) Ethernets.

In a WLAN, stations can use whatever speed(s) are supported by their PHYs, as conditions warrant (i.e., if there is significant interference, slower speeds might be more successful than higher speeds); whereas in Ethernet, once a station has determined its speed, it continues to use that speed unless the station is manually reconfigured.

One advantage that designers of wired LAN MAC protocols have is that the media over which their protocols are designed to operate consist of environments with very high signal-to-noise ratios (e.g., copper twisted pair, or optical fiber), resulting in very low bit error rates. In such environments, since there is so little noise (either relative to the signal, or in absolute terms), there is a very high likelihood of successful transmission.

In addition, many wired LAN access protocols assume that all members can hear each other's transmissions, which is most definitely not a valid assumption in the wireless world. WLAN MAC protocols must be designed to support the much more challenging transmission environment^[18] of wireless (particularly RF wireless). If a wireless MAC design ignored the reality of interference, and assumed that all stations were close enough to each other to hear each other directly, WLAN performance would be horrible, and usability would suffer. There are three main ways in which IEEE 802.11's MAC has been designed to tolerate interference.

^[18] In fact, the 2.4 GHz band that is used by IEEE 802.11, IEEE 802.11b, and IEEE 802.11g has been known as a "junk" band because of contamination by microwave oven emissions and more recently cordless telephone transmissions. Originally, the 2.4 GHz band was reserved because of interference from microwave ovens, expressing the FCC's feeling that no one else would ever want to try to use this band. However, the pressure to allocate more of the available RF spectrum to communications forced the FCC to create rules for unlicensed ISM operation in this allegedly worthless band.

The most common example of a wired LAN, Ethernet, began life as a half-duplex LAN that operated over a shared broadcast medium (initially coaxial cable, a.k.a. "thicknet," which evolved into shared 10BASE-T hubs that were still half-duplex, at least initially). In one very important way, the Ethernet's physical characteristics were similar to the RF environment that IEEE 802.11 is designed to operate in they are both broadcast media, in the sense that when one station transmits, others can hear it. To fairly allocate access to the shared 10 or 100 Mbps half-duplex medium, Ethernet employed the CSMA/CD algorithm.

However, CSMA/CD is not suited to operation over the WM. The radios cannot hear while they transmit, so they cannot hear a collision. Even if they could hear while they transmit frames, the fact that they didn't hear a collision didn't mean that one didn't happen. The STA that sent whatever frame interfered with the sender's frame may have been out of range of the sender's radio, but in range of the receiver's radio. This is the key difference. In half-duplex Ethernet, all STAs are presumed to be able to hear each other, but in IEEE 802.11, hidden nodes are a fact of life. A method of collision detection that can handle hidden nodes was required, which is known as CSMA/CA.^[19]

^[19] CSMA/CA has also been used in some wired LANs; for example, Apple's LocalTalk 230.4 kbps LAN that was based on RS-422 cabling.

The result of a collision in Ethernet and IEEE 802.11 is similar, in that a binary exponential backoff algorithm helps ensure that after a collision, one of the stations will have a chance to transmit a frame successfully. However, the IEEE 802.11 design places the collision backoff in front of the frame transmission, to help eliminate obvious collisions due to STAs simultaneously detecting an idle medium.

The big difference between Ethernet's CSMA/CD and IEEE 802.11's CSMA/CA is that in the case of half-duplex Ethernet, the LAN's collision domain is defined so that the sending and receiving stations are guaranteed to be able to hear each other's traffic within 512 bit-times (which is the reason why the minimum packet size is 64 octets; i.e., 512 bits). In IEEE 802.11, however, there is the possibility that the sender's transmission could be interfered with by a hidden node, a node that is within range of the receiver, but not of the sender. Of course, all these STAs are in range of the AP, and the IEEE 802.11 protocols incorporate several techniques for handling hidden nodes, one of which is the ACK mechanism, and the other is the virtual carrier sense mechanism that is explicitly enabled by the RTS/CTS exchange, and is implicitly enabled by any frame via its Duration field.

To detect if a collision has occurred, IEEE 802.11 STAs must acknowledge every frame that they receive; if no acknowledgment is received by the sender, the frame is retransmitted until it gets through or until the sender gives up and declares an error condition. It is important to note that the retransmissions are not meant to make the WM into a reliable transport service. IEEE 802.11 is still a LAN, and it still provides an unreliable datagram service. However, IEEE 802.11's designers realized that the sender may not be able to tell if its transmission has been corrupted, since the energy that was transmitted that stomped on the sender's transmission may have been from a hidden node, and the sender may not have been able to hear that hidden node but the receiver did, and that's all that matters. In Ethernet, the sender can tell immediately if a collision has occurred, and can take steps to recover as soon as the error has been detected. In IEEE 802.11, the STA can't detect the collision until after the frame has been transmitted fully; even if more than half of it is garbled, the sender has no way to know that until after it realizes it never got an ACK for that frame.

One limitation of the IEEE 802.11 method of collision detection is that a lost ACK is equivalent to a sender inferring the occurrence of a collision. If a frame is re-transmitted by the sender, the frame is marked to indicate that it is a retransmission, and the receiver will ACK a retransmitted frame, multiple times (until the ACK finally gets through to the sender), but will only accept one copy of the frame. Each frame has a unique sequence number that can be used to eliminate duplicate frames due to retransmission. Remember, in the case of a lost ACK, the sender thinks the frame did not arrive successfully, although that is not really true.

The IEEE 802.11 access protocol uses several mechanisms to try to avoid collisions on the medium (/CA = Collision Avoidance), but these mechanisms are not foolproof. For example, each STA maintains a local "Network Allocation Vector," or NAV, which allows it to keep track of the imminent users of the WM so that the STA does not interfere with known imminent transmitters; there is also an RTS/CTS mechanism that can be used to ensure that all the STAs in the BSS will know that a transmission is coming, and therefore to be quiet until it is complete.

Third and finally, IEEE 802.11 supports MAC sub-layer fragmentation of large frames. In a WLAN, it is useful to break up the transmission of a large frame into smaller "fragments." Large frames are more likely to encounter interference because larger frames take longer to transmit at a given data rate. By breaking large frames into smaller pieces, the stations can increase their chances of a successful transmission, since each smaller piece may be able to get through without encountering interference. Consequently, if interference happens to be encountered during the transmission of a fragment, the damage will be localized to that fragment. As a result, only that fragment will need to be retransmitted, as opposed to the entire frame.

Before resorting to fragmentation, a STA will attempt to retransmit the entire frame, and possibly might reduce the speed at which it transmits, in order to use a more robust, albeit slower, scheme for encoding the bits at the Physical layer.

Besides the fact that this fragmentation^[20] happens at the MAC sub-layer, the other major difference between IEEE 802.11 frame fragmentation and IPv4 packet fragmentation is that IEEE 802.11 fragments are transmitted one at a time, in order, whereas IPv4 packet fragments are independent packets on their own and may each take its own path through the network. IPv4 packet fragments are transmitted in order initially (from the point at which the fragments were created), but could potentially be re-ordered during their subsequent travels through the network before arriving at the ultimate destination of the original packet. Thus, it is possible for IPv4 packet fragments to arrive in an order that differs from the original order in which they were transmitted.

^[20] This MAC sub-layer frame fragmentation is independent of any higher-layer packet fragmentation; for example, IPv4 packet fragmentation. Not all higher-layer protocols support packet fragmentation, but some popular ones do, notably IPv4 (IPv6 only support end-to-end fragmentation).

Alongside environmental differences between wired and wireless networks, there is also the fact that wireless devices are frequently battery-operated, at least some of the time, which makes power management a top priority for them. If a station's radio is kept active all the time, simply for the convenience of other stations that might want to communicate with this station, the result will be a big power drain. IEEE 802.11 specifically supports integrated "power management," in that the stations of a WLAN can tell each other how long they plan to "sleep" before they will be ready to accept data again. (This notion of "sleep" does not correspond to OS sleep states. The OS may or may not be awake the whole time, but the IEEE 802.11 MAC is conserving power by only being active when it needs to be.) Laptop users always appreciate power-saving features, especially when their laptop is running on battery power.

The IEEE 802.11-1999 standard specifies two different schemes that STAs can use to share access to the medium, namely the Distributed Coordination Function (DCF) and the Point Coordination Function (PCF). DCF is based CSMA/CA. PCF relies on a Point Coordinator (PC) (effectively, the WLAN's traffic cop) to tell each STA when it may transmit. Because the PC typically resides in the AP, the AP might use its superior knowledge of the traffic mix to provide a variety of class-of-service support.

Despite PCF being specified in the IEEE 802.11-1999 standard, the author is aware of very few implementations other than engineering demonstrations. As far as the author is aware, the Wi-Fi Alliance does not make PCF operation part of their certification test suite for Wi-Fi devices.

The operation of the PCF mode of medium access control is regulated and indicated by bits 2 and 3 of the Capabilities IE of all Beacon and Probe Response MMPDUs. As a preview of PCF, suffice it to say that in PCF mode, a central control entity (in the AP) acts to collect frames from WLAN STAs by polling each STA, rather than by allowing each STA with data to send to independently contend for access to the medium.

The "CF" abbreviation in each of the labels for bits 2 and 3 means "Contention-Free," as distinguished from the access method that is based on contention. Confusingly, the IEEE 802.11-1999 standard refers to the entity in the AP as a PC. Because PC is a ubiquitous acronym with a commonly interpreted meaning, the author will not use it. Beware that in the standard, when you see PC, it probably means Point Coordinator, not Personal Computer.

Distributed Coordination Function

The primary method of medium access control deployed in most real-world networks is DCF. CSMA/CA is the usual method employed by proximate IEEE 802.11 STAs to share access to their common WM. Like CSMA/CD, which is employed by half-duplex Ethernet, CSMA/CA is a "listen before talk" (CS) method of minimizing collisions resulting from simultaneous transmission of multiple radios.

In IEEE 802.11, collision avoidance rather than collision detection must be used, because the IEEE 802.11-1999 standard chose to rely on simplex radios, which are incapable of receiving while transmitting, or vice versa. Consequently, unlike conventional wired Ethernet nodes, a WLAN station cannot detect a collision while it is transmitting. When an Ethernet station (in half-duplex mode) detects that its current frame has been collided with, it stops its transmission immediately and initiates backoff procedures. This behavior is very commonly understood by people who get paid to manage networks, so they might be surprised to learn that WLAN devices do not operate using this basic functional stance.

In fact, the WLAN access protocol inverts the order of the backoff, placing it before the frame transmission. The reasoning is as follows: The most likely time that a collision would occur is immediately after a frame transmission completes. If multiple STAs were waiting to send frames of their own, and an in-progress frame concluded its transmission, the STAs with frames ready to send would immediately collide with each other as soon as they had determined that the medium was quiet. Therefore, in IEEE 802.11, the collision backoff happens before the frame is transmitted, which serves to reduce the likelihood of a collision.

The only way for an IEEE 802.11 transmitter to detect a collision is implicit: the transmitting STA will not receive an ACK control frame from the recipient STA (the STA to which the data frame was addressed). To help ensure that ACK control frames will make it through ahead of other traffic, they have a higher priority than all other network traffic, which derives from the fact that there is a short time window after the data frame is transmitted when only the receiver may transmit. This bit of time is reserved so that the receiver may transmit an ACK control frame.

Since all the other STAs know that the data frame had been in progress (because of the CS and CA parts of CSMA/CA), and can also all tell when it has finished, they all share the knowledge of how long to wait to allow the ACK to flow back to the sender. All the other STAs that had data to send while the frame was in progress must wait a pseudo-random period of time before transmitting, similar to the way that half-duplex Ethernet stations use a binary exponential backoff algorithm to regulate retransmissions after collisions. If the requisite ACK control frame is not received, the transmitting station may wait for a subsequent opportunity to retransmit the data frame, or if its retry threshold has been exceeded, it can indicate an error.

Timing Is Everything

The BSS is kept to a synchronized clock by the AP. Every Beacon is transmitted as close as possible to the TBTT (an AP may not transmit a Beacon if another frame is in progress…). Each Beacon and Probe Response begins with a fixed-length (eight-octet) IE known as the "Timestamp" IE. The Timestamp IE holds a 64-bit timer value expressed in units of microseconds, which allows for up to 18,446,744,073,709.551616 seconds before the timer must "roll over." This is equivalent to just over 584,542 years, if we define a year as 365.25 days long. Even if a manufacturer designs the perfect IEEE 802.11 product that never crashes, it would probably be obsolete long before the Timestamp field rolls over.

The reason why IEEE 802.11's Timing Synchronization Function (TSF) operates in units of microseconds is that the smallest time unit that can be precisely measured by all devices in an IEEE 802.11 LAN is the time to transmit a single bit by the slowest possible STA. The slowest modulation, Barker/DBPSK, runs at 1 Mbps, which implies that a bit is equivalent to one microsecond. An IEEE 802.11 STA running at 1 Mbps would find it impossible to measure any time interval with sub-microsecond precision unless it were endowed with additional hardware to support a more precise clock, something that the standard does not require. To maintain backward compatibility for speeds all the way down to 1 Mbps, the IEEE 802.11 MAC sub-layer access protocol never expects STAs to be able to measure time more precisely than at one-microsecond intervals.

The eight-octet fixed-length Timestamp IE is immediately followed by another fixed-length timing-related IE, known as the Beacon Interval IE, which contains the TBTT. The Beacon Interval is a two-octet field expressed in units of "time units." The duration of a "time unit" is one "kilomicrosecond" (kµs). (Normally, one "kilo" (1000) of microseconds would just be one millisecond, but the power-of-2-sized 1024 microseconds is more useful for measuring time in the IEEE 802.11 MAC sub-layer protocol.) Thus, the TBTT can be anywhere from 1 to 65,535 kµs.

There are a number of "time windows" that govern the operation of the IEEE 802.11 MAC sub-layer protocol. To control access, it is critical that all the STAs understand a common time reference, since many timers are kept that are relative, and if the STAs had no common idea of what "time" it is, then they will be unsynchronized in their usage of the relative timers and the timers will not have the desired effects.

There are a number of inter-related aspects of the access control mechanism used by the IEEE 802.11 MAC sub-layer protocol. The following sections enumerate the mechanisms that have some bearing on each other. Because of the nature of the way these features are defined, it is difficult to explain any one of them in detail without referring to at least one other. The author will make every effort to avoid "forward references" to concepts that are not yet known to the reader by the use of sidebars and footnotes.

Time Intervals and Access Methods

There is one basic access mechanism known as the Distributed Coordination Function (DCF). It's clear why any access mechanism needs to be "distributed" if you're talking about WLANs. However, that doesn't explain the "coordination" aspect of DCF. It took the author a long time to figure out what the coordination was all about, and that's the most interesting part of the IEEE 802.11 MAC sub-layer's access mechanisms.

The Collision Avoidance mechanism is actually intimately interwoven with the Carrier Sense mechanism. A collision is when two STAs try to use the medium at the same time. When is such an event most likely to occur? Logically, such an event is most likely immediately following the successful transmission of a frame. Why? Again, remembering that a collision occurs when two STAs transmit at the same time, if we back up a bit before they transmitted, they must have both been waiting for the medium to go idle (because of their Carrier Sense mechanism). Once the medium was idle, they would both determine at about the same instant that this was the case and proceed to transmit their frame(s).

In Ethernet, collisions can be detected as they happen, and recovery (a binary exponential backoff procedure) can be initiated immediately. In IEEE 802.11, there is no way to detect a collision immediately, so the penalty for not detecting it is more severe, in that it takes more time to initiate corrective measures. Therefore, in IEEE 802.11's MAC sub-layer access method, the binary exponential backoff mechanism is applied before a STA attempts to transmit. If a STA believes it is next in line to use the medium, it will still randomize the start if its frame, in an effort to avoid a collision. Once the frame is under way, the other STAs in range of this one should perform their Carrier Sense (i.e., listen-before-talk) procedure and detect a transmission already in progress. If the random backoff were not implemented prior to transmitting, it would be virtually guaranteed that every time the medium went idle, there would be a collision. There are other mechanisms that are used to help control access to the medium, but the Collision Avoidance backoff is one of the more straightforward to understand.

Because IEEE 802.11 relies on simplex radios, the STAs cannot hear a collision while it is occurring. Why wouldn't requiring duplex radios solve the problem? The main reason not to require duplex-capable radios is the hidden node problem. Even if a STA could hear the medium as it was transmitting, it may be out of range of the STA with which it is interfering. The only place that interference is important is at the receiver of the frame. It is quite irrelevant to enable the sender to detect collisions, because the one device that can absolutely detect the collision is the receiver, and it needn't be burdened with a duplex radio to detect a collision. It will simply begin receiving a frame and never find a valid FCS during the frame's stated Duration.

This is one of the reasons for the hop-wise acknowledgment that is built into IEEE 802.11's MAC sub-layer access protocol. When a STA sends a frame to another STA, the frame is sent to the AP, which ACKs the frame. The sender can re-transmit if the ACK is not received. One might presume that the ACK mechanism confers some degree of reliability, but this is not the case. It is simply a way of validating the conditions that exist at the receiver's location. Without the ACK, the sender has no way of knowing if a collision has occurred. Contrast this with the case of Ethernet, in which a basic assumption of its MAC sub-layer access method is that all stations must be able to detect collisions as they happen, and all stations in a collision domain must be close enough to each other that the farthest two stations can exchange the shortest legal frame and still be able to detect a collision before the frame's transmission is concluded.

Given the likelihood of hidden nodes, there is no good reason to incur the expense of a duplex radio, since many collisions would be undetectable by the sender. To deal with the hidden node problem, the MAC sub-layer access protocol would have to find some way to detect collisions, and even if duplex radios were in use, some form of explicit acknowledgment would probably be required.

How does a collision manifest itself? The effect of the collision is to corrupt the frame such that the receiver cannot determine its complete contents (it might have seen a frame start that had its MAC address as the MAC-RA or MAC-DA, but it would never see an FCS within the stated Duration of the frame). The corruption could even happen early enough in the frame that even the D/I field is mangled, which could give the receiver a very long (or very short) value in the Duration field. Eventually, the sender will give up if it has not heard an ACK, and re-try the transmission.

The ACK is not a reliability enhancer; it is really nothing more than an implicit collision detection mechanism (it's implicit since it's a "no news is bad news" protocol, in which the lack of an ACK implies a collision, or some form of interference that prevented the frame from being successfully received; Ethernet's explicit collision detection mechanism involves actually being able to hear a collision as it happens). When a protocol designer is considering ways to increase reliability, it is indisputable that detecting collisions is an important component of a "reliability" solution. However, a collision detection mechanism alone does not constitute a reliability solution.

Ethernet is widely understood to be an "unreliable" Data Link layer technology. As with IEEE 802.11, that's not completely true. Ethernet's collision detection mechanism is not a reliability mechanism as such, but it is used to improve the reliability in half-duplex scenarios. Ethernet's reaction to the detection of a collision is the same as that of an IEEE 802.11 STA that has failed to receive an ACK the frame is retransmitted after some randomly chosen backoff delay interval. The fact that Ethernet retransmits a frame after a node detects a collision does not make it a reliable Data Link layer protocol. A station could encounter a series of collisions (on a very busy LAN) such that the station can never successfully transmit its frame.

Ethernet's retransmission mechanism doesn't exist to provide reliability it exists to increase the chances that a frame might get through. The mechanism is a throughput aid, not a reliability aid. IEEE 802.11's ACK mechanism provides the very same function, in a less direct fashion, but in a way that is ideally suited to operation over a WM in which not all nodes are in range of each other. In IEEE 802.11, the lack of an ACK serves as the collision detection mechanism, and this is a mechanism that can work in the face of the hidden node issue. Being able to perform collision detection in the presence of hidden nodes is the most important difference between the MAC sub-layer access protocols of Ethernet and IEEE 802.11.

These throughput-enhancing mechanisms do not make any guarantees that the frame will get through. This is an important distinction. Many people's only exposure to ACKs comes in TCP, and TCP is known to be a reliable transport protocol. However, ACKs do not always imply reliability. The unconscious binding of the concept of an ACK with the concept of reliability (because of the familiarity of TCP) is not generalizable to other scenarios.

Why is the ACK mechanism not a "reliable Data Link" mechanism? Certainly, reliable Data Link protocols do exist, and they are commonplace in WAN-oriented Data Link layer protocols; even IEEE 802.2 LLC supports a reliable mode, which is used by SNA when operating over LANs, such as IEEE 802.5 Token Ring. The ACKs in reliable Data Link protocols are end-to-end, not hop-by-hop. The only thing that an IEEE 802.11 STA gains from this ACK mechanism is the awareness that the frame got to the AP. The AP is now free to corrupt, drop, delay, or otherwise mistreat the frame, such that the frame that was received from the sender may never reach its intended destination intact. Effectively, the ACK mechanism in IEEE 802.11's MAC sub-layer access protocol is a "hope-by-hope" technique.

Before digging too deeply, there is a canonical timing diagram that seems obligatory. Figure 6-9 shows the relationships of the important timers defined in IEEE 802.11, including showing the relative lengths of the SIFS, PIFS, and DIFS intervals, and depicting the random backoff window (the contention window). At a minimum, a STA will defer access while the medium is busy, and then for at least a DIFS thereafter. Then, after a suitably chosen random backoff interval (some number of slot times), the STA will finally attempt to transmit its frame.

The SIFS, PIFS, and DIFS timers are all PHY-dependent, as can be seen in Figure 6-10. The PIFS and DIFS are PHY-dependent because they are dependent on the SIFS and the PHY's "slot time." The slot time of a given PHY is a basic attribute of that PHY. The slot time for IEEE 802.11's DSSS PHY is 20 µs, which includes 5 µs for the PHY's Rx/Tx turnaround time and any MAC processing delay associated with its driving the evolution of the state of the medium, and 15 µs for the "energy detect" function (i.e., Clear Channel Assessment), which is taken to be long enough to accommodate the propagation delay between the two stations.

In Figure 6-10, the D1 time interval reflects the time it takes for the PHY to indicate that a frame is complete, after it has received the last symbol from the medium. The D2 interval is the D1 interval plus a propagation delay component. The M1 and M2 intervals represent MAC processing, and are actually identical duration. The CCAdel interval is the CCA interval less the D1 interval. If one studies Figure 6-8, one finds that the slot time is the sum of the PHY Rx/Tx turnaround time, the CCA interval, and the air propagation delay on the medium.

The IEEE 802.11b-1999 standard specifies a slot time of 20 µs, with the same timing components as IEEE 802.11-1999. The IEEE 802.11a-1999 slot time is 9 µs. In the latter standard, the "energy detect" function is expected to take less than 4 µs, with the remainder of the time (5 µs) allowed for PHY Rx/Tx turnaround time and MAC processing.

A successful frame exchange in DCF is as shown in Figure 6-11, which also shows how the non-involved STAs use their NAVs to do their virtual carrier sense. Virtual carrier sense allows hidden nodes to be equally aware of transmissions that are happening for which either the sender or the receiver is out of range of the hidden node. If there were no possibility for hidden nodes, it is possible that the protocol could get by with only "physical" carrier sense mechanisms.

In Figure 6-11, time proceeds to the right. After it has seen previous activity conclude on the medium, the Sending STA waits for a DIFS and sends an RTS. All the STAs in range of the sender will hear its RTS and will use the Duration value in that frame to update their NAVs. That Duration is sufficient to encompass three SIFS intervals, plus the time to transmit a CTS and ACK, and of course the MMPDU or MPDU.

The Receiving STA responds with a CTS frame that is heard by a perhaps disjoint set of STAs, some of which will be out of range of the Sender's radio. The Duration value in the CTS is smaller than that in the RTS. Any STA that heard the RTS will not update their NAV because the IEEE 802.11 DCF procedures dictate that the NAV only be updated in one of two possible conditions.

• The frame^[21] must not be addressed to a given STA for it to be able to update its NAV. In other words, the frame on the air must not be meant for a STA if that STA is to use the information in the frame's Duration field to update its NAV.

  ^[21] The frame that could cause another STA to update its NAV could be any of the following types of frames: RTS, MMPDU, or MPDU.

• The other condition is that a STA only updates its NAV if the received value in a frame's Duration field is greater than the value that the STA already knows.

As can be seen in Figure 6-11, the CTS is sent after a SIFS interval, and then after a second SIFS interval the MPDU or MMPDU is sent, and the ACK is sent after a third SIFS interval. The STAs that were not involved in the conversation, whether they heard the RTS or the CTS, will have their NAVs expiring at approximately the time when the ACK is complete. At that point, after another DIFS interval, a further Contention (i.e., Backoff) Window will begin among any other STA(s) that might have data to send.

The previous discussion can be examined in both the context of infrastructure BSS or IBSS mode. In the case of infrastructure BSS, the AP will be either sending or receiving a frame.

• If the AP is sending a frame, then the AP is the STA that sends the RTS, which means that all the STAs in the BSS will hear the RTS at essentially the same time. There are no hidden nodes with respect to the AP. The CTS will only be heard by the STAs within range of the receiver's radio, but they will not update their NAVs because the Duration field in the CTS is smaller than that in the RTS.

• If the AP is receiving a frame, then it is equivalent to say that another STA is sending a frame. In this case, the AP will hear the RTS, as will all the STAs in range of the sender's radio. The AP will send the CTS, which will be heard throughout the BSS. The Duration field in the CTS will not cause the sender-local STAs to update their NAVs, since the CTS has a smaller Duration value than the RTS.

By using this technique, the DCF procedures make an effort to eliminate hidden nodes from interfering with the operation of the MAC sub-layer's access control protocol.

DCF, PCF, and Timing

There are two levels of timing. One applies at the Beacon level, and applies to Beacons that contain Traffic Indication Message (TIM) IEs. Most timers in IEEE 802.11 are expressed in units of Beacon Intervals, including the STA Listen Interval, which is used by power-saving STAs to express the times when the AP can expect them to be awake, and the DTIM Interval, which is important in PCF mode and DCF mode. The sub-Beacon-Interval timing consists of intervals like SIFS, PIFS, and DIFS.

When the BSS is operating in DCF mode, the Beacon Interval and the DTIM Interval are the same. In PCF mode, the DTIM Interval may an integer multiple of 2 or more Beacon Intervals, which allows the Point Coordinator in the AP an ample amount of time in which to operate in contention-free (i.e., polling) mode. The CFP begins when the DTIM Interval is at its time-zero point.

The benefit of CFPs is that during CFPs, data may be transmitted on an essentially regular basis, with predictable (bounded) latency. Thus, PCF enables the AP to support time-sensitive services for frames that can benefit from such treatment, such as frames that contain voice and/or video data. The CFPs repeat at a fixed rate that is determined by the AP, which may choose to reserve some portion of the available bandwidth for "isochronous^[22] " or "plesiochronous^[23] " (fancy words for "time-sensitive) data traffic.

^[22] An isochronous signal is one that depends on some uniform timing, often from an external "clock" source; the timing information could also be embedded in the signal. Two signals that are isochronous should maintain synchronization over long time periods.

^[23] Two or more signals that are plesiochronous relative to each other have clocks that tick within some defined precision. The signals are not sourced from the same clock and so, over the long term, they will tend to become skewed relative to each other. Their relative closeness of frequency allows a switch to cross connect, switch, or in some way process the signals, but over time, that inaccuracy of timing will force a switch to repeat or delete frames (called frame slip events) in order to handle buffer under- or over-flow.

When using this higher priority access, the AP issues polling requests to the stations for data transmission, hence controlling medium access. To still enable regular stations to access the medium, there is a provision that the Point Coordinator must leave enough time for Distributed Access in between the CFPs.

Not all STAs must implement contention-free operation. However, all STAs do need to be able to tell when a Point Coordinator has initiated contention-free operation so they can avoid interfering with the contention-free STAs. All the traffic sent during the CFP is sent with the Duration set to 32,768 (the protocol's version of the concept of infinity), and all the non-PCF STAs will set their NAVs so that they will wait essentially forever until they transmit. When the CFP ends, the AP sends a MAC Control frame,^[24] which causes all STAs, PCF or otherwise, to reset their NAVs.

^[24] The Point Coordinator in the AP could send either a CF-End frame or a CF-End + CF-ACK frame.

Power-Save Mode

The circuitry that drives the transmit side of the RF subunit draws considerable power even when there is no data to transmit. When there is data to transmit, it draws even more power. The receive-side circuitry also is a constant power drain, sensing the WM for incoming frames, or even just passing frames (to keep the STA's NAV updated). It is likely that the receive side circuitry's power demands do not vary as much as the transmit circuitry does. To maximize battery life, a reasonable strategy is to shut down all of the RF circuitry periodically. The MAC circuitry will stay awake, because it is the MAC subunit that wakes up the RF subunit in time to be ready for the next DTIM interval. Power-save mode is intimately dependent on the timekeeping functions of the WLAN, driven by the Timestamps in the AP's Beacon frames.

In the IEEE 802.11 specification, a STA that has temporarily shut down its RF circuitry is said to be "dozing." If a STA wants to do this kind of thing, it must tell the AP at association time. In particular, the STA tells the AP how often it will be awake to accept any queued data that is addressed to it. It is up to the STA to be awake when it has promised to be, and after it has received and sent whatever traffic it cares to, it may choose to "doze" until the next time it is obligated to be awake.

Clearly, when a STA is dozing, it can neither send nor receive frames. The latter constraint places a duty on the AP. When the AP knows that a STA is in power save mode, the AP must buffer any frames destined for that STA, so that the STA will not miss anything, although the relative order of multicast and unicast traffic may be affected when the STA wakes up. When a STA enters this mode, it gives up the ability to use the "Strictly Ordered" service that IEEE 802.11 optionally provides, whereby the delivery order of the frames is preserved. Any STAs that want to receive frames using the Strictly Ordered service may never doze. The default mode is known as "Re-orderable Multicast."

The mechanism by which sleeping STAs (sleeping and power save will be synonymous in this discussion; the power save mode of the WLAN STA has nothing to do with the ability of a laptop to enter a low-power "standby" or "hibernation" mode) are awakened is via the DTIM mechanism. In case anyone was wondering why the association IDs (AIDs) were numbered from 1 to 2007, it is because these numbers are used in the DTIM bit mask that is included in the DTIM IE that may be in a Beacon or Probe Response. Every Beacon does not include the DTIM IE…there is a DTIM interval that is a multiple of Beacon intervals that controls how often the DTIM is included in a Beacon frame.

Every Beacon includes a TIM IE. The TIM is used to indicate which STAs have traffic pending for them. The DTIM interval is a number of TIM intervals (a TIM interval is the same as a Beacon interval), and the DTIM contains information on the unicast traffic that is buffered, indicated in a bitmap on a per-AID basis. The TIM IEs in the usual Beacons provide a countdown to the next DTIM, and also indicate if there is any multicast traffic buffered. If any STAs are dozing, they all must wait for any multicasts that the STA receives, since every STA must be awake simultaneously if they want to receive the multicast.

One way this is accomplished is that the STAs join the WLAN and at Association time they get to express their desired "Listen Interval." This is the interval at which the STA promises to be awake. The Listen Interval is expressed as some number of Beacon intervals, and the DTIM must be larger than the largest Listen Interval. Even if a STA expresses a Listen Interval when it joins the WLAN, it need not ever actually enter Power-Save mode. The Listen Interval exists so that if the STA ever does decide to doze, it will wake up at a predictable time and prevent the AP from needing to buffer traffic indefinitely.

Power Management Details

Due to the fact that wireless devices are often mobile devices, and therefore tend to be battery-powered, it is important that a WLAN solution minimize power drain to the maximum extent possible. For example, it would be wasteful of battery power if a laptop were sitting idle for several hours, with nothing to send, but the wireless card was kept ever at the ready to receive (or send) data.

In IEEE 802.11, a station can "doze" after sending a frame, and it can wake up periodically to peek into the AP's Beacon frame to see if the AP is holding a packet for it. It can then wake up, get the packet from the AP, and go back to dozing…unless it has some data of its own to send. The STA tells the AP the rate at which it will promise to be awake (the Listen put in a space Interval), and the AP will buffer traffic for that STA if the STA decides to doze. Just because the STA indicated that it might doze, does not mean that it must doze.

There are degrees of strictness with respect to dozing. In the strictest mode, a STA will enter the "dozing" state every ListenInterval, and any delay in dozing will be due to an in-progress frame exchange running into the time when the STA might have been dozing. The STA will, in this strict mode, doze as soon as it can, as close as possible to once per Listen put in a space Interval. In a less strict mode, the STA might decide to not doze right away, since it knows it is in the middle of an exchange of data, or it simply knows that it has a significant amount of data queued and ready to transmit. The STA may decide that sending a few extra frames might be okay, as long as it eventually does doze for a while before the next Listen put in a space Interval wakes it up. Finally, a STA may be configured to never doze, regardless of the consequences (i.e., increased power drain).

Power management state transitions are indicated by a bit in the "Frame Control" portion of the MAC header. Obviously, in order to be transmitting a frame, the station has to be awake. A bit in the Frame Control header is used to tell the other stations whether it will stay awake after successfully completing the current frame exchange.^[25] If a large number of frames have already been dispatched to the wireless NIC, none of these frames will have had the Power-Save bit set. Therefore, whatever frames are buffered in the driver or hardware will have to drain prior to the station going to sleep. At that point, however, the STA must have something further to say or else it will not be able to doze. This is why there is a "null" Data subtype…a null Data frame can be sent that can trigger a change of state using the Power-Save bit.

^[25] For unicast packets, the ACK from the receiving or destination station is considered part of this frame exchange, and the sending station will not go to sleep until it has received the ACK. After all, if the ACK is not received, the frame will need to be retransmitted.

Within the FC, which is the first two octets of the IEEE 802.11 MAC header, the "Power Management" state is carried in bit number 12 (the bits are numbered 0 15). A value of 0 indicates that the station will remain active after the current frame exchange, while a value of 1 indicates that the station will enter "power save" mode after the current frame exchange.

Since all traffic must go through the AP, the AP must keep track of which stations are dozing, and buffer the frames destined for those stations. The Beacon frames indicate to the stations when they need to wake up to receive frames that are destined for their MAC address. Observe that APs cannot be permitted to doze. In IBSS mode, it is possible for stations to doze, as long as at least one of them stays awake to send the Beacons. In an IBSS, the STAs use the ATIM MMPDU to indicate that traffic is buffered to a peer STA.

Every Beacon frame has a TIM IE. The TIM IEs use a bit mask to indicate which Association IDs have buffered traffic. Association ID number zero is reserved to mean that multicast traffic is buffered. When any STA dozes, the multicast traffic in the BSS is only transmitted once per DTIM interval. Since multicasts can only be sent once per DTIM Interval, it is important that all the STAs be awake when this happens. In PCF mode, multicast traffic will be burstier than in DCF mode, in which it can come out at least as often as once per Beacon Interval (the only time that the multicasts are buffered is when at least one STA is dozing). If no STAs are dozing, multicasts are sent in essentially the order they are received.

In any BSS mode, an optional additional layer of control is possible, via the PCF, or "Point Coordination Function." If supported,^[26] PCF is only active at one "point" in the network the AP as opposed to the Distributed Coordination Function, which is active simultaneously (distributed) in all the stations of a BSS.

^[26] PCF support is not mandatory in the IEEE 802.11 specification. IEEE 802.11e support, which may be shipping in many products sometime in 2004, pending approval of the IEEE 802.11e standard, will make QOS-enhanced operation available to more people.

When PCF is active, time is divided into two types of alternating periods: the CFP, and the Contention Period (CP). CFPs are only possible if PCF is active in the AP. The PCF makes use of a smaller PCF Inter Frame Space (PIFS) so that the AP can gain access to the medium before other stations, effectively giving the AP a higher priority.