Chapter 4. 802.11 Framing in Detail
Chapter 3 presented the basic frame structure and the fields that comprise it, but it did not go into detail about the different frame types. Ethernet framing is a simple matter: add a preamble, some addressing information, and tack on a frame check at the end. 802.11 framing is much more involved because the wireless medium requires several management features and corresponding frame types not found in wired networks.
Three major frame types exist. Data frames are the pack horses of 802.11, hauling data from station to station. Several different data frame flavors can occur, depending on the network. Control frames are used in conjunction with data frames to perform area-clearing operations, channel acquisition and carrier-sensing maintenance functions, and positive acknowledgment of received data. Control and data frames work in conjunction to deliver data reliably from station to station. Management frames perform supervisory functions; they are used to join and leave wireless networks and move associations from access point to access point.
This chapter is intended to be a reference. There is only so much life any author can breathe into framing details, no matter how much effort is expended to make the details interesting. Please feel free to skip this chapter in its entirety and flip back when you need in-depth information about frame structure. With rare exception, detailed framing relationships generally do not fall into the category of “something a network administrator needs to know.” This chapter tends to be a bit acronym-heavy as well, so refer to the glossary at the back of the book if you do not recognize an acronym.
Data Frames
Data frames carry higher-level protocol data in the frame body. Figure 4-1 shows a generic data frame. Depending on the particular type of data frame, some of the fields in the figure may not be used.
The different data frame types can be categorized according to function. One such distinction is between data frames used for contention-based service and those used for contention-free service. Any frames that appear only in the contention-free period can never be used in an IBSS. Another possible division is between frames that carry data and frames that perform management functions. Table 4-1 shows how frames may be divided along these lines. Frames used in contention-free service are discussed in detail in Chapter 9.
Frame type | Contention-based service | Contention-free service | Carries data | Does not carry data |
Data | ✓ | ✓ | ||
Data+CF-Ack | ✓ | ✓ | ||
Data+CF-Poll | AP only | ✓ | ||
Data+CF-Ack+CF-Poll | AP only | ✓ | ||
Null | ✓ | ✓ | ✓ | |
CF-Ack | ✓ | ✓ | ||
CF-Poll | AP only | ✓ | ||
CF-Ack+CF-Poll | AP only | ✓ |
Frame Control
All the bits in the Frame Control field are used according to the rules described in Chapter 3. Frame Control bits may affect the interpretation of other fields in the MAC header, though. Most notable are the address fields, which depend on the value of the ToDS and FromDS bits.
Duration
The Duration field carries the value of the Network Allocation Vector (NAV). Access to the medium is restricted for the time specified by the NAV. Four rules specify the setting for the Duration field in data frames:
Any frames transmitted during the contention-free period set the Duration field to 32,768. Naturally, this applies to any data frames transmitted during this period.
Frames transmitted to a broadcast or multicast destination (Address 1 has the group bit set) have a duration of 0. Such frames are not part of an atomic exchange and are not acknowledged by receivers, so contention-based access to the medium can begin after the conclusion of a broadcast or multicast data frame. The NAV is used to protect access to the transmission medium for a frame exchange sequence. With no link-layer acknowledgment following the transmission of a broadcast or multicast frame, there is no need to lock access to the medium for subsequent frames.
If the More Fragments bit in the Frame Control field is 0, no more fragments remain in the frame. The final fragment need only reserve the medium for its own ACK, at which point contention-based access resumes. The Duration field is set to the amount of time required for one short interframe space and the fragment acknowledgment. Figure 4-2 illustrates this process. The penultimate fragment’s Duration field locks access to the medium for the transmission of the last fragment.
If the More Fragments bit in the Frame Control field is set to 1, more fragments remain. The Duration field is set to the amount of time required for transmission of two acknowledgments, plus three short interframe spaces, plus the time required for the next fragment. In essence, nonfinal fragments set the NAV just like an RTS would (Figure 4-3); for this reason, they are referred to as a virtual RTS.
Addressing and DS Bits
The number and function of the address fields depends on which of the distribution system bits are set, so the use of the address fields indirectly depends on the type of network deployed. Table 4-2 summarizes the use of the address fields in data frames. The fourth address field is only used by wireless bridges, and is therefore relatively uncommon.
Function | ToDS | FromDS | Address 1 (receiver) | Address 2 (transmitter) | Address 3 | Address 4 |
IBSS | 0 | 0 | DA | SA | BSSID | Not used |
To AP (infra.) | 1 | 0 | BSSID | SA | DA | Not used |
From AP (infra.) | 0 | 1 | DA | BSSID | SA | Not used |
WDS (bridge) | 1 | 1 | RA | TA | DA | SA |
Address 1 indicates the receiver of the frame. In many cases, the receiver is the destination, but not always. The destination is the station that will process the network-layer packet contained in the frame; the receiver is the station that will attempt to decode the radio waves into an 802.11 frame. If Address 1 is set to a broadcast or multicast address, the BSSID is also checked. Stations respond only to broadcasts and multicasts originating in the same basic service set (BSS); they ignore broadcasts and multicasts from different BSSIDs.[20] Address 2 is the transmitter address and is used to send acknowledgments. Transmitters are not necessarily senders. The sender is the frame that generated the network-layer protocol packet in the frame; the transmitter put the frame on to the radio link. The Address 3 field is used for filtering by access points and the distribution system, but the use of the field depends on the particular type of network used.
In the case of an IBSS, no access points are used, and no distribution system is present. The transmitter is the source, and the receiver is the destination. All frames carry the BSSID so that stations may check broadcasts and multicasts; only stations that belong to the same BSS will process broadcasts and multicasts. In an IBSS, the BSSID is created by a random-number generator.
802.11 draws a distinction between the source and transmitter and a parallel distinction between the destination and the receiver. The transmitter sends a frame on to the wireless medium but does not necessarily create the frame. A similar distinction holds for destination addresses and receiver addresses. A receiver may be an intermediate destination, but frames are processed by higher protocol levels only when they reach the destination.
To expand on these distinctions, consider the use of the address fields in infrastructure networks. Figure 4-4 shows a simple network in which a wireless client is connected to a server through an 802.11 network. Frames sent by the client to the server use the address fields as specified in the second line of Table 4-2.
In the case of frames bound for a destination on the distribution system, the client is both source and transmitter. The receiver of the wireless frame is the access point, but the access point is only an intermediate destination. When the frame reaches the access point, it is relayed to the distribution system to reach the server. Thus, the access point is the receiver, and the (ultimate) destination is the server. In infrastructure networks, access points create associated BSSs with the address of their wireless interfaces, which is why the receiver address (Address 1) is set to the BSSID.
When the server replies to the client, frames are transmitted to the client through the access point, as in Figure 4-5. This scenario corresponds to the third line in Table 4-2.
Frames are created by the server, so the server’s MAC address is the source address for frames. When frames are relayed through the access point, the access point uses its wireless interface as the transmitter address. As in the previous case, the access point’s interface address is also the BSSID. Frames are ultimately sent to the client, which is both the destination and receiver.
The fourth line in Table 4-2 shows the use of the address fields in a wireless distribution system (WDS), which is sometimes called a wireless bridge. In Figure 4-6, two wired networks are joined by access points acting as wireless bridges. Frames bound from the client to the server traverse the 802.11 WDS. The source and destination addresses of the wireless frames remain the client and server addresses. These frames, however, also identify the transmitter and receiver of the frame on the wireless medium. For frames bound from the client to the server, the transmitter is the client-side access point, and the receiver is the server-side access point. Separating the source from the transmitter allows the server-side access point to send required 802.11 acknowledgments to its peer access point without interfering with the wired link layer.
Variations on the Data Frame Theme
802.11 uses several different data frame types. Variations depend on whether the service is contention-based or contention-free. Contention-free frames can incorporate several functions for the sake of efficiency. Data may be transmitted, but by changing the frame subtype, data frames in the contention-free period may be used to acknowledge other frames, saving the overhead of interframe spaces and separate acknowledgments. Here are the different data frame types that are commonly used:
- Data
Frames of the Data subtype are transmitted only during the contention-based access periods. They are simple frames with the sole purpose of moving the frame body from one station to another.
- Null
Null frames [21] are a bit of an oddity. They consist of a MAC header followed by the FCS trailer. In a traditional Ethernet, empty frames would be extraneous overhead; in 802. 11 networks, they are used by mobile stations to inform the access point of changes in power-saving status. When stations sleep, the access point must begin buffering frames for the sleeping station. If the mobile station has no data to send through the distribution system, it can use a Null frame with the Power Management bit in the Frame Control field set. Access points never enter power-saving mode and do not transmit Null frames. Usage of Null frames is shown in Figure 4-7.
Several other frame types exist for use within the contention-free period. However, contention-free service is not widely implemented; the discussion of the contention-free frames (Data+CF-Ack, Data+CF-Poll, Data+CF-Ack+CF-Poll, CF-Ack, CF-Poll, and CF-Ack+CF-Poll) can be found in Chapter 9.
Applied Data Framing
The form of a data frame can depend on the type of network. The actual subtype of the frame is determined solely by the subtype field, not by the presence or absence of other fields in the frame.
IBSS frames
In an IBSS, three address fields are used, as shown in Figure 4-8. The first address identifies the receiver, which is also the destination address in an IBSS. The second address is the source address. After the source and destination addresses, data frames in an IBSS are labeled with the BSSID. When the wireless MAC receives a frame, it checks the BSSID and passes only frames in the station’s current BSSID to higher protocol layers.
IBSS data frames have the subtype data or Null; the latter is used only to communicate power management state.
Frames from the AP
Figure 4-9 shows the format of a frame sent from an access point to a mobile station. As in all data frames, the first address field indicates the receiver of the frame on the wireless network, which is the frame’s destination. The second address holds the transmitter address. On infrastructure networks, the transmitter address is the address of the station in the access point, which is also the BSSID. Finally, the frame indicates the source MAC address of the frame. The split between source and transmitter is necessary because the 802.11 MAC sends acknowledgments to the frame’s transmitter (the access point), but higher layers send replies to the frame’s source.
Nothing in the 802.11 specification forbids an access point from transmitting Null frames, but there is no reason to transmit them. Access points are forbidden from using the power-saving routines, and they can acknowledge Null frames from stations without using Null frames in response. In practice, access points send Data frames during the contention-based access period, and they send frames incorporating the CF-Poll feature during the contention-free period.
Frames to the AP
Figure 4-10 shows the format of a frame sent from a mobile station in an infrastructure network to the access point currently serving it. The receiver address is the BSSID. In infrastructure networks, the BSSID is taken from the MAC address of the network station in the access point. Frames destined for an access point take their source/transmitter address from the network interface in the wireless station. Access points do not perform filtering, but instead use the third address to forward data to the appropriate location in the distribution system.
Frames to the distribution system have the ToDS bit set, but the FromDS bit is 0. Mobile stations in an infrastructure network cannot become the point coordinator, and thus never send frames that incorporate the contention-free polling (CF-Poll) functions.
Frames in a WDS
When access points are deployed in a wireless bridge (or WDS) topology, all four address fields are used, as shown in Figure 4-11. Like all other data frames, WDS frames use the first address for the receiver of the frame and the second address for the transmitter. The MAC uses these two addresses for acknowledgments and control traffic, such as RTS, CTS, and ACK frames. Two more address fields are necessary to indicate the source and destination of the frame and distinguish them from the addresses used on the wireless link.
On a wireless bridging link, there are no mobile stations, and the contention-free period is not used. Access points are forbidden to enter power-saving modes, so the power management bit is always set to 0.
Encrypted frames
Frames protected by link layer security protocols are not new frame types. When a frame is handled by encryption, the Protected Frame bit in the Frame Control field is set to 1, and the Frame Body field begins with the appropriate cryptographic header described in Chapter 5 or Chapter 7, depending on the protocol.
Control Frames
Control frames assist in the delivery of data frames. They administer access to the wireless medium (but not the medium itself) and provide MAC-layer reliability functions.
Common Frame Control Field
All control frames use the same Frame Control field, which is shown in Figure 4-12.
- Protocol version
The protocol version is shown as 0 in Figure 4-12 because that is currently the only version. Other versions may exist in the future.
- Type
Control frames are assigned the Type identifier 01. By definition, all control frames use this identifier.
- Subtype
This field indicates the subtype of the control frame that is being transmitted.
- ToDS and FromDS bits
Control frames arbitrate access to the wireless medium and thus can only originate from wireless stations. The distribution system does not send or receive control frames, so these bits are always 0.
- More Fragments bit
Control frames are not fragmented, so this bit is always 0.
- Retry bit
Control frames are not queued for retransmission like management or data frames, so this bit is always 0.
- Power Management bit
This bit is set to indicate the power management state of the sender after conclusion of the current frame exchange.
- More Data bit
The More Data bit is used only in management and data frames, so this bit is set to 0 in control frames.
- Protected Frame bit
Control frames may not be encrypted. Thus, for control frames, the Protected Frame bit is always 0.
- Order bit
Control frames are used as components of atomic frame exchange operations and thus cannot be transmitted out of order. Therefore, this bit is set to 0.
Request to Send (RTS)
RTS frames are used to gain control of the medium for the transmission of “large” frames, in which “large” is defined by the RTS threshold in the network card driver. Access to the medium can be reserved only for unicast frames; broadcast and multicast frames are simply transmitted. The format of the RTS frame is shown in Figure 4-13. Like all control frames, the RTS frame is all header. No data is transmitted in the body, and the FCS immediately follows the header.
Four fields make up the MAC header of an RTS:
- Frame Control
There is nothing special about the Frame Control field. The frame subtype is set to 1011 to indicate an RTS frame, but otherwise, it has all the same fields as other control frames. (The most significant bits in the 802.11 specification come at the end of fields, so bit 7 is the most significant bit in the subtype field.)
- Duration
An RTS frame attempts to reserve the medium for an entire frame exchange, so the sender of an RTS frame calculates the time needed for the frame exchange sequence after the RTS frame ends. The entire exchange, which is depicted in Figure 4-14, requires three SIFS periods, the duration of one CTS, the final ACK, plus the time needed to transmit the frame or first fragment. (Fragmentation bursts use subsequent fragments to update the Duration field.) The number of microseconds required for the transmission is calculated and placed in the Duration field. If the result is fractional, it is rounded up to the next microsecond.
- Address 1: Receiver Address
The address of the station that is the intended recipient of the large frame.
- Address 2: Transmitter Address
The address of the sender of the RTS frame.
Clear to Send (CTS)
The CTS frame, whose format is shown in Figure 4-15, has two purposes. Initially, CTS frames were used only to answer RTS frames, and were never generated without a preceding RTS. CTS frames were later adopted for use by the 802.11g protection mechanism to avoid interfering with older stations. The protection mechanism is described with the rest of 802.11g in Chapter 14.
Three fields make up the MAC header of a CTS frame:
- Frame Control
The frame subtype is set to 1100 to indicate a CTS frame.
- Duration
When used in response to an RTS, the sender of a CTS frame uses the duration from the RTS frame as the basis for its duration calculation. RTS frames reserve the medium for the entire RTS-CTS-frame-ACK exchange. By the time the CTS frame is transmitted, though, only the pending frame or fragment and its acknowledgment remain. The sender of a CTS frame subtracts the time required for the CTS frame and the short interframe space that preceded the CTS from the duration in the RTS frame, and places the result of that calculation in the Duration field. Figure 4-16 illustrates the relationship between the CTS duration and the RTS duration. Rules for CTS frames used in protection exchanges are described with the protection mechanism.
- Address 1: Receiver Address
The receiver of a CTS frame is the transmitter of the previous RTS frame, so the MAC copies the transmitter address of the RTS frame into the receiver address of the CTS frame. CTS frames used in 802.11g protection are sent to the sending station, and are used only to set the NAV.
Acknowledgment (ACK)
ACK frames are used to send the positive acknowledgments required by the MAC and are used with any data transmission, including plain transmissions, frames preceded by an RTS/CTS handshake, and fragmented frames (see Figure 4-17). Quality-of-service enhancements relax the requirement for a single acknowledgment per Data frame. To assess the impact of acknowledgments on net throughput, see Chapter 25.
Three fields make up the MAC header of an ACK frame:
- Frame Control
The frame subtype is set to 1101 to indicate an ACK frame.
- Duration
The duration may be set in one of two ways, depending on the position of the ACK within the frame exchange. ACKs for complete data frames and final fragments in a fragment burst set the duration to 0. The data sender indicates the end of a data transmission by setting the More Fragments bit in the Frame Control header to 0. If the More Fragments bit is 0, the transmission is complete, and there is no need to extend control over the radio channel for additional transmissions. Thus, the duration is set to 0.
If the More Fragments bit is 1, a fragment burst is in progress. The Duration field is used like the Duration field in the CTS frame. The time required to transmit the ACK and its short interframe space is subtracted from the duration in the most recent fragment (Figure 4-18). The duration calculation in nonfinal ACK frames is similar to the CTS duration calculation. In fact, the 802.11 specification refers to the duration setting in the ACK frames as a virtual CTS.
- Address 1: Receiver Address
The receiver address is copied from the transmitter of the frame being acknowledged. Technically, it is copied from the Address 2 field of the frame being acknowledged. Acknowledgments are transmitted in response to directed data frames, management frames, and PS-Poll frames.
Power-Save Poll (PS-Poll)
When a mobile station wakes from a power-saving mode, it transmits a PS-Poll frame to the access point to retrieve any frames buffered while it was in power-saving mode. The format of the PS-Poll frame is shown in Figure 4-19. Further details on the operation of power saving modes appears in Chapter 8.
Four fields make up the MAC header of a PS-Poll frame:
- Frame Control
The frame subtype is set to 1010 to indicate a PS-Poll frame.
- Association ID (AID)
Instead of a Duration field, the PS-Poll frame uses the third and fourth bytes in the MAC header for the association ID. This is a numeric value assigned by the access point to identify the association. Including this ID in the frame allows the access point to find any frames buffered for the now-awakened mobile station.
- Address 1: BSSID
This field contains the BSSID of the BSS created by the access point that the sender is currently associated with.
- Address 2: Transmitter Address
This is the address of the sender of the PS-Poll frame.
The PS-Poll frame does not include duration information to update the NAV. However, all stations receiving a PS-Poll frame update the NAV by the short interframe space plus the amount of time required to transmit an ACK. The automatic NAV update allows the access point to transmit an ACK with a small probability of collision with a mobile station.
Management Frames
Management is a large component of the 802.11 specification. Several different types of management frames are used to provide services that are simple on a wired network. Establishing the identity of a network station is easy on a wired network because network connections require dragging wires from a central location to the new workstation. In many cases, patch panels in the wiring closet are used to speed up installation, but the essential point remains: new network connections can be authenticated by a personal visit when the new connection is brought up.
Wireless networks must create management features to provide similar functionality. 802.11 breaks the procedure up into three components. Mobile stations in search of connectivity must first locate a compatible wireless network to use for access. With wired networks, this step typically involves finding the appropriate data jack on the wall. Next, the network must authenticate mobile stations to establish that the authenticated identity is allowed to connect to the network. The wired-network equivalent is provided by the network itself. If signals cannot leave the wire, obtaining physical access is at least something of an authentication process. Finally, mobile stations must associate with an access point to gain access to the wired backbone, a step equivalent to plugging the cable into a wired network.
The Structure of Management Frames
802.11 management frames share the structure shown in Figure 4-20. The MAC header is the same in all management frames; it does not depend on the frame subtype. Management frames use information elements, little chunks of data with a numerical label, to communicate information to other systems.
Address fields
As with all other frames, the first address field is used for the frame’s destination address. Some management frames are used to maintain properties within a single BSS. To limit the effect of broadcast and multicast management frames, stations are required to inspect the BSSID after receiving a management frame, though not all implementations perform BSSID filtering. Only broadcast and multicast frames from the BSSID that a station is currently associated with are passed to MAC management layers. The one exception to this rule is Beacon frames, which are used to announce the existence of an 802.11 network.
BSSIDs are assigned in the familiar manner. Access points use the MAC address of the wireless network interface as the BSSID. Mobile stations adopt the BSSID of the access point they are currently associated with. Stations in an IBSS use the randomly generated BSSID from the BSS creation. One exception to the rule: frames sent by the mobile station seeking a specific network may use the BSSID of the network they are seeking, or they may use the broadcast BSSID to find all networks in the vicinity.
Duration calculations
Management frames use the Duration field in the same manner that other frames do:
Any frames transmitted in the contention-free period set the duration to 32,768.
Frames transmitted during the contention-based access periods using only the DCF use the Duration field to block access to the medium to allow any atomic frame exchanges to complete.
If the frame is a broadcast or multicast (the destination address is a group address), the duration is 0. Broadcast and multicast frames are not acknowledged, so the NAV is not needed to block access to the medium.
If a nonfinal fragment is part of a multiframe exchange, the duration is set to the number of microseconds taken up by three SIFS intervals plus the next fragment and its acknowledgment.
Final fragments use a duration that is the time required for one acknowledgment plus one SIFS.
Frame body
Management frames are quite flexible. Most of the data contained in the frame body uses fixed-length fields called fixed fields and variable-length fields called information elements. Information elements are blobs of data of varying size. Each data blob is tagged with a type number and a size, and it is understood that an information element of a certain type has its data field interpreted in a certain way. New information elements can be defined by newer revisions to the 802.11 specification; implementations that predate the revisions can ignore newer elements. Old implementations depend on backward-compatible hardware and frequently can’t join networks based on the newer standards. Fortunately, new options usually can be easily turned off for compatibility.
This section presents the fixed fields and information elements as building blocks and shows how the building blocks are assembled into management frames. 802.11 mandates the order in which information elements appear, but not all elements are mandatory. This book shows all the frame building blocks in the specified order, and the discussion of each subtype notes which elements are rare and which are mutually exclusive.
Fixed-Length Management Frame Components
10 fixed-length fields may appear in management frames. Fixed-length fields are often referred to simply as fields to distinguish them from the variable-length information elements. Fields do not have a header to distinguish them from other parts of the frame body. Because they have a fixed length and appear in a known order, fields can be delimited without using a field header.
Authentication Algorithm Number
Two bytes are used for the Authentication Algorithm Number field, which are shown in Figure 4-21. This field identifies the type of authentication used in the initial 802.11-level authentication process before association occurs. 802.1X authentication occurs after association, and is not assigned an algorithm number. (The authentication process is discussed more thoroughly in Chapter 8.) The values permitted for this field are shown in Table 4-3. Only two values are currently defined. Other values are reserved for future standardization work.
Authentication Transaction Sequence Number
Authentication is a multistep process that consists of a challenge from the access point and a response from the mobile station attempting to associate. The Authentication Transaction Sequence Number, shown in Figure 4-22, is a two-byte field used to track progress through the authentication exchange. It takes values from 1 to 65,535; it is never set to 0. Use of this field is discussed in Chapter 8.
Beacon interval
Beacon transmissions announce the existence of an 802.11 network at regular intervals. Beacon frames carry information about the BSS parameters and the frames buffered by access points, so mobile stations must listen to Beacons. The Beacon Interval, shown in Figure 4-23, is a 16-bit field set to the number of time units between Beacon transmissions. One time unit, which is often abbreviated TU, is 1,024 microseconds (ms), which is about 1 millisecond.[22] Time units may also be called kilo-microseconds in various documentation (Kms or kms). It is common for the Beacon interval to be set to 100 time units, which corresponds to an interval between Beacon transmissions of approximately 100 milliseconds or 0.1 seconds.
Capability Information
The 16-bit Capability Information field (Figure 4-24) is used in Beacon transmissions to advertise the network’s capabilities. Capability Information is also used in Probe Request and Probe Response frames. In this field, each bit is used as a flag to advertise a particular function of the network. Stations use the capability advertisement to determine whether they can support all the features in the BSS. Stations that do not implement all the features in the capability advertisement are not allowed to join.
- ESS/IBSS
These two bits are mutually exclusive. Access points set the ESS field to 1 and the IBSS field to 0 to indicate that the access point is part of an infrastructure network. Stations in an IBSS set the ESS field to 0 and the IBSS field to 1.
- Privacy
Setting the Privacy bit to 1 requires the use of WEP for confidentiality. In infrastructure networks, the transmitter is an access point. In IBSSs, Beacon transmission must be handled by a station in the IBSS.
- Short Preamble
This field was added to 802.11b to support the high-rate DSSS PHY. Setting it to 1 indicates that the network is using the short preamble as described in Chapter 12. Zero means the option is not in use and is forbidden in the BSS. 802.11g requires use of the short preamble, so this field is always set to 1 in a network built on the 802.11g standard.
- PBCC
This field was added to 802.11b to support the high-rate DSSS PHY. When it is set to 1, it indicates that the network is using the packet binary convolution coding modulation scheme described in Chapter 12, or the higher-speed 802.11g PBCC modulation described in Chapter 14. Zero means that the option is not in use and is forbidden in the BSS.
- Channel Agility
This field was added to 802.11b to support the high rate DSSS PHY. When it is set to one, it indicates that the network is using the Channel Agility option described in Chapter 12. Zero means the option is not in use and is forbidden in the BSS.
- Short Slot Time (802.11g)
This bit is set to one to indicate the use of the shorter slot time supported by 802.11g, which is discussed in Chapter 14.
- DSSS-OFDM (802.11g)
This bit is set to one to indicate that the optional DSSS-OFDM frame construction in 802.11g is in use.
- Contention-free polling bits
Stations and access points use these two bits as a label. The meanings of the labels are shown in Table 4-4.
CF-Pollable | CF-Poll Request | Interpretation |
Station usage | ||
0 | 0 | Station does not support polling |
0 | 1 | Station supports polling but does not request to be put on the polling list |
1 | 0 | Station supports polling and requests a position on the polling list |
1 | 1 | Station supports polling and requests that it never be polled (results in station treated as if it does not support contention-free operation) |
Access point usage | ||
0 | 0 | Access point does not implement the point coordination function |
0 | 1 | Access point uses PCF for delivery but does not support polling |
1 | 0 | Access point uses PCF for delivery and polling |
1 | 1 | Reserved; unused |
Current AP Address
Mobile stations use the Current AP Address field, shown in Figure 4-25, to indicate the MAC address of the access point with which they are associated. This field is used to ease associations and reassociations. Stations transmit the address of the access point that handled the last association with the network. When an association is established with a different access point, this field can be used to transfer the association and retrieve any buffered frames.
Listen interval
To save battery power, stations may shut off the antenna units in 802.11 network interfaces. While stations are sleeping, access points must buffer frames for them. Dozing stations periodically wake up to listen to traffic announcements to determine whether the access point has any buffered frames. When stations associate with an access point, part of the saved data is the Listen Interval, which is the number of Beacon intervals that stations wait between listening for Beacon frames. The Listen Interval, shown in Figure 4-26, allows mobile stations to indicate how long the access point must retain buffered frames. Higher listen intervals require more access point memory for frame buffering. Access points may use this feature to estimate the resources that will be required and may refuse resource-intensive associations. The Listen Interval is described in Chapter 8.
Association ID
The Association ID, shown in Figure 4-27, is a 16-bit field. When stations associate with an access point, they are assigned an Association ID to assist with control and management functions. Even though 14 bits are available for use in creating Association IDs, they range only from 1-2,007. To maintain compatibility with the Duration/ID field in the MAC header, the two most significant bits are set to 1.
Timestamp
The Timestamp field, shown in Figure 4-28, allows synchronization between the stations in a BSS. The master timekeeper for a BSS periodically transmits the number of microseconds it has been active. When the counter reaches its maximum value, it wraps around. (Counter wraps are unlikely given the length of time it takes to wrap a 64-bit counter. At over 580,000 years, I would bet on a required patch or two before the counter wrap.)
Reason Code
Stations may send Disassociation or Deauthentication frames in response to traffic when the sender has not properly joined the network. Part of the frame is a 16-bit Reason Code field, shown in Figure 4-29, to indicate what the sender has done incorrectly. Table 4-5 shows why certain reason codes are generated. Fully understanding the use of reason codes requires an understanding of the different classes of frames and states of the 802.11 station, which is discussed in the section “Frame Transmission and Association and Authentication States.”
Code | Explanation |
0 | Reserved; unused |
1 | Unspecified |
2 | Prior authentication is not valid |
3 | Station has left the basic service area or extended service area and is deauthenticated |
4 | Inactivity timer expired and station was disassociated |
5 | Disassociated due to insufficient resources at the access point |
6 | Incorrect frame type or subtype received from unauthenticated station |
7 | Incorrect frame type or subtype received from unassociated station |
8 | Station has left the basic service area or extended service area and is disassociated |
9 | Association or reassociation requested before authentication is complete |
10 (802.11h) | Disassociated because of unacceptable values in Power Capability element |
11 (802.11h) | Disassociated because of unacceptable values in Supported Channels element |
12 | Reserved |
13 (802.11i) | Invalid information element (added with 802.11i, and likely one of the 802.11i information elements) |
14 (802.11i) | Message integrity check failure |
15 (802.11i) | 4-way keying handshake timeout |
16 (802.11i) | Group key handshake timeout |
17 (802.11i) | 4-way handshake information element has different security parameters from initial parameter set |
18 (802.11i) | Invalid group cipher |
19 (802.11i) | Invalid pairwise cipher |
20 (802.11i) | Invalid Authentication and Key Management Protocol |
21 (802.11i) | Unsupported Robust Security Network Information Element (RSN IE) version |
22 (802.11i) | Invalid capabilities in RSN information element |
23 (802.11i) | 802.1X authentication failure |
24 (802.11i) | Proposed cipher suite rejected due to configured policy |
25-65,535 | Reserved; unused |
Status Code
Status codes indicate the success or failure of an operation. The Status Code field, shown in Figure 4-30, is 0 when an operation succeeds and nonzero on failure. Table 4-6 shows the status codes that have been standardized.
Code | Explanation |
0 | Operation completed successfully |
1 | Unspecified failure |
2-9 | Reserved; unused |
10 | Requested capability set is too broad and cannot be supported |
11 | Reassociation denied; prior association cannot be identified and transferred |
12 | Association denied for a reason not specified in the 802.11 standard |
13 | Requested authentication algorithm not supported |
14 | Unexpected authentication sequence number |
15 | Authentication rejected; the response to the challenge failed |
16 | Authentication rejected; the next frame in the sequence did not arrive in the expected window |
17 | Association denied; the access point is resource-constrained |
18 | Association denied; the mobile station does not support all of the data rates required by the BSS |
19 (802.11b) | Association denied; the mobile station does not support the Short Preamble option |
20 (802.11b) | Association denied; the mobile station does not support the PBCC modulation option |
21 (802.11b) | Association denied; the mobile station does not support the Channel Agility option |
22 (802.11h) | Association denied; Spectrum Management is required |
23 (802.11h) | Association denied; Power Capability value is not acceptable |
24 (802.11h) | Association denied; Supported Channels is not acceptable |
25 (802.11g) | Association denied; the mobile station does not support the Short Slot Time |
26 (802.11g) | Association denied; the mobile station does not support DSSS-OFDM |
27-39 | Reserved |
40 (802.11i) | Information element not valid |
41 (802.11i) | Group (broadcast/multicast) cipher not valid |
42 (802.11i) | Pairwise (unicast) cipher not valid |
43 (802.11i) | Authentication and Key Management Protocol (AKMP) not valid |
44 (802.11i) | Robust Security Network information element (RSN IE) version is not supported |
45 (802.11i) | RSN IE capabilites are not supported |
46 (802.11i) | Cipher suite rejected due to policy |
47-65,535 | Reserved for future standardization work |
Management Frame Information Elements
Information elements are variable-length components of management frames. A generic information element has an ID number, a length, and a variable-length component, as shown in Figure 4-31. Standardized values for the element ID number are shown in Table 4-7.
Element ID | Name |
0 | Service Set Identity (SSID) |
1 | Supported Rates |
2 | FH Parameter Set |
3 | DS Parameter Set |
4 | CF Parameter Set |
5 | Traffic Indication Map (TIM) |
6 | IBSS Parameter Set |
7 (802.11d) | Country |
8 (802.11d) | Hopping Pattern Parameters |
9 (802.11d) | Hopping Pattern Table |
10 (802.11d) | Request |
11-15 | Reserved; unused |
16 | Challenge text |
17-31 | Reserved[a] (formerly for challenge text extension, before 802.11 shared key authentication was discontinued) |
32 (802.11h) | Power Constraint |
33 (802.11h) | Power Capability |
34 (802.11h) | Transmit Power Control (TPC) Request |
35 (802.11h) | TPC Report |
36 (802.11h) | Supported Channels |
37 (802.11h) | Channel Switch Announcement |
38 (802.11h) | Measurement Request |
39 (802.11h) | Measurement Report |
40 (802.11h) | Quiet |
41 (802.11h) | IBSS DFS |
42 (802.11g) | ERP information |
43-49 | Reserved |
48 (802.11i) | Robust Security Network |
50 (802.11g) | Extended Supported Rates |
32-255 | Reserved; unused |
221[b] | Wi-Fi Protected Access |
[a] 802.11 shared key authentication is no longer recommended, so it is unlikely that these fields will ever be used. [b] This is used by WPA, and is not an official part of 802.11. However, it is widely implemented, so I include it in the table. | |
Service Set Identity (SSID)
Network managers are only human, and they usually prefer to work with letters, numbers, and names rather than 48-bit identifiers. 802.11 networks, in the broadest sense, are either extended service sets or independent BSSs. The SSID, shown in Figure 4-32, allows network managers to assign an identifier to the service set. Stations attempting to join a network may scan an area for available networks and join the network with a specified SSID. The SSID is the same for all the basic service areas composing an extended service area.
Some documentation refers to the SSID as the network name because network administrators frequently assign a character string to it. However, the SSID is just a string of bytes that labels the BSSID as belonging to a larger agglomeration. Some products require that the string be a garden variety ASCII string, though the standard has no requirement on the content of the string.
In all cases, the length of the SSID ranges between 0 and 32 bytes. The zero-byte case is a special case called the broadcast SSID; it is used only in Probe Request frames when a station attempts to discover all the 802.11 networks in its area.
Supported Rates
Several data rates have been standardized for wireless LANs. The Supported Rates information element allows an 802.11 network to specify the data rates it supports. When mobile stations attempt to join the network, they check the data rates used in the network. Some rates are mandatory and must be supported by the mobile station, while others are optional.
The Supported Rates information element is shown in Figure 4-33. It consists of a string of bytes. Each byte uses the seven low-order bits for the data rate; the most significant bit indicates whether the data rate is mandatory. Mandatory rates are encoded with the most significant bit set to 1 and optional rates have a 0. Up to eight rates may be encoded in the information element. As the number of data rates has proliferated, the Extended Supported Rates element was standardized to handle more than eight data rates.
In the initial revision of the 802.11 specification, the seven bits encoded the data rate as a multiple of 500 kbps. New technology, especially ETSI’s HIPERLAN efforts, required a change to the interpretation. When 7 bits are used to have a multiple of 500 kbps, the maximum data rate that can be encoded is 63.5 Mbps. Research and development on wireless LAN technology has made this rate achievable in the near future. As a result, the IEEE changed the interpretation from a multiple of 500 kbps to a simple label in 802.11b. Previously standardized rates were given labels corresponding to the multiple of 500 kbps, but future standards may use any value. Current standardized values are shown in Table 4-8.
Binary value | Corresponding rate (Mbps) |
2 | 1 |
4 | 2 |
11 (802.11b) | 5.5 |
12 (802.11g) | 6 |
18 (802.11g) | 9 |
22 (802.11b) | 11 |
24 (802.11g) | 12 |
36 (802.11g) | 18 |
44 (802.11g) | 22 (optional 802.11g PBCC) |
48 (802.11g) | 24 |
66 (802.11g) | 33 (optional 802.11g PBCC) |
72 (802.11g) | 36 |
96 (802.11g) | 48 |
108 (802.11g) | 54 |
As an example, Figure 4-33 shows the encoding of two data rates. 2-Mbps service is mandatory and 11-Mbps service is supported. This is encoded as a mandatory 2-Mbps rate and an optional 11-Mbps rate.
FH Parameter Set
The FH Parameter Set information element, shown in Figure 4-34, contains all parameters necessary to join a frequency-hopping 802.11 network.
The FH Parameter Set has four fields that uniquely specify an 802.11 network based on frequency hopping. Chapter 12 describes these identifiers in depth.
- Dwell Time
802.11 FH networks hop from channel to channel. The amount of time spent on each channel in the hopping sequence is called the dwell time. It is expressed in time units (TUs).
- Hop Set
Several hopping patterns are defined by the 802.11 frequency-hopping PHY. This field, a single byte, identifies the set of hop patterns in use.
- Hop Pattern
Stations select one of the hopping patterns from the set. This field, also a single byte, identifies the hopping pattern in use.
- Hop Index
Each pattern consists of a long sequence of channel hops. This field, a single byte, identifies the current point in the hop sequence.
DS Parameter Set
Direct-sequence 802.11 networks have only one parameter: the channel number used by the network. High-rate direct sequence networks use the same channels and thus can use the same parameter set. The channel number is encoded as a single byte, as shown in Figure 4-35.
Traffic Indication Map (TIM)
Access points buffer frames for mobile stations sleeping in low-power mode. Periodically, the access point attempts to deliver buffered frames to sleeping stations. A practical reason for this arrangement is that much more power is required to power up a transmitter than to simply turn on a receiver. The designers of 802.11 envisioned battery-powered mobile stations; the decision to have buffered frames delivered to stations periodically was a way to extend battery life for low-power devices.
Part of this operation is to send the Traffic Indication Map (TIM) information element (Figure 4-36) to the network to indicate which stations have buffered traffic waiting to be picked up.
The meat of the traffic indication map is the virtual bitmap, a logical structure composed of 2,008 bits. Each bit is tied to the Association ID. When traffic is buffered for that Association ID, the bit is 1. If no traffic is buffered, the bit tied to the Association ID is 0.
- DTIM Count
This one-byte field is the number of Beacons that will be transmitted before the next DTIM frame. DTIM frames indicate that buffered broadcast and multicast frames will be delivered shortly. Not all Beacon frames are DTIM frames.
- DTIM Period
This one-byte field indicates the number of Beacon intervals between DTIM frames. Zero is reserved and is not used. The DTIM count cycles through from the period down to 0.
- Bitmap Control and Partial Virtual Bitmap
The Bitmap Control field is divided into two subfields. Bit 0 is used for the traffic indication status of Association ID 0, which is reserved for multicast traffic. The remaining seven bits of the Bitmap Control field are used for the Bitmap Offset field.
To save transmission capacity, the Bitmap Offset field can be used to transmit a portion of the virtual bitmap. The Bitmap Offset is related to the start of the virtual bitmap. By using the Bitmap Offset and the Length, 802.11 stations can infer which part of the virtual bitmap is included.
CF Parameter Set
The CF Parameter Set information element is transmitted in Beacons by access points that support contention-free operation. Contention-free service is discussed in Chapter 9 because of its optional nature.
IBSS Parameter Set
IBSSs currently have only one parameter, the announcement traffic indication map (ATIM) window, shown in Figure 4-37. This field is used only in IBSS Beacon frames. It indicates the number of time units (TUs) between ATIM frames in an IBSS.
Country
The initial 802.11 specifications were designed around the existing regulatory constraints in place in the major industrialized countries. Rather than continue to revise the specification each time a new country was added, a new specification was added that provides a way for networks to describe regulatory constraints to new stations. The main pillar of this is the Country information element, shown in Figure 4-38.
After the initial type/length information element header, there is a country identifier, followed by a series of three-byte descriptors for regulatory constraints. Each constraint descriptor specifies a unique band, and they may not overlap, since a given frequency has only one maximum allowed power.
- Country String (3 bytes)
A three-character ASCII string of where the station is operating. The first two letters are the ISO country code (e.g., “US” for the United States). Many countries have different indoor and outdoor regulations, and the third character distinguishes between the two. When a single set of omnibus regulations covers all environments, the third character is a space. To designate indoor or outdoor regulations only, the third character may be set to “I” or “O”, respectively.
- First Channel Number (1 byte)
The first channel number is the lowest channel subject to the power constraint. Channel number assignment for each PHY is discussed in the appropriate chapter.
- Number of Channels (1 byte)
The size of the band subject to the power constraint is indicated by the number of channels. The size of a channel is PHY-dependent.
- Maximum Transmit Power (1 byte)
The maximum transmit power, expressed in dBm.
- Pad (1 byte; optional)
The size of the information element must be an even number of bytes. If the length of the information element is an odd number of bytes, a single byte of zeroes is appended as a pad.
Hopping Pattern Parameters and Hopping Pattern Table
The initial 802.11 frequency hopping specification, described in Chapter 11, was built around the regulatory constraints in effect during its design. These two elements can be used to build a hopping pattern that complies with regulatory constraints in additional countries, which allows further adoption of the frequency-hopping PHY without requiring additional revision to the specification.
Request
In Probe Request frames, the Request information element is used to ask the network for certain information elements. The Request information element has the type/length header, and is followed by a list of integers with the numbers of the information elements being requested (Figure 4-39).
Challenge Text
The shared-key authentication system defined by 802.11 requires that the mobile station successfully decrypt an encrypted challenge. The challenge is sent using the Challenge Text information element, which is shown in Figure 4-40.
Power Constraint
The Power Constraint information element is used to allow a network to describe the maximum transmit power to stations. In addition to a regulatory maximum, there may be another maximum in effect. The only field, a one-byte integer, is the number of decibels by which any local constraint reduces the regulatory maximum. If, for example, the regulatory maximum power were 10 dBm, but this information element contained the value 2, then the station would set its maximum transmit power to 8 dBm (Figure 4-41).
Power Capability
802.11 stations are battery powered, and often have radios that are not as capable as access points, in part because there is not usually the need for mobile client devices to transmit at high power. The Power Capability information element allows a station to report its minimum and maximum transmit power, in integer units of dBm (Figure 4-42).
TPC Request
The Transmit Power Control (TPC) Request information element is used to request radio link management information. It has no associated data, so the length field is always zero (Figure 4-43).
TPC Report
For stations to know how to tune transmission power, it helps to know the attenuation on the link. TPC Report information elements are included in several types of management frames, and include two one-byte fields (Figure 4-44). The first, the transmit power, is the transmit power of the frame containing the information element, in units of dBm. The second, the link margin, represents the number of decibels of safety that the station requires. Both are used by the station to adapt its transmission power, as described in Chapter 8.
Supported Channels
The Supported Channels information element is similar to the Country information element, in that it describes sub-bands that are supported. After the header, there is a series of sub-band descriptors. Each sub-band descriptor consists of a first channel number, which is the lowest channel in a supported sub-band, followed by the number of channels in the sub-band (Figure 4-45). For example, a device that only supported channels 40 through 52 would set the first channel number to 40, and the number of channels to 12.
Channel Switch Announcement
802.11h added the ability of networks to dynamically switch channels. To warn stations in the network about the impending channel change, management frames may include the Channel Switch Announcement element shown in Figure 4-46.
- Channel Switch Mode
When the operating channel is changed, it disrupts communication. If this field is set to 1, associated stations should stop transmitting frames until the channel switch has occurred. If it is set to zero, there is no restriction on frame transmission.
- New Channel Number
The new channel number after the switch. At present, there is no need for this field to exceed a value of 255.
- Channel Switch Count
Channel switching can be scheduled. This field is the number of Beacon frame transmission intervals that it will take to change the channel. Channel switch occurs just before the Beacon transmission is to begin. A non-zero value indicates the number of Beacon intervals to wait; a zero indicates that the channel switch may occur without any further warning.
Measurement Request and Measurement Report
Regular channel measurements are important to monitoring the channel and power settings. Two information elements are defined to allow stations to request measurements and receive reports. Reports are a key component of 802.11h, and will be discussed in detail in the “Spectrum Management” section of Chapter 8.
Quiet
One of the reasons for the development of dynamic frequency selection was the need to avoid certain military radar technologies. To find the presence of radar or other interference, an AP can use the Quiet element, shown in Figure 4-47, to temporarily shut down the channel to improve the quality of measurements.
Following the header, there are four fields:
- Quiet Count
Quiet periods are scheduled. The count is the number of Beacon transmission intervals until the quiet period begins. It works in a similar fashion to the Channel Switch Count field.
- Quiet Period
Quiet periods may also be periodically scheduled. If this field is zero, it indicates there are no scheduled quiet periods. A non-zero value indicates the number of beacon intervals between quiet periods.
- Quiet Duration
Quiet periods do not need to last for an entire Beacon interval. This field specifies the number of time units the quiet period lasts.
- Quiet Offset
Quiet periods do not necessarily have to begin with a Beacon interval. The Offset field is the number of time units after a Beacon interval that the next quiet period will begin. Naturally, it must be less than one Beacon interval.
IBSS DFS
In an infrastructure network, the access point is responsible for dynamic frequency selection. Independent networks must have a designated owner of the dynamic frequency selection (DFS) algorithm. Management frames from the designated station in an IBSS may transmit the IBSS DFS information element, shown in Figure 4-48.
After the header, it has the MAC address of the station responsible for maintaining DFS information, as well as a measurement interval. The bulk of the frame is a series of channel maps, which report what is detected on each channel. The channel map consists of a channel number, followed by a map byte, which has the following fields:
- BSS (1 bit)
This bit will be set if frames from another network are detected during a measurement period.
- OFDM Preamble (1 bit)
This bit is set if the 802.11a short training sequence is detected, but without being followed by the rest of the frame. HIPERLAN/2 networks use the same preamble, but obviously not the same frame construction.
- Unidentified Signal (1 bit)
This bit is set when the received power is high, but the signal cannot be classified as either another 802.11 network (and hence, set the BSS bit), another OFDM network (and hence, set the OFDM Preamble bit), or a radar signal (and hence, set the Radar bit). The standard does not specify what power level is high enough to trigger this bit being set.
- Radar (1 bit)
If a radar signal is detected during a measurement period, this bit will be set. Radar systems which must be detected are defined by regulators, not the 802.11 task group.
- Unmeasured (1 bit)
If the channel was not measured, this bit will be set. Naturally, when there was no measurement taken, nothing can be detected in the band and the previous four bits will be set to zero.
ERP Information
802.11g defined the extended rate PHY (ERP). To provide backwards compatibility, the ERP information element, shown in Figure 4-49, was defined. In its first iteration, it is three bit flags in a single byte.
- Non-ERP present
This bit will be set when an older, non-802.11g station associates to a network. It may also be set when overlapping networks that are not capable of using 802.11g are detected.
- Use Protection
When stations incapable of operating at 802.11g data rates are present, the protection bit is set to 1. This enables backwards compatibility with older stations, as described in Chapter 14.
- Barker Preamble Mode
This bit will be set if the stations which have associated to the network are not capable of the short preamble mode described in Chapter 12.
Robust Security Network
With the significant security enhancements in 802.11i, it was necessary to develop a way to communicate security information between stations. The main tool for this is the Robust Security Network (RSN) information element, shown in Figure 4-50. There are several variable components, and in some cases, the RSN information element might run into the limits of the information element size of 255 bytes past the header.
- Version
The version field must be present. 802.11i defined version 1. Zero is reserved, and versions of two or greater are not yet defined.
- Group cipher suite
Following the version number is the group cipher suite descriptor. Access points must select a single group cipher compatible with all associated stations to protect broadcast and multicast frames. Only one group cipher is allowed.
A cipher suite selector is four bytes long. It starts with an OUI for the vendor, and a number to identify the cipher. Table 4-9 shows the standardized cipher suites. (Values not shown in the table are reserved.) The OUI used by 802.11i is 00-0F-AC, which is used by the 802.11 working group.
- Pairwise Cipher Suites (count + list)
Following the group cipher suite may be several pairwise cipher suites to protect unicast frames. There is a two-byte count, followed by a series of supported cipher descriptors. The suite selector may be set to zero to indicate support for only the group cipher suite. There is no limit, other than the size of the information element, on the number of supported pairwise ciphers.
- Authentication and Key Management (AKM) suites (count + list)
Like the pairwise cipher suite selector, there may be multiple authentication types defined. Following a count, there is a series of four-byte suite identifiers. As with the cipher suites, the four-byte identifier consists of an OUI and a suite type number. Table 4-10 shows the standard authentication types.
- RSN Capabilties
This two-byte field consists of four flags used to describe what the transmitter is capable of, followed by reserved bits that must be set to zero.
- Pre-authentication
An AP may set this bit to indicate it can perform pre-authentication with other APs on the network to move security sessions around. Otherwise, this bit is set to zero. Preauthentication is discussed in Chapter 8.
- No Pairwise
This bit is set when a station can support a manual WEP key for broadcast data in conjunction with a stronger unicast key. Although supported by the standard, this configuration should not be used unless absolutely necessary.
- Pairwise Replay Counter and Group Replay Counter
Separate replay counters may be maintained for each priority level defined in emerging quality of service extensions. These bits describe the number of replay counters supported by the station.
- PMK list (count + list)
Faster hand-offs between access points are possible when the pairwise master key is cached by the AP. Stations may provide a list of master keys to an AP on association in an attempt to bypass the time-consuming authentication. PMK caching is discussed in more detail in Chapter 8.
Extended Supported Rates
The Extended Supported Rates information element acts identically to the Supported Rates element in Figure 4-33, but it allows an information element body of up to 255 bytes to be supported.
Wi-Fi Protected Access (WPA)
Wi-Fi Protected Access is a slight modification of a subset of 802.11i, designed to bring TKIP to the market more quickly. It is identical to the Robust Security Network information element in Figure 4-50, but with the following changes:
The element ID is 221, not 48.
A WPA-specific tag of 00:50:F2:01 is inserted before the version field.
Microsoft’s OUI (00:50:F2) is used instead of the 802.11 working group’s OUI.
Only one cipher suite and one authentication suite are supported in the information element. However, many WPA implementations do not follow this restriction.
TKIP is the default cipher, rather than CCMP.
Preauthentication is not supported in WPA, so the preauthentication capabilities bit is always zero.
Types of Management Frames
The fixed fields and information elements are used in the body of management frames to convey information. Several types of management frames exist and are used for various link-layer maintenance functions.
Beacon
Beacon frames announce the existence of a network and are an important part of many network maintenance tasks. They are transmitted at regular intervals to allow mobile stations to find and identify a network, as well as match parameters for joining the network. In an infrastructure network, the access point is responsible for transmitting Beacon frames. The area in which Beacon frames appear defines the basic service area. All communication in an infrastructure network is done through an access point, so stations on the network must be close enough to hear the Beacons.
Figure 4-51 shows most the fields that can be used in a Beacon frame in the order in which they appear. Not all of the elements are present in all Beacons. Optional fields are present only when there is a reason for them to be used. The FH and DS Parameter Sets are used only when the underlying physical layer is based on frequency hopping or direct-sequence techniques. Only one physical layer can be in use at any point, so the FH and DS Parameter Sets are mutually exclusive.
The CF Parameter Set is used only in frames generated by access points that support the PCF, which is optional. The TIM element is used only in Beacons generated by access points, because only access points perform frame buffering. If the Country-specific frequency hopping extensions were to be present, they would follow the Country information element. Frequency hopping networks are much less common now, though, so I omit the frequency hopping extensions for simplicity. Likewise, the IBSS DFS element occur between the Quiet and TPC Report elements, were it to appear.
Probe Request
Mobile stations use Probe Request frames to scan an area for existing 802.11 networks. The format of the Probe Request frame is shown in Figure 4-52. All fields are mandatory.
A Probe Request frame contains two fields: the SSID and the rates supported by the mobile station. Stations that receive Probe Requests use the information to determine whether the mobile station can join the network. To make a happy union, the mobile station must support all the data rates required by the network and must want to join the network identified by the SSID. This may be set to the SSID of a specific network or set to join any compatible network. Drivers that allow cards to join any network use the broadcast SSID in Probe Requests.
Probe Response
If a Probe Request encounters a network with compatible parameters, the network sends a Probe Response frame. The station that sent the last Beacon is responsible for responding to incoming probes. In infrastructure networks, this station is the access point. In an IBSS, responsibility for Beacon transmission is distributed. After a station transmits a Beacon, it assumes responsibility for sending Probe Response frames for the next Beacon interval. The format of the Probe Response frame is shown in Figure 4-53. Some of the fields in the frame are mutually exclusive; the same rules apply to Probe Response frames as to Beacon frames.
The Probe Response frame carries all the parameters in a Beacon frame, which enables mobile stations to match parameters and join the network. Probe Response frames can safely leave out the TIM element because stations sending probes are not yet associated and thus would not need to know which associations have buffered frames waiting at the access point.
IBSS announcement traffic indication map (ATIM)
IBSSs have no access points and therefore cannot rely on access points for buffering. When a station in an IBSS has buffered frames for a receiver in low-power mode, it sends an ATIM frame during the delivery period to notify the recipient it has buffered data. See Figure 4-54.
Disassociation and Deauthentication
Disassociation frames are used to end an association relationship, and Deauthentication frames are used to end an authentication relationship. Both frames include a single fixed field, the Reason Code, as shown in Figure 4-55. Of course, the Frame Control fields differ because the subtype distinguishes between the different types of management frames. 802.11 revisions did not need to change the format, but many have added new reason codes.
Association Request
Once mobile stations identify a compatible network and authenticate to it, they may attempt to join the network by sending an Association Request frame. The format of the Association Request frame is shown in Figure 4-56.
The Capability Information field is used to indicate the type of network the mobile station wants to join. Before an access point accepts an association request, it verifies that the Capability Information, SSID, and (Extended) Supported Rates all match the parameters of the network. Access points also note the Listen Interval, which describes how often a mobile station listens to Beacon frames to monitor the TIM. Stations that support spectrum management will have the power and channel capability information elements, and stations supporting security will have the RSN information element.
Reassociation Request
Mobile stations moving between basic service areas within the same extended service area need to reassociate with the network before using the distribution system again. Stations may also need to reassociate if they leave the coverage area of an access point temporarily and rejoin it later. See Figure 4-57.
Association and Reassociation Requests differ only in that a Reassociation Request includes the address of the mobile station’s current access point. Including this information allows the new access point to contact the old access point and transfer the association data. The transfer may include frames that were buffered at the old access point.
Association Response and Reassociation Response
When mobile stations attempt to associate with an access point, the access point replies with an Association Response or Reassociation Response frame, shown in Figure 4-58. The two differ only in the subtype field in the Frame Control field. All fields are mandatory. As part of the response, the access point assigns an Association ID. How an access point assigns the association ID is implementation-dependent.
Authentication
At the beginning of 802.11 networking, stations authenticated using a shared key, and exchanged Authentication frames, which are shown in Figure 4-59. With 802.11i, shared key authentication was kept in the standard, but made incompatible with the new security mechanisms. If a station uses shared key authentication, it will not be allowed to use the strong security protocols described in Chapter 8.
Different authentication algorithms may co-exist. The Authentication Algorithm Number field is used for algorithm selection. The authentication process may involve a number of steps (depending on the algorithm), so there is a sequence number for each frame in the authentication exchange. The Status Code and Challenge Text are used in different ways by different algorithms; details are discussed in Chapter 8.
Action frame
802.11h added support for Action frames, which trigger measurements. These frames will be described in detail in the “Spectrum Management” section of Chapter 8.
Frame Transmission and Association and Authentication States
Allowed frame types vary with the association and authentication states. Stations are either authenticated or unauthenticated and can be associated or unassociated. These two variables can be combined into three allowed states, resulting in the 802.11 Hierarchy of Network Development:
Initial state; not authenticated and not associated
Authenticated but not yet associated
Authenticated and associated
Each state is a successively higher point in the development of an 802.11 connection. All mobile stations start in State 1, and data can be transmitted through a distribution system only in State 3. (IBSSs do not have access points or associations and thus only reach Stage 2.) Figure 4-60 is the overall state diagram for frame transmission in 802.11.
Frame Classes
Frames are also divided into different classes. Class 1 frames can be transmitted in State 1; Class 1 and 2 frames in State 2; and Class 1, 2, and 3 frames in State 3.
Class 1 frames
Class 1 frames may be transmitted in any state and are used to provide the basic operations used by 802.11 stations. Control frames are received and processed to provide basic respect for the CSMA/CA “rules of the road” and to transmit frames in an IBSS. Class 1 frames also allow stations to find an infrastructure network and authenticate to it. Table 4-11 shows a list of the frames that belong to the Class 1 group.
Class 2 frames
Class 2 frames can be transmitted only after a station has successfully authenticated to the network, and they can be used only in States 2 and 3. Class 2 frames manage associations. Successful association or reassociation requests move a station to State 3; unsuccessful association attempts cause the station to stay in State 2. When a station receives a Class 2 frame from a nonauthenticated peer, it responds with a Deauthentication frame, dropping the peer back to State 1.[23] Table 4-12 shows the Class 2 frames.
Class 3 frames
Class 3 frames are used when a station has been successfully authenticated and associated with an access point. Once a station has reached State 3, it is allowed to use distribution system services and reach destinations beyond its access point. Stations may also use the power-saving services provided by access points in State 3 by using the PS-Poll frame. Table 4-13 lists the different types of Class 3 frames.
Control | Management | Data |
PS-Poll | Deauthentication | Any frames, including those with either the ToDS or FromDS bits set |
If an access point receives frames from a mobile station that is authenticated but not associated, the access point responds with a Disassociation frame to bump the mobile station back to State 2. If the mobile station is not even authenticated, the access point responds with a Deauthentication frame to force the mobile station back into State 1.
[20] Not all cards perform this BSSID filtering correctly. Many products will pass all broadcasts up to higher protocol layers without validating the BSSID first.
[21] To indicate that Null is used as the frame type from the specification rather than the English word, it is capitalized. This convention will be followed throughout the chapter.
[22] Kilo-microseconds are an odd blend of the powers-of-2 used in computing for the kilo, and the more common 1/1,000 for micro. Presumably, the International Bureau of Weights and Measures would protest the mangling of the traditional form of the prefixes.
[23] This rejection action takes place only for frames that are not filtered. Filtering prevents frames from a different BSS from triggering a rejection.
Get 802.11 Wireless Networks: The Definitive Guide, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
