As we move forward in this Wi-Fi design series, we come to a discussion about a critical infrastructure service – your phone calls. When users come into the office, they want two things to work without fail. They need to send, receive and read email, and they want a dial tone. Poor call quality is a sure way to get your user population to rise up in anarchy! If your customers are using softphones like Skype for Business, your wireless design needs to support the unique requirements of voice services.
The Wi-Fi solution should have sufficient bandwidth augmented with quality of service (QoS) markings. I’d highly recommend reading the Skype for Business over Aruba Validated Reference Design document, even if you aren’t running Skype for Business as your voice solution. The referenced link is to a 2017 document, but it will form a basis for making call quality a priority on your network.
Why is QoS a “thing” on the wireless network? Take for instance roaming with a wireless Skype for Business client. The latency limit with Skype for Business is right around 200ms. At that point, clients will begin to disconnect and have to reregister with the Skype servers. Calls will drop and the video will begin to buffer. This is the ceiling for call quality and your target to hit, but that’s worst case. Don’t aim for worst.
Think about this: You have one Aruba 330 series access point servicing 150 users. This device shares out 1.7Gbps/600Mbps on the 5/2.4GHz spectrum with a maximum of 256 clients per device radio. If those 150 users are connected to the 5GHz band and trying to push maximum throughput, you are clearly out of bandwidth to support their applications. This means interface queueing, buffer drops and jitter. QoS is concerned with moving traffic from one side of an interface to the other and putting that data on the wire in an organized and timely manner.
Simply enabling QoS on your wireless infrastructure is no guarantee of smooth sailing for your users. Something to consider in relation to bandwidth, hardware, applications and users that you can’t overlook is the air gap between your users and the physical WAP. You can’t prioritize the traffic between the client’s wireless NIC and the access point. The atmosphere has no sense of service classification! All you can really do is a) make sure you have proper RF coverage; b) monitor for interference from devices such as microwave ovens and Bluetooth radios; c) watch for roaming delays between APs; d) adjust radio power so you don’t bleed into the other spectrum. This means you need to monitor the air space, and deal with interruptions.
Configuring QoS for Wi-Fi
Skype for Business uses several ports within the TCP stack to set up a user’s call. Call control and setup uses Session Initiated Protocol (SIP) whereas screen sharing, chat and other features use different ports. You have to know the application so you can ensure call quality. It’s these protocols you’ll need to mark for the different classifications through the entirety of your network.
Clearly you should check the application requirements for the voice applications installed on your network. There may be some overlap on the transport protocols, but Zoom, Jabber and the host of other collaboration apps may vary.
What to Monitor
Monitoring is critical and the natural question to ask is clear: What do you monitor, and how do you monitor it? Furthermore, what happens if you don’t use a product like Aruba AirWave? If you don’t have a solution that can check for RF interference (among other things) you’re in a world of hurt. Even if you can hire an intern to walk all over your building with a wireless scanner, at least you have visibility. Network engineers need to know what the user experience is.
As I had mentioned earlier, concerning QoS/CoS and Wi-Fi, the big gap is in the air. You have to be able to see things like Bluetooth interference, where users were located when they had a “problem,” and then correlate the issues. The hard part is most users don’t create a help desk ticket every time they have a problem. You have to look through the data and recognize a trend as your customers walk in a dead zone. It’s not easy especially when you finally doget a ticket for a “wireless performance” problem that happened three weeks prior.
Parting Thought(s)
The ins and outs of configuring your traffic for QoS markings are outside the scope of what my intentions are for this article. It has the potential to change from code version to code version and platform to platform. It isn’t enough to enable it on all your APs. You must extend the traffic engineering throughout your environment. End-to-end.
Review your platform’s release notes and go from there. A few places to start would be to read the Skype for Business over Aruba design guide or the notes for your particular platform. Network engineers can no longer just sit back as a “transport” department. We have to enable the business functions and QoS along the path is a great place to start.
Pro Tip: If you're really interested in diving deeper in WAP queuing, start investigating Aruba's Application Layer Gateways. It's really fascinating, especially at an academic level.
Read My Other Blogs
Cutting the Cable: Where Do You Start?
Wireless Design: Turn up the Heat(map)
Voice over Wi-Fi Doesn't Have to Be Trouble
Understanding Wi-Fi Authentication
