Many people, who know how “WiFi contention mechanism” works, ask that it is really viable to have two same-band radios in the same AP box.

So, you can run one 2.4Ghz and one 5Ghz radio in a single AP box but can you run two 5Ghz radios at the same time.

Here, “at the same” does not mean simultaneous Tx or Rx. One should Tx while the other is receiving. So, basically, they should “interfere” with each other because the Tx and Rx are so close, right? Even if they choose UNI-1 and UNI-2 Ext bands and try to move away from each other in the spectrum view, they should see the interference due to close proximity.

Theoretically, this can be solved via a physical – hardware based filter (band pass filter).

When there is a filter for a radio, that radio only hears what filter “filters” :) The rest is dropped.

So, let’s test if Aruba AP345 dual 5Ghz mode works as expected:

Here we have two SSIDs:

First SSID is 5Ghz1 and it is being broadcast on ch60E (80Mhz wide and it is on UNI2) and the other SSID is again named as 5Ghz1 but on ch104E (80Mhz and UNI2-Ext).

They are being broadcast via a single Aruba AP345. So, both radios on the AP are on 5Ghz, meaning no 2.4Ghz SSID on that AP.

Test Case 1 – Client1 Tx, Client2 Rx (iperf between clients) when they’re connected to the SAME 5Ghz radio.

If we connect two 2×2 11ac clients to the same radio, of course they will share the medium, right?

So, here are the results:

In this case, client one is connected to the 80Mhz SSID with max rate (867Mbps), the other is the same (867Mbps)

..and Client1 is sending traffic to Client2, so basically, they are sharing the air and they are getting around “half” of the total air bandwidth (we can say that 2-stream air bandwidth is around 600Mbps)

So, with air sharing, we’re processing around 300Mbps from each client.

What if we connect one client to radio1-5Ghz and the other client to radio2-5Ghz?

Test Case 2 – Client1 Tx, Client2 Rx (iperf between clients) when they’re connected to the different 5Ghz radios in the same AP.

If those radios are in the same box (very close proximity to each other), they should interfere with each other, so we should be able to get the results similar to test case 1 above, right?

Let’s test this:

In this test, clients are connected to different radios. Client1 is sending traffic to Client2. So, one radio is shouting at max, while the other is trying to listen.

So, they should interfere and we should see the below adverse effects, right?

1- The performance on the radios should be lower than expected due to excessive noise, so, bad client SNRs. So, low throughput numbers.

2- Transmitting radio is very close the receiving radio, so receiving radio should defer a lot, because of signal (or even energy) detect threshold(s), so receiving radio should suffer a lot.

So, we should see really low throughput numbers due to these effects, so, in the end, that should equal to (or maybe a bit better than) the case number 1 above (connecting to the same radio)

However, in reality, we’re not seeing the adverse effects explained above.

Transmitting radio is sending ~520Mbps data, while the other radio is receiving the same, without affecting each other too much.

So, that means that dual 5Ghz feature on Aruba AP345 just works. That means there is a very strong hardware based filtering between 5Ghz radios and those radios do not interfere with each other even while one radio doing Tx, while the other is doing Rx.

This is very rough test. No RF-cage, no special config tuning or so. I’ve seen that people are talking about Dual-5Ghz, so I grabbed an AP345 and did the test between my computer and my phone. AOS 8.4.0.1.

Summary

Aruba AP345 has the correct level of filtering between 5Ghz radios. When one WiFi client is sending data to another WiFi client (one radio Tx, the other radio Rx scenario), here are the results:

If the clients are connected to the same radio, throughput between clients: ~280Mbps

If the clients are connected to the different 5Ghz radios in the same AP, throughput between clients: ~520Mbps.

 

 

 

“It is very likely that a communication from a client which has 867Mbps rate could easily be “intercepted” or “lowered” by another client which is transmitting 6Mbps on the very same channel that the high-rate client operates. So, in this case, the high rate client or the AP will be affected by this low rate client, but the question is how much?”

Here are the details: Measuring the Effects of WiFi Low Rate Transmissions on the High Rate WiFi Traffic in the Same Frequency – updated Oct 2018

 

Oguzhan EREN, CWNE#266

Here we have a “Saturday Night Test!”

We were talking about 4 channel plan with OFDM modulation in 2,4Ghz band and trying to understand whether that is a reality or not.

We all know that the non-overlapping channels in 2,4Ghz band are 1,6 and 11; right?

However, if the numbering is consistent and correct between 2,4Ghz and 5Ghz, there are 4 channel-numbers between non-overlapping 5G channels but why is there 5 channel-numbers between non-overlapping 2,4Ghz channels?

For example, you have channel 36 and plus 4, you have channel 40 and this is non-overlapping with each other. So, if that is OFDM and we also have OFDM in 2,4Ghz; then the same should apply right?

So, if we have ch1 and plus4, the channel 5 should NOT overlap with the channel 1, if we use the exact the same channel spacing math between 2,4Ghz and 5Ghz.

So, what is the reality here?

Channel 1 and Channel 5 (like ch36 and ch40). Are they non-overlapping or no?

Let’s test this.

We should be careful, because there should not be any DSSS transmissions there (due to 11b client Tx or due to RTS/CTS to “protect” them because DSSS ruins this test as this is 22Mhz wide, not 20Mhz wide like OFDM Tx)

So, to be sure about zero DSSS Tx around, I removed all DSSS rates and started with 12Mbps as the basic rate, Tx rate and beacon rate. Yes there could be DSSS Tx in the area that I run these tests but I checked the air and saw that no STA around was doing DSSS.

So, here is my ultra basic test setup:

One client downloads from an AP, another client downloads from another AP, all are in the same RF domain, meaning they do hear each other very well.

So, in this case, if AP1 and AP2 both are on the same channel, that is called CCI, right? So, they share the air.

If they are on ch1 and ch11, that means they don’t contend for the medium, so they can use their “own” air bandwidth, right?

If they are on ch1 and ch6, and if they are placed apart from each other (o couple of meters) they won’t need to go into contention again, so they can again use their own air, right? –because ch1 and ch6 do not overlap, we all know this very well.

What if ch1 and ch5? With a couple of meters away from each other, will they contend for the medium?

Let’s test this with pure OFDM Tx.

 

 

With the above test scenario, I run these tests

• iPerf between clients, AP1 is on ch11, AP2 is on ch1
• iPerf between clients, AP1 is on ch6, AP2 is on ch1
• iPerf between clients, AP1 is on ch5, AP2 is on ch1
• iPerf between clients, AP1 is on ch4, AP2 is on ch1
• iPerf between clients, AP1 is on ch3, AP2 is on ch1
• iPerf between clients, AP1 is on ch2, AP2 is on ch1
• iPerf between clients, AP1 is on ch1, AP2 is on ch1

(Clients were 2×2 11ac clients, connected to the 2,4Ghz 11n radios, 20Mhz channel, with MCS15, 144Mbps rate, SGI, 64 QAM 5/6)

Here are the results:

So, we can clearly see that the non-overlapping channels give the best overall throughput between clients.

For example, if the AP1 is on Ch11 and the AP2 is on Ch1, then the average throughput between clients are (completely non-controlled environment, with lots of interfering APs and Clients around) 85,64Mbps.

When we see the result between clients, when the AP1 is on Ch6 and AP2 is on Ch1, that’s another non-overlapping scenario. The result is 78,96Mbps between clients.

However, we can clearly see that, Ch5 and Ch1 does also NOT overlap with the results similar to the other scenarios, like 11-1 and 6-1.

Let’s get closer to the AP2 Ch1. When we configure AP1 in Ch4, things start to get bad with around %50 throughput loss, due to contention between APs.

That’s why Ch4-Ch1 contention drops the performance to 41Mbps and it stays the same even with Ch1-Ch1 CCI contention, in which the performance is around 42Mbps.

Here is the spectrum output while the tests were running:

The above part is the ch6 – ch1 test, and the below is where ch6 stays:

So, the channel 6 with OFDM modulation is there, starts with 2427Mhz and ends with 2447Mhz.

..but where is channel 5? Here it is:

Channel 5 starts with 2422Mhz. Does it interfere with channel 1. Where does channel 1 ends? Any overlap. No, they don’t overlap with OFDM, as you can see from the above waterfall output.

Here is the channel 1 and it ends at the exact point that ch5 starts, like 5Ghz OFDM channels.

So, ch1 ends at 2422Mhz and ch5 starts at 2422Mhz, so they DON’T overlap and we can prove this via simple throughput runs between clients with ch1-ch6 pairs vs ch1-ch5 pairs.

 

When we are running enterprise or telco grade 802.11 networks in an high density indoor area, probably there are also some 3G or LTE indoor antennas broadcasting 3G or LTE signal in that area, alongside with the WLAN coverage.

However, there are two types of “disturbance” coming from nearby LTE radios to the WLAN devices.

• Disturbance from high level of RF energy hitting to the radio, so “desensing” it.
• Disturbance from a side products of the signals combined at the Rx

Let’s start from the first one. If the WLAN device’s Rx side is hit by high energy coming from a nearby LTE radio, the powerful signal can “desensitize” it, causing its AGC circuit to make the device less sensitive to the regular WLAN communication. So, that means low performance for WLAN.

When can this happen? What is the dangerous space between the high-power indoor/outdoor LTE e-node B and WLAN device? This “separation” should be more than 30-40 meters, if the WLAN Rx is not filtered correctly.

If, somehow, the amplitude of the LTE signal hits to WLAN equipment at -45 dbm or higher; the radio starts to suffer and shows some performance degregation, if used heavily.

If the incoming signal is around -15 dbm at the WLAN Rx, then the radio is completely blocked, no Tx or Rx is possible. It is interesting that the incoming signal’s frequency is NOT important here, the “desensitization” is happening because of the power, not because of the frequency.

So, the AP vendor should be using correct filters to block this high energy RF, BEFORE it hits to the AGC circuit. So, if you are using “filtered” AP, nearby high-power LTE transmitters won’t be able to degrage your performance, even if they are located as close as 1 meter. So, for this “high power nearby LTE transmitters” issue, the APs should be selected as “filtered” models, if there are strong LTE signals around. If there are only 802.11 signals around, like regular home WiFi or low-usage WiFi setup, non-filtered APs can also be used.

This above diagram is a basic representation of the radio, with correct filters in-place.

Let’s move onto the next “disturbance”. Side products or harmonics.

This is another effect that a WLAN Rx can receive from the nearby 3G/LTE stations.

For example, think about a 3G transmitter, which transmits ~1800Mhz (this is, lower frequency, hence F1 here) and ~2100Mhz (this is F2) at the same time. So, they produce harmonics and we can find this with 2xF2-F1 formula, which is (2 x 2100) – 1800 = 2400Mhz (Bingo!)

So, this is common problem for 3G operators using those frequencies together withing the same Tx chains.

This harmonics interference can be detected with an external spectrum analyzer:

Also, if the APs are spectrum analysis capable, they can also see this interference:

Swept spectrogram output of this harmonics is like below:

So, these interference does mainly affect 2.4Ghz band and less likely has an effect on 5Ghz band.

To mitigate these types of effects, mainly “high-power nearby signal” effect, it is better to use “filtered” APs at required locations.

With the introduction of 802.11ac, we met 80Mhz channels. It meant more data because more spectrum is utilized when a packet is being transmitted.

Of course, there are other consequences when using 80Mhz channels, such as being more prone to interference, less channels to use etc. However, what about the backward compatibility?

We know that still some devices out there using 20Mhz channels in 5Ghz band. Yes, these are legacy 802.11a devices. And also there are 40Mhz devices. And now we have 80Mhz client devices.

What will happen when there are three types of devices (20Mhz, 40Mhz and 80Mhz) connected to an AP which supports 80Mhz? How is backward compatibility working here?

Another question is about Co-Channel Interference. What will happen if there are two 80Mhz APs sharing the same 80Mhz portion of the spectrum? How are they handle the CCI issue?

So, the backward compatibility is solved nicely with 80Mhz channels. Every 80Mhz channel consists of sub 40 and 20Mhz channels.

For the example, the above image represents an 80Mhz channel. It consists of 4 blocks and each block is 20Mhz.

For example, let’s look at the lower portion of the spectrum in the 5Ghz band, which is UNII-1 band.

UNII-1 is clean from DFS and sometimes we are hit badly by weather RADARs, so sometimes it is better to stay on UNII-1. What is DFS and how is it being affected by RADARs? These could be the subjects of another blog post.

So, when we put 2 80Mhz APs in the same band, say, UNII-1, which has 4 x 20Mhz channels which are 36, 40, 44 and 48; two APs will cover the same spectrum in the entire UNII-1 band. Two APs will be broadcasting on 36+40+44+48.

However, automatically (based on the gear you are using), APs will select different 20Mhz and 40Mhz sub-portions despite their same 80Mhz channel.

Let’s look at the below image, again:

Assume that A is channel 36. B is channel 40. C is channel 44 and D is channel 48.

Your first 80Mhz AP is on A+B+C+D

And, your second 80Mhz is AP is also on the same band: A+B+C+D

However, according to your radio management mechanism that you use on your APs, they will be selecting different “sub”channels for the 40Mhz and 20Mhz operation.

For example, if you are a 20Mhz client, which sub-channel you’ll use on the first AP? Which sub-channel be used by the second AP? Of course, they will be selecting different channels for 20Mhz operation even though they are on the same 80Mhz channel. At the same time, they will be selecting different 40Mhz sub-channels.. However, the selected 40Mhz sub-portion, should include the 20Mhz subportion.

For example, the first AP is on A+B+C+D as 80Mhz channels.

“A” can be the 20Mhz channel. This will be used for beaconing, NAV, mgmt frames, 802.11a frames, all 20Mhz supported clients’ frames etc.

A+B can be the 40Mhz channel. This will be used for the 40Mhz clients. The 40Mhz portion should include the “A” here. So it must be A+B. For example, B+C portion cannot be used as the 40Mhz sub-portion. C+D cannot be the 40Mhz portion for this AP, as well.

On the other hand, the second AP will be selecting different 20Mhz (hence, 40Mhz) subportion.

For example, AP1 is on

• A+B+C+D as 80Mhz.
• A+B as 40Mhz.
• A as 20Mhz.

AP2 will select like:

• A+B+C+D as 80Mhz.
• C+D as 40Mhz.
• C as 20Mhz.

So, this will decrease the CCI within the ABCD (80Mhz) block and this will also provide simultaneous transmissions to different 20Mhz or 40Mhz channels by different APs. For example, given the channels selected above, AP1 will be communicating with a 20Mhz client on channel A, and at the same time, AP2 will be able to communicate another 20Mhz client on channel C.

So, 80Mhz channels also provides backward compatibility for older 20 or 40Mhz clients and, at the same time, the radio resource allocation mechanism are assigning different sub-channels to different APs, to utilize the air better.

When designing WiFi networks, everybody thinks about the “coverage” first.

Are you covering correctly? Yes. Then it is OK. If you need more data, more capacity, more speed; just add more APs.

It seems simple, but is is not so simple in the real world.

Also, I’m hearing such statements that “Our hall-placed APs were good at first but when many clients from different rooms connect to the same AP at the same time, the WiFi performance suffers”

Why is this the case? What is the missing point here?

It is “hidden node problem” and it is one of the highly under-estimated problems in the entire WiFi world today.

According to the simple rule of CSMA/CA mechanism used in 802.11, all stations should be able to hear each other. This is the rule.

 

Think about the station B is the Access Point, in the above diagram.

Station A can transmit data to the AP (station B) and the AP can transmit data to the station A.

On the other hand. Station C can transmit data to AP, and the AP can transmit data to the station C.

All seems correct, right? A can hear the AP, C can hear the AP; that means AP can cover the stations, so there shouldn’t be any problem.

However, we have a big problem here. The stations A and C, cannot hear each other. In other words, their transmissions cannot reach each other. So that’s a problem and this is called “Hidden Node Problem” because in our diagram, Client A and Client C are “hidden” from each other.

Why is this a problem?

CSMA/CA works like (simply) “if somebody is not transmitting, wait and still no one is transmitting, then you can transmit”.  So, it relies on Tx station’s own Rx to see if somebody is Txing or not. What if somebody is actually transmitting but the station cannot hear that? Of course it will transmit and it will cause a collision.

Collision means re-transmit, and re-transmit means lower speed transmission, and lower speed transmission means longer “duration” values for everybody out there as longer NAVs for all STAs, which means more waiting in the medium by everyone, which means less overall throughput from the air.

So, in short, in our WiFi cell design, all STAs should be able to hear each other to make WiFi work correctly and efficiently.

On the other hand, RTS/CTS mechanism could be utilized in hidden-node environments, in which, AP uses RTS and CTS frames to distribute NAV timers in the RF domain to inform STAs to wait for duration specified in the CTS frame.

As shown in the above diagram, RTS packet from the source is also used to distribute NAV timer to other and the CTS is also distributing another NAV timer which means everybody out there (either received RTS or CTS) will be waiting until NAV timer expires plus DIFS and then they will all go into contention window)

Of course there is a possibility that many clients try to send RTS at the same exact time. This is possible. However, in general, RTS CTS mechanism makes good job relieving hidden node issues.

As you can see from the above explanations, all WiFi channel access mechanism is based on the assumption that every STA hears all transmission in the RF domain. However, in the real world, unfortunately, many WiFi designs are based on “coverage” rather than “capacity” which means very large coverage areas which makes clients cannot hear each other, lowering overall performance of the cell.

Many WiFi-focused people have seen some disruptive non-WiFi interference on WiFi bands. Those can be on 2.4Ghz and 5Ghz but the 2.4Ghz is especially crowded in terms of both WiFi and non-WiFi energy levels on those bands.

Enterprise and Telco grade access points should be able to detect/understand and measure the energy levels, not only coming from WiFi based sources, but also non-WiFi based sources.

There can be numerous non-WiFi energy sources hitting to 2.4Ghz band, such as:

• Non-data-transmitting devices, such as Microwave ovens or other magnetron based devices.
• Data transmitting, in-band non-WiFi devices, such as video bridges.
• Data transmitting, out-of-band non-WiFi devices, such as LTE or 3G multi-band equipment, whose -probably- third harmonics hit 2.4Ghz WiFi band.

On the other hands, there are basically two types of Access Points, in the enterprise/telco market.

• Spectrum Capable Aps, which have integrated spectrum analyzer to see the raw energy in the environment.
• Non-spectrum capable Aps, which have no spectrum visibility for non-WiFi energy.

However, there is some confusion here. What are the capability levels that we can expect from APs?

• Capability Level1 – An AP which is doing basic WiFi stuff, but no capability to see non-WiFi energy on the channel. If the Ap is on channel1 and there is a non-WiFi energy on the same frequency, AP cannot see that energy, cannot report it, cannot change channels to jump to a “cleaner” channel.
• Capability Level2 – An AP which broadcast WiFi signal and sees the channel metrics including WiFi and non-WiFi energy levels on the channel it operates. If there is a non-WiFi energy on the channel, AP can see the existence of non-WiFi energy, can report the level the signal occupies in the given channel/spectrum space and the AP is capable of changing the channel to get better channel with less non-WiFi interference.
• Capability Level3 – An AP which broadcast WiFi signal and it has correct hardware/software components to see the actual FFT from the channel and it has correct algorithm to see duty cycle of the channel to understand (or tries to understand) the source of the signal whether it is coming from a microwave oven, or from a Bluetooth device or from a Video bridge etc. So, this type of APs can report the “reason” and “source” of the non-WiFi energy.

Some vendors are offering spectrum capable APs, which are on “Capability Level3” and offering non-spectrum capable APs which are on “Capability Level1”

On the other hand, some vendors are offer spectrum capable APs which are Level3 but offering non-spectrum capable APs, interestingly, which are on “Level2”

Now, let’s look at Aruba’s AP207 which does NOT support spectrum analysis capability and it is an entry-level AP.

We know that AP207 has no Level3, and we’ll try to test if AP207 has Capability Level1 or Level2.

For this testing, I used a non-WiFi signal generator from a brand called “Next” which is actually a video transmitter device works on 2.4Ghz band, without obeying any 802.11 transmission rules. No IFS, no contention window, no CSMA/CA, no back-off, no EDT, no NAV. This device just shouts out, without caring about anybody in the band.

I wanted to test Aruba AP207 for this. My aim was to understand which level it is on, in terms of spectrum visibility.

First test is to define the baseline.

Here is the empty channel values from a 3^rd party spectrum analyzer. Video bridge is not working and all 2.4Ghz spectrum seems OK.

Aruba AP207 broadcasts a test SSID, with regular load on the channel, and 207 reports that the below channel metrics:

Here, the AP207 reports the following values:

• %85 of the channel (in this instance, this is channel1) is free.
• Remaining %15 of the channel is used according to the below values:
• %2 of the channel is busy, because of this APs “transmitting” frames.
• %1 of the channel is consumed by non-WiFi or “cannot-be-decoded-WiFi” signals.
• %12 of the channel is consumed by this APs “receiving” frames. Actually, in this sampling interval, 14559 frame just have hit to the radio Rx, and 14366 of 14559 is actually destined for another WiFi STA in the same channel but also hit to this APs Rx. 193 frames out of 14559 destined for this AP and hit to this AP’s Rx.

Now, it is time to enable video bridge to block all the transmissions on channel 1.

As you can see from the photo above, video device is shouting like crazy in the channel 1..

Now, it is impossible to Tx any 802.11 frame on channel 1 because the WiFi STA tries to Tx but hits energy detect threshold (which is -62dbm), defers access and reports that the channel is busy. Because all of the trials are not successful and the transmitter cannot send even one 802.11 packet, it reports high channel utilization with all of them comes from a non-wifi source, which means the Rx cannot decode the incoming energy, so it is reported as non-WiFi. Sometimes, some distant WiFi transmissions which cannot be decoded at the Rx, can be reported as non-WiFi energy.

So, here are the channel metrics after the interferer device has been turned on:

As we can see from the above output, the Rx of the AP cannot receive any frame because of the high level of non-WiFi interference seen on the channel.

So, it reports zero Tx and zero Rx and high level of interference. So it can see the non-WiFi interference. It also reports high level of noise.

After a couple of seconds or minutes, the AP selects another channel and jumps to Channel 6, to broadcast its SSID in a fairly clean environment. So, the AP saw the non-WiFi interference and changed the channel to recover from that interference.

So, even though AP207 has no spectrum analysis capability, it saw the non-WiFi interference and managed to change the channel to recover itself. The “Reason: N” means that the AP has changed the channel because of “Noise Threshold Exceeded”. This confirms that AP207 is on the capability level2, based on the capability levels explained above.