A Field Guide to Wireless LANs for Administrators and Power Users

A station that wants to join a WLAN must first determine that a WLAN is present. This is accomplished either passively (by listening for a Beacon, a type of management frame that is sent by the AP), or actively (by transmitting a Probe Request on all available channels, until a Probe Response is received from the AP). The Beacon and Probe are two types of management frames, which along with Control and Data frames define the existing types of WLAN frames. Once it has determined that a WLAN is present, it must use local configuration to decide if it should join this WLAN.

In many WLAN clients, the user is asked to statically specify the SSID of the local WLAN; when a user of a product with such a driver roams to an area with a WLAN that has a different SSID, the user will have to manually update the SSID in order to join the new WLAN. Figure 6-1 shows an example of such a configuration screen.

Figure 6-1 shows an example configuration screen that allows input of the SSID from a product running on Windows 2000. In Chapter 3, we saw configuration screens from Red Hat Linux 9.0 and MacOS X.

To improve usability, it is also possible for the STA implementation to format the Probe Request MMPDU with a null SSID.^[1] Any AP receiving such a Probe Request MMPDU with a null SSID will respond with a Probe Response MMPDU that lists its own SSID. After some time has passed, the STA will have accumulated a list of one or more available SSIDs. Based on these available SSIDs, or perhaps the configured SSID, the STA will either join the SSID that it has been configured to join, or it will present the user with the list of the available SSIDs, allowing the user to select which ESS to join.

^[1] The null SSID is interpreted as a broadcast, which is effectively a wildcard SSID that will match any SSID configured into any AP.

The complete list of the IEEE 802.11-1999 Management frame Types and their associated Subtypes is in Figure 6-2, in which the structure of the Probe Request and Probe Response can be seen, as well as all types of Management frames.

Included here in Figure 6-3, for completeness, is the complete list of the IEEE 802.11-1999 Control frame Types and their associated Subtypes. The Control frames are primarily employed in the operation of the MAC sub-layer's access control protocol, and will be described in more detail later in this chapter. (The other type of IEEE 802.11-1999 frame is the Data frame (MPDU). It was described in detail in Chapter 4, IEEE 802.11's MAC Sub-layer Protocol Frames, etc.).

IEEE 802.11 Frame Types and Usage

For each type of frame, there are situations in which it may (or may not) be used, as will be seen shortly. Note that in Figure 6-4, each frame type is classified as being Class 1, Class 2, or Class 3. These "classes" correspond to the state machine that governs the interaction between a STA and an AP (in infrastructure mode), or a STA and another STA (in IBSS mode).

The Data frame types in italics are associated with the IEEE 802.11e task group,^[2] and will only become valid once that standard has been approved.

^[2] The working title for this draft standard is "Medium Access Control (MAC) Enhancements for Quality of Service (QoS)."

Note that in the case of Data type frames, each bit position has a defined meaning.

Basic STA State Machine

The first thing that happens when a STA wants to join a WLAN is that the STA does a passive or active scan. If an AP is within range, the STA will then move on to the authentication phase of the state machine, which is shown in Figure 6-5.^[3]

^[3] It is worthwhile to note that this state machine is not strictly representative of the states in which a STA can find itself, because of primarily the IEEE 802.11i work that is ongoing to improve security. There is considerable pressure to maintain the fiction that this state machine is still, essentially, correct. The state machine is accurate as a high-level representation, but it does not depict all the states that a STA may be in.

In general, as a station progresses through the state machine of Figure 6-5, it will be able to send more of the possible frame types. In State 1, only Class 1 frames can be sent, but in State 3, all classes of frames may be sent (i.e., Class 1, Class 2, and Class 3).

The "Frame Class" column in Figure 6-4 associates each Type/Subtype combination with a corresponding state and/or class. As can be seen in that table, the Probe Request MMPDU is an example of a Class 1 frame, which means it can be sent from a STA that is neither authenticated nor associated, which corresponds to the usage of this MMPDU that has already been described.

Because the Authentication phase precedes the Association phase, it is possible for a STA to authenticate to multiple APs, even though a STA can only associate with one AP at any given time. This feature allows the STA to seamlessly roam from one AP to another, since it can simply disassociate from one AP and associate with the AP it is moving toward. The STA can use hints such as signal strength and signal quality to tell it which new AP it should associate with, since closer APs should have stronger signals.

Addressing in MPDUs

A data frame in a WLAN, just as in a wired LAN, must have a source and a destination MAC address (denoted MAC-SA and MAC-DA). However, in Chapter 4 you may have already observed that the MPDU frame format has no field with either of those names, yet it does have four six-octet fields named Address-1, Address-2, Address-3, and Address-4.

These four fields are all of the expected size necessary to accommodate a MAC address, but in IEEE 802.11's MAC sub-layer protocol, the Address fields in MPDU headers do not have fixed assignments; instead, the allocation of the Address fields to particular meanings depends on the setting of the ToDS and FromDS bits. There is a perfectly reasonable explanation for this.

In an infrastructure WLAN, it is not normal for a STA to send a frame directly to another STA…the frame is forwarded through an intermediate node, known as an AP.^[4] This is done so that the AP can mitigate the effect of so-called "hidden" nodes, which are nodes that can both hear the AP but cannot hear each other. The necessity exists for the address of an intermediate node (or of intermediate nodes) to be identified in the MPDU header so that the frame can be properly forwarded to its destination.

^[4] In IBSS mode, the STA-to-STA case is normal, but the dominant deployment of WLANs involves APs.

Influence of ToDS and FromDS on the MPDU Header

The settings of the "To Distribution System" (ToDS; bit 8) and "From Distribution System" (FromDS; bit 9) bits in the Frame Control field control the meaning and usage of the three (or four) Address fields in the MPDU header.

It is important to remember that (depending on the situation) there may not be a requirement for all four of the address fields to be present in the MPDU header. The layout and meaning of the individual Address fields for each combination of ToDS and FromDS is depicted on the left side of Figure 6-6, with the various combinations of ToDS and FromDS in the center, and a description of that particular scenario on the right.^[5]

^[5] Adapted from IEEE Std. 802.11^™-1999, copyright 1999, as amended by IEEE 802.11e draft 5.0 (a work-in-progress, which is subject to change before its publication). All rights reserved.

Please remember that both IEEE 802.11 MAC Control frames and MMPDUs have fixed header formats. The arrangement of the Address-n fields on the left-hand side of Figure 6-6 is only applicable to MPDUs, which are unique in having this variable interpretation of the Address fields based on the settings of the ToDS and FromDS bits.

Whenever the ToDS and FromDS bits are set such that Address-4 is listed as "n/a" (i.e., not applicable), the Address-4 field is omitted from the MPDU^[6] header, thereby reducing its size by six octets. The remaining bits in the FC field each control a particular feature that is provided by the IEEE 802.11 MAC sub-layer protocol. As a result, MPDU headers will either be short (24 octets) or long (30 octets).

^[6] The combination of ToDS and FromDS both being set to "1" is only valid for Data frames. Neither of these bits can be set in either Management or Control frames.

On any given hop over the WM, it is possible that interference will require the use of MAC sub-layer retransmissions.^[7] To accomplish this, the intermediate target needs to get the retransmission not from the originator of the frame, but from the most recent intermediate node that transmitted it (unsuccessfully, as yet). For this reason, in certain situations (e.g., particularly where a wireless distribution system is in use), all four of the Address fields will need to be populated (for the original sender, the ultimate destination, the current intermediate transmitter, and the current intermediate receiver).

^[7] MAC sub-layer retransmission will be discussed later in this chapter, in the section covering medium access algorithms for WLANs.

Despite the presence of the four Address fields in the MPDU header, all four are not always populated in every situation. In the Wireless Distribution System (WDS) case, multiple APs must be traversed in order to reach the destination, so the intermediate node addresses will change with each successive hop across the WM.

For frames in the midst of being forwarded through a WDS, the Address-3 field contains the MAC-DA, and the Address-4 field contains the MAC-SA. In the WDS case (i.e., wherein both ToDS and FromDS bits are set to "1"), the Address-1 field contains the Receiver Address (MAC-RA) and the Address-2 field contains the Transmitter Address (MAC-TA). The MAC-RA may be thought of as an "intermediate MAC-DA," and the MAC-TA may be thought of as an "intermediate MAC-SA," which may help with remembering their ordering.^[8]

^[8] The MAC-TA is an intermediate "source," and the MAC-RA is an intermediate "destination." The IEEE Project 802 LMSC tends to put destination addresses closer to the front of a frame.