When it comes to “reliable” WiFi operation, it is critical to use some QoS measures to get the best possible performance from the air. Air medium is half duplex, so there should be some mechanisms to prioritize it.

WiFi Prioritization is based on 802.11e. WMM should be utilized on the WiFi network where over-the-air prioritization is needed.

Network engineers are focusing on wired QoS and “traffic engineering” concepts for many years, but “WiFi over the air traffic engineering” is somehow under-rated. However, in many cases, the-most-studied wired medium, which is full-duplex and probably has higher speed links than WiFi, needs less QoS compared to a highly-utilized air medium. So, WiFi needs QoS badly, because of its half-duplex contention “war”.

How WMM Works.

Whole WMM operation is out of the scope of this blog post but WMM basically works by applying 4 different priority levels to the frames transmitted over the air, via WiFi.

WiFi contention basically works as “put some IFS and then, put some contention window waiting time, and then transmit”. However, this schema is not so good when we need to prioritize some frame over the others.

IFS is one variable. Contention window is another variable.

IFS is the “fixed” wait time, after the transmitter decides the medium is NOT busy. So, after detecting the availability of the medium, transmitter should wait until the IFS duration is passed. What happens after? The “contention window”. The transmitter selects a contention window time, for example a random value between 15 and 1023 and then counts down from that number. Counting down is not based on regular “seconds” that we use in our everyday life, rather, it is based on slot times. After one slot time has passed, count down one, another slot time has passed, count down again, and so on. Slot times are also variable by 802.11 technology.

So, it can be easily seen that the contention mechanism CANNOT be the same for all frame types. All types of frames cannot be forced to wait for equal times. Instead, some frames should be allowed to wait less, and some frames should wait more. Yes, this is handled by WMM. WMM does this.

So, in WMM schema, some packets get more airtime, by making them wait less and some are waiting more than the others.

For example, let’s think about the contention window. It should be “random” wait time, right? What are the lower and upper boundaries that we should choose a random number in between? In WMM, high priority packets are choosing a contention windows wait time between 3 and 7. Less important packets are choosing between 7 and 15. And the others are choosing between 15 and 1023. So, this is a good prioritization to make frames different from one another.

So, there are 4 access categories for WiFi frames, with WMM.

• Voice
• Video
• Best Effort
• Background

So, if we put our frames into these categories, these will be prioritized accordingly.

So far, we haven’t talked about Aruba, yet.

What is the role of Aruba firewall here? The role of Aruba’s stateful firewall is that it is able to classify the traffic flows according to the customizable L4-L7 rules and these rules can mark traffic to be put into these access categories to be prioritized over the air.

That means you can “catch” your critical business application and prioritize it over the air. You don’t need any other “marking” device to mark your traffic via DSCP tags. You can catch your traffic via your Aruba Firewall, which is integrated to the Aruba controller box, and then the WLAN process is prioritizing it while sending the frames to the air.

These are the default DSCP to WMM mappings:

These mean that if a packet hits to the controller to be transmitted over a WMM enabled SSID with a DSCP value of 56 or 48, it will be transmitted as WMM Voice AC. (meaning highly prioritized)

If there is a packet came with DSCP value with 32 or 40, it will be transmitted with WMM Video AC.

And so on.

However, who will tag those packets? Upper devices? Isn’t this a configuration/operational load?

Aruba Firewall does this internally, via its integrated stateful firewall. You can catch the traffic via Firewall, apply DSCP markings to them and bingo, your traffic will be prioritized over the air. So, you can provide the best priority to your business-critical custom-developed app which runs over TCP 5567

So, with Aruba Firewall, you can easily do a “traffic-engineering” work for your all traffic types to prioritize them over the air, thanks to WMM.

By the way, default DSCP to WMM mappings can be changed per SSID, as shown below:

So, you can catch your desired traffic accordingly, apply correct DSCP tags via Aruba integrated firewall and let them fly with priority.

For example, the above screenshot means that all SIP VoIP traffic gets prioritized by DSCP and then prioritized over the air via WMM.

This is done with “SIP to all destinations” however, you can make it more granular. You can make it like, “SIP to destination X will be prioritized higher than SIP to destination Y”. And also you can make your prioritization based on the time of the day, based on your location etc. Nice “traffic engineering over the air”, right?