What Would Clients Do? (WWCD)

I have a lot of friends who live ‘down south’ and are strong believers of a Christian lifestyle. When visiting those in the ‘bible belt’ I’ve noticed this phrase “WWJD” – for “What Would Jesus Do” – on bracelets, lockets, bumper stickers, everywhere.

In our craft of working on Wireless Networks… we need to have our own phrase to follow:

In many of the Wireless Networks I’ve worked with, the designers, installers, and folks who have to maintain the network get all focused on the Access Point side of the equation. Worrying about the APs are doing, is there adequate coverage, what the controller reports, etc.

But when was the last time you had to directly troubleshoot an AP?

No, we are always tracking down problems with the clients, yet we do our entire Wireless LAN designs with Access Points in mind.

I’m suggesting we start thinking more and more about the Client side of the equation. Thus, “What Would Clients Do” should become our watch words.

Here’s some examples of where to think from the Client’s perspective instead of from the Access Points:

Coverage Overlap – the Client wants to see a ‘primary’ AP and a ‘backup’ AP – they don’t care a bit about what the coverage looks like on a floorplan. Measure for Primary and Backup coverage in dB – not in percentage.

Channels – Clients will *always* move to the channel of the AP their algorithm chooses as ‘best’. Don’t worry about channels from a client side, make sure your AP’s channels keep co-channel interference as small as possible.

Collision Domains – from the Client’s perspective, all those APs and other clients that it can ‘see’ from wherever it is, it has to contend with, and wait for, ALL of those to access the frequency to send it’s own frames. Thus many times when the human clients complain about a ‘drop’ in their wireless, they are referring to the delay caused by a collision domain, NOT by a lack of RF coverage. Minimize Collision Domains by LOWERING POWER.

Coverage – we tend to want to have more and more power, but that’s NOT what Clients want to see. They need to have one strong signal, a backup signal, and then as little as possible. You can measure this by turning on your favorite tool of choice, and seeing how many APs you can see at what RSSI levels from any location. If you are troubleshooting a Client, and yet at that location you can see more than two strong APs, well you don’t have an RF coverage problem! You have too much coverage and that causes a collision domain, and all the bad things associated therein. Design for adequate coverage, not too much coverage.

Heat Maps – many vendor’s controllers will show you ‘heat maps’ — but this is from the Access Points perspective, the Clients are not included in the equations. If you want accurate heat maps, you must do a survey with a client, at a client height. AP to AP communications, though nice, are NOT sufficient to know what the clients will see. Survey regularly with a client, at client height, with regular traffic loads, to get accurate heat maps to really know what your coverage patterns look like.

Dropped Sessions – sometimes we opt to think when laptops somehow lost a connection, it was caused by a drop in wireless. Many times it isn’t a lack of signal, (see coverage above), but a dropped connection higher in the stack. If you were trying to diagnose a wired laptop who complained about a ‘dropped connection’, but when you arrive on scene the ‘link light’ is still glowing steady, would your first thought be the patch cable is somehow broken and merely replace the patch cable? Of course not. Yet many times our first ‘solution’ is to look down the stack to the MAC and PHY layers–only because we can easily see the ‘link light’ on wireless. If a clients is still associated to an Access Point, the problem is higher in the stack. Remember, association is to wireless what a link light is to wired.


Well, you get the idea. When ever confronted with a troubleshooting problem, designing a Wireless Network, or tracking down a human client’s complaint, always think to yourself:

I welcome your comments and suggestions on this and other Wireless topics.