Atheros Fast-Frames Support


Atheros Fast-Frames support is a Vendor specific extension which concatenates two frames into a single 802.11 MPDU.

It's negotiated as part of the beacon IE and station probe request (TODO: add exactly what).

This was done to mitigate the interframe spacing issue and squeeze some further performance out of the link. Instead of having to do DIFS and exponential backoff on every frame, the fast-frames method would only do it for every other frame. Ie, it would attempt to form an aggregate and then burst that out as one frame, with only one DIFS and back-off period.

For a good set of example timing diagrams, take a look at this:

Since it's transmitted as a single large frame, there's also only a single ACK. So either both frames are transmitted successfully or both are considered as failed.


The net80211 layer intercepts frames destined for a fast-frame capable node and throws them on a per-node, per-AC staging queue.

If a second frame comes in soon enough, it's concatenated with the first frame and has some fast-frames header glue added before it's pushed up to the driver to encapsulate.

Since it's just concatenating two frames together, they must be to the same destination station. Fast-frame aggregation doesn't occur to two different stations in a single aggregate frame.

The fast-frame format is just an 802.3 frame with some specific Atheros-isms:

There's also some rounding/alignment padding going on.

Please see ieee80211_ff_encap() for more details.


The fast frames implementation is in sys/net80211/ieee80211_superg.[ch].

Any driver which supports transmitting and receiving frames up to 3066 bytes (and I'd say a bit more for things like 4-address format support.) Currently this is just ath(4), but I'm sure other drivers support it.

Frame decapsulation is done via ieee80211_ff_decap().

Frame encapsulation is done via ieee80211_ff_encap().

The driver is responsible for calling ieee80211_ff_age() and ieee80211_ff_flush() periodically to ensure that frames on the staging queue do get purged.


Since the aggregation is done in net80211, you can use wlanstats to see if this is occuring:

$ wlanstats -i wlan0 | grep fast
1404337       fast frames decap'd
854866        fast frames encap'd for tx


WiFi/FastFrames (last edited 2018-04-05T23:11:48+0000 by MateuszPiotrowski)