Cisco WLC: EDCA timers

Because of a customer project I’m checking the IEEE 802.11-2016 standard for the changed QoS EDCA parameters. These parameters changed compared to the IEEE 802.11-2012 standard.

If you don’t know what wireless QoS is about and want to know more, read this excellent blog post of Rasika.

The following tables reflects the EDCA timers for OFDM data rates (802.11a,g,n,ac)

Source: IEEE 802.11-2016 Table 9-137 – “Default EDCA Parameter Set element …..”

Here’s the 802.11-2012 standard as for comparison. Differences are highlighted in red

Source: IEEE 802.11-2012 Table 8-105 – “Default EDCA Parameter Set element …..”

Differences between IEEE 802.11-2012 and 2016

The main thing that changed are TXOP limits. Stations sending frames inside the voice of video queue may send more frames in one DCF cycle (additional ~1.000 ms for video and ~5000 ms for voice). Furthermore, the TXOP limit for the background and the best effort queue was changed from 0 to a value of 2.528 ms. At first sight, someone could think, that any value is better than zero and that the background and best effort queues are allowed to send bursts as well, giving them better treatment. Well, it depends….

Let’s assume a station wants to send a 1.500 byte data frame. Without considering medium reservation frames and the variable backoff timer, the air transmission time for this is approximately 2 ms at 6 MBit/s data rate. This is smaller than the TXOP limit in the 2016 standard for BE or BK queues. So the station may send this one frame in DCF cycle (and an additional smaller frame, because ~ 0.5 ms are still free). However, if sending the same frame at 1 MBit/s, the air transmission time is ~12 ms. This is higher than the TXOP limit in the 2016 standard for BE or BK queues. In the table above the TXOP limit is 2.528ms, but this is only true for OFDM data rates. At 1 MBit/s (DSSS), the TXOP limit is 3.264 ms.

In the 802.11-2012 standard, the legacy station is allowed to send the frame in one DCF duty cycle, because the TXOP limit is 0 in the BK and BE queues. Consequently, the medium is blocked for ~12 ms, not allowing any other station  to send frames in this time. So the truck blocks the road. For voice packets of other stations in the cell this means a delay of voice packets of ~12 ms. This influences jitter was well and could result in poor voice quality.

In the 802.11-2016 standard, the legacy station is not allowed to send the frame in one DCF duty cycle, because the TXOP limit is 3.264 ms in the BK and BE queues. The station must (somehow fragment) the frame and send it in multiple DCF cycles. Consequently, the medium is blocked by one station for the maximum of 3.264 ms (if allowing 802.11b). Smaller trucks are used and smaller trucks don’t block the road so easily. The 802.11-2016 standard states in these cases (chapter 10.22.2.8)):

“[…] a STA shall fragment an individually addressed MSDU or MMPDU so that the
initial transmission of the first fragment does not cause the TXOP limit to be exceeded.” 

“If the TXOP holder exceeds the TXOP limit, it should use as high a PHY rate as possible to minimize the duration of the TXOP.”

Nice idea, but I doubt, that legacy 802.11b clients (yeah, they are still around – even in the hyped “Industry 4.0” world) will follow this. These clients were manufactured decades ago. I guess the vendors didn’t implement 802.11e/WMM in those clients.

However, what parameters are actually used in the Cisco WLC?

Unfortunately the actual values cannot be determined in the WLC GUI or CLI. Furthermore, the names of the EDCA profiles don’t reflect whether the IEEE 802.11 parameters are used. The good thing is, that the values can be captured in beacon frames.
If you don’t know how to capture wirless frames, please check these posts: WLAN traffic capture [1] and WLAN traffic capture [2]

Note: In the captures the values can be found in the 802.11 tagged parameter 221 “WMM/WME parameter element”. The TXOP limit are  given as integer values in the frames. To get the TXOP limit in microseconds, these values must be multiplied by 32µs.

So here is a summary of the most important EDCA profiles in AireOS version 8.3.133.0 along with the beacon captures.

The EDCA profile “WMM” is implemented using the IEEE 802.11-2012 specifications.  Download the capture files here.

The EDCA profile “Fastlane” is implemented using the IEEE 802.11-2016 specifications. Download the capture files here.

All other profiles are not implemented according to the IEEE 802.11 specifications

Download the capture files here.

Download the capture files here.

My personal opinion is, to use the “Fastlane” (IEEE 802.11-2016) or the “WMM” (IEEE-2012) EDCA profile. Following the standard is a good thing – so why messing up things?

Also keep in mind, that the EDCA “Fastlane” setting does not implement an “Apple” device bonus in any kind. Fastlane is a framework and some features will prioritize Apple clients despite of any standard QoS mechanisms (personally I don’t like that). The EDCA “Fastlane” profile is just another name for “802.11-2016” EDCA. I don’t get the point why Cisco doesn’t name is that way…. (well – at least this stuff fills up my blog)