MSDU or MPDU: Which Is Best Frame Aggregation?

Frame aggregation has to be one of the most commonly asked about, or worse, ignored settings I've seen in my time consulting. That said, it can be a bit tricky to understand and even worse to implement. Let's try to break it down and discuss how to use it more efficiently. Frame aggregation is fairly close to what it says on the box: it aggregates or puts together frames. Frames are logical units of data grouped by transmission.

This all sounds great, right? However, there are two different main types of frame aggregation introduced by 802.11n. And unless you know the protocol in and out, it can be hard to tell them apart. So, let’s explore them both.

Aggregated MAC Service Data Unit (A-MSDU)

The A-MSDU can be best conceptualized as a container ship. It's one big package, with all the little packages inside of it. In this case, it's aggregation by taking the MSDUs of the frames-to-be-aggregated and inserting them under a single MAC header and sending them as one large transmission. Kind of like a good shipment, they need to be organized into destination (port) and QoS (Shipping speed). They're all going to arrive at the same place, at more or less the same time. If you pull a packet capture of an A-MSDU transmission, you'll see a single frame with a section called "IEEE 802.11 Aggregate MSDU" including various numbers of "A-MSDU" subframes inside of the decode.

The issue with A-MSDU is that, like a cargo ship, if you run into rough seas there is a lot to be lost all at once. For your wireless network, this correlates roughly to low SNR or SINR. In 802.11, if you do not receive an Ack frame back, the entire payload must be resent, and this takes up more airtime and induces latency in your network. Congested networks and latency sensitive networks may want to reconsider use of the A-MSDU entirely. Please, please use a test bed. No one likes rolling back a production change.

Key Takeaway: A-MSDU is transmitted as a single 802.11 frame with multiple 802.3 frames inside it, only having to be sent, and therefore contend, once.

Aggregated MAC Protocol Data Unit (A-MPDU)

If A-MSDU is a container ship, then A-MPDU is closer to a charter fleet — a group of smaller boats in a group going to the same place. Each of these ships are their own discreet frame, with a payload, but they aren't existentially tied to one another. Speaking in 802.11 terms, the aggregated frames are sent one after another, in the same contention period so only one TX OP has to be won. Of note is that more data can be sent this way in a single contention period. The TXOP won covers all the intended frames, so it may eat an overly large amount of airtime when sending large amounts of data. In other words, instead of adding latency to the transmission at hand like A-MSDU, it adds latency to all the other transmissions through airtime capitalization.

The A-MPDU method of frame aggregation does not require a single ACK reply, like a A-MSDU method transmission would; Or rather it does but it's not a standard ACK frame. Remember that frame aggregation was introduced with 802.11n alongside a few other frame types, namely the "Block-Ack" Frame type. A block Ack acknowledges a group of frames all at once, and provides a bitmap (Think of like a checklist in this instance) that details what frames, if any, were not received properly.

Key Takeaway: A-MPDU is many frames in the same contention period but is less efficient.

It bears remembering that as A-MPDU uses a block Ack, you should understand the basics of how that process works. After all, Block Ack isn't "native" to the contention process as we understand it. The A-MPDU/Block Ack process is begun with a unique send/response of an "ADDBA Exchange" which prepares the medium and TX/RX sides of the equation to handle the block of information.

During the process, this also checks capability before sending the request. Then the ADDBA request is sent (From the party wishing to SEND the "blocked" data) and Ack'd by the receiver, who follows the Ack with an ADDBA response. When the sending party Ack, data transmission can begin. The sender then sends the A-MPDU information, one frame after another, with only a short interframe space in between. When the transmitted block is complete, the sender sends a BlockAckReq (request), which instead of being Ack'd, is responded to with a BlockAck frame.

As mentioned previously, the BlockAck frame includes what frames, if any, were not received. This means that the only thing that needs a Retry or Retransmission are the dropped/corrupted frames, instead of the entire block.

Differences between A-MSDU and A-MPDU

While both the forms of frame aggregation ostensibly exist to increase throughput, they are significantly different and shouldn't be lumped together in one option nor discarded altogether. A-MSDU is better suited to environments where larger than normal, but still fairly small lumps of data need to go together in a fairly clean RF environment. The larger overhead in A-MSDU results in is best minimized this way. Your biggest penalty will be with retry and retransmission rates. I'd consider using this in a small, contained, but not overly dense space. It wouldn't be out of place in an office.

Conversely, it's suggested to not use this in areas where you have distant or a large number of clients. Remember, clients drive the network. More questionable would be applications like real-time voice. There is a manufacturer who is a near-real-time voice application that could have been using the improvements of 802.11n, many years after it came out, but didn't understand that you are not required to use A-MSDU. A more firm client-network agreement would enable them to at least have the option for aggregation and use a more modern and capable PHY. Think of PHY like a ladder. In enterprise settings, you don't always want to be at the top rung of the ladder, but it behooves the network to be close.

A-MPDU on the other hand adds protocol overhead, instead of the risk of losing data. It's more reliably going to be less airtime efficient than A-MSDU. Remember, the cost of sending all those little ships instead is that every one of those frames comes with it's own header, even if they don't have to contend for the medium generally. This makes it more popular in crowded environments, but don't go nuts with it, as the larger block is still going to eat up your airtime. Test, Test, Test.

Fusion-HA! A-MPDU and A-MSDU together

Both of these methods can be used together. It's one of the best ways to increase your throughput to devices that eat a lot of your airtime anyway. The catch here is though you do get the best of both, you get the weaknesses of each, too.

Using both together can be a lifesaver, but it should only be used in a low to medium density environment where you have considerable control over the RF environment. An example would be in a high-rise office building. You have to play nice with your neighbors and they may not do the same, leading to increased contention even with the best channel planning you can muster. Make wise use of your channel widths as well, and use the smallest you can for your use cases. Contending on many channels takes much longer than contending on one, after all. The converse is true if you have the luxury of a shielded environment, like some government sites or are simply in the boonies.