Wi-Fi thoughts from the under side of the world

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


  1. Have you done any comparisons of a network using 80/40/20 MHz channels? Do you see increased client CCI on the 80 MHz channel?
    I routinely remove the 40 MHz channels from WLANs and configure them as 20 MHz channels and the network works much better. These networks were designed for 5Ghz, of course.
    What are your thoughts?

    • Tim,
      There are two issues at play with the wider channels.
      1. The same Tx power is split over more subcarriers (as you increase channel width), which will mean lower SNR at the receiver and have a lower chance of client CCI. (Wider channels have reduced range)
      2. Less channels to choose from the wider you go. Having more channels will allow for greater separation between same channel APs, and so will also have greater separation of those clients on those same channel APs.
      In my mind the lack of channels far outweighs the benefits of the reduced range.

      I design for 20MHz channels, and if I can go to 40MHz without introducing CCI (both AP and Client induced) then that’s a bonus.

Leave a Reply

Your email address will not be published.


© 2018 802.11du

Theme by Anders NorenUp ↑