Wi-Fi thoughts from the under side of the world

Category: Wi-Fi

Client Induced Co-Channel Interference

In the previous post, I discussed AP Induced Co-Channel Interference (CCI) and what tools we have available on the infrastructure side to combat it. In this post, I will discuss what Client Induced CCI (CI-CCI) is and what tools we have available to reduce its effect on network performance.

Client Induced CCI, is where there are two APs that share the channel, but are separated enough (using some of the tools in the last post) that the APs themselves do not cause CCI between each other, but where there are clients which join the AP cells together. This is similar to the “Hidden AP” problem described by GT Hill.

How do clients join AP cells together?


No CCI. Both APs on channel 36

No CCI. Both APs on channel 36

As you can see in the above illustration, the APs are both using channel 36 and the outer rings of the APs coverage are the AP Rx sensitivity limits for 6Mbps (the data rate for which the PLCP preamble and  header are sent on 5GHz). These APs are not causing CCI between themselves.


Client1 connected to AP1

Now suppose a client (Client1) connects to AP1 near the edge of the AP1’s cell. The image above shows the client device coverage pattern when connected to AP1. As you can see the client device coverage pattern now overlaps with some of AP2’s coverage pattern. The amount of channel overlap, will depend on how much “effective distance” there is between the two cells, and the Tx power of the client. In the image above, the AP Tx power has been designed to match mobile devices Tx power, however, the laptop uses higher Tx power than a mobile device. This causes an increased channel overlap between the two cells. This one client is “joining” the two channel 36 cells together, but the APs still cannot hear each other.


Client1 on AP1, causing CCI with 3 Clients from AP2

Client1 on AP1, causing CCI with 3 Clients from AP2

Let’s add some clients to AP2. In the above image, the clients that are coloured orange are inside the coverage pattern of the Client1 on AP1. This will cause those clients to not be able to transmit or receive whilst Client1 is transmitting. In this way Client1 has joined AP1 and AP2 cells together, which could bring the total throughput of the combined cells down, through increased contention and retransmissions.

Since AP2 does not hear Client1, AP2 can transmit at the same time as Client1, which could cause frame corruption if the intended receiver is one of the clients covered by the overlapping coverage area (clients coloured orange).


What can be done to reduce the effects of CI-CCI?

In the last post we discussed the tools available for the infrastructure and you could use those tools to increase the “effective distance” between same channel APs to reduce the effects of the clients on CCI. But none of those tools are regularly available on client devices and so what can you do from the client perspective? Some clients have the ability to adjust Tx output power in their drivers, but in today’s life of mobile devices, most of these devices don’t have that sort of granular control. Let’s discuss what we can do across the board to try and address the CI-CCI issue:

  1. RTS/CTS
  2. Modifying data rates
  3. 802.11h
  4. 802.11k



RTS/CTS works when a client prefixes its frame transmission with the RTS/CTS exchange. Thereby notifying clients in its cell that the client is about to transmit. More details about RTS/CTS can be read here on the excellent site from Rasika Nayanajith. Client configuration control of RTS/CTS is rare, although Apple’s iOS makes use of it. Will RTS/CTS fix the issues with CI-CCI? Let’s look at its effectiveness.

In GT Hill’s video, he mentions that when the traffic is downstream to the client (the AP is initiating the RTS/CTS) that the CTS response from the client is able to notify AP2 of the pending transmission, but with the greater separation of cells in our example this does not happen since Client1’s coverage doesn’t reach AP2. Which means that RTS/CTS for downstream traffic may not help too much.

With a greater percentage of the traffic on networks these days being upstream traffic, we also need to look at the impact of using RTS/CTS when the client needs to transmit a frame (upstream traffic).


(1) Client1 sends RTS


(2) AP1 sends CTS

In the images above, the RTS is sent by Client1 to AP1 (1). The RTS is only heard by those devices in Client1’s coverage area (including AP1). AP1 then sends out the CTS (2) and the CTS is only heard by the clients in the coverage area for AP1, as there is no overlap in the AP coverage areas. The only AP2 clients that will know to be idle would be the clients in the overlapping coverage area of AP2 and Client1 (light blue area) due to the RTS being received. An AP2 transmission to one of the orange coloured clients could result in a corrupt frame if Client1 is transmitting at the same time.

You can see that RTS/CTS will only have limited impact, and that impact is dependent on how much client induced cell overlap there is.


Modifying data rates

Adjusting the Minimum Basic Rate to 24Mbps

Adjusting the Minimum Basic Rate to 24Mbps

Besides being a way to reduce overhead on the network caused by management and control traffic, data rates also affect client associations. If a client is unable to demodulate the minimum basic rate (MBR) they are unable to associate to the AP. So if you raised the MBR, the client needs to remain closer to the AP in order to associate. In the image above, the MBR has be raised to 24Mbps on AP1 (shown by the inner circle on AP1). You can see that in order for the client to associate it has to be within the 24Mbps coverage area. Client1’s coverage area is still the same, but now the client is further from AP2 and its clients, and so is not joining the two cells together. Thereby eliminating CI-CCI. This can be difficult to attain complete separation of the clients and APs, and it is likely that some CI-CCI still exists. It is also worth noting that modifying the data rates does not have any effect on AP Induced CCI due to the PLCP preamble and header being sent at the band specific lowest data rates (1Mbps on 2.4GHz, 6Mbps on 5GHz).



802.11h includes a feature called Transmit Power Control (TPC). TPC is intended to reduce interference from WLANs to satellite services by reducing the radio transmit power WLAN devices use. TPC also can be used to manage the power consumption of client devices and the range between APs and clients. When clients associate/reassociate to an AP, the client provides the AP with its minimum and maximum transmit power capability for the current channel using a Power Capability information element.

Power Constraint IE & TPC IE

Power Constraint IE & TPC IE

TPC allows the AP to control the transmit power of its clients by sending a management frame containing a Power Constraint information element (IE). The contents of this IE (along with the Country IE) provide supported clients with the local maximum transmit power level at which they can transmit.

From the 802.11 Standard: “The local maximum transmit power for a channel is thus defined as the maximum transmit power level specified for the channel in the Country element minus the local power constraint specified for the channel (from the MIB) in the Power Constraint element.”

An AP may also use the minimum and maximum transmit power capability of associated clients as an input into the algorithm used to determine the local transmit power constraint for any BSS it maintains.

Client1 on AP1, causing CCI with 3 Clients from AP2

Without Client TPC

With Client TPC

With Client TPC

By using the Power Constraint IE (as you can see in the above images), it is possible for the infrastructure to reduce the effects of CI-CCI since the client is not transmitting at a power level greater than what the network is design for.

802.11h only applies to DFS-compliant devices in the 5GHz band and by no means all 802.11 devices are 802.11h-capable, and not all infrastructure vendors allow the configuration of the Power Constraint IE. This means that support may be limited in your environment.



With 802.11k, an AP can advertise a transmit power constraint lower than the regulatory limit in the same way as 802.11h. The 802.11k Transmit Power Control and link reports also allows a client to discover how its signal is heard by the access point, including a link margin figure, so it can reduce transmit power levels if appropriate. 802.11k is dual band, unlike 802.11h, and is able to control the client transmit power level on both 2.4GHz and 5GHz bands.

The issue with 802.11k is client support – not all devices support this amendment.



As you can see CCI is a complex issue that is not only caused by APs but by clients as well. Eliminating CCI is very difficult in 5GHz and near impossible in 2.4GHz. There are many tools available in WLAN infrastructure to assist in reducing the effects of both types of CCI, all of which have pros and cons which need to weighed up as to whether of not you should employ them in your network.



Further reading:

TPC: IEEE 802.11™-2012, Section 10.8

Power Constraint IE: IEEE 802.11™-2012, Section

AP Induced Co-Channel Interference

There has been lots of discussion in blogs and on Twitter about Co-Channel Interference (CCI) between APs and adjusting data rates. However, I haven’t seen much about Client Induced CCI (CI-CCI). Devin Akin briefly mentioned it in his blog about adjusting data rates and GT Hill brought it up with the idea of the “Hidden AP“, but other than that I wasn’t able to find a great deal of info about CI-CCI. So over the next two posts I want to illustrate that there is more to CCI than just APs, and what we can do about it.

In this first post I want to make sure everyone is on the same page around AP induced CCI, that is CCI caused by APs.

Co-Channel Interference is where 2 (or more) APs share the same RF spectrum. In other words, when there at least two APs that are using the same channel and where they can “hear” each other so that the effect is that their cells “join”. Like in the image below where the APs are still able decode the Preamble and PLCP header of the other AP. If you want to read about the data rates used by the preamble and PLCP header read this.


AP Induced Co-Channel Interference. Both APs are on the same channel.


Now that we have cleared up what CCI is, how do we solve it? The basics are that you move APs further apart. But there are many ways to increase the “effective distance” between the APs:

  1. Physically make the distance between the APs further
  2. Increase the attenuation between the APs
  3. Reduce AP Tx power
  4. Rx sensitive tuning (CSR, RX-SOP)
  5. Narrower channels
  6. Directional antennas

Let’s look at those one by one.


Moving APs further apart

Physical distance is most obvious method. However, this can be difficult given how far away the data rates used by the preamble and PLCP header can be decoded by today’s APs. The physical properties of the facility may also make that impossible.


Increase attenuation between the APs

It may be possible to relocate the APs to locations that allow the natural attenuation (walls and other obstacles) of the facility to make the APs to appear further apart by attenuating the signal and therefore not be able to “hear” each other.


Reduce AP Tx power

Turning down Tx power results in a weaker signal at the other AP, which may be below the decodable SNR for that particular data rate at the other AP. But there is a point in which you can go to far. If the AP Tx power is turned down to far to reduce CCI it could reduce the ability of clients on the edge of the cell to achieve acceptable throughout due to a drop in MCS caused by the lower SNR. In a lightly used network, this drop in throughput might not be outweighed by the gains from the reduced CCI. Best practice is to make sure you have a balanced link between the AP and Clients. Each client device type typically uses different Tx power, so obtaining a balanced link between the AP and all clients is not likely. Most designs are done by matching the AP Tx power with the weakest client. However, even at low Tx power, today’s APs can decode the preamble and PLCP header at a large distance.


Rx Sensitivity Tuning

Some vendors have features (RX-SOP, CSR, etc) that make the radio deaf beyond a certain threshold. This could reduce the effects of CCI as the radio will not ever enter the 802.11 state machine as the radio will drop the frame due to the threshold limit and such be able to transmit even in the presence of the another AP on the same channel. These types of  features need to be used with care, as it can prevent the AP from hearing necessary frames if the thresholds are not set correctly.


Narrower channels

Moving to narrower channel widths allows for more separation in the contention domain (and therefore more channel reuse) as there as more separate RF domains to choose from. However, even with lots of channels, in scenarios like VHD there still aren’t enough channels to eliminate CCI, and even environments like outdoor yards and large open plan offices can also make this challenging. With the 2.4GHz band it is highly unlikely that you will be able to completely remove CCI, due to the limited channel availability.


Directional antennas

The use of directional antennas allow for shaping of the RF propagation. By directing the RF energy towards the users, it may also be directed away from neighbouring APs. But be careful as APs can also hear better in the direction of the antenna. This could lead to APs hearing another AP on the same channel even better, or at a greater distance.



So, you can see that there are lots of options when it comes to APs and reducing the impact of CCI, but there is no silver bullet to completely remove CCI in most environments. One big problem still remains – Clients. The next blog post will discuss Client Induced Co-Channel Interference.



Further Reading on Rx Sensitivity Tuning:

Aruba Cell Size Reduction: ArubaOS User Guide. Search for “Reduce Cell Size”

Cisco RX-SOP: No Strings Attached Show

© 2019 802.11du

Theme by Anders NorenUp ↑