Skip to main content

12.7 High Throughput (802.11n) — The Ticket to the Highway

When we finished discussing the skeleton and muscles of mac80211 in the previous section, I mentioned that the wireless world needs not just connectivity, but speed. If you used Wi-Fi before 2005, you probably remember the feeling: you were connected, but transferring a large file was agonizingly slow. The problem wasn't signal strength, but the physical limits of the rules.

This is where 802.11n steps in. In this section, we'll look at how it broke through that ceiling.

1. The Price of Speed: MIMO and Multiple Antennas​

Not long after 802.11g was ratified, IEEE formed the "High Throughput Task Group" (TGn) with a clear goal: make wireless as fast as fiber optics. It took several years of work before the standard was officially finalized in 2009.

But before the standard was formally released, vendors couldn't wait any longer. Broadcom set the precedent by releasing chips based on the 802.11g draft back in 2003. With a precedent set, draft-based 802.11n devices started appearing on the market by 2005. Intel's Santa Rosa platform featured the Intel WiFi Link 5000 series and the 4965AGN, both offering an "early access" experience for that era. Atheros and Ralink weren't sitting idle either. By June 2007, the Wi-Fi Alliance even began certifying these Draft 2.0 devices. You could say this was a game where a "ragtag troupe" of vendors shipped products first, and the standards organization played catch-up.

Frequency Bands and MIMO​

The biggest difference between 802.11n and its predecessors was its ambition—it occupied both the 2.4 GHz and 5 GHz bands simultaneously. In contrast, 11b/g could only squeeze into the crowded 2.4 GHz "farmer's market," while 11a used 5 GHz but suffered from poor compatibility.

But simply switching bands wasn't enough. 802.11n introduced a core killer feature: MIMO (Multiple Input, Multiple Output).

The principle behind this technology isn't actually that complex, but the results are outstanding: it equips both the AP and the client with multiple antennas. It's like going from one mouth shouting and one ear listening, to three or four mouths shouting and three or four ears listening simultaneously—and each mouth shouts something slightly different, yet the receiving end can use algorithms to distinguish them all.

This brings two direct benefits:

  1. Greater range: Signal combining across multiple antennas dramatically improves reliability.
  2. Higher speeds: Theoretically, the 802.11n physical layer rate could hit 600 Mbps. Of course, you'll never actually hit that number in practice, given the overhead of medium access, interference, protocol headers... but compared to the previous 54 Mbps, this is a qualitative leap.

2. The Art of Packing: Packet Aggregation​

Besides stacking antennas at the physical layer, 802.11n also performed major surgery on the MAC layer. It's like going from sending letters one by one—where each envelope has its own cost—to sending a thick book, stuffing a hundred letters into a single package and sending it all at once.

This technique is called Packet Aggregation. It stuffs multiple application-layer packets into a single transmission frame. To support this mechanism, the 802.11e amendment introduced Block Acknowledgment (BA).

Previously, sending one packet required waiting for one ACK; sending ten packets meant waiting for ten ACKs. With BA, you can send a burst of packets, and the receiver replies with a single BA saying: "I got all ten of those." That dumb waiting interval in between is eliminated, and efficiency naturally goes up.

There are two aggregation methods—don't mix them up:

  • A-MSDU (Aggregated MAC Service Data Unit): This combines multiple MSDUs (i.e., data packets from upper layers) together, wrapping them in only a single MAC header. ⚠️ Note: In mac80211, A-MSDU is only supported in the receive direction; it is not supported in the transmit direction. Furthermore, it does not depend on the Block Ack mechanism we're about to discuss.
  • A-MPDU (Aggregated MAC Protocol Data Unit): This is the main character of this section. It bundles multiple complete MPDUs, each already wrapped in its own MAC header, into a single package. It must be used in conjunction with the Block Ack mechanism. Everything we discuss next is the story of A-MPDU.

3. The Handshake: Establishing a Block Ack Session​

You can't just enable Block Ack whenever you want; you have to go through a formal procedure. This process involves two parties: the initiator and the receiver. Each Block Ack session is bound to a specific TID (Traffic Identifier).

Step 1: Initiating the Request​

Everything starts with the rate control algorithm in the driver. Take the ath9k driver, for example. Its ath_tx_status() function (in drivers/net/wireless/ath/ath9k/rc.c) calls ieee80211_start_tx_ba_session() at the appropriate time.

This function does two things:

  1. Marks the state as HT_ADDBA_REQUESTED_MSK (pending request).
  2. Calls ieee80211_send_addba_request() to send an ADDBA Request frame.

This request frame carries two key parameters:

  • Buffer Size: The size of the reordering buffer. This value has an upper limit; it must not exceed 64K (see ieee80211_max_ampdu_length_exp). This parameter is packed into the capab member of struct addba_req and sent out.
  • TID: Identifies which traffic flow this is.

Step 2: The Countdown and Response​

Once the request is sent, the countdown begins. The time allowed for the peer to respond is 1 second (defined as ADDBA_RESP_INTERVAL). This is a hard rule.

If a full second passes on x86_64 without a response, the sta_addba_resp_timer_expired() callback is triggered. It will ruthlessly call ___ieee80211_stop_tx_ba_session(), nipping the session in the bud.

If the peer receives the ADDBA request, the flow looks like this:

  1. Reply with an ACK first: Just like all 802.11 frames, the rules must be followed.
  2. Process the request: It calls ieee80211_process_addba_request(). If all goes well, it sets its own state to HT_AGG_STATE_OPERATIONAL (ready to work).
  3. Send the ADDBA Response: It calls ieee80211_send_addba_resp() to tell the peer: "Deal, I got your parameters."
  4. Disable the timer: It calls del_timer_sync() to defuse that 1-second ticking time bomb.

Step 3: Sending Data and BAR​

Once the handshake is complete, the real action begins. The initiator sends a massive burst of data (an A-MPDU containing multiple MPDUs) roaring across the air. After finishing this burst, to confirm the receiver actually got it, it needs to send a Block Ack Request (BAR).

This is accomplished by calling the ieee80211_send_bar() method.

4. BAR: The Urgent Summons​

Block Ack Request (BAR) is a control frame. Its subtype is IEEE80211_STYPE_BACK_REQ. You can think of it as the initiator tapping the receiver on the shoulder and asking: "Did you actually get all of that massive chunk I just sent?"

The most important piece of information in this packet is the SSN (Start Sequence Number). It tells the receiver: "I want confirmation for that batch of packets starting from this sequence number." Upon receiving the BAR, the receiver checks its own ampdu buffer and reorders things if necessary.

Let's see what a BAR looks like (the struct ieee80211_bar structure in the kernel):

struct ieee80211_bar {
        __le16 frame_control;
        __le16 duration;
        __u8 ra[6];          /* 接收者地址 */
        __u8 ta[6];          /* 发送者地址 */
        __le16 control;      /* 包含 TID 等信息 */
        __le16 start_seq_num; /* 起始序列号 SSN */
} __packed;

(include/linux/ieee80211.h)

Here, the type in the frame control is IEEE80211_FTYPE_CTL, and the subtype is IEEE80211_STYPE_BACK_REQ. ra is the receiver's MAC address, and ta is the sender's. The TID is hidden inside the control field. And start_seq_num is naturally the SSN.

5. Block Ack: Two Confirmation Strategies​

After receiving the BAR, the receiver must reply with a Block Ack (BA). There are two strategies here, depending on the hardware capabilities and protocol configuration at the time:

  1. Immediate Block Ack: Reply with a BA immediately after receiving the BAR. No dilly-dallying, best performance, but demands high processing speed.
  2. Delayed Block Ack: This approach is more relaxed:
    • First, reply to the BAR with a normal ACK.
    • Wait a bit, finish processing, and then send the BA. This suits scenarios where software processing power is limited and a little buffer time is needed.

Of course, the BA frame itself also needs to be acknowledged.

The Curtain Falls: DELBA​

All good things must come to an end. When the initiator has no more data to send, or simply wants to end the session, it calls ieee80211_send_delba() to send a DELBA request. Upon receiving this, the peer processes it via ieee80211_process_delba() and tears down the Block Ack session. Either party can send a DELBA packet—whether initiator or receiver, anyone can leave the party whenever they want.

6. Limits and Boundaries​

Finally, there are a few hard boundaries you should keep in mind:

  • Maximum length: The maximum length of an A-MPDU is 65535 bytes.
  • Mode restrictions: Packet aggregation is only supported in AP mode and Managed mode (client). If you're using IBSS (Ad Hoc) mode, forget about it—the specification doesn't support it at all.

With this entire mechanism in place, wireless networks finally took on the true appearance of "high speed." But don't forget, this is only one set of rules on the highway. In the next section, we'll enter another, more complex topological world—Mesh Networking (802.11s). There, routing and transmission logic become intertwined, forming a much more complex web.