Follow me:

Dynamic Bandwidth Operation

Dynamic bandwidth operation occurs when a transmitter attempts to acquire the medium for a bonded channel but is only cleared to use a smaller channel width.

For example, let’s consider an access point configured to serve devices with a 40 MHz channel width. A device would transmit an RTS for 40 MHz but the receiver (the AP) determines that only a 20 MHz channel can be used.

Dynamic bandwidth operation utilizes Request to Send (RTS) and Clear to Send (CTS) frames.

802.11 has used RTS and CTS frames to clear the medium for transmissions and was typically used for hidden nodes. Every device, whether 802.11a/n/ac, was able to understand these frames and set their NAV based on the duration field. Additionally, the RTS and CTS frames were transmitted at lower data ratets.

Then bonded channels came along. How would an 802.11a device understand another device that wanted to utilize a 40 MHz, 80 MHz, or 160 MHz channel width?

A non-HT duplicate frame was transmitted at 802.11a PHY for all devices to hear and set their NAV.

In 802.11ac, duplicate frames is used for bandwidth signaling. The RTS and CTS frames work to clear the channel that will be used by a transmitter.

For example, I’m using channel 36 at 80 MHz wide and my primary channel is 36. An RTS would be duplicated on each of the 20 MHz channels, channel 40, 44, and 48. That is three additional RTS frames. This is to indicate the device would like to transmit using 80 MHz channel width.

The receiver (AP in this case) would perform clear channel assessment (CCA) and send CTS frames for channels that are idle. If a channel is determined to be busy, then a CTS is not sent for that channel.

Acquiring 80 MHz Channel

Acquiring 40 MHz channel instead

The Individual/Group bit would be set to 1 in the TA field which would make the address a bandwidth signaling transmitter address.

I wanted to attempt to capture the non-HT duplicate frames. In my lab, I utilized two Ekahau Sidekicks on two separate laptops. Using Ekahau Capture, one Sidekick was set to capture on channel 149 and 153. The other on channel 157 and 161.

Using Wireshark, I merged the two pcap files. Attached is what I was able to grab. Did I manage to capture the non-HT duplicate frames? I’m not sure. It’s the same duration, sent at a lower data rate, but I don’t see that the individual/group bit set to 1 in the TA field. What do you think?

Resources

Join Clear To Send

Come join the Clear To Send community.

Powered by ConvertKit
Hosted by
Rowell

Rowell, CWNE #210, is a network engineer in Higher-Ed. He enjoys working with wireless networking technologies and loves to share and engage with the community. You can connect with him on Twitter, LinkedIn, and Facebook.

Join the discussion

This site uses Akismet to reduce spam. Learn how your comment data is processed.

2 comments
  • Thanks for your post. Looking at the transmit address of the RTS, it is not a BW signaling TA..maybe this transmission was not using this feature (?)…when i read the current version of the 802.11-2016 standard, it is mandatory for RTS which are sent at higher bandwidths..is there a way that this has to be enabled somewhere?..

  • adding another point.. since the primary channel is 149 ( i presume).. since you have captured RTS/CTS at legacy rates but going between the same 2 units, i think the RTS/CTS captured on non-primary 20 MHz is all confirming that you have captured 4 non-HT duplicate transmissions of RTS/CTS..most likely, the followup data was in 80 MHz (?) ..

More from this show

Episode 242