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

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

Portable network testing tools

The market for small affordable and portable network testing tools is starting to heat up.

Network test tools were long the domain of Fluke (now NetScout) and not long ago they launched a tool called the LinkSprinter. The LinkSprinter brought a suite of tests for the network into a small package at an affordable price. Tying that to a central cloud service that allowed for easy remote diagnostics of network ports. Not content with letting the LinkSprinter have the market to itself, another tool has recently entered a beta testing.


LinkSprinter 300 and Netool

LinkSprinter 300 and Netool

Netool.io has released Netool, a device similar to the LinkSprinter, but differs in a few ways. Netool promises flexibility that the might appeal in the software driven world of today. Netool offers the ability to test IP information obtained from the network port, as well as switch side information and ping tests which are very similar to the features of the LinkSprinter, while coming at a lower price point. Couple that with a slick mobile app that provides easy sharing of the testing information and Netool shows plenty of promise.

My beta unit had no issues with upgrading to the latest software, which is one of the promises of the Netool – that is easily updated and upgraded as it is built on top of a highly customized version of linux.

I’m looking forward to new tests being added to the suite of tests already available, and with the unit having a rechargeable battery built-in is in my opinion a cleaner solution than the AA powered LinkSprinter. However, the LinkSpinter has a couple of features that Netool can’t replicate without a hardware update which makes the LinkSprinter stand out.

Coming from a Wi-Fi view of the network, means that I have different requirements for network testing than a traditional route and switch guy might be looking for. PoE tests are one of those tests that is a must have for me and unfortunately Netool doesn’t support PoE testing, but the LinkSprinter does. Another nice feature of the LinkSprinter is the on-device notification of test status via simple LED lights on the unit. To view this information on the Netool requires using the app on my phone (although that is not a deal breaker).

Netool does include a handy feature to see what tagged VLANs are on the network port, which it seems to do by listening to traffic on the port. It’s not perfect since if there is no traffic on that VLAN when the test is running it won’t list that VLAN as being on the port. In my mind, Aerohive had a great VLAN test available in HiveManager (sadly it’s only available in the CLI these days) called VLAN Probe. It worked by sending DHCP “discover” messages on specified VLANs and listening to the returning “offer” message to able to display the DHCP range on the VLAN. It kind of showed the results of two tests. One, that traffic was allowed on that VLAN and two, that the DHCP scope was correct. Two birds with one stone! With WLANs that use local bridging of network traffic, these kinds of tests are very handy. Hopefully either NetScout or Netool will be able to replicate a test like Aerohive’s VLAN Probe, in a way that is configurable for the VLANs that would need to be tested at that site.

All in all, these kinds of network testing tools now being more affordable to the masses is a great thing, and hopefully the competition can spur new and innovative ways to test the networks of the future.


Yes, I finally did it!

After being told lots of times that I should start a blog, and watching lots of my friends in the Wi-Fi community start their own blogs, I decided to make time to build a blog and to try and write some content that might interest some people. So here it is.

For those who don’t know me, you can see who I am here.

Hopefully this will be a long journey, and not just another one of those blogs that never gets updated. Fingers crossed.


© 2017 802.11du

Theme by Anders NorenUp ↑