Tuesday, September 6, 2016

Jake's Rules of Wi-FI Design

By Jake Snyder

One of the guiding principals of the my wireless career has been to engineer wireless networks that meet my customer's goals. In order to achieve this, I  had to break down some of the complexity of RF design into rules to help myself design wireless networks.  This is not an exhaustive breakdown of RF engineering processes, but it is some very basic techniques to improve RF design.

But over time these rules either hold true or fall out.  Often rules get absorbed into a more generic rule or divide into more specific rules.  I'll attempt to describe the rules and how they function as part of a wireless design.

Rules of Wi-Fi design:
  1. Capacity first
  2. Put RF where clients are
  3. Use Attenuation to your advantage 
  4. Use antennas to your advantage
  5. Coverage > Capacity or as i like to call it "I'd rather have co-channel than no-channel"
  6. Design in 3 dimensions
  7. Take RRM algorithms into account
  8. Take device capabilities into account.
  9. Predictive models are only as good as the data you use to build them.
  10. Design up and down the stack
I know some of these will sound odd.  Let me give some brief descriptions on what I means by some of these.

Rule 1: Capcity First
Knowing how much capacity you need in a given space is paramount.  This enables you to plan for the number of cells you need.  Only then can you know where you need to put the APs in order to meet your goal.  Also, this helps you realize when your goal is unrealistic, improbable or impractical.

Rule 2: Put RF where clients are
This rule is pretty straightforward.  If you want people to use wireless devices in a room, why would you install APs in places that aren't that room? This can also be the "Put APs close to where the bulk of clients are" rule.  Reducing this distance, increases signal strength for clients, increasing data rates.  If you get more clients closer to the AP (or vice versa), you can leverage faster data rates, and therefore create more available capacity.  

Rule 3: Use attenuation to your advantage
This rule is all about building capacity.  While most people get that attenuation helps shrink cell sizing, it also shrinks contention domains which can be dramatically bigger than the coverage cell.  Reducing the contention domain allows for greater channel reuse and ultimately will result in higher performing networks.  Remember, capacity gains are only realized when you are not sharing the spectrum with another AP.

Rule 4: Use antennas to your advantage.
A great way to keep a cell size small is to reduce the amount of RF you are putting into a place that you don't want.  For example, putting omni antennas in a high ceiling manufacturing area.  There's a significant amount of RF going up that you probably don't want.   Instead, a patch (even a wide patch) antenna pointed down can help reduce the amount of RF energy going up into the ceiling.  Also, directional antennas can help seperate clients into cells.  Load-balancing mechanisms aren't needed if clients can easily see which AP they should be connecting to.

Rule 5: Coverage is greater than capacity (aka I'd rather have co-channel than no-channel)
I know this rule is going to work some WLAN pros up.  Notice that I didn't say "design for coverage."  The intent here is that you can easily measure the performance of no coverage (it's zero).  In an ideal world there would be no co-channel interference, but in reality you cannot entirely eliminate it.  This rule embodies that you have to have coverage before you can have capacity and helps in your design methodology to make sure you start with getting coverage to an area and then iterate through your design process building capacity.  And there are times when you must make a choice, either not covering an area or introducing some co-channel interference.

Rule 6: Design in 3 dimensions
A lot of people talk about measuring wall attenuation to aid in their predictive designs.  Just don't forget that in some buildings you will have less attenuation between floors than you do across walls.  Measure the floors and take it into account.  If you can't account for the inter-floor attenuation, you could see substantially higher co-channel interference that you didn't account for in your model.

Rule 7: Take RRM/ARM into account
If you plan to use RRM/ARM, make sure you understand how it works.  My belief is that these technologies reduce ongoing operational costs by reducing the impact of environmental changes.  Every vendor does different things with their auto channel and power settings.  Understand how these work and how you can help these systems make good decisions.  Fail to do so may result in poor decisions.

Rule 8: Take device capabilities and behaviors into account:
Our client devices vary wildly in capabilities.  Rarely do you ever have the pure 802.11ac client mix.  Make sure you take client capabilities into account with regard to your capacity planning.  Spatial streams, supported channel widths, modulation rates, required rates can all have an impact on how much capacity your cells are going to have.  Failing to design for device capabilities and capacity is designing to fail.

Rule 9: Predictive Models are only as good as the data you use
All models are wrong, some are useful.  The easiest way to getting useful models is to make sure that your models reflect what you see in the real world.  Measure wall attenuation, cell sizes, floor attenuation, etc.  Use these as inputs into your predictive models.  Then sanity check your model to make sure what you predict aligns with what you saw.  If you blindly trust that the wall is "Dry wall with metal studs," you will find that sometimes it's accurate and sometimes it's not.  

Rule 10: Design up and down the stack
While the goal of this article is Wi-FI Design, Wi-Fi needs to be design up and down the stack.  Layer 2 design, routing, DNS, DHCP, firewalls can all be contributing factors to how a network performs.  Make sure you are taking these other components into account as well as designing the RF.  WiFi is a system, it should be designed as such.

As with most things in Wi-Fi, everyone will have opinions about RF design.  These some of mine.

Wednesday, August 24, 2016

Why validation surveys aren't enough, the importance of functional validation testing.

I've been thinking a lot lately about post validation surveys and what value they provide.  And I'm starting to wonder if the premise of validation surveys isn't being realized. After all, what exactly are you validating?

I've seen surveys that looked great, -67dbi coverage, 30 SNR,  no CCI, no interference, and yet those site have been the receiving complaints about the wifi.  A visit to the site illuminates some challenge that the survey didn't convey, and usually easily remedied.  Sometimes it's RF related. Sometimes configuration.

Surveys don't lie, but they tell the story from their perspective.  Let's call this subjective reality.  And the reality that your survey rig sees may vary dramatically from what other devices see, so much that it appears false.  Think of a cog native bias around how Wi-Fi works as seen by the device testing it.

There has been a lot written on "compensation" lately and how we can compensate the delta from the survey device to the real device. But I don't know if this can overcome enough of the differences between our survey device and the variety of devices out there.  Sure, I can compensate a fixed amount from my survey NIC to the actual device.  Is that compensation value flat?  Or is there a compensation value per channel?

And then let's talk about noise, SNR, overlap, roaming, etc.  Can we compensate for all of these variables per channel?  Suddenly compensation seems about as practical as calibration.  Then we have another view to consider: how the APs see things.  So how do we validate networks?  

Functional Validation Testing:
Personally, I think engineers spend too much time focusing on surveys and not enough time validating that the network meets the requirements for the devices using it.  That means getting the actual devices on the network and testing that they meet the requirements.  Who's requirements?  The business requirements for their devices.

Ever seen a device that fails to roam if it sees more than one "good" candidate?  Those are fun.  What about an iPhone that can see a network but won't automatically associate to it even when configured to?  But... But... But... The survey results look fine.  You won't find those problems on a Windows machine running your favorite survey software.

Take that forklift and barcode scanner for a ride and make sure it roams and works they way it's intended.  Spend a day walking the facility measuring voice call quality, roaming, throughput, etc with the devices that will actually be deployed.  This ensures that you know and understand the device, how it will be used, and identify places where we may have issues.  Have actual workers show you how they use it.

This process also makes you think about how you can validate if the device works normally.  Maybe it's packet captures looking for L2 retransmission?  Measured roaming delays?  Maybe it's constantly scanning a barcode into the order management system as you fly by on a forklift.  Maybe it's wired side packet captures looking for Telnet or SSH sessions dropping and reconnecting within a specific amount of time.  Or, if you are lucky, it might be putting the device into a survey mode and see how t sees the network around it.

Spend the day after the turn-up working onsite.  Find a comfy chair and work wirelessly for the day.  Take every device you can manage with you.  Make sure they behave as you expect them to.  See odd behavior?  End users will too.

Now, before I get a bunch of angry emails, I'm not saying validation surveys are dead.  I'm saying that we need to spend more time validating the actual devices and less about a relative measurement that may or may not be indicative of a how well a network performs for specific devices.  Validation surveys give us a relative baseline from which to judge a network, which is valuable.  It does not however tell us how well a network functions.

As my friend Chris Lyttle (http://www.wifikiwi.com/) so eloquently put it: "It's a system, all things matter."  Validating the RF is one thing, but testing the rest of the system is just as important.

Thursday, August 11, 2016

CMX Cloud with Mobility Express is here

For some, Mobility Field Day 1 may be a distant memory.  The first Mobility Field Day Cisco brought Cisco to the delegates to talk about CMX Cloud.  Simply taking presence analytics to the cloud wasn't all that interesting to me.  Prior to 8.3 code you needed a proxy server to convert the NMSP data from the controller to an HTTPS connection to the CMX server in the cloud.  This was a bummer for me because now I have to deploy a server to run the proxy on, as well as a WLC to connect to CMX.   And if I'm deploying a server infrastructure at a site, why not just run CMX locally?

But not all was lost, Cisco told us the plan was for 8.3 to support a native connection to CMX cloud.  So that removes the server requirement, but what about the WLC?  They also announced that Mobility Express (the WLC software running on an AP) would support this direct connection to CMX Cloud in 8.3, removing the requirement to have a physical WLC and controller licensing for this deployment.  This is great news for distributed organizations like retail that want to gain presence analytics, but are shy about either deploying gear locally, or building/leveraging their WAN circuits for this.

Fast forward to today and 8.3 code for Mobility Express is published on Cisco.com.  I was asked to build a CMX demo for the upcoming Interface Boise conference in a few weeks, so I decided what a great opportunity to try out CMX Cloud with Mobility Express.  In just a few minutes I had reset my 1832 AP running Mobility Express and run through the initial setup.  A reboot later and the Mobility Express AP was up and operational.

Now for the CMX Cloud component.  I signed up for a CMX Cloud trial at cmxcisco.com.  It warns you that it can take up to a day to receive your account info.  Less than an hour later, I had my login credentials, server url and authentication token.   Going to the Mobility Express GUI, I was able to configure this with a minimal effort.

*Note: I ran into an issue where during the Mobility Express initial setup, DNS was listed as optional.  When you setup CMX, it NEEDS the DNS server functional to resolve the CMX server URL and to build the needed ACLs for the CMX Connect functionality.  You can configure DNS on the CLI of the Mobility Express if you don't want reset the AP and rerun the setup.  Once DNS was setup, the CMX configuration on the AP worked flawlessly.

If you're familiar with CMX Presence, the setup of CMX Cloud for presence is quite straight forward.  First you create a site and add your AP to CMX.  Remember it's the base radio MAC, not the ethernet MAC.  

Once you have the site created and the AP added to the site, I verified that I saw the Mobility Express controller connected to CMX and that I started to receive data.

Now that the AP is talking to CMX Cloud, for the next part all I had to do was wait (for data to populate).
The AP was running at my desk in the CompuNet Meridian office.  Pretty quickly i started to see the Insights panes starting to get populated.

I found the insights pretty interesting.  Our local engineering team is still edged out on Intel PCs vs Macs, but it's close (51 to 46 in the last 7 days).  I did find it interesting that 12-1 was he peak hour, considering the number of people who go out for lunch.

All things considered, this solution looks really well thought out, easy to deploy and simple from the fact that the only hardware required on-site is the Mobility Express AP.  I’m also really interested to see what this data looks like for the day of the conference (which is the whole point of the demo).

For the future, I think having location as part of this offering would be cool.  However, I think that the need to have maps in Prime Infrastructure and sync that to CMX might be more cumbersome and really take away from the minimal hardware needed.  Maybe this is an opportunity for Prime Infrastructure in the cloud (Or a “Prime Lite” in the cloud).  I also like the fact that I don’t have to manage the box.  It has been exceptionally stable and not having to update it periodically exemplifies why this belongs in the cloud.  This is really attractive when you realize that Cisco markets this to non-IT folks.  IT Doesn’t have to support it aside from 3 lines of config in the Mobility Express AP, and the rest can be managed by the marketing or BI folks.

It should be noted that Cisco provided me with the 1832 access point as part of participating in previous Wireless Field Day activities.  The CMX Cloud was provided by Cisco as part of a 60 day trial.   

Monday, April 4, 2016

Aruba AP 330: Resilience and RF Performance in the Access Layer

It's an interesting time in the industry.  Each AP manufacturer is trying to differentiate against their competitors.  We're seeing speeds, feeds and radios popping up all over the place.  I recently had a chance to look at the new Aruba a Hewlett Packard Enterprise Company 330 series AP at Atmosphere 2016 in Las Vegas.

The keynotes talked about how our reliance on wireless are increasing, and how it's becoming a more critical part of our network infrastructure.  I see the 330 series AP announced as a big part of Aruba's strategy moving forward.

Instead of giving a big detailed spec sheet for the AP, I'm going to highlight the things I found interesting.

Tuesday, February 2, 2016

Shifting Views on RRM

So RRM is the hot topics these days.  We have notable CWNEs out in the media actively discouraging its use, with others (including myself) advocating its use when you understand how to use it.  It’s really hard to cut through the FUD and make a good decision as to what wireless operators should be doing.  I’m going to take a minute to relate RRM to another technology and hopefully let you make some informed decisions for yourself.

Thursday, January 21, 2016

Cradlepoint as a Backup WAN

I've been skeptical of using cellular as a backup solution, cost being the primary concern.  Cellular data is not exactly cheap.  Yet I found myself in a situation recently where I was working from and had a remote cutover.  Less than an hour before the cutover, my home internet went down.  Now posed with the option of either driving into the office, or finding another internet connection with less than an hour.

I grabbed my IBR1100 that @Cradlepoint gave me from #WFD8.  I pulled the SIM out of my work cell phone and 3D printed an adapter in order to get my SIM into the router.  One I powered the IBR1100 up, it came up and I logged into the interface for the first time.  The interface is simple, the initial setup wizard asks a lot of the right questions to get the device up and running quickly for most of their primary use cases.

Sunday, September 27, 2015

A look at HORST on a Raspberry Pi.

I've been working on diagnosing wireless issues from a Raspberry Pi for almost a year now.  And after writing a bunch of python around packet capture and upload I was searching for some airtime calculations when I stumbled across a piece of software called HORST.  Standing for Highly Optimized Radio Scanning Tool, HORST allows you to analyze wireless statistics and packets in real time.  In just a few minutes, I had it running and was amazed at how well it can analyze a network remotely.