Unveiling QoS Prioritization Issue in Real-World AP Testing: A Packet-Level Analysis

In the context of Quality of Service (QoS) priorities, the ToS (Type of Service) field in IP headers traditionally defines different classes of service. The table below summarizes the mapping of ToS values to their corresponding classes:

While evaluating the Access Point's performance, we conducted a Quality of Service (QoS) test with 50 real devices of different operating systems with an intended load of 100Mbps. We observed that the Quality of Service (QoS) Type of service (ToS) priority was not as expected, with the highest priority being given to best effort traffic instead of voice traffic, which was anticipated.

Let us deep dive into the understanding of QOS parameters at the packet capture level.

In Quality of Service (QoS) for Wi-Fi networks, AIFSN (Arbitration Inter-Frame Space Number) is a crucial parameter. It is a part of the EDCA (Enhanced Distributed Channel Access) mechanism which defines how different types of traffic are prioritized.

In QoS, lower AIFSN values signify higher priority. This is because stations with lower values wait for shorter periods, gaining faster access to the medium. Typically, traffic types such as voice and video are assigned lower AIFSN values, ensuring prioritized transmission, while best-effort and background traffic are allocated higher values.

In a QoS-enabled Wi-Fi network, the AIFSN values are commonly configured as follows:

As part of debugging this issue, we sniffed the packets on the wireless side and observed that in the beacon frame, the EDCA parameter set had all the AIFSN values set and broadcasted by the AP as expected. However, the priority is given to a ToS bit which has a higher AIFSN Value, which is not expected.

To narrow down this issue, I performed the same QoS test with a single client at a lower intended load of 10 Mbps and observed the same behavior of other access categories/ToS bits with high AIFSN were getting the highest priority.

When tried the same test with a different Access Point with the same device, we were able to achieve the correct traffic priorities as expected with the same intended load as shown below,

?Before moving to further observations, let’s understand about TID (Traffic Identifier).

The TID (Traffic Identifier) is used to differentiate traffic streams in Wi-Fi networks typically maps to the 802.11e Access Categories (ACs), which correspond to different levels of QoS (Quality of Service). Here's how TID generally maps to the respective AC and TOS (Type of Service) priorities:

Now when we checked the number of QoS frames filtered by the Traffic Identifier (TID), which is used to differentiate traffic streams, we observed that the Access Point is sending less QoS frames for Voice and Video ToS bits than expected. These ToS bits are anticipated to have a higher count of QoS frames. Additionally, we observed a 0% packet drop rate for all ToS bits.

?We have observed that approximately 30% of the total wireless packets sniffed consist of RTS (Request to Send) and CTS (Clear to Send) frames. While RTS/CTS frames are essential for managing collisions and enhancing transmission reliability, an excessive presence of these frames can introduce significant overhead.

In conclusion, with one of our Access Points, we consistently encounter a QoS prioritization issue due to this overhead. The increased presence of RTS and CTS frames diminishes the available bandwidth for data transmission, adversely impacting QoS-sensitive traffic by increasing latency and reducing throughput.

Here are my observations and debugging analysis regarding the QoS priorities mismatch issue. I look forward to your valuable thoughts and suggestions on this front.