The more common form of aggregate frame, the A-MPDU, is shown in Figure 5-4. The A-MPDU is a relatively simple form of aggregation in that the higher-layer (IP) packet that would normally be transmitted is given a MAC header and sent back-to-back. In Figure 5-4(a), the IP packet is given a MAC header and trailer, and the (unaggregated) frame is put into a PHY-layer frame for transmission. In contrast, Figure 5-4(b) shows the aggregation process. Several IP packets are each given their own header. Because these individual packets in the aggregation process will be put together, they are referred to as A-MPDU subframes at this stage. In the aggregation process, the MAC Delimiter is inserted to assist a receiver in extracting individual subframes. Each subframe gets a complete 802.11 header, frame check sequence, and is padded so that it aligns on symbol boundaries in the physical transmission. Because each subframe in an A-MPDU gets its own MAC header, encryption is applied to each subframe in isolation. Because each subframe in an A-MPDU has its own frame check sequence, an error in one subframe will only affect that subframe, and other subframes in the aggregate can be recovered. All frames within an A-MPDU must be destined to the same receiver address on the wireless link, but may have multiple destination addresses.^[25]

Figure 5-4. A-MPDU aggregation

A-MPDU is widely supported, and typically uses hardware-assisted processing. The Wi-Fi Alliance 802.11n certification program requires support for reception of A-MPDU frames. Although A-MPDU is widely supported, it is not typically easy to tell from an analyzer that an A-MPDU has been transmitted. Many analyzers plug into the host protocol stack at a level at which the aggregate frame has already been separated out into its constituent subframes, and each of those subframes is made available to the analyzer separately. An A-MPDU is limited in size only by the 802.11n PLCP, and thus can be up to 65,535 bytes.

In addition to aggregation just before handing bits to the PHY for transmission, it is possible to pack multiple higher-layer packets into a single MAC frame. Building an Aggregate MSDU (A-MSDU) requires more software support because the network driver must take several higher-layer packets and build them into a single MAC frame payload.^[26] The format of the A-MSDU, shown in Figure 5-5, shows how a higher-layer packet is put into an A-MSDU subframe, and those subframes are put together into a single MAC frame. In contrast to A-MPDU, this type of aggregation has only one MAC frame. As a result, when security is applied to an A-MSDU, one encryption operation secures the whole aggregate frame.

Figure 5-5. A-MSDU aggregation

An A-MSDU can have a maximum size of 7,955 bytes because all the aggregated frames must fit in the frame format shown in Figure 5-1.

The two forms of aggregation can be combined. Each of the A-MPDU subframes can itself be an A-MSDU, as shown in Figure 5-6. In the figure, the last subframe in the A-MPDU is itself an aggregate frame containing two MSDUs.

Figure 5-6. A-MPDU of A-MSDU

The two methods of aggregation described in the previous sections are subtly different, and therefore, it is worth showing a comparison between the two. Table 5-2 compares A-MPDU and A-MSDU aggregation. Reception of both types of aggregate frames is widely supported, and about half of products support transmission of A-MPDUs.

In the 802.11 MAC as it was originally specified in 1997, every frame required a positive acknowledgment. Each transmission was not complete until an acknowledgment was received. Network traffic is generally bursty. For example, a user reading web pages will send out a request, receive a flurry of packets carrying the requested web page, and then the network will generally be idle while the user reads the page. The original conception of the 802.11 MAC required that each frame sent to the receiver be acknowledged separately, as in Figure 5-7(a). The quality-of-service extensions in 802.11e brought in block acknowledgments (usually abbreviated as BlockACK), which allowed the sender to transmit a stream of frames and have them all acknowledged at once. Conceptually, the BlockACK extensions work similar to the selective ACK option in TCP. Two forms were defined in 802.11e, and subsequently carried over to 802.11n, and both are illustrated in Figure 5-7(b). With the Immediate Block ACK form, the sender transmits a series of frames and expects an acknowledgment right away, while in the Delayed Block ACK form, the receiver can send its acknowledgment later.

Figure 5-7. Block ACK transmissions

In Figure 5-7(b), the QoS Data frames are sent without any immediate positive acknowledgment. Instead of requiring that each frame be individually acknowledged, a single Block ACK frame exchange handles all acknowledgment. Because the Block ACK exchange is faster than individual acknowledgments, medium efficiency is improved. Block ACKs work by setting up a “window” for acknowledgment, and enable a receiver to selectively acknowledge any or all of the frames within a window. If any one of the three frames in Figure 5-7(b) are lost, the block acknowledgment can request retransmission of just the lost frame. For example, if the second data frame is lost, the Block ACK exchange will acknowledge the first and third frames.

Aggregate frames are well-suited for use with block ACKs because an aggregate frame holds several individual frames. By transmitting all the frames in the aggregate together, much less time is expended in the protocol overhead operations used to gain control of the channel. Block ACK processing was originally optional, but the efficiency gains possible when coupled with aggregate frame transmission are so compelling that Block ACK support is mandatory for 802.11n devices.

In addition to requiring support for Block ACKs, 802.11n defined new extensions to the protocol to reduce resource requirements for receivers of aggregate frames. The most notable of these extensions is the compressed block ACK, which takes its name from the acknowledgment method. In 802.11e, Block ACKs worked on frame fragments, and the Block ACK could acknowledge individual fragments. Maintaining data structures that supported both the sequence numbers for assembled frames and the fragment identifier numbers that compose them required building significant state at the receiver. In 802.11n, the acknowledgment is compressed because it works on whole, unfragmented frames. As part of the standardization process, the task group considered whether to include fragmentation support with A-MPDU. Simulations showed that benefits existed only at higher bit-error rates than are widely used in the real world. Therefore, fragmentation support in block acknowledgment is not required.

To request a block acknowledgment, a station sends the Block ACK Request frame, shown in Figure 5-8. For the purposes of discussing a block acknowledgment in 802.11n, the important fields are the Compressed field, which requests use of the compressed form. The fragment number in the Block ACK Request Information field is set to zero.

Figure 5-8. Block ACK Request frame

To send a block acknowledgment, the receiver uses the compressed Block ACK frame, shown in Figure 5-9. A single Block ACK frame can be used to acknowledge 64 MSDUs. In its “basic” uncompressed form, the Block ACK frame must acknowledge individual fragments, and is 128 bytes long. By restricting the block ACK to unfragmented frames, the length of the bitmap can be significantly reduced. Each bit in the bitmap acknowledges the frame that has that offset from the starting sequence number. If the starting sequence number is 100, then bit 0 acknowledges sequence number 100, bit 1 acknowledges sequence number 101, and so on.

Figure 5-9. Compressed Block ACK frame

802.11 basic channel access protocol uses spaces in between frame transmissions as a method of allocating access to the medium.^[27] At the core of the interframe space mediation mechanism is that high-priority transmissions, such as acknowledgments, have a shorter waiting period and can jump on the medium in front of the start of new frame exchanges. Prior to 802.11n, the shortest interframe space was the short interframe space (SIFS), and it was used to complete frame exchanges by allowing response frames to be transmitted immediately following their triggers. For example, an acknowledgment can be transmitted after waiting only one SIFS. Likewise, a clear-to-send (CTS) frame transmitted immediately following a request-to-send (RTS) frame need only wait for one SIFS before getting on the medium.

802.11n defines a new interframe space, the Reduced Interframe Space (RIFS). It is functionally equivalent to the SIFS, and used whenever the SIFS might be used. Although it is shorter, as shown in Table 5-3, it does not define a new priority level. Its only purpose is to be used in place of the SIFS to increase efficiency. Obviously, it is not available on 802.11a/b/g devices, and, in fact, should not be used when 802.11a/b/g devices are present because it may prevent them from reading the Duration field in the frame header and updating medium access information.

Most devices do not transmit using the RIFS because the efficiency gain is relatively small. However, all Wi-Fi CERTIFIED n devices are tested for the ability to receive frames transmitted after the RIFS.

In addition to the MAC-layer protections, 802.11n adds a new PHY-layer protection mechanism. The PLCP contains information on the length of a transmission, and 802.11n sets up the physical-layer header so that it includes information on the length of transmissions.

PHY-layer protection: L-SIG duration in HT-Mixed Mode

A simple method of protection is to alter the expected medium usage time that is calculated from values in the L-SIG frame header on the physical-level frame. In 802.11a/g frames, the SIGNAL header in the PLCP frame contains both a data rate and a length in bytes of the included MAC frame. Stations that receive the PLCP frame calculate a “duration” of the transmission from the data rate and length, and then defer transmitting until the calculated duration has passed. 802.11n devices operating in HT-Mixed Mode will typically set the data rate to 6 Mbps, and then reverse engineer a length field based on the amount of time required for transmission. (Wireless LAN analyzers must be programmed to discard the L-SIG data rate and look instead at the MCS in the HT-SIG field.)

Note

If your wireless LAN analyzer is reporting that nearly all traffic on your network is sent at 6 Mbps, chances are that it is reading the L-SIG header and not the HT-SIG header. Upgrade to the latest version, be sure you are using an 802.11n capture interface, and look at a new capture.

When using L-SIG duration, 802.11n devices will set the L-SIG duration to be the amount of time required to transmit the included HT frame, plus any amount of time required for the next frame in the sequence. During a multi-frame exchange, the MAC duration field may be set for the duration of the entire exchange, but the L-SIG duration will cover the next frame in the sequence. Figure 5-11 illustrates the difference between the two forms of duration setting, and it shows how the L-SIG duration is distinct from the MAC duration. On the radio link, the transmission is simple: a CTS-to-self, followed by a data frame that is acknowledged. At the MAC layer, the NAV is set according to the basic protection rules. In L-SIG protection, there is a second “duration” value calculated from the data rate and length transmitted in a frame’s PLCP header. Along the PHY line at the bottom of the figure, the shaded area along the PLCP line shows the extra length added to the legacy Signal field as computed by the PLCP. 802.11n’s mixed mode frame header is identical to that used by 802.11a/g, and therefore, it is possible to use the PLCP header to establish the time required for the transmission. Using the PLCP header requires somewhat less time on the medium because it does not require a whole separate frame and interframe space.

Figure 5-11. L-SIG duration

The previous section described how protection works, but not when it is activated. Networks advertise the type of protection used through the HT Operation information element, described in Figure 5-3. 802.11n defines four protection modes, and each network selects one:

802.11n protection also interacts with the existing Use_Protection bit defined in 802.11g. When the 802.11g Use_Protection flag is set, any frame transmissions used for protection are sent at 802.11 direct sequence or 802.11b rates (1, 2, 5.5, or 11 Mbps).