This question is driven by Apple. They have a proprietary Wifi API (CoreWLAN) that takes two parameters when changing channels. The first is the channel number, the second is bandwidth. As far as this API is concerned, channel 52 has three permutations for my particular NIC: 52 @ 20 MHz, 52 @ 40 MHz, and 52 @ 80 MHz. I'm trying to figure out if the bandwidth parameter is really used or if Apple just designed a bad API.

This is a layer 1 question. It has nothing to do with joining a network, ad hoc networks, access points, or negotiations. I keep getting those types of answers elsewhere, so I thought I'd try to rule them out.

Here's the use case. I'm using Wireshark to put the NIC in monitor mode. The NIC is RECEIVING arbitrary data. It's not transmitting at all. And I'm changing channels using Apple's API.

Could you imagine a NIC actually putting a pass filter on a receiver in order to honor different bandwidths? If so, does it have advantages (say, filtering out wide band noise)?

Or is this just a wonky API designed by Apple?

  • \$\begingroup\$ WiFi channels are overlapping, so by setting the bandwidth to a narrower value, you reduce the interference with the adjacent channels, but also reducing it's capacity. You can see in your router settings (unless you cannot :) ), that you can select between 20MHz and 40MHz bandwidths. \$\endgroup\$
    – Eugene Sh.
    Jul 21, 2022 at 18:31
  • \$\begingroup\$ I am not sure why the pass filter is relevant here. If you're talking about stopping nonlinear interference/overdrive upstream of the LNA and mixer, there's no way a commercial product will have sharp enough filters. If you're talking about filtering after you've downmixed and recovered subcarriers, the filter is also irrelevant - you just disregard subcarriers not specified by the MCS. \$\endgroup\$
    – nanofarad
    Jul 21, 2022 at 18:42
  • \$\begingroup\$ Channel 52 is the edge of a band that can be 20, 40 or 80 MHz wide. Maybe I'm misunderstanding you but seems like the bandwidth setting does exactly what you'd expect? \$\endgroup\$ Jul 21, 2022 at 18:49
  • \$\begingroup\$ Thanks everyone. I can reword the question a bit. Is there any reason not to put the NIC into the widest bandwidth setting possible? It seems in this case 80MHz is likely to pick up the most frames (assuming a receiver operating at 80 MHz can pick up a signal from a transmitter sending a 20MHz signal) \$\endgroup\$
    – Brian
    Jul 21, 2022 at 19:21
  • \$\begingroup\$ @Brian The receiver is receiving the same narrowband preambles regardless, and drives its demodulator depending on the frequency specified in the preamble. Or, are you actively seeing frames not show up when your bandwidth is set to a narrow one? \$\endgroup\$
    – nanofarad
    Jul 21, 2022 at 19:30

3 Answers 3


It makes logical sense to put the bandwidth along with the channel selection, as logically a network administrator would consider the two when allocating channels in their wireless network environment. In considering this, the API isn't "wonky", but is rather designed to an intended audience that uses their WiFi card to negotiate with another station, so these parameters go together very logically.

Presumably, this will affect the bandwidth that the NIC is willing to use when joining a network and negotiating parameters (but I am not familiar with the process that two stations use to negotiate on HT vs VHT vs legacy, bandwidth, and MCS).

For each frame, the actual bandwidth is encoded as part of:

  • the VHT-SIG-A portion of the VHT preamble when dealing with 802.11ac
  • the HT-SIG portion of the HT preamble when dealing with 802.11n
  • irrelevant for pre-HT setups as 802.11n legacy (talking to a pre-802.11n station) and 802.11b/g stations only support 20 MHz

As for the remarks about filters, the bandwidth setting almost certainly doesn't affect reception performance. If you have "wide band noise" that's strong enough to cause a problem (such as analog intermodulation/gain compression in the LNA/mixer), then there's almost no way to get a sharp enough filter to cut off on a 20 MHz (vs 40 MHz) sharp edge off your specific channel of choice.

On the other hand, if you consider "wide band noise" when decoding OFDM subcarriers, the filter is again moot: if the header indicated 40 MHz, you're going to have to decode the subcarriers for 40 MHz, and if the header indicated 20 MHz, you just don't consider subcarriers outside the 20 MHz. No switchable filter required.


This is by design to increase thruput but a higher probability of noise means a higher SNR is required for error-free tolerance. It is called channel-bonding.

Channel bonding is a practice commonly used in IEEE 802.11 implementations in which two adjacent channels within a given frequency band are combined to increase throughput between two or more wireless devices. (Google)

Filtering is not an option but bonding the channels is an option if the sender sees that communication errors, then it will downshift the data rate and/or down-shuft the channel bonding. In the noisiest carrier situations from multipath echoes etc , the best data rate error-free will the lowest b data rate 11 Mbps in 2.4 GHz. While if echos are weak but signal is strong, the highest data rate 5G band can be supported, but that requires a much stronger signal.

enter image description here (1)


Does a receiver have the concept of bandwidth?

Always. There's nothing to be done in RF without bandwidth. It's a fundamental concept in RF engineering.

What's perhaps new to you is that in modern Wifi, bandwidth is configurable. It was always there, but in the early days of Wifi, it was fixed in the spec, and not something a user could configure. The newest standards make this flexible, and a network admin can choose the channel [band]width according to the results of network planning.

Moreover, it's not that only the receiver has a set bandwidth. The transmitter does too! The receiver bandwidth generally has to be at least as wide as the widest transmitter bandwidth. This may be exposed in APIs in a variety of ways, since Wifi has backwards-compatible negotiation between the nodes. So, if a node doesn't support wide channels, it will still be heard by nodes that are configured to use a wider channel.

They have a proprietary Wifi API (CoreWLAN) that takes two parameters when changing channels. The first is the channel number, the second is bandwidth.

Their API may be proprietary, but there's nothing too special about channel bandwidths.

In modern WiFi, channels have variable bandwidths.

Thus, the channel number alone is not enough to provide the configuration of the transceiver, since it's just the frequency part of the spec. Channel number and bandwidth are both properties of the channel. One determines the frequency, another bandwidth. Both are required to fully specify the channel used.

Could you imagine a NIC actually putting a pass filter on a receiver in order to honor different bandwidths?

Nothing to imagine here. It's part of the spec. In older WiFi specs, the channel width was fixed. So it was still there, and the transmitter and receiver still had appropriate filters to keep the channel's width appropriate. It's just that now it's a value you can configure.

And the channel bandwidth ultimately determines the maximum transfer rate. In ideal conditions, narrower channels are slower, proportionally to the decrease in bandwidth. But you can put more channels in the adjacent areas then. So it's a tradeoff. And interference may effectively make a narrower channel deal with fewer retransmissions and perform better.

For sniffing, you need to configure the receiver for the appropriate channel width in use in the network you're listening to. Both the channel number and channel width will be configured in the access points, and the sniffer has to follow at least the channel number. For passive listening, the device may end up ignoring the channel width. You'd have to experiment with the particular Apple device and see what channel bandwidth settings make it work with which actual channel widths set up on the network.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.