A station that wants to transmit on the wireless medium must sense whether the medium is in use. If the medium is in use, the station must defer frame transmission until the medium is not in use. The station determines the state of the medium using two methods:

The station can check the PHY and detect that the medium is available. But in some instances, the medium might still be reserved by another station via the NAV. The NAV is a timer that is updated by data frames transmitted on the medium. For example, in an infrastructure BSS, suppose Martha is sending a frame to George (see Figure 2-4). Because the wireless medium is a broadcast-based shared medium, Vivian also receives the frame. The 802.11 frames contain a duration field. This duration value is large enough to cover the transmission of the frame and the expected acknowledgment. Vivian updates her NAV with the duration value and does not attempt transmission until the NAV has decremented to 0.

Figure 2-4. The NAV Update Process

Note that stations only update the NAV when the duration field value received is greater than what is currently stored in their NAV. Using the same example, if Vivian has a NAV of 10 milliseconds, she does not update her NAV if she receives a frame with a duration of 5 milliseconds. She updates her NAV if she receives a frame with a duration of 20 milliseconds.

The IEEE-mandated access mechanism for 802.11 networks is DCF, a medium access mechanism based on the CSMA/CA access method. To describe DCF operation, we first define some concepts. Figure 2-5 shows a time line for the scenario in Figure 2-4.

Figure 2-5. Timeline for DCF Medium Access

In DCF operation, a station wanting to transmit a frame must wait a specific amount of time after the medium becomes available. This time value is known as the DCF interframe space (DIFS). Once the DIFS interval elapses, the medium becomes available for station access contention.

In Figure 2-5, Vivian and George might want to transmit frames when Martha's transmission is complete. Both stations should have the same NAV values, and both will physically sense when the medium is idle. There is a high probability that both stations will attempt to transmit when the medium becomes idle, causing a collision. To avoid this situation, DCF uses a random backoff timer.

The random backoff algorithm randomly selects a value from 0 to the contention window (CW) value. The default CW values vary by vendor and are value-stored in the station NIC. The range of values for random backoff start at 0 slot times and increment up to the maximum value, which is a moving ceiling starting at CW_min and stopping at a maximum value known as CW_max. For the sake of this example, assume that the CW_min value begins at 7 and CW_max value is 255. Figure 2-6 illustrates the CW_min and CW_max values for binary random backoff.

Figure 2-6. Random Backoff with DCF Medium Access

A station randomly selects a value between 0 and the current value of the CW. The random value is the number of 802.11 slot times the station must wait during the medium idle CW before it may transmit. A slot time is a time value derived from the PHY based on RF characteristics of the BSS .

Getting back to the example, Vivian is ready to transmit. Her NAV timer has decremented to 0, and the PHY also indicates the medium is idle. Vivian selects a random backoff time between 0 and CW (in this case, CW is 7) and waits the selected number of slot times before transmitting. Figure 2-7 illustrates this process, with a random backoff value of four slot times.

Figure 2-7. Frame Transmission After Random Backoff

Once the four slot times pass, Vivian can transmit. But what if George's station has a random backoff time of two time slots? Vivian hears a new duration from George's frame when he begins his transmission, and Vivian updates her NAV with that new value. Vivian must wait for her NAV to decrement to 0 and her PHY to report that the medium is available again before she can resume her backoff. (In this example, Vivian must wait an additional two slot times before attempting to transmit.)

Assuming that Vivian is able to defer transmission for all four slot times, she transmits the frame. So how does Vivian know that the frame made it to its destination? The 802.11 specification requires that the receiving station send an acknowledgment frame to the frame sender. This acknowledgment frame allows the sending station to indirectly determine whether a collision took place on the medium. If the sending station does not receive an acknowledgment frame, it assumes that a collision occurred on the medium. The sending station updates its retry counters, doubles the CW value, and begins the medium access process again. Figure 2-8 summarizes the steps a DCF station must iterate through to transmit a frame.

Figure 2-8. The DCF Medium Access Process

A station receiving a frame acknowledges error-free receipt of the frame by sending an acknowledgment frame back to the sending station. Knowing that the receiving station has to access the medium and transmit the acknowledgment frame, you would assume that it is possible for the acknowledgment frame to be delayed because of medium contention. The transmission of an acknowledgment frame is a special case. Acknowledgment frames are allowed to skip the random backoff process and wait a short interval after the frame has been received to transmit the acknowledgment. The short interval the receiving station waits is known as the short interframe space (SIFS). The SIFS interval is shorter than a DIFS interval by two slot times. It guarantees the receiving station the best possible chance of transmitting on the medium before another station does.

Referring to Vivian's transmission to George, Vivian deferred her transmission attempt for four slot times. The medium was still available, so she transmitted her frame to George, as depicted in Figure 2-9. The AP receives the frame and waits a SIFS interval before sending an acknowledgment frame.

Figure 2-9. Frame Transmission and Acknowledgment

Supposing that Vivian never receives an acknowledgment frame, she doubles the CW value to 15 and repeats the backoff process. For every medium access attempt that fails, the 802.11 station increments a retry counter. CW continues to double until it is equal to CW_max. The MAC layer may continue to attempt to transmit the frame, but once the frame retry counters reach a administrator-defined retry threshold, Vivian's station attempts to reserve the medium.

Vivian might be unable to access the medium because of another station that is within range of the AP yet out of range of her station. Figure 2-10 illustrates this situation. Vivian and George are in range of each other and in range of the AP. Yet neither of them is in range of Tony. Tony is in range of the AP and attempts to transmit on the medium as well. The situation is known as the hidden node problem because Tony is hidden to Vivian and George.

Figure 2-10. The Hidden Node Problem

Vivian attempts to reserve the medium using a special control frame known as an RTS frame. The RTS frame is sent to the AP and indicates to the AP, and all stations that are within range of Vivian, the expect duration of Vivian's frame exchange. The frame exchange includes the frame she wants to initially transmit as well as the expected acknowledgment frame.

The AP receives Vivian's RTS frame and reply with a CTS control frame. The CTS frame contains a duration field value long enough to allow Vivian to complete her frame exchange. All stations within range of the AP, including Tony and George, receive the CTS frame and update their NAVs, as illustrated in Figure 2-11.

Figure 2-11. Medium Reservation with RTS/CTS Frames

The initial RTS frame that Vivian transmits must go through the DCF process, as would any normal frame. But similar to the acknowledgment frame, the corresponding CTS frame from the AP skips the random backoff procedure and only needs to wait the SIFS interval before being transmitted. Figure 2-12 details Vivian's RTS frame transmission. Both George and Tony update their NAVs accordingly, but the acknowledgment frame the AP sends back to Vivian does not have to conform to the DCF rules. When George receives the frame, George immediately sends back an acknowledgment frame. Although George's NAV is nonzero, he still sends an acknowledgment frame back to the AP after a SIFS interval.

Figure 2-12. Example of RTS/CTS

The Contention Free Period (CFP) is the window of time for PCF operation. The CFP begins at set intervals following a beacon frame containing a delivery traffic indication map (DTIM) information element (described later in the chapter). The frequency of CFPs is determined by the network administrator. Once the CFP begins, the AP assumes the role of the PC (and as such, PCF operation is only supported in infrastructure BSSs). Each 802.11 client sets its NAV to the CFPMaxDuration value. This value is included in the CF parameter set information element (detailed later in the chapter). The CFPMaxDuration defines the time value that is the maximum duration for the CFP. The PC can end the CFP before the CFPMaxDuration time elapses. The AP transmits beacon frames at regular intervals, and beacon frames sent during the CFP contain the CFPDurationRemaining field to update station NAVs of the remaining duration of the CFP. Figure 2-15 depicts the CFP and contention period (CP) as a function of time.

Figure 2-15. The CFP and CP Timeline

Unlike DCF operation, PCF does not allow stations to freely access the medium and transmit data. Stations can only send data (one frame at a time) when the PC polls them. The PC can send frames to stations, poll stations for frame transmission, acknowledge frames requiring MAC-level acknowledgments, or end the CFP.

When the CFP begins, the PC must access the medium in the same manner as a DCF station. Unlike DCF stations, the PC attempts to access the medium after waiting an interval of time known as the priority interframe space (PIFS). The PIFS interval is one slot time longer than the SIFS interval and one slot time shorter than the DIFS interval, allowing PCF stations to access the medium before DCF stations yet still allowing control frames, such as acknowledgment frames, to have the highest probability of gaining access to the medium. Figure 2-16 illustrate the SIFS, PIFS, DIFS, and slot time relationships.

Figure 2-16. SIFS, PIFS, DIFS, and Slot Time Relationships

After waiting a PIFS interval, the PC sends the initial beacon frame containing the CF parameter information element. The PC waits for one SIFS interval subsequent to the beacon frame transmission and then sends one of the following to a CF-Pollable station:

If the PC has no frames to send and no CF-Pollable stations to poll, the CFP is considered null, and immediately following the beacon frame, the PC sends a CF-End frame terminating the CFP.

Continuing the same example as before, Vivian, Martha, and George are communicating with AP1. Figure 2-17 depicts this example.

Figure 2-17. PCF Medium Access Operation

AP1 sends a beacon frame indicating the start of a CFP. The CFP is set for 20 seconds (sec). Vivian, Martha, and George all update their NAVs to reflect the 20-sec CFP. After waiting a SIFS interval, AP1 sends a frame buffered for Vivian's station and also sends a poll to Vivian's station to see whether she has any frames to send using the Data+CF-Poll frame. Vivian receives the Data+CF-Poll frame and sends one data frame and a contention-free acknowledgment (Data+CF-ACK) frame after waiting a SIFS interval. Note that Vivian's station ignores her NAV setting when transmitting frames in response to a CF-Poll frame.

AP1 iterates through its polling list to Martha's station. AP1 uses another combination frame to send a data frame to Martha, acknowledge Vivian's frame, and poll Martha's station for frame transmission (Data+CF-ACK+CF-Poll). Note that the frame is destined for Martha's station, yet it acknowledges Vivian's last frame. The multiple access nature of 802.11 allows for this arrangement. Martha waits a SIFS interval and sends a Data+CF-ACK frame.

AP1 finally iterates to George's station. The AP has no data frames buffered for George's station, so it sends a CF-Poll frame to see whether George has any frames to send. George has no frames buffered either, so George sends a null data frame. Although the CFP has not exceeded the maximum duration allowed, AP1 sends a CF-End frame to end the CFP and proceed to the CP and normal DCF medium access. Vivian, Martha, and George receive the CF-End frame and reset their NAVs.

In Figure 2-21, Vivian's station is in range to three APs. Two of the APs belong to the service set marketing, and the remaining AP belongs to the service set sales. Vivian's station is configured for the service set marketing.

Figure 2-21. Vivian and the Surrounding APs

The client station sends an 802.11 probe request frame. Generally, an 802.11 station sends the probe request frame on every channel it is allowed to use (channels 1 through 11 in North America). This process is not mandated by the 802.11 specification. The probe request frame contains information about an 802.11 wireless station, such as which data rates the station supports and what service set the station belongs to. Figure 2-22 is a protocol decode of a probe request frame.

Figure 2-22. A Protocol Decode of a Probe Request Frame

The key fields in the probe request are

Client stations send probe requests frames blindly, meaning they don't know anything about the APs they are probing for. As such, most probes are sent at the lowest possible data rate of 1 Mbps. Figure 2-22 illustrates this process.

When an AP receives a probe request frame that successfully passed a frame check sequence (FCS), it replies with a probe response frame. Figure 2-23 is a protocol decode of a probe response frame.

Figure 2-23. A Probe Response Frame

The key fields in a probe response frame follow:

When the client station receives the probe response frame, it is able to determine the signal strength of the received frame. The station compares the probe response frames and determines which AP to associate with. The mechanism for how a station chooses an AP to associate with is not specified by the 802.11 specification, so it is left to vendor implementation. In general, the AP selection criteria can include matching SSIDs, signal strength, and vendor proprietary extensions.

For the sake of this example, assume that matching SSIDs, supported data rates, and signal strength are the criteria (see Figure 2-24).

Figure 2-24. The Probe Process

Table 2-1 summarizes the data from the probe response frames Vivian receives.

Vivian is inclined to communicate with AP2. AP2 has a matching SSID, supports all data rates, and has a signal strength of 100%. AP1 is a close contender, but the signal strength is lower at 50%.

Now that Vivian's station has determined which AP to associate to, she can proceed to the next phase of station connectivity, the authentication process.

802.11 authentication consists of two authentication modes: open authentication and shared-key authentication. These two modes are detailed in Chapter 4, “802.11 Wireless LAN Security,” which covers wireless security in depth. 802.11 authentication is oriented around device authentication and determines whether the device is allowed on the network. For the purposes of this section, authentication is simplified to an authentication request and an authentication response, as depicted in Figure 2-25.

Figure 2-25. The Authentication Process

The 802.11 association process allows an AP to map a logical port or association identifier (AID) to the wireless station. The association process is initiated by the wireless station with an association request frame containing the capability information of the client and completed by the AP in an association response frame. The association response indicates success or failure as well as a reason code. Figure 2-26 is a protocol decode of an association request frame, and Figure 2-27 is a protocol decode of a association response frame.

Figure 2-26. An Association Request Frame

Figure 2-27. An Association Response Frame

The key fields for the association request frame follow:

The key fields from the association response frame follow:

When the client associates to the AP, it specifies a listen interval value in the association request frame. The listen interval is the number of beacons the client waits before transitioning to active mode. For example, a listen interval of 200 indicates that the client wakes up every 200 beacons.

The beacon frame includes a traffic indication map (TIM) information element. The element contains a list of all AIDs that have traffic buffered at the AP. There can be up to 2008 unique AIDs, so the TIM element alone can be up to 251 bytes. To minimize network overhead, the TIM utilizes a shorthand method of listing the AIDs. Figure 2-28 is a protocol decode of a beacon with a TIM indicating buffered traffic for a client.

Figure 2-28. A Protocol Decode of a TIM Element

Notice that nowhere in the protocol decode is the AID of the client station explicitly stated. To determine the AID of the client station (or stations), you need the following pieces of information:

802.11 specifies a traffic indication virtual bitmap as a means to indicate which station AIDs have frames buffered. The virtual bitmap starts from AID 1 to AID 2007. AID 0 is reserved for multicast/broadcast. Table 2-2 represents what a traffic indication virtual bitmap might look like. Every station with frames buffered at the AP has a flag value of 1 set for that station's AID. Stations with no frames buffered use a flag value of 0.

The partial virtual bitmap eliminates all unnecessary 0 flag values by summarizing them. All client stations that have frames buffered (and therefore have flag values of 1 in the traffic indication virtual bitmap) are included in the partial virtual bitmap. All AIDs with a flag value of 0 leading up to the partial virtual bitmap are summarized by a derived value referred to as X in the following examples. All AIDs with flag values of 0 subsequent to the partial virtual bitmap are summarized by a derived value referred to as Y in the following examples. Referring to Table 2-2, AIDs 1 through 15 are summarized by value X, and AIDs 32 through 2007 are summarized by value Y.

To calculate X and Y, you must first derive N1 and N2. The formulas for deriving N1, N2, X, and Y are as follows:

In the sample decode from Figure 2-28, N1 = (1 * 2) = 2 and N2 = (5 – 4) + 2 = 3. The value X is (2 * 8) – 1 or 15, and Y is (3 + 1) * 8 or 32. X indicates that AIDs 1 through 15 all have flag values of 0, and Y indicates that AIDs 32 through 2007 also have flag values of 0.

That leaves AIDs 16 through 31, which is where the partial virtual bitmap comes into play. The partial virtual bitmap in our example is a 2 byte value, 0x0020. The first byte, 0x00 or 00000000 in binary, indicates that the next 8 station AID flags following X (AIDs 16 to 23) are all 0. The second byte is 0x20 or 00100000 in binary. So in the example, AIDs 24 to 28 have a flag value of 0 and AID 29 has a flag value of 1. Because AID 29 is the only AID with a flag value of 1, AID 29 has traffic buffered at the AP.

If the client determines that frames are buffered for it, it sends an 802.11 MAC management frame known as a power save poll (PS-Poll) frame. Figure 2-29 provides a protocol decode of the PS-Poll the client station sent in response to the beacon. Note that the AID field has a value of 29, which is what was determined to be the AID from the partial virtual bitmap in the TIM element.

Figure 2-29. A Protocol Decode of a PS-Poll Frame

The AP responds to the PS-Poll frame with one of the client's buffered frames and an indication of whether more frames are buffered. The client must send a PS-Poll frame to the AP to receive each of the buffered frames on the AP. Figure 2-29 is a protocol decode of a PS-Poll frame. Note that the AID field indicated AID 29, as was calculated in the previous example.

A broadcast power save operation has the same basic operation as unicast power save operation. The differences follow:

The TIM has two fields to indicate whether multicast/broadcast traffic is buffered and how long until it is delivered to the BSS:

Figure 2-30 highlights a protocol decode of a beacon containing a DTIM. In Figure 2-31, note that the frames following the beacon are all multicast frames.

Figure 2-30. A Protocol Decode of a DTIM Element

Figure 2-31. Multicast Frames Following a Beacon Frame with a DTIM Element

The 802.11 specification stipulates six unique control frames:

The first four are the primary frames to focus on. The CF-End and CF-End+CF-ACK are part of the PCF, which is not widely deployed.

The PS-Poll Frame

The PS-Poll frame is an indicator to the AP that a wireless station in power save mode is requesting that any frames buffered on the AP be delivered. The PS-Poll frame contains the following variation of the generic MAC frame:

• AID—. The AID of the wireless client, with the two most significant bits set to 1

• The BSS identifier (BSSID)—. The MAC address of the AP in an infrastructure network

• Transmitter address (SA)—. The MAC address of the power save wireless station

Figure 2-36 shows the frame format of the PS-Poll frame, and Figure 2-37 shows a protocol decode of the PS-Poll frame.

Figure 2-36. Frame Format of the PS-Poll Frame

Figure 2-37. A Protocol Decode of PS-Poll Frame

The RTS Frame

The RTS frame is the request to reserve the wireless medium as a part of the 802.11 medium access mechanism:

• Duration—. The time required for the station's frame exchange to take place. It includes the time to transmit the RTS frame, the time to receive the CTS frame (including the SIFS interval), the time to transmit the data frame (including the SIFS interval), and the time to receive the ACK frame (including the SIFS interval). Duration time is measured in microseconds.

• Receiver address—. The MAC address of the intended recipient of the frame.

• Transmitter address—. The MAC address of the transmitter of the frame sender.

Figure 2-38 shows the frame format of the RTS frame and Figure 2-39 shows a protocol decode of the RTS frame.

Figure 2-38. Frame Format for the RTS Frame

Figure 2-39. A Protocol Decode of the RTS Frame

The CTS Frame

The CTS frame is the response to an RTS frame. It is an indication to the receiving station that the medium has been reserved for the specified duration:

• Duration—. The value obtained from the Duration field of the immediately previous RTS frame, minus the time required to transmit the CTS frame and its SIFS interval.

• Receiver address—. The MAC address of the intended recipient of the frame.

Figure 2-40 shows the frame format of the CTS frame, and Figure 2-41 shows a protocol decode of the CTS frame.

Figure 2-40. Frame Format for the CTS Frame

Figure 2-41. A Protocol Decode of the CTS Frame

The ACK Frame

The ACK frame acknowledges frame transmission. The receiver of a frame sends an ACK frame to the sender to indicate successful frame receipt:

• Duration—. The duration for ACK frames is usually 0 because the frame it is acknowledging includes the transmission time for the SIFS interval and the ACK frame in its duration field.

• Receiver address—. The MAC address of the intended recipient of the frame.

Figure 2-42 shows the frame format of the ACK frame, and Figure 2-43 shows a protocol decode of the ACK frame.

Figure 2-42. Frame Format for the ACK Frame

Figure 2-43. A Protocol Decode of the ACK Frame

The CF-End and CF-End+CF-ACK Frames

The CF-End and CF-End+CF-ACK frames are specific to PCF operation. They indicate the end of the contention-free period, and the CF-End+CF-ACK also includes an acknowledgment of the last frame received by the PC. Figure 2-44 shows the format for the CF-End and CF-End+CF-ACK frames and the list that follows describes the key fields.

• Duration—. Set to 0.

• Receiver address—. The destination MAC address of the intended recipient of the frame. In the case of the CF-End frames, it is the broadcast MAC address because every station in the service set should receive the notification.

• BSSID—. The MAC address of the AP.

Figure 2-44. Frame Format for the CF-End and CF-End+CF-ACK Frames

802.11 management frames leverage fields from the generic MAC frame detailed earlier and also utilize data structures known as information elements (IE) and fixed fields.

Figure 2-45 shows the format of an IE. The purpose of the IE and the fixed fields is to give flexible capability definitions to existing frames and to provide a scalable method of expanding the functionality of the MAC management frames. The 802.11 management frames are constructed by using relevant fields from the general MAC frame format and adding the appropriate IEs and fixed fields (see Figure 2-46).

Figure 2-45. Format of an IE

Figure 2-46. Management Frame Construction using IEs and Fixed Fields

Table 2-5 lists the 802.11-defined IEs.

The SSID IE

The SSID can be up to 32 bytes in length, and if the length is 0, the SSID is a broadcast SSID.

Figure 2-47 shows the frame format of the SSID IE, and Figure 2-48 shows a protocol decode of the SSID IE.

Figure 2-47. Format of the SSID IE

Figure 2-48. A Protocol Decode of an SSID IE

The Supported Rates IE

The supported rates IE specifies what rates the wireless station is capable of supporting. The binary values are in increments of 500 kbps. For example, a supported rate of 11 Mbps is represented by 0x16, which is equal to decimal 22. 22/500 kbps (or .5 Mbps) = 11 Mbps.

Figure 2-49 shows the frame format of the supported rates IE, and Figure 2-50 shows a protocol decode of the supported rates IE.

Figure 2-49. Format of the Supported Rates IE

Figure 2-50. A Protocol Decode of the Supported Rates IE

FH Parameter Set IE

Figure 2-51 shows the format of the FH parameter set IE, and the list that follows describes the key fields:

• Dwell time—. The FH dwell time in TU

• Hop set—. The FH hopping pattern set

• Hop pattern—. The individual FH hopping pattern

• Hop index—. The current channel index from within the hopping pattern

Figure 2-51. Format of the FH Parameter Set IE

The DS Parameter Set IE

Figure 2-52 shows the format of the DS parameter set IE. The current channel field indicates the channel in use by the direct-sequencing wireless station.

Figure 2-52. Format of the DS Parameter Set IE

The CF Parameter Set IE

Figure 2-53 shows the format of the CF parameter set IE, and the list that follows describes the key fields:

• CFP count—. A count of remaining DTIMs (including the current frame) before the start of the next CFP

• CFP period—. The number of DTIM intervals between the CFPs

• CFP MaxDuration—. The maximum duration of the CFP in TUs

• CFP DurationRemaining—. The duration remaining in TUs for the current CFP

Figure 2-53. Format of the CF Parameter Set IE

The TIM IE

Figure 2-54 shows the frame format of the TIM IE, and Figure 2-55 shows a protocol decode of the TIM IE. The list that follows describes the key fields of the TIM IE frame:

• DTIM count—. A count of how many beacon frames (including the current frame) appear before the next DTIM. A value of 0 indicates this frame is the DTIM.

• DTIM period—. The number of DTIM intervals between DTIM frames. A value of 1 indicates all TIMs are DTIMs. The value of 0 is reserved.

• Bitmap control—. Bit 0 of the field contains the traffic indicator bit associated with AID 0. This bit is set to 1 in TIM elements with a value of 0 in the DTIM count field when one or more broadcast or multicast frames are buffered at the AP. The remaining 7 bits of the field form the bitmap offset.

• Partial virtual bitmap—. A per-station indication of AP frame buffer status. An indication for AID 0 indicates that broadcast/multicast frames are buffered.

Figure 2-54. Format of the TIM IE

Figure 2-55. A Protocol Decode of the TIM IE

The IBSS Parameter Set IE

Figure 2-56 shows the format of the IBSS parameter set IE.

Figure 2-56. Format of the IBSS Parameter Set IE

The ATIM window field indicates the ATIM window length in TU.

The Challenge Text IE

Figure 2-57 shows the format of the challenge text IE.

Figure 2-57. Format of the Challenge Text IE

The challenge text field indicates the challenge text for use in authentication frames.

In addition to IEs, the 802.11 specification also defines 10 fixed-field elements for use in management frames, as listed in Table 2-6.

The Capability Information Field

The capability information field only includes subfields relevant for the management frames for which the transmission rules are defined. Figure 2-58 illustrates the capability information field format, and the list that follows describes the key subfields:

• ESS—. The AP sets this value to 1 and the IBSS subfield to 0 in beacon and probe response frames.

• IBSS—. Stations in an IBSS set this field to 1 and the ESS subfield to 0 in beacon and probe response frames.

• CF-Pollable—. APs and wireless stations use this subfield.

• CF-Poll request—. APs and wireless stations use this subfield. Tables 2-7 and 2-8 describe the subfield settings and corresponding meanings.

• Privacy—. This subfield is set to 1 if WEP encryption is required for data frames. It is included in beacon, probe response, association, and reassociation response frames. If WEP encryption is not required, this subfield is set to 0.

Figure 2-58. Format of the Capability Information Field

Table 2-7. CF-Poll Request Field in Frames Sourced by the Client Station

CF-Pollable	CF-Poll Request	Meaning
0	0	Station is not CF-Pollable.
1	0	Station is CF-Pollable and is requesting to be placed on the polling list.
0	1	Station is CF-Pollable and is not requesting to be placed on the polling list.
1	1	Station is CF-Pollable and is requesting to never be placed on the polling list.

Table 2-8. CF-Poll Request Field in Frames Sourced by the AP

CF-Pollable	CF-Poll Request	Meaning
0	0	AP does not support PCF; no PC.
1	0	PC supports frame delivery only.
0	1	PC supports frame delivery and polling.
1	1	Reserved.

802.11 management frames consist of the following:

The following sections give more details on each management frame.

The Beacon Frame

The beacon frame is a management frame that the AP (or beacon sender in an IBSS) transmits at the beacon interval rate. The beacon provides time synchronization between the AP and the wireless stations as well as PHY-specific parameters. In addition, power save stations are alerted if the AP has frames buffered. In addition to the 802.11 defined fields and IEs, vendor-specific IEs can also be included in the beacon frames.

Figure 2-59 shows the frame format of a beacon frame, and Figure 2-60 shows a protocol decode of the beacon frame.

Figure 2-59. Frame Format of a Beacon Frame

Figure 2-60. A Protocol Decode of a Beacon Frame

The Probe Request Frame

Figure 2-61 shows the frame format of a probe request frame, and Figure 2-62 shows a protocol decode of the probe request frame.

Figure 2-61. Frame Format of the Probe Request Frame

Figure 2-62. A Protocol Decode of the Probe Request Frame

The Probe Response Frame

Figure 2-63 shows the frame format of a probe response frame, and Figure 2-64 shows a protocol decode of the probe response frame.

Figure 2-63. Frame Format of the Probe Response Frame

Figure 2-64. A Protocol Decode of the Probe Response Frame

The Authentication Frame

Figure 2-65 shows the frame format of an authentication frame, and Figure 2-66 shows a protocol decode of the authentication frame.

Figure 2-65. Frame Format of the Authentication Frame

Figure 2-66. A Protocol Decode of the Authentication Frame

The Deauthentication Frame

Figure 2-67 shows the frame format of a deauthentication frame, and Figure 2-68 shows a protocol decode of the Deauthentication frame.

Figure 2-67. Frame Format of the Deauthentication Frame

Figure 2-68. A Protocol Decode of Deauthentication Frame

The Association Request Frame

Figure 2-69 shows the frame format of an association request frame, and Figure 2-70 shows a protocol decode of the association request frame.

Figure 2-69. Frame Format of the Association Request Frame

Figure 2-70. A Protocol Decode of Association Request Frame

The Association Response Frame

Figure 2-71 shows the frame format of an association response frame, and Figure 2-72 shows a protocol decode of the association response frame.

Figure 2-71. Frame Format of the Association Response Frame

Figure 2-72. A Protocol Decode of Association Response Frame

The Reassociation Request Frame

Figure 2-73 shows the frame format of a reassociation request frame, and Figure 2-74 shows a protocol decode of the reassociation request frame.

Figure 2-73. Frame Format of the Reassociation Request Frame

Figure 2-74. A Protocol Decode of Reassociation Request Frame

The reassociation request frame is nearly identical to the association request frame, with the addition of the current AP address field. The key purpose of this frame is to alert the AP that the station is associating to that it had a previous association. The new AP can query the old AP for buffered frames for the roaming client, but it is a vendor-specific implementation and not defined in the 802.11 specification.

The Reassociation Response Frame

Figure 2-75 shows the frame format of a reassociation response frame, and Figure 2-76 shows a protocol decode of the reassociation response frame.

Figure 2-75. Frame Format of the Reassociation Response Frame

Figure 2-76. A Protocol Decode of Reassociation Response Frame

The reassociation response frame is identical to the association response frame.

The Disassociation Frame

Figure 2-77 shows the frame format of a disassociation frame, and Figure 2-77 shows a protocol decode of the disassociation frame.

Figure 2-77. Frame Format of the Disassociation Frame

Figure 2-78. A Protocol Decode of Disassociation Frame

The 802.11 specification stipulates eight unique data frames:

The Data Frame

Figure 2-79 shows the frame format of the data frame, and Figure 2-80 shows a protocol decode of the data frame.

Figure 2-79. Frame Format of a Data Frame (AP to Client Station)

Figure 2-80. A Protocol Decode of a Data Frame

The Null Data

Figure 2-81 shows the frame format of the null data frame, and Figure 2-82 shows a protocol decode of the null data frame.

Figure 2-81. Frame Format of a Null Data Frame

Figure 2-82. A Protocol Decode of a Data Frame

A null data frame is so named because it has no payload field. Its purpose is to indicate a change in the power save mode bit in the frame control field.