The Question is under what conditions would one be able to capture frame bursting in the act?
and if anyone has packet captures to share, they would be welcome.
according to the release notes for HM6.1r5
"Frame Burst Mode: The Frame Burst mode allows a device to transmit a series of frames in rapid sequence. This differs from frame aggregation in that frame aggregation encapsulates multiple subframes within an aggregate frame, whereas a frame burst consists of multiple individual frames (and their ACK responses) separated by a SIFS (short interframe space). A SIFS is a very short period of time normally reserved for separating a data frame from its immediate control frames, such as the ACK (acknowledgment) frame. Normally, individual frames are separated from their respective control frames by a SIFS, but the individual data frames are separated by a full contention window consisting of a clear channel assessment, a random backoff time, and a DCF interframe space (DIFS). When you enable Frame Burst, the access point just uses a SIFS to separate data frames, thereby increasing data transmission efficiency, which results in higher throughput.
Frame Burst functionality is available in all radio modes."
So I set out to see if I could capture such a transaction.
These seem to be the requirements for Frame Bursting to exist
The AP and STA must be WMM compatible
The "Application" would need to mark the traffic and the STA would have to indicate that it has more then one frame to send or a WMM-PS station would have indicate that it has or would like to receive multiple frames to get or send.
These frames would have to be in ACs that are configured for TXOP values.
Evidence of Frame Bursting:
The frames that do all this work are QoS Data frames containing a QoS control field.
Frames from AP to STA would contain TXOP [transmit opportunity] Limit value and ESOP [end of service period] value.
Frames from STA to AP would have TXOP request value
the other possibilities would be to see
Frames from STA to AP indicating Queue size or how much traffic is buffered at the STA, thus allowing the AP to issue a TXOP.
Frames from AP to STA indicating PS Buffer state, basically informing the STA that frames for an AC are buffered at the AP.
According to the CWAP in the real would you would rarely if ever see these frames, because a STA would never really have more then one frame ready to transfer at a time.
I have done multiple captures with multiple WMM clients and applications.
to mark frames as voice and video ACs, I used openphone and xmeeting
I attempted to use skype and facetime, but they mark frames as best effort, which has a TXOP of 0. I also attempted to change the TXOP of the best effort AC [on the AP WMM Qos] to see if I could create a Frame Bursting event, but this was to no avail.
these are the only QoS control fields I am seeing other then corrupted frames
This is from Intel STA [openphone] AP is transmitter to Apple Imac [xmeeting]
This is from intel to the AP230
So in order to prove frame bursting exists
one would have to capture frames that had a TXOP Limit value greater then 0, TXOP request value greater the 0, PS buffer state greater then 0 followed by a TXOP, or Queue size greater then 0 followed by a TXOP.
Anyone able to capture such frames and willing to post them, it would be much appreciated.
On a side note to this adventure:
I discovered my intel STA sending CF-END frames, which are not supposed to exist, but apparently do. The FCS values of CF-END frames were all correct.
These frames might indicate that the STA is reserving more airtime then is needed to transmit it's frame. It's a strange one, since these are designed for PCF [Point Coordination Function] and yet they exist.