Structure of the IEEE 802.11 MAC
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
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.
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.
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.
Figure 4-6. IEEE 802.11
Management frames (MMPDUs)
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).
Figure 4-7. Overall structure of
an IEEE 802.11 MPDU
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
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
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).
Figure 4-8. IEEE 802.1Q VLAN tag
in Ethernet and IEEE 802.3
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
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.
Figure 4-9 illustrates
the insertion of the IEEE 802.1Q-2003 VLAN tag after the IEEE 802.11 MPDU header.
Figure 4-9. IEEE 802.1Q VLAN tag
in IEEE 802.11
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
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
Figure 4-10. Possible Data Link
protocol stack based on IEEE 802.11
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.
Figure 4-11. The 12 basic Data
Link protocol stacks based on IEEE 802.11
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
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
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.