★ THE BLOG ★ Ramblings on WiFi & stuff.

If You're Going To Use Single-Channel Architecture, At Least Know What You're Doing (via @Badger_Fi)

I don't have much experience with SCA (Single-Channel Architecture), other than what I've read, and some not-so-pleasant experiences with Ubiquiti. Mitch Dickey (@Badger_Fi) does, and has some really good stuff to say.

He writes about troubleshooting a problem at a high school that implemented an SCA solution. The problem turned out to be Co-Channel Contention. WAT?! Yup. But, before you think you know what's up, read the post. SCA may not have anywhere near the footprint MCA does in today's world, but it always good to learn something new, especially from someone like Mitch.

Read it here.

Source: https://badger-fi.com/2016/08/31/single-ch...

DFS implications for hidden networks and roaming

UPDATE: See the comment below by Andrew Von Nagy. It clarifies what I said about hidden SSIDs and DFS.


I'm a huge advocate of using DFS channels in most medium to large deployment scenarios. But, you should always validate your channel plan and make sure it doesn't cause issues with you WLAN. By that I mean verify that your devices actually do support DFS. It’s possible certain devices support DFS, but not ALL DFS channels. Checking manufacturer documentation, Google, or site like clients.mikealbano.com can help you figure that out.

Case in point: Hidden SSIDs. Most wireless folks recommend against using hidden SSIDs. It doesn't provide any security, requires more work to connect devices to, and some NIC drivers don't like hidden networks and won't, or have trouble, connecting to them.

There are practical reasons to hide an SSID - to avoid confusion between networks, or to simplify your network advertisement. But, security isn't one of them, the AP is still beaconing, clients probe more (so you're wasting airtime and announcing the SSID anyways), and the SSID is sent in plaintext in association requests anyway, so it's not that difficult to find them.

But, there's yet another reason to avoid hidden SSIDs - especially if you want to take advantage of DFS (Dynamic Frequency Selection) in your WLAN:

I'll admit to doing "little contemplation" on this. Fortunately, I don't run into hidden networks that much these days (thank goodness), but I've also spent little time considering the consequences of DFS and hidden networks. Using hidden networks on DFS channels can cause unforeseen connectivity issues.

Clients can't actively probe on DFS channels. Active Probing is when a client send a "Probe Request". Clients  send probes on a channel to discover any potential APs. Since ACTIVE probing is not allowed on DFS channels, clients will do Passive Probes - which simply means they listen for beacons on a channel. Well, if they just happen to listen BETWEEN beacons, they’ll miss what they don’t see.

This also has implications for voice and roaming. If the clients can't probe for new APs then roaming times will be longer, and real-time data starts having issues. Many hospital deployments don't use DFS because of these issues.

Just food for thought. If you need frequency re-use (and these days who doesn't?) you'll need DFS. And DFS does not play well with hidden SSIDs. So, just stop hiding your SSIDs. Another thing you can do is mix your channel plan up so you don't have all DFS in an area. Always have non-DFS channel options available in case the device doesn’t have enough time to find the channel, or it doesn’t support it.

One final note, if roaming is important, you should be using 802.11r and devices that support it. And in conjunction with 11r use 11k/v to help speed up channel discovery. Of course, make sure your infrastructure and your devices support these features, and test them thoroughly to insure there are no compatibly issues when enabling them.


UPDATE: See the comment below by Andrew Von Nagy. It clarification  hidden SSIDs and DFS.


Actually, that isn't correct. Clients can't initiate transmissions on DFS channels, which prohibits most of the benefits of probing... namely faster discovery of the APs operating on the channel. But hidden SSIDs have no impact on this. Once a client hears a beacon on the channel by a "master" device (that must conform to radar scanning regulations) then it is safe for a client to probe.

So the real issue is two fold with DFS and client scanning:

1) Longer initial AP discovery time due to waiting until it hears a beacon (102.4ms intervals) instead of probing immediately (discover within just one or a few ms), and

2) Longer scanning time when roaming, especially for latency sensitive applications such as voice.

Whether or not the beacon populates the SSID IE field is irrelevant.


via @BLAKEKRONE: Where's Waldo? (or, The case of the missing wireless engineer.) →

Blake Krone, via his blog →

What do I mean by a skilled wireless engineer? Do I mean they are CWNE or CCIE or AC[]X? No, not at all. I simply mean someone that understands wireless and the challenges it brings when trying to design. It’s the person that knows about Co-Channel Interference and Adjacent Channel Interference, someone that understands when and how to use 20/40/80MHz channel widths, the person that knows you have to do a survey to get things right, etc.

I think sometimes we (myself included), as wireless engineers, make it seem impossible for people to think they can unlock the "secrets of Wi-Fi". No doubt there are some complicated things, but no more so than some other enterprise technologies out there as Blake points out. He thinks it's the PERCEPTION of wireless be too high an entry level and I tend to agree.

Maybe we need to preach some more "bare bones" wireless for the network folks out there that don't have the budget, or support, to access the expensive tools we all desire. Things like knowing WHAT to look for when doing a wireless scan, or basic understanding of channel management could go a long way to helping the many over-burdened IT individuals out there saddled with the task to install a WLAN. At the very least enough knowledge to know when to call in an "expert". In the end what we really need is to bring more people into the wireless fold.

First thing's first: REQUIREMENTS

Estimated reading time: 2 minutes, 14 seconds. Contains 448 words


I was at a meeting today with a large Mechanical/Electrical Engineering firm who was in need of some wireless expertise. More and more they are getting asked to include wireless "designs" for building projects and are finding (as many do) that it's not as simple as it seems.

The discussion took many turns, but often came back to something like, "So, if we have a school with say 35 students per classroom how many APs do we need?" My answer would be, "it depends." What does it depend on? Their requirements.

How many clients (not users, but devices)? What type of clients (1 stream, 2 stream, 3 stream)? What applications will they be using (e-mail & web, video streaming vs. YouTube caching, voice, etc) What are the bandwidth requirements for their State testing? And more.

The point was - just like they could not just "make up" an electrical, or engineering design out of the blue (How many people need to be in the space? What's the total power consumption required? Do we need HVAC in all locations?) - one could not just "make up" a WLAN "design" (Well, one could, but then you get what you get). That made total sense to them which was good.

I love explaining how wireless works and seeing their eyes light up. I love how it makes sense to them when I explain why they're not going to see 1.3GBs throughput, or adding more APs is not a default answer to a problem, how coverage & capacity are different things, how having a bunch of low-end single stream devices is not as efficient as have a bunch of 2, or 3 stream devices, etc.

The FIRST step to wireless network design, and the best way to avoid the BAD-FI, is to determine the REQUIREMENTS and EXPECTATIONS of the customer. Here just a few of things you should consider:

  • How many clients will be using the WLAN?
  • What are the types/capabilities of the devices? (# of streams, 5GHz support, DFS support, 802.11r/k/v support, etc.)
  • What applications will be using the WLAN and what are the requirements of those applications?
  • Is there a budget for the project?
  • Are there accurate, scale floor plans available?
  • What security and authentication types are you looking to support?
  • What the total bandwidth coming into your facility?
  • What is the time-frame for the project?
  • Aesthetics: Are external antennas ok? Do LEDs need to be off Should APs be inconspicuous?
  • Cable lengths: where are/is the MDF/IDFs located? More than 300ft from the APs?

These are a few off the top of my head, but you get the gist. DEFINE your customer's (or, YOUR) requirements and expectations BEFORE you design a solution.

Anything else and you're just guessing.

Bad Design at Your Request

Estimated reading time: 6 minutes, 44 seconds. Contains 1348 words


What does one do when presented with a highly questionable request from a customer? Nothing immoral here, just when a potential customer is asking you to do something you know won’t work. I had this exact scenario happen this Summer with a resort that wanted to do a wi-fi refresh.

Originally, the customer just wanted to do a rip-n-replace - swap out their existing 7-year old, 2.4GHz APs - with new APs. After some discussion we convinced them that a simple swap out was not the best solution. We agreed to do a predictive survey using data collected from on-site data collection.

One of the caveats was that the APs could not be in the rooms. For aesthetic reasons, and others, management wanted no APs in rooms. We knew this would not be an ideal solution, and we let this be known on several occasions. After explaining our reasoning, IT was in agreement with us on this matter. However, the management was not convinced and decided to take a chance on the hallway “design”.

We did our best in collecting data on-site and used that data in our predictive surveys. In the end the initial deployment was a hallway placement. We adjusted some AP locations and added some, but I knew this solution would not yield the desired results. Directional antennas brought the budget to more than they wanted, so those were not an option. They also wanted this in on a tight time-line. I had made my concerns know at multiple occasions, but there was no budging from management.

So, I could choose not to do this project and walk away, or sell a solution I was not confidant in. Well, I have a business to run, bills to pay, and employees to… employ. I chose to “design” a solution within the constraints - both AP placement and budgetary. With this in mind I drafted the cover letter below for the predictive survey I presented to the customer:

Thank for this opportunity to allow us to present you with a wireless access solution for your wonderful property. Before you proceed to the information in the document please indulge us and read this overview in its entirety. It will clarify the purpose and scope of this document. 
This report is a “Predictive Survey”. The term “predictive” is used deliberately to denote the fact that the process used in the creation of this report is a best guess and will most likely not be 100% accurate. In a structurally complicated deployment such as yours we can probably assume a 75-80% accuracy rate. 
Predictive surveys are a very useful tool for the Wireless LAN Professional when a full, cost-prohibitive survey is unavailable. There are two methods to perform a predictive survey: 
OPTION 1. Using only the floor plans and a questionnaire we can use the survey software to automatically place the APs and then manually adjust to our specifications. We can alternatively manual add the APs to specification. This type of survey is best for traditional, modern open-floor plan office environment where the loss and performance characteristics are well known. This is also the most cost-affective (up font) solution and very commonly used. In the end you get the best data out when you put the best data in so this option should be used sparingly and mainly for budgetary purposes.
OPTION 2. Perform a physical site survey to become aware of the building materials in use, current AP locations and limitations, physical build of the rooms and furniture materials and locations, etc. Also, using the same APs and antennas that are being proposed take as many readings as possible to determine the true signal loss at varying distances from the AP. We also are able to look at various types of RF interference that may be present, and possibly mitigate that interference before the deployment begins. This allows us to use that data to better build our predictive model. This is less cost effective than option 1, but more cost-effective than a full site survey, and allows the model to go in with the best possible data that the circumstances allow. 
Option 2 is what we have done. We spent time on site taking readings, and noting material types as we could. Obviously, in an environment as busy as yours it was not possible to have access to every location so we did the best we could taking readings in multiple rooms and room types and through the various material types at your location. This is not perfect, nor definitive, but it will at least give us valuable information to use when making our predictive model. 
We would also like to take this moment to also state that locating all the APs in the hallways is the least effective model in a multi-room, multi-tenant environment such as yours. The best-case scenario here is allowing the APs to be located with-in the rooms. This allows us to use the structure of the building itself to allow for separation between the APs and help mitigate interference as well as getting the RF signal closer to the clients. We understand that this is not always possible for a variety of reasons, but we felt the need to make you - the customer - aware of the limitations to which this design has been restricted.
In conclusion, we ask that you look at the following report with the information in this overview in mind and with the understanding that after deployment we highly recommend that we (or a 3rd party) perform a validation survey to confirm where the predictive model falls short. Upon the results of this verification there may be several things that need to be done. It may be adding, relocating, or even removing some APs, or we may simply need to disable certain AP radios to reduce co-channel interference. Either way the design is not complete in our view if it has not been validated after implementation.
With this in mind please proceed to review the report. Thank you. 
Eddie Forero, Principal CommunicaONE Inc. 

The report essentially showed what we had been saying - that APs in the hallways would not provide the in-room coverage they desired. We also provided an alternative design with APs in room. In the end the management went ahead with the hallway solution despite ITs misgivings.

The end result was not much better than what they had. I fully expected to bear the wrath of the customer. I was not happy that I installed a solution I didn’t believe in. And I was not expecting what happened next.

The Director of IT flew out the the head office to present the results of our post-installation validation survey. He showed that hallway APs were providing great “coverage” in the hallways, but not in the guest rooms. He explained how we had predicted that this design would not give them the results they were after and the gamble did not pay off.

Because we had been very clear about our concerns, and because we had predicted, then validated those concerns, the management decided to foot the bill for a complete in-room redesign (even using less expensive APs). And not only that, but also light up another property next door!

Maybe we should have walked away. But, instead, I stated clearly why the solution would not work and made sure they were aware of a drawbacks. I’m don’t know if I would do this again, but I will definitely make even more of an effort in the future to have the customer deploy the right solution the first time around. It’s more cost effective and less stressful.

I don’t know if this is helpful to anyone, but I figured I’m not the only one who has had projects where your hands were tied. The moral of this story is - stand your ground. In this case it worked out because the customer realized the error and stepped up to do it right. But, make sure you fully layout the issues. Be respectful of the customer, but respect your skills and knowledge as well.

The Ultimate Guide to Modernizing Classroom Wi-Fi

Recently Aruba Networks hosted a webinar presented by Keith Parsons. I love how Keith breaks down the technical details for his audience. 

I also really appreciate Aruba hosting this webinar. There’s been much discussion about vendors falling back on the “1 AP per classroom” “design” without appreciating that starting with that premise often results in a poor designed and functioning WLAN.

Aruba is selling responsibly. 1 AP per may sell more APs for Aruba, but this just shows they’re looking out for the needs of the customer. Good on ya, Aruba!