Yazar arşivleri: Oguzhan Eren

Dual 5Ghz Performance Test with Aruba AP345

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:

spectrum-1

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:

test-1-same-radio

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:

test-2-diff-radios-

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.

 

 

 

Measuring the Effects of WiFi Low Rate Transmissions on the High Rate WiFi Traffic in the Same Frequency

“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

4 Channel Plan with OFDM. An ACI Analysis.

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.

 

Screen Shot 2018-07-15 at 15.30.41

 

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:

Screen Shot 2018-07-15 at 15.51.07

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:

spectrum1

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

ch6

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

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

ch5

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.

ch1

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.

 

What are the “DFS” Channels and how are they dealing with RADAR systems?

5Ghz band is huge spectrum. However, there is a one big issue with this channel plan: DFS Channels.

DFS stands for “Dynamic Frequency Selection” and if your want to use some channels in the 5Ghz band, you should obey DFS rules.

DFS channels are used by some military and civilian RADAR systems and WiFi should be shut itself off, immediately after it detects the presence of RADAR pulses. So, if an AP has no RADAR detection capabilities, cannot operate in DFS channels.

Why are we dealing with this? Are there any non-DFS frequencies? Yes, there are.

For example, the below chart shows the band plan (5Ghz, ETSI) including DFS channels.

graphic-80211-acChannels-all

 

Let’s remove the DFS channels, and make them grey-out:

 

graphic-80211-acChannels-noDFS

 

Oh! We lost nearly all our space, right? We only have some indoor channels with limited power levels, no outdoor channels and very limited spectrum to use (only 80Mhz total)

So, this non-DFS area tells us that we MUST use DFS channels and we need to understand DFS rules.

What are the DFS rules? Where are they written?

For ETSI regulatory domain that I’m working in, these details are writting in the document called “ETSI EN 301 893 v1.8.1 (2015-03)” document. (I’m not sure if there are updated version of this doc)

Link to the original document:  http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.08.01_60/en_301893v010801p.pdf

According to this document, the section 4.7 states the details about the DFS operation, such as:

  • There should be “channel availability check” before attempting the first transmission on the channel. CAC is 60 seconds but 10 minutes (for frequencies between 5600-5650Mhz). So, APs should wait first, then if there is no RADAR transmission heard on the channel for at least 60 seconds or 10 minutes, then start transmitting.
  • The device may conduct off-channel scanning to understand the presence of RADAR signals, these off-channel scannings should last minimum 6 minutes or 1 hour for frequencies between 5600-5650Mhz.
  • If RADAR is seen in a channel, no more Tx there, in the next 30 minutes.
  • If RADAR is seen in a channel, the channel should be emptied in max 10 seconds.
  • During these 10 second channel move time, total Tx duration should not last more than 1 seconds.

Screen Shot 2017-12-07 at 18.21.52

If every WLAN device obeys these rules, then RADAR operators will be happy, but why?

Here is a civilian weather radar output for Istanbul, Turkey. This is to see rain, snow etc. Meteorological Institutions are using these RADARs to detect atmospheric events in an area. So, for the below image, we can see some rain in the south of Istanbul and some other areas as well. This is a regular output for a rainy day(s):

ist-weather-radar

However, what about the below image for Ankara?

ankara-weather-radar

What are those straight lines nearly around the top right of the image. Clouds with rain? Looks unnatural, right?

These are some WiFi signals captured by Ankara RADAR, probably coming from in the middle of the city. RADARs are using very very high gain antennas and they can pick up your very weak WiFi transmission. So, your WiFi transmission, if you do not obey DFS rules, literally blinds the RADAR and it cannot see the atmosphere, it cannot work as expected.

This is the critical point about DFS and we should all know DFS and its rules, to be careful about that.

 

 

What is “Cellular Coexistence” and “Filtering” for 802.11 Networks?

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.

Screen Shot 2017-12-07 at 16.11.26

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:

interference seen with external spectrum analyser

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

interference seen by aruba ap

Swept spectrogram output of this harmonics is like below:

cellular interferenc hit

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.

80Mhz Channels in 802.11ac and the “Backward Compatibility”

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.

Screen Shot 2017-12-07 at 12.12.25

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:

Screen Shot 2017-12-07 at 12.12.25

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.

What is “Hidden Node Problem” and why is it a critical thing for 802.11 networks?

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.

hidden-node

 

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.

35640-RTS-CTS_Handshake

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.