What I learned from the CWAP

Having just challenged and successfully passed the recent version of the CWNP’s Certified Wireless Analysis Professional (CWAP-402) exam, I wanted to put some thoughts down on (virtual) paper about the experience. **DISCLAIMER** I’m not going to talk about, or even hint at the exam’s contents, you’ll have to book and experience it for yourself.

To start, what’s important is knowing who the Certified Wireless Network Professionals (CWNP) are, and why the program is so universally relevant.  From their website, https://www.cwnp.com/about  – “Certified Wireless Network Professional (CWNP) is the IT industry standard for vendor neutral enterprise Wi-Fi certification and training.”  The greatest part, for me, about the whole CWNP is the vendor-neutral part.  Talking to people about certifications I generally break it down this way; vendor technical certifications are typically focused on “how” to implement a solution or product X, which is good, has its place and is definitely important.  What the CWNP process offers though is the “why” and universal wireless truths.  Here’s a video breakdown of the learning track with the levels and disciplines: https://youtu.be/VuhONgb6rIM


For me, the CWAP exam represented the final of the three CWNP exams I needed to successfully challenge and complete before I could submit my application for the Certified Wireless Network Expert (CWNE).  It’s been a common comment and axiom in the wireless community that people should probably complete the CWAP first before the Design (CWDP) and Security (CWSP) Professional tracks. However, my job history and duties have dictated the order I’ve completed things.  Years ago, I was exclusively involved in the pre-sales and design phases, so learning the CWDP realm was most relevant.  Later, after a job change when I became fully engaged in the installation and operational phase, I had to take on a constant load of access control projects with Cisco’s Identity Services Engine (ISE).  This meant that for me at least, learning the CWSP material made the most sense.  So, like Keith Parsons (@KeithRParsons) says for a lot of wireless things, “it depends.”

Having said that, the CWAP, for me, was one of the most in-depth, challenging and interesting exams I’ve pursued.  When I say that, I don’t mean just the actual writing of the exam, I mean the study process as a whole.  If you’re studying for this exam, you must completely and totally commit and immerse yourself in the topics to get the most out of it.  Let’s look at the exam topics from the official CWNP website (https://www.cwnp.com/certifications/cwap):

  • 11 Physical (PHY) Layer Frame Formats and Technologies
  • 11 MAC Layer Frame Formats and Technologies
  • 11 Operation and Frame Exchanges
  • Spectrum Analysis and Troubleshooting
  • Protocol Analysis and Troubleshooting

When you read each of those five topics it’s very clear that you are going to be learning the foundations and nuts and bolts of the entire 802.11 process.  Not only that, but you have to know it cold, in detail and you will need to know how to use all the tools that test and troubleshoot the medium.

So now to the meat of it, what did I actually learn from the CWAP?  I definitely learned all the nuts and bolts of the Frame Control fields, not to mention the composition of the PHY Preamble and PLCP Header.  Wireshark filters for specific frame types and all the different frame types and subtypes in binary notation.  Oh, I filled two notebooks with facts, figures, sketches and scribblings.


But for me at least outside all the esoteric trivia I came away from the CWAP process with one lesson that is burned into my brain like never before:  how 802.11 wireless works.  I question the odds of me ever having to recall a great deal of the natty little details, especially if I can just look them up in reference materials, but when I put all those little bits together, I have a crystal-clear, unadulterated understanding of how and more importantly why 802.11 wireless works the way it does.  A good example of this would be with wireless Quality of Service, defined under the 802.11e amendment with Enhanced Distributed Coordination Access Function (EDCAF).  Studying and going through the CWAP process showed me exactly where in the 802.11 process QoS is applied, what exact parameters can be influenced and modified, how to troubleshoot to the nth degree, and most importantly, that it provides only probabilistic not absolute priority to clients.  For me that was huge, not just technically, but also for setting expectations with customers on what wireless QoS can actually accomplish.

Here’s a list of the core reference materials I used.  I also have to say that a home lab where you can capture wireless frames and analyze them in different scenarios is absolutely essential not just for this, but for any WiFi professional:

So here’s my advice to those who maybe just passed their CWNA and are trying to chart out their next step: study the CWAP content now.  Even if you aren’t going to challenge the exam, or are going to first challenge one of the other CWNP exams, or a manufacturer exam, pick the study guide(s) up and read them.  The core content within will help you with every single other piece of wireless learning you do. Enjoy the process, and good luck!

Designing for VoWLAN Part 1

Part of my job involves supporting my consultant peers in other cities/provinces with wireless projects.  For the most part, it means either assisting with wireless troubleshooting or doing the preliminary predictive designs and high/low-level design documents for a project.  One of these scenarios just came up, and I wanted to journal it, mostly for myself to look back on.

This particular customer is moving from their old offices into new buildings, four of them, and they are planning to leave the old WLAN infrastructure behind and start from scratch.  First few pieces of information I look for with any WLAN design is: scale floorplans to import in my Ekahau planning software, what are the client use cases and what physical devices they want to service with the new WLAN.  I find this is the basic starting point for most WLAN design efforts, kind of a wireless “design trinity.”


As anyone who’s done wireless design knows, getting what seems to be simple information from a customer can be challenging at best, and most of the time comes in dribs and drabs, and incomplete.  This case was no different; the floorplans had no marked scale, were PDFs, and were missing several floors, plus one whole building – encouraging start.  The use cases were fairly vague, but what did perk my ears up was that they wanted to use Skype For Business as an organization-wide collaboration tool.  Unfortunately, as I’m writing this, I still don’t know specifics on the actual client devices.  But if Skype is business critical, and I’m basing the design on the “neediest” use case, then I’m going to assume it’ll be running mostly on laptops and smartphones/tablets. In the absence of any other details, I send out a questionnaire and get the design started.  What I find is a good basis for any and all WLAN designs is captured in a past Ekahau webinar: http://www.ekahau.com/wifidesign/blog/2016/06/09/wi-fi-infographic-critical-aspects-tips-and-tricks-for-wlan-design/

The first thing I like to do when starting a WLAN design is I do an initial predictive design.  It gives me a general idea of AP quantities and types which are good for planning backend infrastructure like controllers and licensing, but even just drawing in the walls, aligning floors and shuffling APs around gives me a sort of “peace” where I can start visualizing what I’m going to want to look at during the validation, how I would configure things, test plans, the whole install strategy.  I use the Ekahau ESS Pro planning software, so with that fired up, and maps imported, I began to look at the design requirements and translating them into Ekahau-speak.  Lucky for me, Jussi, Mikko and the Ekahau crew have gift-wrapped WLAN design requirements for Skype already!:


With these design requirements, making the predictive design “pass” wasn’t too tough.  The biggest test was meeting the Channel Overlap requirement.  To start, I made the decision to write-off the 2.4 GHz band for mission critical applications.  Just too many limitations, not the least are the limited number of non-overlapping channels.  5 GHz has far more frequency space to play in, so my first recommendation was to have any “corporate” SSIDs solely reside there, with 2.4 GHz reserved for guest or non-critical use.  With 5 GHz as the primary band, Channel Overlap and Co-Channel Interference (CCI) mitigation became a lot easier, but still one other decision to be made – channel width.  802.11ac gave us 80 MHz-wide and the theoretical 160 MHz-wide channels.  The problem is that every time you bond and double-up your channel width from the base 20 MHz to 40 MHz, then to 80 MHz, you reduce your number of usable, non-overlapping channels.  20-odd channels become 4 or 5 pretty quick.  With that in mind, I made the design decision to limit the 5 GHz channel width to the base 20 MHz only.  My rational was that it was likely I’d need a higher than normal density of APs to support the client use case (which is what this is about), and I would need the maximum number of channels in my reuse plan.

So I started placing my simulated APs in the predictive model, with constrained transmit power settings to control their cell size, and statically setting the operating channels to prove out a CCI-free environment was possible.  Success! (green means no calculated Channel Overlap)


For the most part, the remaining exercise of the predictive design was tweaking to meet the design requirements like SNR and coverage.  One big, but often overlooked factor in designs, especially with high-roam apps like VoWLAN, is Secondary Cell coverage.  Primary cell coverage is pretty easy to achieve, but for VoWLAN, you’ll want to have a secondary cell coverage that will allow devices to gracefully roam as they move without dropping packets and cutting off conversations.  The trick I find is that when you start adjusting for solid secondary cell coverage, you can introduce CCI without meaning to.  This is where the tricky part came in, but in the end, I managed to get quality secondary RF coverage in the key areas where these users would be congregating, while maintaining a (theoretical) CCI-free environment.


So that was it for that phase, run the reports and write a nice summary to give all the heat maps some context.  The next steps are probably going to look like this (I hope):

Pre-Install Validation survey – unlikely to do a full APOAS survey, they seem like an inefficient use of time and effort given the tools and knowledge we now have.  At the very least, though, do some material attenuation testing, which IS important.  That predictive design I did, it’s predicated on some assumptions, foremost amongst them is the materials that the walls are made of and the attenuation effect they have.

Order, install and configure the gear – pretty straightforward, especially with a plan.  I’ve found that when you spend a lot of effort on a detailed low-level design, and Method of Procedure (MOP) for the AP installs, the actual installation phase can go very smooth.

Implement the business-critical clients and use-case – my recommendation was that the customer deploys wireless and offer a status quo situation as far as services go.  This will allow for a post-installation survey and remediation phase without disrupting important business processes.  It’ll also give time to do extensive client testing with the Skype application and the client devices running it.  A while back George Stefanick (@wirelessguru & @my80211) gave an amazing talk on the all-wireless office he and his team deployed, and one of the key lessons I got from it was how important exhaustive client testing is to the success of a wireless project. Check it out: https://www.youtube.com/watch?v=3RAyHNN_49Q&feature=youtu.be

So that’s it for now.  My hope is the next phases will fall into place as planned, and I’ll have a Part 2 of this post to write.

Sell Outcomes, Not Boxes

I like boxes I suppose. I appreciate the little ones APs come in for their efficiency in packing all the stuff into a small space.  The boxes that the WLCs come in are great for shipping Christmas and Birthday gifts across the country to family. As far as utility, a solid cardboard box has it.  Then you take a look at the boxes inside the boxes.  They’re making those new APs sleek and aesthetic and so, so pretty. Tiny, pretty boxes that push a million Jigabits now, with fewer calories and Full-Duplex with blinky lights.  For your server racks, we have boxes that fit in a standardized and uniform fashion – server and appliance boxes all lined up in an orderly, vertical row.


But I have never, ever had a customer call me and ask me to sell them boxes.  Never had a customer conversation go like this:

“Mr. Chappelle, it’s Mr. Smith at ABC Company.  Was wondering if you guys could sell us a couple hundred of those little WiFi WAP-thingy boxes, and oh, heck, throw in a couple of those big boxes, what do you call them?  Controllers?”

Doesn’t happen, ever.

What does happen is I get calls from customers and they are looking for an outcome, and they think that it has something to do with, or can be achieved with wireless technology.  Now I’m no expert on sales, but when someone has a problem and is looking for a solution, designing that solution towards an outcome is a lot easier to sell to a customer than just moving pallets of gear and boxes because they’re the newest, shiniest, <insert marketing bs>.  That’s not saying that upgrading, migrating and evolving to new technology should be discounted, not at all.  There are tons of new features, performance increases and functionality being added in the wireless space, and the rate of change is only growing.  But implementing this new gear and their new features has to support an outcome for the customer.  I recently read a tweet responding to the great @wirednot #WIFIQ and the great potential the upcoming 802.1ax amendment will be for WiFi.  The response basically said, “we don’t need faster than 802.11n performance, so not of impact.”  The point; more Jigabit-capable boxes would not support a positive business outcome for this customer.

Here’s another point to consider; many of us work in a system integrator or vendor environment that provides services/products other than just wireless.  Now, just think if you go to a customer and say, “hey, there are these new WAP-boxes that go super-uber-faster than the ones you have now, want to buy some?”  Then let’s say you sell them, and then swap out the old WAP boxes for the new WAP boxes.  Now on your way to the bank to deposit your commission cheque, the customer find out from a consultant, Gartner, or the good old Interwebs that the boxes you sold them really weren’t necessary for their business.  Short-term box-selling impulse just broke one of the hardest things to grow with a customer, trust.  That broken trust isn’t going to help down the road when maybe in six months they’re looking at moving to “the cloud,” or issue a storage RFP (they might not have issued if they trusted you).

The flip side to that is when you support and deliver an outcome for a customer, the trust, and long-term relationship only improve.  Real life example:  a customer approached me a while back, usual story “our WiFi sucks, guests complain constantly, we need new Wifi.”  The easy response would have been to just do a like-for-like swap out (more or less), replacing the old WAP-boxes for new ones, hung up in places I thought were better based on surveys, design, etc, etc.   Instead of just doing that, we sat down with the senior business leaders, took a long tour of the facility, took the time to understand their business and what they were looking for in an outcome, and then came up with a roadmap and strategy to transform their business through an infrastructure upgrade, including new wireless. The result was a successful project, tremendous customer satisfaction, and deal revenue five times what a mindless box replacement would have reaped.  It was a big win, for all sides, because the focus was on the outcome, not some boxes.

Dark Tale of Data Rate Pruning

It turns out, even in WiFi, there’s sometimes too much of a good thing.  Take Data Rates for example.  Wireless design best practices, the CWDP included, generally recommend disabling the lowest data rates in a wireless network.  We do this to prevent slow clients that can only support (for various reasons) the bottom data rates from slowing down all the other clients that are connected at higher performing rates – shared medium remember?  It’s become common for people to disable all the DSSS rates in 2.4 GHz (1, 2, 5.5 and 11 Mbps) to keep the ultra-damaging legacy 802.11b devices from crippling the network. So generally speaking, we design and implement modern wireless networks with data rates pruned somewhat to improve performance.

To set the stage a little, I have a customer that is a retailer, with stores all across Canada.  Their set-up on the wireless is pretty simple; Cisco hardware that’s a little long in the tooth, but serviceable.  They have Guest WiFi exclusively on 2.4 GHz and the Corporate and VoWiFi on 5 GHz only for simplicity. I got contacted recently because their Cisco 7925 wireless VOIP phones are “cutting out all the time and unusable.”  Lucky for me this is reported in the local store, so no airplane-time.  The contact asks me to go to site, because he suspects there are holes in the coverage, and he’d like me to walk around and survey the store for signal strength.  Since the store isn’t all that large, I do a quick walk around, gathering survey results in ESS and take a peek:


No real gaping holes in the coverage, maybe a little hot (we lowered the RRM Tx Power Max Threshold), but there isn’t anything that jumps out and says “hey that back stockroom has no signal.”  Time to look at the WLC I guess.

The customer had taken my advice a while back and had created separate RF Profiles for each store for flexibility.  Take a look at what I found when I went into the 802.11a profile specific to that store under the 802.11 tab:


I’m all for pruning data rates, but this seemed a little….extreme.  The disabled MCS rates aside, having Basic Data Rates disabled all the way to 48 Mbps can’t be a good thing.  Not for a client device that’s portable in the extreme, walking around a store with displays and shelving, and doors to go through, and all with a real-time VOIP call going on.  There’s bound to be a time that phone feels the need to rate shift because maybe the SNR just isn’t enough because a canoe or a human body got in the way. Without some lower data rates available, the phone just dropped its association and the call.

Sure enough, we enabled the data rates down to 24 Mbps, making it Mandatory, and the report back from the store a couple of weeks later was “working a million times better, no dropped calls.”  Lesson learned; most everything in moderation, and a little bit of thought before enabling or disabling something.

Warehouse Wireless – A Tale of Emergency RF Design Surgery

A few months ago I was engaged by an Account Manager to take a look at an issue that one of his customer’s was having in a warehouse space. Basically, the wireless coverage was so bad they couldn’t do their job: that was the diagnosis I was given, and it was up to me to fix it.

First step, discovery. How often do we talk to a customer or a sales person and get told “the WiFi doesn’t work,” and that’s the limit of the details we receive? So, I got on the phone and called the company ‘s IT manager to get the skinny on what was happening. This warehouse (in my hometown, Calgary) was the stocking distributor covering all of Canada for this company. They had a wireless LAN installed several years before, but “it never worked that well.” The users in the warehouse had two specific use-cases that relied on quality wireless: bar code scanners – Intermec model CK3’s, and Vocollect Talkman A720 Wireless Headsets. Office users used a different SSID for “data” coverage, but it wasn’t considered critical. Next step, establish a baseline and quantify the current RF environment through an onsite wireless site survey.


The warehouse itself wasn’t all that large, small by the standards of most. From a layout perspective, all the aisles ran in an East-West fashion, which would help with coverage planning. On the downside, these aisles were super narrow, maybe four feet across. Plus, the metal shelving almost reached the ceiling, thirty-five feet in the air. This made the deployment of their current WLAN even more challenging because the APs were mounted to the ceiling. There were four Cisco model 1242 APs suspended from the ceiling rafters, roughly a foot above the tops of the shelving. To make matters worse, the antennas selected were dipole, omni-directional types, suspended from the same rafters; and only servicing the 2.4 GHz radio band! From a very basic point of view, this deployment was doomed to fail. When I describe the RF propagation pattern of an omni antenna, I often say it looks like a donut on its side, and that its effective coverage area extends roughly twenty feet down. These antennas were: a)not going to reach the ground/users b)deployed in the wrong spot and c)only serviced one radio band. Breaking out my laptop and firing up my Ekahau Site Survey tool, I was able to confirm and quantify just how poor the coverage was, all due to bad design and equipment choices.


Presenting the findings to the customer resulted in a solid plan of action: design a proper deployment, do a proof of concept and then deploy the planned solution. I like the opportunity to do a proof of concept, it is more or less an APOS survey, but it validates the plan not only for you as the engineer, but shows the customer that you know your stuff, and that the plan will work.

The design called for the following: replace the ceiling mounted, omni-antenna-equipped old APs with new, directional-patch antenna-equipped APs “shooting” RF down the aisles for pervasive coverage. Staying with Cisco infrastructure seemed to make the most sense; they had an existing investment in their controller and licensing, plus their other locations had Cisco WLANs, so Day 2 operational support could stay consistent. Cisco model 2702e Access Points and ANT2566 patch antennas were the gear chosen for the new install, but I needed some flexibility in mounting the antennas – a flat-wall mount wouldn’t work for me, I wanted to down-tilt the antennas slightly. @AccelTex and @elonsmitty to the rescue. AccelTex makes a wide range of accessories, like antenna mounts, for wireless installs that are a lifesaver.


Installation day finally came, and all went according to plan. Once you get past the unique deployment model, the install is pretty stock. Cables were run and terminated, APs and antennas mounted, oriented and configured. There were some key configuration choices made, specifically to tailor the RF to the space and requirements. First off, 20 MHz channels in 5 GHz because of how many APs/antennas required, and the fact the DFS channels had to be disabled (next door to the airport literally). Enabling any sort of channel-bonding would have ruined the channel reuse plan and created unacceptable levels of Co-Channel Interference (CCI). The mission-critical users didn’t need high throughput, they needed reliable connections! Always remember who it is you’re serving, and what they need the wireless service for. Another crucial parameter that needed to be set was the Maximum Transmit Power threshold in the RRM section of Transmit Power Control (TPC). I know that a lot of people hate automatic RRM, but I find that within reason, and if setup properly, it is up to the task in the right situation. In this case, the default maximum of 30 dBm (which is insane IMHO), was lowered to a more reasonable 17 dBm which matches one of the 5 GHz power settings of the 2702e AP.

All that remained was the all-important post-installation validation survey and any fine-tuning. The post-install survey results looked very similar to the plan, which is exactly what you’re looking for. Because the design was optimized for the 5 GHz band, the mission-critical devices needed to move there. Fortunately, the scanners were smart enough to jump there automatically (with a little help from Band Select), but the “potatoes”, the A720 Voice Pods, needed to be manually configured to work on the 5 GHz band. Having a post-install survey report showing quality coverage throughout the facility is great for quantifying the success of the project, but hearing from the customer that “there hasn’t been a single ‘beep’ from us getting disconnected” is pretty rewarding and a good success measure too.