Follow me:

Optimizing for Client Devices

Are we relying too much on proprietary tech to optimize Wi-Fi for client devices? Recently, Rowell had to optimize a wireless network which became this episode.

What do we think about features like client load balancing? Can it work efficiently and how do client devices react to it? Is there a better way to load balancing clients across access points? Ultimately, the client device decides where it wants to join, right? Maybe 802.11k/v can help with transitioning client devices more smoothly. We would think so but sometimes client devices don’t leverage 802.11k/v properly.

Do you turn on all DFS channels? If a client device supports the channel, why not? But what about which AP is operating on which channel within DFS. That’s going to be important when designing a network that relies on roaming.

Then there’s the discussion of matching transmit power levels from the APs with your client devices. How do you know which transmit power to set it to when you have many different types of clients?

These are the topics we talk about in this episode. Let us know what your optimization tips are in the comments below.

Join Clear To Send

Come join the Clear To Send community.

Powered by ConvertKit
Hosted by
Rowell

Rowell, CWNE #210, is a network engineer in Higher-Ed. He enjoys working with wireless networking technologies and loves to share and engage with the community. You can connect with him on Twitter, LinkedIn, and Facebook.

Join the discussion

This site uses Akismet to reduce spam. Learn how your comment data is processed.

2 comments
  • I experienced this issue recently during a customer review of their Cisco 9800 controller where clients were not roaming well. It turns out that if you follow Cisco best-practices as recommended on the controller GUI, then enabling the default client load balancing has defaults as low as 5 client per AP. When you hit the MAX_STA limit of 5, then the AP will reject the association. Some Intel drivers are not smart enough to take the hint. iOS was pretty good when 802.11r was enabled. But in general I think the feature is totally flawed for the reasons you mentioned. 802.11k/v is a better method to inform clients and then the clients make the final decision. Excellent podcast. I also like the discussion of DFS since it’s so tempting for customers to enable all those channels without considering the consequences. The more I learn about Wi-Fi the more I realise that there are not so many best practices – we tend to design based on our latest bad experiences, and we drag around all this technical debt into the future. But the industry is partly to blame because of the variety of client capabilities. It’s a sad reality, but in some cases we need to turn off a lot of cool new features on a multi-thousand Dollar, just to allow the lowest common denominator client to connect.

  • Thanks for the nice coverage especially on the client’s final say on many things in WiFi. I do not think this is going to change dramatically. Many measures are being attempted to give cellular basestation like controls to a WiFi AP but it might not be effective. We have to find a way to work with “smart (sometimes).. independent..minded” clients..

More from this show

Episode 259