Wireless 2017: What We Wanted Then, and What We Want Today

As a wireless engineer, we study the 802.11 protocol. We read how the standard is written, study how it is supposed to work and yet seem to spend our time fighting why it doesn’t work.  Tweaking power, channels, datarates, toggling features and code versions in hope that things functions the way we want. I know I’m not the only one who is frustrated with the bugs, the oddities and the constant upgrades in order to make the box on the ceiling work the way we want it to.
My fellow MFD2 delegate Lee Badman wrote his thoughts on this just a few days ago:

Today is a day to look back and figure out where we went wrong.  And I’m starting 5 years back.  Mostly because I feel that 5 years ago is when things started to go wrong for me.  Maybe we sent the wrong messaging to the manufactures?  Some how they got the impression about 5 years ago that we wanted features.  Lots and Lots of features.  Things like traffic analysis with deep packet inspection, MDNS routing, dynamic PSKs, NAT, content filtering and a whole host of other absurd features that were created for a customer who’s pocketbook were larger than their understanding of network architecture.

The first question I need an answer to was “What did we really want 5 years ago?”  The answer for me was stability.  I want to get away from having conversations about “what version of code should I be running?”  No other questions has occupied more of my time with a customer than this.  Even the cloud players have those “these aren’t the code versions you’re looking for” moments. A close second being “why is this thing happening” of which the answer is always dependent on a deviation from the answer to the first question.  

What if we had addressed this stability issue 5 years ago?  What would we be asking for today?  Part of me can’t even conceive of something so far fetched.  But trying to open my mind, I would want these systems to help us on our journey to better Wi-Fi.  “Tell me what I’m doing wrong, tell me why things aren’t working, and tell me how I could go about improving it.”  I really think these are the ultimate questions about Wi-Fi. The answer probably isn’t 42, but maybe i’m wrong.  

Answering these questions was THE theme at Mobility Field Day 2:

Mojo Networks had their Client Aware dashboard, one of the most elegant UIs for monitoring I’ve seen.  And even just deploying it in my lab, it was spot on with my issues.

Mist Systems is bringing AI in to help answer those questions, running on every AP and looking at every client, every minute of the day.  And attempting to answer why you don’t meet the SLE metrics for your network.  Their AI virtual assistant is early, but it’s moving in the direction we all want to go.

Cape Networks is an overlay sensor to monitor any existing Wi-Fi network, baseline it, and report on issues it detects.  One of the best interfaces for defining tests that the overlay network performs.

Nyansa is all about monitoring the end user experience and correlating it to wireless and network settings and issues.  It looks at everything going into or out of your WLC and provides intel down to the client level.

It’s my opinion that if you’re in the the Wi-Fi game today and you aren’t starting to address how your system can answer these questions in a stable way, it’s time to rethink your approach.  Management in the cloud is not enough.  Fabric is not enough.  Features are not enough.  Stability might be enough for some.  But stability with actionable intel about how things are performing and a direction of continuous improvement is answer to “What we want today.” 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s