Designing by the channel

Channel planning! Almost as glorious as clicking in all those little walls on your million sq. ft. floorpan…. Which by the way is a scanned in PDF from 1994. The things they don’t tell you when you decide to do wireless…

Today I’m writing about my preferred method of planning channels. “How hard is this?” You may be thinking. Well, its not. But with my personality type (ISTP or a 1,5,4 as Devin calls it) I like to help people, tinker, and fix things. As my friend Chris Hopkins once described me: “Joey is the type of guy that could take a car apart and put it back together with a screwdriver.” I don’t know about that much, but I do find myself dismantling things and fixing them and most of the time making them better throughout my days. Also helped me figure out that I’m an extremely visual learner. To sum all this up, I’ve been planning channels for almost as long as I’ve done wireless (sad, I know). But in all this planning, I’ve tried several methods to figure out what the best and most time-efficient way of laying out a building’s channel plan. Here is what I’ve come up with…

All my planning is done using Ekahau. I know there are others, but Ekahau has become my favorite because of the ease of use, and the features that they keep coming out with that is making our jobs as wireless engineers easier. I mean, what other company has a VP that drives across a country he isn’t from just to talk to customers about new features and asks what they want? Props @JussiKiviniemi. Props.

First off, lets start with the available channels.

I only channel plan for 5Ghz. Why? Cause there are 25 channels available to use and that means less interference, better connections, and higher speeds for the little guys(clients). A part of this channel set is the dreaded, evil DFS! You’ve heard the stories… Mostly from those “Tech on the side” guys:

“DFS is evil! If you are within 4 million miles of an airport, you’ll NEVER be able to use DFS! And Radar?! Why do they even allow wifi on those channels? Nobody can use them! Its like wasting energy just typing the number into the standard!”

Hardly. I HIGHLY recommend testing for DFS events before deciding that you can’t use them. You’d be amazed at the times that you can. The hospital I worked at implemented a full 5Ghz channel plan across 7 buildings and 6 stories; less than 2 miles from an airport. After baking for a month, I discovered ONE DFS event. Always on the same channel 116. Always on the same AP. So what happened? Did the FCC come shut our hospital down, dooming all the grandmas that were laying so helplessly in all the beds? Did the entire wireless network collapse while surgeons were cracking rib cages open with ball peen hammers and chisels, listening to Dire Straits wirelessly (I’ve seen that.)? No, we just changed the channel to something else that doesn’t interfere. Don’t forget that most (all?) of the time, the AP doesn’t stop working when it gets a DFS trigger. It simply moves to a non-DFS channel for 30 minutes and then moves back. So uneventful!

In my experience with using DFS channels, so far I’ve only had one instance where it caused a problem. A doctor in a corner office said he didn’t have any signal on his Toshiba laptop. I went over to the area and sure enough, my AirCheck G1 said the same thing. What the heck?! There was an AP IN his office! Looking on the controller, I quickly realized that the AP was on channel 144. This channel, at the end of the DFS spectrum, is the newest channel allowed in the 5Ghz range. Because he was in a corner office, his secondary coverage was crap and he’d drop once he closed the door. There are quite a few clients and wireless cards that do not support 144 yet. After seeing that instance, I decided to remove channel 144 from our entire layout (which hadn’t been installed yet). This was a crappy process but it helped me hone the subject of this blog post and once it was completed, I didn’t have to worry about it again because I USE STATIC CHANNELS. (yes, you can remove 144 from RRM settings. but I couldn’t resist.)

So with all that, lets remove 144 and back it down to 24 channels. We want to make sure that all devices can reach Facebook, am I right?

Signal First.

So the first step I take in planning the RF coverage of a building (after testing walls, and replicating them for weeks) is placing 1 of my chosen model APs in a location that covers -67dbm (or my target signal strength) at the corner of the building. This is typically in a room across the hall from the corner office or conference room unless I’m designing for HD or VHD.

After that first AP is placed we can configure the settings for the rest of the placements. I put the channel on 116 and set the desired power level. Why? Well, 116 is pretty much in the center of the 5Ghz band, so later on, I can change that channel to the final channel and the coverage isn’t going to change too much. I also have it engrained in my head that APs on 116 haven’t been planned yet so its a good starting point. This will make sense later. If the power is lowered I then move the AP as needed to keep signal where it was in the corner.

Next, I layout all the primary coverage in the entire building. All floors, indoor and out. Placing all the APs with the settings from the first -Channel 116/tx-power xx. Ekahau duplicates the first AP automatically. Just don’t leave the screen…I’ve been bitten by that in the past. Its not fun to fix 50 “generic” APs after you’ve saved…

Secondary coverage

This isn’t something that is talked about by vendors very much. Instead they say something stupid like “20% cell overlap!” What the heck does that even mean? Who said that and then convinced others that it was a good idea? Someone that uses that “honeycomb” pattern..Not a CWDP.

Secondary coverage has two functions. First, its what makes roaming successful. Too hot, and devices will have a hard time making a decision to which AP they should roam. Too lacking, and the client will either disconnect from the primary AP before roaming or you’ll stick to the primary AP and your signal will turn to crap before the roam is successful. Either is bad for the client. The second purpose is for redundancy. With a good secondary coverage plan, and AP can go down and users won’t notice. I experienced this at the HD3 hospital that I redesigned:

Cablers (somehow) always manage to get a bunch of ceiling tile fiberglass inside the ethernet port. They plug it in and it works initially, but later it craps out and you get an alert that the AP went down. When you go unplug the AP and blow the entire ceiling tile out of the ethernet port and plug it back in -it works fine. This happened to the MAIN AP in the middle of the Emergency Department. The one that ALL the nurses and doctors sit under and work from. Average client count of 35. The AP went down, and nobody said a word. No calls, no support ticket. I just noticed it was down. I remediated the AP a couple weeks later during a slow day and all was good. That is what secondary coverage can do for you.

To plan secondary coverage on Ekahau, select the 5Ghz band for the view, and click options. Down at the bottom is a drop-down that says “Show the (strongest) signal at (all) channels“. Change the first drop-down from (strongest) to (2nd strongest). Then change the legend to your desired secondary level. I mostly use -70. Some devices recommend more. If you use the default view, you want the map to be speckled with mostly yellow and gray. Once you see darker green, your APs are probably too close and you need to move them apart a little bit to get rid of the green. Lighter green is certainly better than dark green. Also, remember grey is ok for this view. Large spots of of grey should probably be fixed. I don’t typically worry about the secondary coverage for the edge of the building because users won’t be roaming in those areas.

Now all the APs are placed. Primary and Secondary coverage is looking good and I’m ready to start changing channels.

Before I start changing channels, I like to do a calculation to determine how many APs need to be on each channel in order to get blanket coverage with non-DFS and DFS channels. I like to design with a 60-65% coverage model for non-DFS and 35-40% for DFS channels. I do this calculation per floor instead of the entire building.

If I’m working on a large floor that has 60 APs, I find out what 60% of 60 is: 36. There are 9 non-DFS channels (36-48, 149-165). So 36 divided by 9 = 4. Each non-DFS channel will have 4 APs. The remaining 40%(24 APs) will have DFS channels. 24 divided by 15 is 1.6 APs per channel.

Recap:

60 APs

60% of 60 APs is 36 APs.

40% of 60 APs is 24 APs.

36 APs will use the 9 non-DFS channels.

36 divided by 9 is 4 APs per channel.

24 APs will use the 15 DFS channels.

24 divided by 15 is 1.6 APs per channel.

Still following? Hopefully.

Now to the channels.

So then we begin:

In ekahau, set these settings:

Show “Channel Overlap” for “Selected APs” on 5Ghz only

Click Options, and select “Detailed” view

I turn contours off in the legend (personal preference)

Leave the legend at 0 and 2.

Now, starting with non-DFS, select 4 APs that do not cause CCI. CCI shows in yellow:

Then click Actions, Edit selected APs, and change the channel to 36. Be sure when you are selecting the APs, that you only click the 116 icon. If you select the AP itself, it will select both channels and the edit screen won’t let you change the channels.

Now, repeat for the other 8 channels. Keep in mind to stay away from ACI. ACI is Adjacent Channel Interference. ACI is caused by putting 2 neighboring channels next to each other in an environment such as 36 and 40. ACI can cause most problems than CCI because its harder to detect without a protocol analyzer and it can produce errors in the transmissions from clients to AP and vis versa. As far as I know, the 2.4 range doesn’t experience ACI because there is a separation of 25 Mhz in between the 1, 6, and 11 channels. In 5Ghz, there is no separation. Channel 36 butts straight up against channel 40. This is where the problem is. *Sometimes its unavoidable. I’m still getting better at this.

At the end of this section you should have covered most of the floor with non-DFS channels, possibly with little gaps here and there. I find that its typically hard to get coverage in the middle of the area. Most of the outside APs will hear the APs in the middle so you can limit yourself if you aren’t paying attention.

Next, Do the same thing with all the DFS channels that you require according to your percentage, again keeping in mind ACI. Your last couple of APs can stay on 116 if you decide to leave them and the channel hasn’t shown any DFS triggers.

(ignore the 2.4 radios. I was mid-project)

Once you are finished, you double check your coverage and interference by viewing “My APs” instead of selected and looking at signal coverage and channel overlap.

And thats it!

When doing a multiple floor building, I start at the top because most APs have a down-tilt antenna. If CCI is going to happen floor-floor, most of the time it will happen from the upper floor broadcasting down. Speaking of, I haven’t found a good way to check floor to floor CCI during the planning phase. What I do currently is take a screen shot of the floor above, and reference that as I’m channeling the current floor. Not perfect but its better than waiting 10 minutes for each floor to refresh.

Lastly, depending on the power level, you probably aren’t going to get rid of all the CCI. My advice would be to know the building and requirements when you are designing. That way you can make good decisions when you get into that situation. Sometimes you just need to accept it, and sometimes you just move a couple APs here and there.

5 thoughts on “Designing by the channel”

Great article – thanks for putting this together. I’ve felt conflicted about using UNII-2E DFS channels due to the way that apple devices scan for networks (taking up to a minute to associate to a DFS channel when it’s the last resort). Has this been a problem for you in environments with voice applications in a roaming heavy environment? If not, I’ll have to rethink how I allocate my channels… it would be nice to have more room to play.

I responded to this but I guess it didn’t work. Unfortunately, I haven’t had to troubleshoot many iPhone connectivity problems. The one time I did, it was a configuration problem with Airwatch. I personally haven’t seen any problems with DFS and iPhones.

Hey Paul, in my experience, algorithms like RRM can only be as good as a static channel plan. In the past I’ve configured and surveyed several locations with auto channeling and I always found problems with the channel selection. There is always CCI created because the way that the program picks its channels. See my Aruba Static channeling post for more of my thoughts on the subject.