Structure of the IEEE 802.11 MAC Frames

As we saw previously, there are three types of frames, and in this subsection they will be discussed in the following order: Control, Management, and Data.

IEEE 802.11 Control Frames

Figure 4-5 shows the format of all six types of Control frames, which are all very short. The first four types of Control frames (Request-to-Send, Clear-to-Send, Acknowledgment, and Power-Save Poll) are the most common.

Figure 4-5. IEEE 802.11 Control frames

RTS and CTS

The RTS/CTS mechanism can be used to protect the transmission of an MPDU or MMPDU, by reserving the medium in advance of the actual transmission of the frame. The RTS/CTS mechanism is used on a hop-by-hop basis; in other words, the sending STA could use this mechanism when sending a frame to the AP, but the AP may make its own decision as to whether or not to use the RTS/CTS mechanism to protect the transmission of the frame to the receiving STA. By "protect" we mean that the RTS/CTS mechanism reserves the medium for a time interval long enough to transmit a frame and to receive the associated ACK frame. This "reservation" obviously only applies to STAs that were present to hear the RTS/CTS exchange, so it is still possible that a STA could jump in and interfere with an allegedly protected exchange (although the MAC entity is supposed to listen before talking, this can't prevent a roaming STA, which listened first, found the medium idle, began transmitting, then roamed into the middle of another WLAN in which another transmission was in progress).

The Request-to-Send (RTS) frame is 20 octets long as is optionally used to reserve the medium for a subsequent frame transmission. After the corresponding Clear-to-Send (CTS) is received, the STA that sent the RTS will know it can safely send its frame, since all STAs in the BSS will have heard the CTS from the AP. The CTS frame is only 14 octets long. Once the receiving STA (which could be an AP) has the frame, a separate decision is made if the receiving STA is not the frame's final destination.

At each hop, a decision must be made as to whether the RTS/CTS mechanism will be used to protect the frame on its next hop, or whether it will send it directly. The STA (or AP) has a configuration parameter known as the RTS threshold that determines whether a frame is preceded by an RTS/CTS exchange. Frames that are smaller than the RTS threshold are not preceded by the RTS/CTS exchange, with the exception that multicast frames are never preceded by an RTS/CTS exchange regardless of their size.

ACK

The Acknowledgment (ACK) Control frame (14 octets) is used to indicate successful reception of a frame by the next-hop receiver. If the sender does not receive an ACK during the expected time window after it finished transmitting its frame, it will re-send the frame at its next opportunity. The ACK is used in a slightly modified fashion in the event of MAC-layer fragmentation, which is covered in Chapter 6.

The ACK in IEEE 802.11 is not used to implement a reliable Data Link layer protocol (many reliable Data Link protocols do use ACK-based schemes to provide for retransmissions). The usage of the ACK in IEEE 802.11 actually serves to indicate to the sender whether a collision has happened. A collision is inferred by the lack of an ACK.

PS-Poll

The PS-Poll (Power-Save Poll) Control frame (20 octets) is used when a STA sees that an AP has frames buffered for it. The STA sends the PS-Poll so the AP knows that the STA is ready to receive the buffered frame(s). This mechanism is used when the STA has been dozing and now wants to collect the frames that the AP buffered while the STA was dozing.

"CF-End" and "CF-End + CF-ACK"

These two Control frames are used only in PCF mode, which is covered briefly in Chapter 6. Note that both of those frames are sent to the broadcast address, and both of them have their Duration field set to indicate zero microseconds.

IEEE 802.11 Management Frames (MMPDUs)

Figure 4-6 shows the format of all 11 types of Management frames.^[10]

^[10] Adapted from IEEE Std. 802.11^™-1999, copyright 1999. All rights reserved.

Figure 4-6. IEEE 802.11 Management frames (MMPDUs)^[10]

The use of these frames will be covered later in this chapter, or in Chapter 6. A general statement that can be made about MMPDUs is that they are all used in infrastructure mode, except for the ATIM message, which is only used in IBSS mode. Anything to do with Association must involve an AP, and so Association-related MMPDUs are not usable in IBSS mode. Authentication MMPDUs can be used in either infrastructure or IBSS mode. Likewise, Probes and Beacons are usable in both modes.

IEEE 802.11 Data Frames (MPDUs)

All of the IEEE 802.11 variants, regardless of the frequency band in which they operate, use the MAC sub-layer protocol frame format depicted in Figure 4-7. The formal name for this structure is the MAC Protocol Data Unit (MPDU). The Address 4 and QC fields have a gray background because they are optional (their presence depends on the contents of the FC field).^[11]

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

Figure 4-7. Overall structure of an IEEE 802.11 MPDU^[11]

Figures 4-5, 4-6, and 4-7 are all drawn to the same scale. (The only exception is that the MMPDU and MPDU frame body fields are not drawn to scale, since they are variable-length and can be so much larger than the rest of the components of the frame.) The labels in Figure 4-7 are as follows:

FC	IEEE 802.11	Frame Control
D	IEEE 802.11	Duration
SC	IEEE 802.11	Sequence Control
QC	IEEE 802.11e	QoS Control
FCS	IEEE 802.11	Frame Check Sequence

The maximum size for an IEEE 802.11 MPDU is 2346 octets. Of that, the IEEE 802.11 frame's MAC header (24 or 30 octets) plus the MAC trailer (i.e., the FCS, at four octets) consumes a total of 28 or 34 octets, which leaves a remainder of 2312 or 2316 octets in which to carry the MPDU payload. These sizes did not consider the effect of the IEEE 802.11e QC field, which would consume two octets if it were present. The entire frame, including the MAC sub-layer protocol header, the MPDU payload, and the FCS, comprises the MAC MPDU, or in the case of Management frames, the MAC MMPDU.

IEEE 802.11 with IEEE 802.1Q

In Ethernet, an IEEE 802.1Q VLAN tag is inserted into the frame and effectively removes four octets from the frame's capacity (Ethernet defines "frame extension" in which a frame may be allowed to have a full-size 1500-octet payload, a 14-octet Data Link header, the usual four-octet FCS, and the four octets of VLAN information, for a total of 1522 octets (the usual maximum frame size for Ethernet is 1518 octets, without VLAN information present).

Because the presence of the two-octet IEEE 802.1Q Tag Control Information Header is indicated by using Ethernet Type 0x8100, the insertion of the TCIH consumes four octets of the Ethernet frame's payload capacity.

Figure 4-8 illustrates the addition of the IEEE 802.1Q VLAN tag to the Ethernet (or IEEE 802.3) header. The "VT" field is the "VLAN [Ethernet] Type", 0x8100. The TCI is the IEEE 802.1Q Tag Control Information Header (TCIH).^[12]

^[12] Adapted from IEEE Std. 802.3^™-2002, copyright 2002, augmented by IEEE Std. 802.1Q^™-2003, copyright 2003. All rights reserved.

Figure 4-8. IEEE 802.1Q VLAN tag in Ethernet and IEEE 802.3^[12]

However, in IEEE 802.11 (and in all other non-Ethernet LAN protocols that rely on LLC sub-layer protocol encapsulation), the "Type" field of 0x8100 is still the only way to indicate that the TCIH is present. To get a TCIH into the stack, one needs a three-octet LLC sub-layer header (because the LLC sub-layer protocol must always follow the IEEE 802.11 MPDU header), and a five-octet SNAP sub-layer header, with the Type field of the latter set to 0x8100 (the SNAP sub-layer header is present to provide a way to encode the "Type" field in the context of LLC…when the SNAP OUI is set to the value of 0x000000, the value in the SNAP "Type" field is interpreted as if it were in the Ethernet "Type" field). The two-octet TCIH then follows the SNAP type field (only when the SNAP Type field contains 0x8100).

A total of 10 octets have been consumed, which are no longer available to carry MPDU payload. Said another way, the presence of the IEEE 802.1Q header has reduced the carrying capacity of the MPDU by a total of 10 octets. Contrary to the situation with IEEE 802.3, there is no concept of "frame extension" in IEEE 802.11 to accommodate the IEEE 802.1Q VLAN header.

In either case, after the inserted IEEE 802.1Q VLAN tag (consisting of the TCIH and whatever it takes to prefix it with a Type of 0x8100), the frame resumes with whatever has been displaced by the insertion of the VLAN tag. In Ethernet, frequently another "Type" field follows the TCIH. In IEEE 802.11, which normally requires the MPDU payload to begin with the LLC sub-layer protocol header, we can conclude that the item immediately following the IEEE 802.1Q TCIH will be an LLC sub-layer header, which encapsulates the frame's "real" higher layer protocol payload.^[13]

^[13] Adapted from IEEE Std. 802.11^™-1999, copyright 1999, augmented by IEEE Std. 802.1Q^™-2003, copyright 2003. All rights reserved.

Figure 4-9 illustrates the insertion of the IEEE 802.1Q-2003^[14] VLAN tag after the IEEE 802.11 MPDU header.

^[14] IEEE 802.1Q was originally standardized in 1998.

Figure 4-9. IEEE 802.1Q VLAN tag in IEEE 802.11^[13]

Data Link Protocol Stacks Based on IEEE 802.11

The field labels in the IEEE 802.11 MAC header are the expected ones, and the remaining labels are as follows. DS and SS are DSAP and SSAP, respectively, and C is Control. Those three are the three octets of the LLC sub-layer protocol header. The OUI is the SNAP Organizationally Unique Identifier (which is set to 0x000000 in this case, since the interpretation of the SNAP Type field is the normal Ethernet Type interpretation).

Figure 4-10 illustrates the possible Data Link protocol stack that might be based on IEEE 802.11's MAC sub-layer protocol. The base of the stack is either the 24-octet (b) or 30-octet (B) IEEE 802.11 MPDU header. That layer is required, and the 24-octet form is more common. The other mandatory layer is the 3-octet IEEE 802.2 LLC sub-layer.

Figure 4-10. Possible Data Link protocol stack based on IEEE 802.11^[15]

^[15] Adapted from IEEE Std. 802.1Q^™-2003, copyright 2003, IEEE Std. 802.2-1998, copyright 1998, and IEEE Std. 802.11^™-1999, copyright 1999, as amended by IEEE 802.11e draft 5.0 and IEEE 802.11i draft 5.0 (both works-in-progress as of this writing, which are subject to change before their eventual publication). All rights reserved.

Starting from the bottom of the stack, we see that the forthcoming IEEE 802.11e standard will optionally add a 2-octet QC field at the end of any QoS-enhanced MPDU's header (indicated by (e) in Figure 4-10). In the event that IEEE 802.11i encryption is in use, there are two options. Headers related to CCMP (indicated by (c) in Figure 4-10) will consume 16 octets of the MPDU's effective payload, while TKIP (indicated by (t)) will consume 20 octets. Next, above the IEEE 802.11 layer is the IEEE 802.1Q layer, which (if present) requires 10 octets (this header is indicated by (v) in Figure 4-10).

Finally, completing the Data Link layer protocol stack is the IEEE 802.2 LLC sub-layer protocol (indicated in Figure 4-10 as (l)), and optionally the IEEE 802.2 SNAP sub-layer protocol (indicated as (s)), which consumes five octets when it is present. The LLC sub-layer protocols, LLC and SNAP, are both part of the MPDU payload, but taken as a whole they comprise the top of the Data Link layer protocol stack. The size of this total stack affects how much data the Network layer can send at a time, in other words, it affects the maximum capacity of the MSDU. In the case of IP, the IP layer refers to the Maximum Transmission Unit (MTU) of a subnetwork technology, which is the payload size of the subnetwork. In the case of Ethernet, a 1500-octet IP packet can fit into a 1518-octet Ethernet frame. In the case of IEEE 802.11, a 2346-octet MPDU can hold an amount of data that depends on how "deep" the Data Link layer protocol stack is.

In a moment, you will see that the deepest stack is 74 octets, which results in an MTU of 2346-74 octets (i.e., 2272 octets) of capacity in the eyes of the IP layer. There are actually 12 "basic" combinations of headers, from which all the possible Data Link layer header sets formed from IEEE 802.11 can be derived, which are illustrated in Figure 4-11.^[16]

^[16] Adapted from IEEE Std. 802.11-1999, copyright 1999, as amended by IEEE 802.11e draft 5.0 and IEEE 802.11i draft 5.0 (both works-in-progress as of this writing, which are subject to change before their eventual publication). All rights reserved.

Figure 4-11. The 12 basic Data Link protocol stacks based on IEEE 802.11^[16]

There are four different ways to "complete" these basic headers to make complete Data Link layer headers. One could add LLC, or LLC + SNAP, or VLAN + LLC, or VLAN + LLC + SNAP. The four groups of resulting headers are shown in Figure 4-12.

Figure 4-12. The 48 possible Data Link protocol stacks based on IEEE 802.11

Figure 4-13 breaks down the 48 header combinations by size, showing the various ways that headers can be arranged to form valid Data Link protocol stacks based on the IEEE 802.11 MPDU.

Figure 4-13. Sizes of Data Link header stacks based on IEEE 802.11

One might be surprised that it is possible, in certain (probably rare) circumstances, to have a Data Link layer header set that is up to 74 octets in length. The most common combinations of headers are likely to be the "bls", "bcls", and "btls", at 36, 52, and 56 octets, respectively. Those are the short (24-octet) IEEE 802.11 MPDU with IEEE 802.2 LLC and SNAP, or that set with CCMP encryption, or that set with TKIP encryption. These formats are the most likely because IP packets (IPv4 or IPv6) are encapsulated in LLC and SNAP over IEEE 802.11, and IP represents the majority of data communications traffic today (and at this point, that is predominantly IPv4, though from an encapsulation perspective, IPv6 is just like IPv4, it just uses a different EtherType).

Because we have constructed complete Data Link layer header sets, the payload capacity for higher layer protocols represents the capacity that will be seen by the higher layer protocol. Just as IPv4 sees a 1518-octet Ethernet MTU and knows it can fit a 1500-octet IPv4 packet into that frame, in the case of IEEE 802.11, the upper layer protocol stack must be aware of the various types of Data Link layer headers, since the payload could range from 2346-74 octets (i.e., 2272 octets) at worst, or 2346-31 octets (i.e., 2315 octets) at best.