Sunday, December 25, 2016

Build your own Ekahau ePerf & server!

One a recent forklift project, we decided to replace our aging 802.11a/g hardware and deploy new 802.11ac WLAN gear.


We designed the building with Ekahau’s ESS - our default WLAN survey and design tool.  After designing the WLAN to meet our healthcare requirement (in this case, Aeroscout tags, Vocera badges, 5GHz Voice and data) we installed the gear and then validated the WLAN.


For this initial 802.11ac deployment, we decided to do both passive and throughput validations.  With throughput surveys, we measure actual data, such as packet loss and jitter.   On a side note - for some time now, we have said to ourselves, “I wish we had a portable Ookla Speedtest server”.   Spoiler alert!


We needed a throughput server that would be both simple to use and portable.  After talking with our Ekahau team, we decided to use the Odroid C2, and configure it for two purposes.  (It turns out that Ekahau has done the homework for us, and a quick web search will unearth most of what we need to know.)  We decided we wanted it to be an iPerf3 server, and a “mini” server. 


Most of the time, we do passive surveys to validate our WLANs – however, every now and then we have the need to do an active survey, which is usually related to a WLAN that is experiencing issues.


I think we have all heard the usual complaints about “the Wi-Fi is horrible”, etc.  Users go to their favorite speed test site on the Internet from their mobile device and immediately blame the Wi-Fi when they don’t get the results they expected.  With our new throughput server, we can plug it into the LAN and have users browse to it and test their throughput, eliminating the Internet connection and all of the other unknowns!  Having a portable speedtest server and seeing the look on their faces is priceless!


Having a portable ePerf/ server is awesome.  You may want to do spot checks to make sure everything is operating properly on your WLAN after setting up new access points and controllers, or your controller-less Wi-Fi gear.


I would like to mention that throughput surveys are not for everyone.  They take a lot of time, and your survey results may not look like what you expected.  If you have never done an active/throughput server, then I encourage you to do a small one and look at the results.  It is a great learning exercise, that’s for sure.


The team at Ekahau has done most of the homework for us, and created a shopping list for us.  Follow this link to see what is available.


I chose the standard build from the document, and with a lot of help, loaded Diet Pi, Fruity WiFi, Ekahau iPerf server and  I will warn you – you should know your way around the Linux command line, or have someone that can help you.  I could never have done it with without a lot of help.


Rumor has it that if you attend WLPC , you can build one yourself while you attend the conference.  That is a great excuse to go!  If you are like me and not a “Linux guy”, definitely go this route.


Here’s what I ended up purchasing:






After building the unit, we plugged it into our wired network.  It boots up, and we connect to it via Wi-Fi and then obtain the wired IP address.  We browse to the wired IP from another wired workstation and test the wired to wired throughput.  In this case, we get over 500 Mb/s.  That’s good enough for me – now I know how fast this can go.  We ignore the slow upload speed, as the Odroid can’t write to the flash that fast.  We’ll just be using download for testing purposes, anyway.


One thing I want to mention is that along the way, I ended up using another micro USB power cable and didn’t notice.  My Odroid was having issues powering up, and I asked around and someone mentioned that I might not be using the power brick that I purchased with the unit.  That was the case!   The next unit I build will have the wall transformer and power plug, so I don’t run into this again.



Here’s what my looks like, wired to wired.  Awesome!





If you have been pondering having your own Ekahau throughput/iperf server, this is the way to go!




Friday, May 20, 2016

Proving "It's not the Wi-Fi network"

We’ve all been there – or at least most of us have, anyway.  The Wi-Fi network appears to be misbehaving and users are frustrated.


Your users will be working for several hours, and then, it looks to them as if someone shut the entire WLAN off.  Their workstation’s Wi-Fi icon, when hovered, states “no Wi-Fi connections are available”.


Now comes the fun part – well, to me it’s fun, anyway.  Let’s start out with what the normal operation of the WLAN client looks like.  This particular client is stationary.  It’s a laptop that is used like a stationary desktop, and is cabled to the desk via lock and key.  I wanted to clarify that because you won’t see any roaming in this packet capture, and you shouldn’t see any.


Since the client is associated to an AP on channel 36, I set my protocol analyzer to only look at that channel, and then set a filter to only look at the client adapter.  This makes is a lot easier to what’s going on.  I will use this as my baseline, since I want to know what it looks like when everything is working normally.  Here’s normal for this client:


Encrypted data from AP to client

Client Request to Send to the AP

AP responds with Clear to Send

Client sends data

AP acknowledges data with ACK packet



Now we will fast forward a few hours.  The user called you and told you “The Wi-Fi is down”.  Or is it?  To them, it is!


We start our same packet capture as before – same filter, same channel.


Now the picture is very clear.  The Client doesn’t see the beacon of the AP’s BSSID because it is sending probe request to ff:ff:ff:ff:ff:ff and we are seeing the unicast probe responses from the APs (only on channel 36 because of the filter) to the client.  I believe the client should send unicast probe request to the AP.


The c lient does not appear to see the beacon of the APs, and starts sending out probe requests.  The APs respond, but the client does not appear to see the probe response.  Almost as if they WLAN client has gone deaf.



Thankfully, the “quick fix” is to turn the WLAN adapter off and then back on.  Long-term fix will most likely entail downloading and installing new WLAN client drivers.





Sunday, March 6, 2016

Using your autonomous AP as a Spectrum Analyzer


Most of us have all done an APoS (AP on a stick) survey, either active or passive, for a customer by now.  Many of us also take a snapshot of the spectrum while doing our WLAN surveys.  We either use an integrated Spectrum Analyzer, such as the DBx adapter coupled with Ekahau’s ESS software, or we use a spectrum analyzer adapter(hardware) and software to collect data for off-site analysis.


If you own the DBx adapter and use it with Ekahau, that doesn’t mean you own Chanalzyer, which is Metageeks Spectrum Analyzer software.  Which leads me to this post, as I do not own a copy of the software mentioned previously.


If you are on-site, using a Cisco 3602i series autonomous AP for your APoS active/passive survey, did you know that with just a little bit of effort you can use it to grab your Spectrum Analysis file?


I usually have my old Dell D630 workhorse with me, which has a PCM/CIA  slot, an old Cognio card, and Cisco Spectrum Expert loaded on it.  However, as most of you know, these machines weigh 4.6 metric tonnes after about three hours of carrying these monsters around, no matter what hand you carry it with.


After a brief conversation with @NoLANWiFi (giving credit where credit is due) I decided to lab it up.  I am assuming you have read @802Tophat’s blog on getting your site survey AP up and running – Thanks Richard for posting that for us!


I logged into my site survey AP running 15.3 code and changed both dot11 interfaces’ station roles to “station-role spectrum”.    Now you need the NSI key.   Type “show spectrum status” from the exec prompt and grab the NSI key.  It looks something like this:  NSI Key:  0FB30A960DA7F66952E30B59640563AC


There are two ways to connect to your “new” Spectrum Analyzer.  Connect to either one of the dot11 radio interfaces with your site survey laptop, like you normally do when active surveying, and use the other interface for spectrum collection.  Meaning, if you connect via the 2.4GHz radio, you will use the 5GHz radio for spectrum collection.  Or, connect via TCP/IP via the Ethernet interfaces.  This is how I am going to do it for this post.  I am going to use the Cisco POE injector, and one end is connected to my survey AP, the other to my laptop.  They’re both on the same /24, so I can simply connect via TCP/IP.


Next, you need to download Cisco Spectrum Expert.  If memory serves me, you need greater than 4.0 for remote spectrum analysis.   After downloading and installing it, go ahead and launch the app.


This is where you plug in that NSI key.



My laptop is, statically set on my Ethernet interface.  Notice how I am given a choice to go use either the 2.4GHz or 5GHz band.  This appears to be one of the downsides of using the AP for spectrum collection.  I cannot select both frequencies to collect data.


Here goes…  Let’s take a look.



As most of you probably already figured out, I have a known environment in my lab to test with, and sitting side by side is the old Dell D630 with the Cognio card.  After running some interference tests, it looks like the remote sensor and the Cognio are, for the most part, on the same page.


However…  something is missing!


When I look at the Channel Summary page, something looks awry.



I’m not seeing any Wi-Fi Present!  What’s the deal? (I know what the deal is, but wondering if you, the reader, can figure it out)


Now I am going to the Devices tab, and again, I don’t see anything!



What could be “wrong” with using the AP as a Spectrum Analyzer?   I left BIG hint for you in that last graphic…


All that said, I think I can use an AP for a spectrum analyzer, in a pinch, if I had to do it from a remote site.   Clearly, when using an AP as a remote spectrum analyzer, we don’t get all the functionality we would get out of our laptop/hardware based spectrum analyzers, such as Metageek’s Chanalyzer, Spectrum Expert (with Cognio card) or AirMagnet’s SpectrumXT.


Please use the comment section to chime in on why we are missing the data that we might want to see at a later date, if we were using the spectrum file as a baseline.









Saturday, March 5, 2016

WLAN Surveying and Validating with Ekahau's integrated Spectrum Analzyer


When doing any WLAN Assessment or Remediation, we ALWAYS look at the spectrum.   In about 60% of the WLANs we assess and remediate, we find interference from a device the customer didn’t know they had, or knew they had but didn’t know it was sharing the same spectrum as their Wi-F.


The complaints vary from Customers that have interference issues.  We hear “I only have two bars”, “my wireless is slow” and “when I stand right here, my Wi-Fi doesn’t work”.


We’ll first start out with stating the obvious.  The 5GHz UNII bands are license free, which means it is a free-for-all when it comes to who is doing what.  Most of us all understand that.  A company, or their neighbors, can pretty much deploy anything they want, as long as they abide by the rules.


When we first start out on an Assessment, we do what we normally call a WLAN Validation.  We walk the entire facility with Ekahau’s ESS – or Site Survey Software.  Ekahau recently updated their software to include Spectrum Integration, so here is our first look using it in the real world. 


In this case, we have an area that we know we have WLAN Interference.  We have looked at it with other tools, however since Ekahau is our tool of choice at the moment, we want to compare what we see with our new spectrum integration to what we are used to seeing in our legacy equipment.  Here is a view of the area known to have an interferer on channel 40.  We looked at our Survey Inspector, and the Spectrum Channel Power view.  We clearly see something there, and can compare it with a quick glance to the other channels. 




And now we are going to take a look at our Spectrum Utilization view.  We scrolled up to another area of the survey/walkabout where we know we have another source of interference.  Again, we can clearly see that there is an issue in another part of the building.




During our Spectrum Integration analysis, we notice another feature called RTFM.  Forget what you know about this acronym, because it stands for Real Time Frequency Monitor.   This is the kind of tool I would use if I had my survey rig in my backpack, and someone told me of an area that was having Wi-Fi issues.  I don’t even need to build a project – I open ESS and hit the RTFM button, select the frequency I want to look at and give it a glance.  Here’s what I see below.  I must say, that’s a nice feature!  Thank you Metageek (for the SpecAn) and Ekahau!



Now that I have seen the interference, I, for whatever reason, want to see it in my Spectrum Analyzer software.  This is available from Metageek – where you would most likely purchase your SpecAn hardware.  This view is with other known interference devices, all by the same manufacturer, turned on – for our testing purposes.  As you can see, there is a lot of interference here, and some remediation and spectrum management needs to take place.




Now for a look from some of our legacy tools.  As you can see, the view is not of the same exact slice in time, however I promise you that what you are looking at is all caused by the same equipment.   This is a view of four devices energized, and one of them is changing channels.  No wonder these folks are complaining about their Wi-Fi not working well for them!





Here’s a view of channel 40 from another Spectrum Analzyer.  AS you can see, the numbers vary from tool to tool, but in each you can tell there is an issue.



Af first, it took us a while to track down the equipment, as we didn’t want to go into an operating room while they were doing their thing.  After several days of intermittent troubleshooting, we finally came to the conclusion that our source was mobile.  We tracked it down to Operating Room “towers”, which were mobile Endoscopy equipment.  The gear has a wireless transmitter and a remote monitor or two, and those remote monitors were connected via the 5GHz spectrum.  This equipment was moved around to whichever Operating Room need it.





Then we discovered something else.  When the equipment was turned on, it searched for a channel to use.  Not in a very Wi-Fi friendly way, though.  It seems as if it always starts on channel 36, then works its way around the first eight channels until it finds “home”.


If you are good with math and have a great imagination, multiply this one source of interference, and what is does to your WLAN, by four.  There were at least four of these devices being turned on and off during the course of any workday, each booting up and trying to find a channel to use.  Stomping on the Wi-Fi as it went.




Something about these tools is worth mentioning. They are somewhat complicated and expensive to own – unless you use them on a weekly basis.  They all do a great job of displaying to the operator what the electromagnetic spectrum looks like at a given frequency.  However, there is no “magic button” that you can click on that will tell you what is wrong with your network and how to fix it.  I highly encourage anyone interested in owning and operating these tools to first go to and purchase the CWNA curriculum and read it several times.  Of course you also have to read the manual of the spectrum analyzer you finally end up purchasing.  You can get the Spectrum Analyzer (and the software) that integrates with Ekahau ESS from









Thursday, February 25, 2016

Is there a need for a Spectrum Policy within the Enterprise?

I recently came across this some equipment that interfered with Wi-Fi in the worst way – well, that’s my opinion, and I will let you be the judge.


We’ll first start out with stating the obvious.  The 5GHz UNII bands are license free, which means it is a free-for-all when it comes to who is doing what.  Most of us (the folks reading our blogs) all understand that.  However, when an Enterprise environment has millions and millions of square feet of office, retail, healthcare or manufacturing space, I think the Company’s Enterprise IT department owes it to their internal customers to have a Spectrum Policy to keep the spectrum in check.  Letting the company buy whatever they want, whenever they want, and deploying it randomly as they see fit, doesn’t work well, as you will see if you continue reading.


I recently came across a surgery center consisting of 8+ operating rooms, and the Wi-Fi was at the core of the complaints.  Nurses had to move their mobile workstations outside of the operating rooms in order to maintain a connection.


We went in with protocol analyzers at midnight and saw nothing.  We went in at 6pm, and saw nothing.  Then we went in during working hours with our Spectrum Analyzers, and that is when we saw a big difference!  We observed channel 40, in the 5GHz range, pegged at 90+ percent duty cycle, for well over an hour. 


Okay, so what, you think.  One channel – no big deal, right?  Most Enterprises use UNII-1,2 &3, so there is likely another channel readily available at a -67dBm. 



It took us a while to track down the equipment, as we didn’t want to go into an operating room while they were doing their business.  After several days of intermittent troubleshooting, we finally came to the conclusion that our source was mobile.  We tracked it down to Operating Room “towers”, which were mobile Endoscopy equipment.  The gear has a wireless transmitter and a remote monitor or two, and those remote monitors were connected via the 5GHz spectrum.  This equipment was moved around to whichever Operating Room need it.





Then we discovered something else.  When the equipment was turned on, it searched for a channel to use.  Not in a very Wi-Fi friendly way, though.  It seems as if it always starts on channel 36, then works its way around the first eight channels until it finds “home”.





What does this do to your Wi-Fi when this is happening?  If the RED color doesn’t spell it out for you, then nothing will!


Just to prove our point, we took our active survey access point (yes, we actually do “active” site surveys still) and put it on channel 36 and associated three clients with continuous pings to it.  We turned on the Stryker gear, and not only did the pings cease, the three clients no longer saw our site survey SSID, and then decided to join another WLAN on another channel.


In a nutshell, it obliterated the channel for however long it decided to rest there. As you can see from our swept spectrogram, there is no real pattern.


We also used two different spectrum analyzers that we happened to have in our kits that week.  Not saying that one is better than the other, and if we didn’t use one that isn’t here, it isn’t because we don’t like it.  We just happened to have both of these with us, and that’s what we used.

The screenshots below are from just one transmitter and one receiver pair.  Imagine a surgery center with ten operating rooms along with five of these units online, coupled with the different schedules and the appearance of random Wi-Fi issues.  When these units boot up, they search for the channel they want, obliterating the spectrum as they go.








If there was a Spectrum Policy, this kind of thing might be avoided.  The 5GHz bands can be divided up within an Enterprise, with UNII 1,2&3 reserved for Wi-Fi, and UNII-2e further divided up for cameras and other gear.


What are your thoughts?  Is it worth the investment to put together and enforce a Spectrum Policy?









Sunday, September 13, 2015

Should I re-design my Wi-Fi, or "swap them out"?

WLAN Site Survey – Should I redesign my WLAN, or just “swap ‘em out” and be done with it?

The purpose of this exercise was to design a WLAN for an office building with either the Cisco 3602i or the 3702 series access point.  We wanted to know if we could survey with either one of those access points, and deploy the other, if it came to that, because we didn’t have a 3702 on the shelf.  After mentioning this to Sam Clements, he immediately came to the rescue and let me borrow some gear.  Our new goal was to survey with both APs, configured to the same power level, so we could compare cell sizes.  You can follow Sam here:

We (@WiFi_Princesa and I) rigged up a 2504 controller running 8.x code and a mast-like structure that would hold two access points up to the ceiling.  We don’t normally use a WLAN controller to do surveys – we usually put autonomous code on them and configure them as survey APs.  Since this was borrowed gear, I decided to leave it in its CAPWAP state and use the 2504.  At the last moment, we decided to toss a 3502 into the equation, since we had one available.

We configured the three access points as follows:

3702, power level 3, channel 36

3602, power level 3, channel 40

3502, power level 3, channel 44

This is the 3702’s  “don’t want” coverage area.  Notice how far out that -85 dBm boundary goes! 

This is the 3702’s “want” coverage area.  The -67 dBm boundary is about where we expected it would be.  This is an office building with offices around the perimeter and cubicles in the center. 


Now let’s compare to the 3602 series AP:

This is the 3602’s  “don’t want” coverage area.  Similar to the 3702.

This is the 3602’s “want” coverage area.  The -67 dBm boundary is about the same as the 3702. 


Now for the 3502i series that we added at the last minute:

This is the 3502’s  “don’t want” coverage area.  Notice how far out that -85 dBm boundary goes!  Something is fishy here!

This is the 3502’s “want” coverage area.  The -67 dBm boundary is a lot larger than I thought it would be.  But we put them all on UNII-1, power level 3. 

The only thing we can think of is that power level 3 is not the same across the board with all three APs in the UNII band.   We quickly figure out how to do this by surfing here:

So, let’s get started!

(Cisco Controller) >show ap config 802.11a Cisco_3602i

<output omitted> 

Tx Power

      Num Of Supported Power Levels ............. 5

      Tx Power Level 1 .......................... 14 dBm

      Tx Power Level 2 .......................... 11 dBm

      Tx Power Level 3 .......................... 8 dBm

      Tx Power Level 4 .......................... 5 dBm

      Tx Power Level 5 .......................... 2 dBm

      Tx Power Configuration .................... CUSTOMIZED

      Current Tx Power Level .................... 3

      Tx Power Assigned By ...................... User

    Phy OFDM parameters

      Configuration ............................. CUSTOMIZED

      Current Channel ........................... 40


(Cisco Controller) >show ap config 802.11a Cisco_3502i

<output omitted>

Tx Power

      Num Of Supported Power Levels ............. 7

      Tx Power Level 1 .......................... 17 dBm

      Tx Power Level 2 .......................... 14 dBm

      Tx Power Level 3 .......................... 11 dBm

      Tx Power Level 4 .......................... 8 dBm

      Tx Power Level 5 .......................... 5 dBm

      Tx Power Level 6 .......................... 2 dBm

      Tx Power Level 7 .......................... -1 dBm

      Tx Power Configuration .................... CUSTOMIZED

      Current Tx Power Level .................... 3

      Tx Power Assigned By ...................... User

    Phy OFDM parameters

      Configuration ............................. CUSTOMIZED

      Current Channel ........................... 44


(Cisco Controller) >show ap config 802.11a Cisco_3702e

<output omitted>

Tx Power

      Num Of Supported Power Levels ............. 5

      Tx Power Level 1 .......................... 15 dBm

      Tx Power Level 2 .......................... 12 dBm

      Tx Power Level 3 .......................... 9 dBm

      Tx Power Level 4 .......................... 6 dBm

      Tx Power Level 5 .......................... 3 dBm

      Tx Power Configuration .................... CUSTOMIZED

      Current Tx Power Level .................... 3

      Tx Power Assigned By ...................... User

    Phy OFDM parameters

      Configuration ............................. CUSTOMIZED

      Current Channel ........................... 36


Looks like we have three different dBm power levels associated with these three access points, all in the UNII-1 band, and on WLC power level three.  We have the 3602i at 8 dBm, the 3702 at 9 dBm, and the 3502 at 11 dBm.

This information seems to not be readily available on Cisco’s website, however, I can point you to Brian Long’s blog, as he is working on a matrix for us:

After reading Brian’s blog and seeing all of the channels, I think abandon the 2504 WLC for surveying with the 3702 and us an autonomous image on it.  Here’s how to do that on a 3602i.


At least we know the 3602 and 3702 are somewhat similar for coverage patterns.  I also answered my own question – if I had WLAN with 3502 series APs deployed properly and met my requirements at the time it was designed, I believe I would still survey/re-design with today’s requirements in mind, and not just “swap them out”.










Saturday, March 7, 2015

5GHz WLAN Site Survey AP power settings - What you want, don't want, and don't care about.

I often see the requirement that a WLAN site survey and design must be done by the AP-on-a-stick method.  That said, you’ll want to use the same AP for your survey that you will use in production – or one that is similar. 

In this case, we are going to convert a lightweight access point to Autonomous, so that we can use it without a WLAN Controller.  The new survey rig is a Cisco 3602i, configured with 5GHz channel 157, set to 40 MHz.

How did we turn the lightweight AP into an Autonomous and do the quick and drity configuration?  The short answer is, we followed Richard McIntosh’s directions.  His blog, and a great “HowTo” is here:  Thanks again, Richard, for putting that out there for everyone to read.

We altered the power output of the new survey rig as sort of an experiment to see how the signal propagated, and where our -67dBm and -85dBm boundaries lie.  Why did I choose those numbers, you ask?  Well, -67dBm happens to be our design requirement for Cisco Voice over Wi-Fi.  The signal degrades as is leaves the AP, and gradually becomes weaker as you get farther away.  The -67 dBm is the “edge” of our cell.  You can think of this as, “the phones should be happy if our signal strength is -67dBm or higher”.  There is a “second cell”, which is the signal that is past the -67dBm edge, and its edge is -85 dBm.  There is a “third cell”, however it is not important, as it does not create any problems for us since it is too weak to cause interference issues.  Let’s talk about that secondary cell.  It isn’t really a second cell, but rather a continuation of the first cell, and we would rather it not be there.  If there is another access point on the same channel, and they both have an area where this secondary cell “overlaps”, they will interfere with each other.  We call this Co-Channel Contention, or CCC.  You’ll hear this also under a different name, Co-Channel Interference.  I prefer CCC, as I think it is a better description of what we are trying to describe.  In this area where the two “secondary cells” overlap, the two access point and client can all hear each other.  This is the problem, because if an AP and client are having a conversation, the other AP will be able to demodulate their conversation, and will not transmit.  Wi-Fi is an extremely polite protocol, and they are not supposed to “talk over one another”.  

There’s a great whitepaper from Keith Parsons about this “secondary cell”, in which he calls it the “Don’t want” area.  His whitepaper can be found here.

We are also interested in seeing what power levels were available when the AP is on a particular channel in the 5GHz band.  Access points can support different power levels of “loudness” when on different channels.  When it comes to designing our WLAN, we will base our design off the channels which are our lowest common denominator – meaning we will not use a power level setting that all channels do not support.  More information on power levels can be found on George Stefanick’s blog, which can be found here:

So, let’s get started!

We setup the AP in the corner room (where the little man is) and mapped out how many rooms we would walk for the entire test.  Each walk is the same, with no other change other than the output power.
Power level 2 dBm, which is lowest setting. Notice the -67 dBm boundary is at the second room.  This is the area we care about.  We’ll follow this graphic with the area all the way through our “second cell”, which is our “don’t want” area.  The grey area in the second graphic will be our “don’t care” area.
Here’s the area we don’t want (not counting the area from the first graphic, which is our "care"), all the way out to our “don’t care”, which is grey.
Next is power level 5 dBm.  Here, our -85 dBm “don’t want” made its way out to 5th  room, however the -67 dBm “want” coverage cell stayed the same.
Power level 5dBm, -67 dBm coverage. This is what we want and care about.
Next, we turn up the volume up a notch.  Power level 8 dBm didn’t change the -85 dBm coverage that much, however the -67 dBm. boundary increased to the third room.

This is power level 8 dBm’s “want/care” zone.

Power level of 11 dBm brought full -85 dBm coverage to five  rooms.  Our -67 dBm boundary didn’t change, and stayed at the third room. 

Power level 11 dBm “want/care” zone.
Next was Power level 14 dBm.  Our -85 dBm boundary increased to six rooms.  Just like the previous example at level 11 dBm, the -67 dBm boundary stayed the same – three  rooms.
Power level 14 dBm -67 dBm “want/care” zone boundary. .
As we increased to power level of 17 dBm, we noticed that the -85 dBm boundary remained at the 6th room, and the -67 dBm boundary also remained at three  rooms.
Power level 17, -67 dBm “want/care” boundary.
Channel 157 allowed us to turn the power level to 20 dBm.  As you can see, our -85 dBm boundary is six  rooms, and a little of the seventh  room.  The -67 dBm boundary remained at three rooms.
Power level 20 dBm, - 67 dBm “want/care” zone boundary.
The maximum power level that we could turn up to was power level of 23 dBm.  As you can clearly see, the -85 dBm boundary was 8  rooms!  The -67 dBm boundary remained mostly the same, at three  rooms, and a small portion of the fourth room.
Power level 23 “want/care” zone.
Now we see that turning up the power on our access points in an Enterprise WLAN mostly increases your “don’t want” area, and doesn’t really do much for the area you want/care about.  We are looking for the “sweet spot” power level/channel of this particular model of access point.  We feel that a power level of 8 dBm and 11 dBm for this particular model access point will be the basis for our WLAN design, and our goal for our power/channel plan.

I want to mention design requirements.  You must define your design requirements before you start designing an Enterprise WLAN.  In this case, this is a 5Ghz WLAN design, utilizing four channels of UNII-1, four channels of UNII-2, and four channels of UNII-3.  We’re going to be supporting 40 MHz channels, which equates to six non-overlapping 5GHz channels.  This design in particular is over a half million square feet of 5GHz voice over Wi-Fi coverage, which requires secondary -67 dBm “want” cells available to every portable phone.  That said, six channels of 5 GHz Wi-Fi will get used up quickly, and we want to keep those “don’t want” cells as small as we can!
As usual, feedback and questions are most welcome!