Forum

I've got to go with GT on this one...

Omni-Directionals are a pain to design around. Yes, I know vendors like them to keep the SKU counts low.

Some vendor's Location Tracking algorithms *require* Omni's.

But the number one problem I find in my consulting gigs is 'Contention Domains' - devices, both APs and Clients, that can 'see' each other on the same channel and 'play nice' - but that process really degrades throughput.

Most omni antennas have a tendency to bleed floor to floor, increasing the size of the contention (collision) domains and lowering overall throughput.

Adding more access points, exacerbates the problem even more.

I like to 'control' where the RF from each Access Point goes. Sometimes Omni's are the right answer, but not allowing for other antenna patterns really makes getting the most of your WLAN difficult.

Remember - it's NOT the dB that matters - its the ability for devices to transmit data we should be caring about! Getting dB coverage is *easy* - what is hard is getting the clean device conversations is what we should be after.

I think it's almost criminal how some Site Surveys only measure dB or maybe SNR and miss all the measurements that determine if a wireless LAN is actually going to work correctly with DATA. (Coverage, Overlap, Channel Interference, User Density, Data Rates, Jitter, Latency, etc.)

I hear the point that the clients still transmit omni-directionally so that is a problem, and I agree. But my argument is still this: STA's just don't transmit nearly as often as AP's. I know that there are exceptions, but overall it is true. If we can improve the data rate from AP to STA, that is a significant advantage.

Thanks for sticking up for me Keith. I've gotten pummeled a few times on this thread and its bruising my ego. :)

GT

I agree with Keith about the "it's not just about dB" and that clients should be considered. Absolutely!

But, I still don't agree about omnis being bad. In fact, from my experience, losing "special" antennas is a good thing. As an operational point, it makes maintaining and deploying your WLAN all that much easier.

And...since the advent of 5GHz, the whole channel thing is nearly quite outdated. Sure, you need 2.4GHz for devices that don't do 5GHz...or for areas where you need the extra omph the lower frequency gets you (low client density, industrial applications, etc, etc, etc), but dense, high performance deployments can be done with 5GHz channel plans.

Yes, I wouldn't say some vendor's RTLS algorithms require omnis....I'd say all! (If you know of an RTLS application that works on a Yagi or directional panel/patch, then by all means, speak up.)

Keith, I'm curious to your "contention domain" issue and your efforts to design around it. I'm assuming you're talking about the 3 non-overlapping 2.4GHz channels yes? Do you find yourself still designing primarily 2.4GHz networks? Curious. And do you seriously attempt to control that by not-using omnis?


Funny...I agree 100% with this too, "Remember - it's NOT the dB that matters - its the ability for devices to transmit data we should be caring about! Getting dB coverage is *easy* - what is hard is getting the clean device conversations is what we should be after. " I just can't buy the omnis are bad vibe.


All this being said, I think one other thing worth mentioning is the number of SSIDs deployed on a per-radio basis. It seems to be rarely discussed. Some people equate SSID=VLAN=differentiated service. I've seen deployments where people have done TWELVE different SSIDs on every AP just because they wanted traffic to come out on 12 different VLANs for access control.

Now if you want something to eat up available bandwidth on the spectrum, then there you go. That's much worse than anything we've discussed here as of yet. Can I get an amen there? :)

BJ,

Not sure if you have seen my video on youtube about DFS, but in a very short time, we are going to be down to just four 5 GHz channels. Here is the short version.

5 GHz channels = 24
5 GHz bonded channels = 11
5 GHz bonded channels that aren't UNII 2 or 2e (think radar and DFS). = 4

RF management is king.

GT

Amen Brother!

Somehow people think since VLANs separate collision domains in the wired world, they also do it in the wireless world. In fact it makes it even worse (more traffic in the same collision domain)

And YES I'm still designing for 2.4GHz! There are sooooo many devices still around in hospitals, retail, warehouse, distribution centers, etc. that work on ONLY 2.4GHz.

It would be very nice to be able to go to all 5GHz... but that would be too easy. ;-) - anyone can design for 5GHz only with all those channels to choose from. (DFS issues excluded)

Yes, you CAN control 2.4GHz same channel overlap with directional antennas. You CAN control floor to floor bleed with directional and high-gain omnis.

Hey GT....I watched your DFS video on youtube. Good preso, and yes, DFS changes a lot.

One thing you call for is AirMagnet, Cognio and others to put radar detection in their test tools so you can test before hand. I agree that would be great.

However, in the absence of that, if you're deploying an Aruba solution (and I have to think that other vendors support this as well), it will syslog pretty clearly that radar was detected. Here is a syslog output of that.

Oct 22 09:11:23 sapd[144]: <404076> <WARN> |GothParkAP5@10.5.2.5 sapd| AM 00:1a:1e:aa:21:e1: Radar detected on interface wifi0, channel 140, typeid 1"

Just FYI, could be handy. One thing to also consider with DFS that you didn't cover in your presentation is the FCC testing routines. They care about the channel change and nothing else as you mention in your presentation. That means that to pass DFS certification, many implementations of DFS that vendors and chipset manufacturers use will err on the side of making the channel change and not worry as much about false-positives. As you state, this pleases the FCC, but not that user on the voice call.

I know that in Aruba's DFS implementation on the AP-124/125, that quite a lot of work was done in eliminating false positives resulting in immediate channel change and hold-down but while still passing the FCC tests.

So...that leaves another subject with regards to DFS. It would be interesting to do testing when dealing with DFS in order to see if the equipment and code you're wanting to use or are using experience DFS channel change false positives. Sheesh, don't know how you'd test for that. But something to consider. Nothing is perfect and false positive readings are very much a concern with DFS.

But at least you can see via syslog that radar avoidance was the cause of the channel change....

Good video GT.

3 pages and only a few "Aruba" based responses.

Can we table the other talk or start a new thread and get back to the topic - "why you chose Aruba"

Aruba is also not the only vendor to do user / role based firewall rules. Some even do location based firewall - if you are not in the right room or building or defined area it won't let you access the WLAN.

~K

I think Aruba is one of the only (or the only) that does role-based access control (role based firewall rules) that are enforced by a stateful-inspection firewall. Many other vendors that support some level of ACL on a user role are non-stateful roles I believe.

I think Ryan Holland said he would respond to you privately if you wanted to know why they decided on and continue to use Aruba. This forums seems to need more end-users doesn't it?

If you have specific questions, you can post them here or ping me via private message.

Let me know.

GT

Excellent video. The slides really bring to life the whole business of bonding.I agree totally with you. Voice calls are just not going to tolerate channels bouncing around. One main issue is the amount of time it taked the frequency synthesizers in the radios to lock up to the new channels. Some manufacturers I'm sure will use cheapo units that are just not very rapid in terms of frequency agility.

What is awful is this: say you do NOT have radar, but instead have someone with a faulty radio system that has lost lock [ e.g a phase-locked loop that has gone faulty and is in an unlocked state ] and is "sweeping" or some other form of interference that looks "radar-ish". You could end up "channel bouncing" all over the place because of this.

Dave

Thanks a lot for the comments on the video.

The Aruba logs look nice to detect radar. Not sure if I mentioned it in my video, but during the roadshow I told the audience that one way to survey for radar would be to implement a test network and look for CSA's (Channel Switch Announcements) in a packet capture. Just have Omnipeek filter on CSA's so it wouldn't fill up the buffer.

Looking at at the logs would also serve the same purpose and may be easier than my OmniPeek idea.

Right now many people that know about DFS are avoiding the UNII2 / 2e channels which I think is a mistake. It would be better to properly test for a radar event with your product and then make a decision as to what channels to use. Losing 7 bonded or 15 20 MHz channels is quite a lot without proper testing.

GT

GT