Packet Captures with Extreme Networks WiNG Access Points

Extreme Networks WiNG Access Points offer several remote packet capture options that are very useful for troubleshooting. For example, the remote-debug command can capture the wireless traffic of an associated device across several distributed remote access points in one command.

Here are some integrated packet capture tools available in the CLI of a Controller or an Access Point with WiNG version 5.x:

  • service pktcap

  • remote-debug live-pktcap

  • remote-debug offline-pktcap

  • sniffer-redirect

Local packet capture

The service pktcap command captures the local traffic traversing a physical or logical interface of an access point. The command is applied in the console of the Access Point.

At first, a capture point on the access point must be chosen:

AP7532#service pktcap on ?

  bridge     Capture packets transiting through the ethernet bridge

  deny       Capture packets being denied by an ACL

  dpi        Capture packtes forwarded to dpi engine (dpi engine must be

             enabled to capture packtes on this location)

  drop       Capture packets being dropped

  ext-vlan   Capture packets forwarded to/from an extended-vlan

  interface  Capture packets received/send through an interface

  radio      Capture packets on a radio (802.11)

  rim        Capture packets at radio interface module

  router     Capture packets transiting through the IP router

  vpn        Capture packets forwarded to/from a VPN link

  wireless   Capture packets forwarded to/from wireless

You can use the radio or interface radio option to capture any wireless packets along with some information from their 802.11 header. It includes any wireless frames that are destined to the radio and that are transmitted by the radio. Except for the 802.11 Beacon frames that are serviced by the access point; they do not appear on the capture, probably to reduce the size of the capture. In addition it does not include any traffic for another Access Point.

Importantly the radios are still servicing wireless clients while the packet capture is performed.

Note that the wireless option captures the traffic that is bridged to and from the wireless interfaces, after decapsulation of the 802.11 header. In this case, no wireless information appears in the packet capture.

To capture the wireless frames on both the 2.4GHz and 5GHz radio interfaces, and display the packet capture on the console output:

AP7532#service pktcap on radio all

Capturing up to 50 packets. Use Ctrl-C to abort.

1 0:13:02.413128 I  BEACON Src:78-8A-20-BD-49-FA Dst:FF-FF-FF-FF-FF-FF Bss:78-8A-20-BD-49-FA, SSID "", CH 1, RSSI -42, RATE 1, bw 20MHz, sgi=0

2 0:13:02.433367 I  PROBE_REQ Src:38-8B-59-3F-3F-F1 Dst:FF-FF-FF-FF-FF-FF Bss:FF-FF-FF-FF-FF-FF, SSID "Laptop 5.0", CH 36, RSSI -62, RATE 1, bw 20MHz, sgi=0

3 0:13:02.436176 I  PROBE_REQ Src:38-8B-59-3F-3F-F1 Dst:FF-FF-FF-FF-FF-FF Bss:FF-FF-FF-FF-FF-FF, SSID "Laptop 5.0", CH 36, RSSI -62, RATE 1, bw 20MHz, sgi=0

4 0:13:02.437273 I  PROBE_REQ Src:38-8B-59-3F-3F-F1 Dst:FF-FF-FF-FF-FF-FF Bss:FF-FF-FF-FF-FF-FF, SSID "Laptop 5.0", CH 36, RSSI -90, RATE 1, bw 20MHz, sgi=0

5 0:13:02.439388 I  BEACON Src:12-DA-43-BC-E6-82 Dst:FF-FF-FF-FF-FF-FF Bss:12-DA-43-BC-E6-82, SSID "Phone WiFi", CH 1, RSSI -90, RATE 1, bw 20MHz, sgi=0

6 0:13:02.440489 I  PROBE_REQ Src:38-8B-59-3F-3F-F1 Dst:FF-FF-FF-FF-FF-FF Bss:FF-FF-FF-FF-FF-FF, SSID "Laptop 5.0", CH 36, RSSI -62, RATE 1, bw 20MHz, sgi=0

7 0:13:02.449908 I  BEACON Src:72-10-3E-98-BD-34 Dst:FF-FF-FF-FF-FF-FF Bss:72-10-3E-98-BD-34, SSID "zen-guest", CH 1, RSSI -73, RATE 1, bw 20MHz, sgi=0

8 0:13:02.452770 I  BEACON Src:94-10-3E-98-BD-37 Dst:FF-FF-FF-FF-FF-FF Bss:94-10-3E-98-BD-37, SSID "zen ", CH 1, RSSI -73, RATE 1, bw 20MHz, sgi=0

9 0:13:02.464237 I  BEACON Src:7A-8A-20-BD-49-FA Dst:FF-FF-FF-FF-FF-FF Bss:7A-8A-20-BD-49-FA, SSID "", CH 1, RSSI -42, RATE 1, bw 20MHz, sgi=0

10 0:13:02.471936 I  BEACON Src:12-13-31-9B-54-33 Dst:FF-FF-FF-FF-FF-FF Bss:12-13-31-9B-54-33, SSID "Totoro", CH 1, RSSI -82, RATE 1, bw 20MHz, sgi=0

23 0:13:02.584208 I  PROBE_REQ Src:EC-9B-F3-32-F1-40 Dst:FF-FF-FF-FF-FF-FF Bss:FF-FF-FF-FF-FF-FF (any SSID), CH 1, RSSI -49, RATE 1, bw 20MHz, sgi=0

24 0:13:02.591405 O  PROBE_RESP Src:74-67-F7-F0-18-B0 Dst:EC-9B-F3-32-F1-40 Bss:74-67-F7-F0-18-B0, SSID "TestSSID", CH 1, RATE 1, SUCCESS: Y

Frame are displayed with some radio information (Channel, RSSI and Data Rate) and some information from the 802.11 header (802.11 Frame Type/Subtype, Source Address, Destination Address, BSSID Address, SSID).

In this example, Beacons from other service sets and Probe Requests have been captured because the destination is broadcast (FF-FF-FF-FF-FF-FF). No Beacon frames broadcasted by the Access Point (with the SSID “TestSSID”) were displayed, but one Probe Response frame advertising this SSID from the Access Point is seen in the last line.

The verbose option provides more details from the 802.11 header:

ap7532#service pktcap on radio all verbose

Capturing up to 50 packets. Use Ctrl-C to abort.

----------------------------------------------------------------------

Packet 1:

Time: 3:28:12.201110, Len: 226, Dir: inbound, 802.11, Priority: 0, Wlan: 0, l3_off: 24, l4_off: 0

802.11: BEACON Src:78-8A-20-BD-49-FA Dst:FF-FF-FF-FF-FF-FF Bss:78-8A-20-BD-49-FA, SSID "", CH 1, RSSI -42, RATE 1, bw 20MHz, sgi=0

  Type:mgmt, SubType:BEACON, Duration:0, Seq:2524, Frag:0, MoreFrags:0

  FromDS:0, ToDS:0, Retry:0, PowerMgmt:0, MoreData:0, Protected:0

 

----------------------------------------------------------------------

Packet 2:

Time: 3:28:12.204259, Len: 240, Dir: inbound, 802.11, Priority: 0, Wlan: 0, l3_off: 24, l4_off: 0

802.11: BEACON Src:12-DA-43-BC-E6-82 Dst:FF-FF-FF-FF-FF-FF Bss:12-DA-43-BC-E6-82, SSID "Phone WiFi", CH 1, RSSI -89, RATE 1, bw 20MHz, sgi=0

  Type:mgmt, SubType:BEACON, Duration:0, Seq:1899, Frag:0, MoreFrags:0

  FromDS:0, ToDS:0, Retry:0, PowerMgmt:0, MoreData:0, Protected:0

 

----------------------------------------------------------------------

Packet 90:

Time: 3:28:27.047719, Len: 386, Dir: inbound, 802.11, Proto: 0x0800, Vlan: 1, Priority: 0, Wlan: 0, l3_off: 42, l4_off: 62

802.11: QOS-DATA Src:EC-9B-F3-32-F1-40 Dst:FF-FF-FF-FF-FF-FF Bss:74-67-F7-F2-50-30 (to DS), CH 36, RSSI -39, RATE mcs8-s2, bw 20MHz, sgi=0

  Type:data, SubType:QOS-DATA, Duration:48, Seq:3, Frag:0, MoreFrags:0

  FromDS:0, ToDS:1, Retry:0, PowerMgmt:0, MoreData:0, Protected:1, Tid:0

IPv4: 0.0.0.0 > 255.255.255.255, proto UDP, IPv4 length 336, DSCP 0, Id 35392

UDP: ports 68 > 67, data length 316

DHCP: Discover from EC-9B-F3-32-F1-40

The associated traffic appears unencrypted in the console output and some upper layer information is provided. In the previous example, there is a DHCP Discover packet from a wireless client.

By default, the command captures 50 packets. You can add the count option to increase the packet count, up to 1,000,000 packets. To stop the capture before it finishes, press Crtl-C

ap7532#service pktcap on radio all count ?

  <1-1000000>  Packet count

Secondly, the destination of the capture can be changed with the write option. Presentation options can be either:

  • displayed onto the console output (by default, without the write option)

  • saved locally on the access point (flash memory)

  • sent to a FTP or TFTP host

  • sent in real-time to a remote packet sniffer (Wireshark) using TaZman Sniffer Protocol (TZSP)

To capture all the wireless packets and copy the resulted .pcap file to a TFTP server:

ap7532#service pktcap on radio all count <NB> write tftp://<HOSTNAME|IP>/<PATH>/<FILENAME>

Capturing up to <NB> packets. Use Ctrl-C to abort.

Once completed, open the following pcap file with Wireshark. In the following example, a wireless client association to the Access Point has been captured. We can filter the packets related to the client with the following Wireshark display filter: wlan.addr == ec:9b:f3:32:f1:40

The next picture shows the Association Request from the client to the Access Point.

The capture shows that all frames are encapsulated using a pseudo header called “IEEE 802.11 plus Radiotap radio header”.

The IEEE 802.11 header provides the Media Access Control layer information transmitted over the air. The Radiotap Header adds some additional information about the frame such as:

  • Antenna Signal: RF signal power at the antenna, in dBm

  • Data Rate: Transmit or received data rate, in unit of 500 Kbps

  • Channel Frequency: frequency in MHz, following by flags indicating the modulation type

Those values can also be displayed in Wireshark columns: radiotap.dbm_antsignal, radiotap.datarate, radiotap.channel.freq

Or using their equivalent values under another pseudo header: wlan_radio.signal_dbm, wlan_radio.data_rate, wlan_radio.frequency

Finally the frames can appear encrypted with Wireshark, compared to using the console output on the Access Point.

To decrypt the 802.11 Data frames in the pcap file from an Extreme Access Point, edit the IEEE 802.11 settings in Wireshark:

In the Edit menu, select Preferences | Protocols | IEEE 802.11, and set "Ignore the Protection bit” to "Yes - with IV".

Check Enable decryption and click on the Edit button for the Decryption keys.

Click on the + button to add a decryption key. For WPA2-PSK authentication, set the Key Type to wpa-pwd and set the Key with the following format: passphrase:SSID

Click on OK. The packets should be decrypted if their associated 4-way handshake was captured.

The command can also send the packet capture in a real-time continuous stream to a protocol analyser using TZSP as explained in the next section.

Remote packet capture

The remote-debug command performs a distributed packet capture from remote Access Points using the live-pktcap option. This command is executed on the RF Domain manager, which is more scalable than the service pktcap command.

At first, the scope of the packet captures must defined within a set or every Access Point of an RF domain:

ap7532#remote-debug live-pktcap ?

  hosts      Remote hosts

  rf-domain  Specify the RF-Domain

Then the presentation (write option), the capture points and the filters are configured similarly to the service pktcap command.

To reduce the size of the destination file or the required bandwidth, you can use the filter option with one or a set of match condition filters. The Access Point provides many different types of filter (by protocol, by addresses or by minimum RSSI for example) to refine the capture.

ap7532#remote-debug live-pktcap rf-domain default radio all filter ?

  LINE        User-defined packet capture filter (enclose in " if ( and ) are

              used)

  arp         Match ARP packets

  capwap      Match CAPWAP packets

  cdp         Match CDP packets

  dot11       Match 802.11 packets

  dropreason  Match packet drop reason

  dst         Match IP destination

  ether       Ethernet

  failed      Match failed 802.11 transmitted frames

  gre         Match GRE packets

  gre6        Match GREv6 packets

  host        Match IP address (IP or ARP)

  icmp        Match ICMP packets

  icmp6       Match ICMPv6 packets

  igmp        Match IGMP packets

  ip          Match IPv4 packets

  ip6         Match IPv6 packets

  l2          Match L2 header

  l3          Match L3 header

  l4          Match L4 header

  lldp        Match LLDP packets

  mint        Match MINT packets

  net         Match IP in subnet

  not         Logical not

  port        Match TCP or UDP port

  priority    Match packet priority

  radio       Match radio

  rssi        Match ingress RSSI

  src         Match IP source

  stp         Match STP packets

  tcp         Match TCP packets

  tcp6        Match TCP over IPv6 packets

  udp         Match UDP packets

  udp6        Match UDP over IPv6 packets

  vlan        Match vlan

  wlan        Match wlan

For example, the dot11 filter can specify 802.11 addresses or 802.11 frame types as match conditions. The filters can be fine-tuned with some logical conditions (and, or, not).

AP7522#remote-debug live-pktcap rf-domain default radio all filter dot11 ?

  addr    Match 802.11 address

  and     Logical and

  beacon  Match 802.11 beacon frames

  bss     Match BSS ID

  ctrl    Match 802.11 control frames

  data    Match 802.11 data frames

  mgmt    Match 802.11 management frames

  or      Logical or

  probe   Match 802.11 probe frames

  stype   Match 802.11 subtype

A typical use of remote-debug is to capture all the traffic of a wireless client within a RF domain, and to export the .pcap file to a TFTP server. This command is useful for troubleshooting roaming scenarios:

ap7532#remote-debug live-pktcap rf-domain default write tftp://<HOSTNAME|IP>/<PATH>/<FILENAME> radio all count <NB> filter dot11 addr 1 EC-9B-F3-32-F1-40 or dot11 addr 2 EC-9B-F3-32-F1-40 or dot11 addr 3 EC-9B-F3-32-F1-40

In this example, the RF domain manager aggregates the packets related to the wireless client (MAC: EC-9B-F3-32-F1-40) and copies the resulted capture file to the TFTP host.

You can check the status of remote-debug sessions:

ap7532#show remote-debug

Currently running sessions

 live-pktcap-1: Type:live-pktcap, Started by:admin

Completed sessions

 live-pktcap-0: Type:live-pktcap, Started by:admin

  ap7522: Successfully received 354720 bytes

  ap7532: Successfully received 230661 bytes

The Access Point allows one running session at a time.

The following example shows a wireless client roaming from an Access Point on channel 36 to another Access Point on channel 6.

Each frame is also encapsulated with a Radiotap header and the 802.11 header.

The following picture shows a DHCP Request from the client.

In this case, the Data Rate displayed in the Radiotap pseudo-header is 11n HT MCS15 (130 Mbps).

Another way to reduce the bandwidth required is the snap option, which truncates the length of each packet.

Finally, there is a last presentation method using TaZman Sniffer Protocol (TZSP) protocol, which sends the packets to a protocol analyser such as Wireshark for real-time analysis. The live capture wraps the packets into TZSP headers. It uses the UDP protocol with the destination port 37008 to transport them to destination. TZSP is also available with the service pktcap command.

To ensure that Wireshark can receive the TZSP streams, the UDP port 37008 must be opened on the operating system. If the port is not opened, the host may reply with an ICMP Destination Port Unreachable. In Windows, you can use the Iperf software or Netcat to open the port and avoid the ICMP Destination Port Unreachable messages. Make sure that the port is also not filtered by a firewall.

Using Iperf in server mode:

iperf.exe -s -u -p 37008

------------------------------------------------------------

Server listening on UDP port 37008

Receiving 1470 byte datagrams

UDP buffer size: 64.0 KByte (default)

------------------------------------------------------------

Using Netcat in listener mode:

nc -l -p 37008 -u

To check that the port is opened, you can use the netstat command:

netstat –anob

 

Active Connections

 

  Proto  Local Address          Foreign Address        State           PID

  RpcSs

  UDP    0.0.0.0:37008          *:*                                    872

 [iperf.exe]

To perform a live capture of the packets of a wireless client using TZSP:

ap7532#remote-debug live-pktcap rf-domain default write tzsp <HOSTNAME | IP> radio all count <NB> filter dot11 addr 1 EC-9B-F3-32-F1-40 or dot11 addr 2 EC-9B-F3-32-F1-40 or dot11 addr 3 EC-9B-F3-32-F1-40

The default number of captured packets is 50, and the maximum number is 1,000,000 packets.

Open Wireshark and start capturing packet on the selected interface. The live capture can be highlighted using the display filter tzsp.

However when using TZSP, the packet capture does not display any HT/VHT 802.11n/ac Data Rates but only 802.11a/b/g Data Rates.

The following picture shows an 802.11 Reassociation Request with its TZSP header:

There are several well-known TZSP fields similar to the Radiotap fields:

  • Signal: Signal strength, in dBm

  • Rate: Data Rate, in unit of 500 Kbps

  • Channel: Channel number (channel 1, channel 36 and so on)

  • Length: Original length of the packet before slicing

Those values can be displayed in Wireshark columns: tzsp.wlan.signal, tzsp.wlan.rate, tzsp.wlan.channel, tzsp.original_length

In addition, there are some vendor-specific fields and other Unknown TZSP tags:

  • Option tag 80: Access Point name. In the example, the ASCII conversion of hexdecimal 0x617037353332 is “ap7532

  • Option tag 81: Capture point on the Access Point. In the example, the ASCII conversion of hexdecimal 0x726164696f2031 is “radio 1” which is the 5GHz radio interface

  • Option tag 40: Sequence number used to order the packets streamed from an Access Point

Those unknown fields can be displayed in Wireshark with Custom columns that are setup in the menu Edit > Preferences > Appearance > Columns, with the field tzsp.unknown and the field occurrence (1, 2 or 3).

Similarly to the remote-debug live-pktcap command, the remote-debug offline-pktcap command allows distributed remote packet captures. However, it starts to copy the captured file only after the captures are completed.

Radio sniffer mode

The radio interface also supports Sniffer mode, which sets the radio in promiscuous mode. A radio in Sniffer mode cannot service any client traffic. However, it can capture any frames that are heard on the selected channel, including neighbouring device traffic, and continuously streams all the packets to a protocol analyser using TZSP.

Another benefit of Sniffer mode is that there is no packet limit compared to the service pktcap and remote-debug commands.

To configure Sniffer mode, use the sniffer-redirect radio interface command.

ap7532#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

ap7532(config)#self

ap7532(config-device-74-67-F7-D1-99-80)#interface radio 0

ap7532(config-device-74-67-F7-D1-99-80-if-radio0)#sniffer-redirect tzsp <IP> channel <CHANNEL>

You can verify that the radio is set to Sniffer mode with the following command:

ap7532#show wireless radio

----------------------------------------------------------------------------------------------

RADIO                RADIO-MAC             RF-MODE        STATE       CHANNEL    POWER #CLIENT

----------------------------------------------------------------------------------------------

ap7532:R1            74-67-F7-F0-18-B0 2.4GHz-wlan Sniffer Mode   N/A (  smt) 21 (smt)       0

ap7532:R2            74-67-F7-F2-50-30   5GHz-wlan Sniffer Mode   N/A (  smt) 20 (smt)       0

----------------------------------------------------------------------------------------------

The next screenshot shows some packets captured on both radio with the tzsp filter on Wireshark:

Beacon frames broadcasted by neighbour APs have been captured on channel 11 and channel 149 for example. I have also noticed that all the Beacon frames in my captures were truncated at the end of the 802.11 frame body. Other packets did not have this issue.

The following picture shows an 802.11 QoS Data frame with its TZSP header:

Compared to the remote-debug capture, the radio in Sniffer mode removes some TZSP tags and adds new ones including:

  • Sensor MAC: this tag should normally display the Sensor MAC address, on which the packet was received. In the example, the length is more than 6 Bytes and the ASCII conversion displays some radio information (Wireless mode, Channel width, Short or Long Preamble, RSSI, Noise, Antenna, Short Guard Interval, Greenfield, Low-Density Parity-Check code, MCS index, Number of Spatial Streams, Code, A-MPDU) rather than the Sensor MAC address “vht,20MHz,longpr,s=-42,n=-92,ant=1,sgi=1,gf=0,ldpc=1,mcs=0,nss=2,code=1,ampdu=(0,0,-).

  • Time: Timestamp, in ┬Ás

  • Frame Check Sequence: whether the packet contains an FCS error or not

Additional Resources

Extreme Wireless WiNG GTAC Knowledge Home, How to collect WiNG wireless packet capture:

https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-collect-WiNG-wireless-packet-capture

Radiotap specification, GitHub:

http://www.radiotap.org

Link-layer header types, Adrian Granados blog:

https://www.adriangranados.com/blog/link-layer-header-types

Link-Layer Header | Adrian Granados | WLPC Phoenix 2018:

https://www.youtube.com/watch?v=-L1lhqQR5Ww&feature=youtu.be

TZSP description, Wikipedia:

https://en.wikipedia.org/wiki/TZSP

Wireshark dissector for TZSP packets, Github:

https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-tzsp.c

IT Podcast series

This podcast list is to share a ton of informative community-based content about IT and especially about wireless technology. Many episodes are so much worth and fun being listened to, no matter how long ago they were released. Each series is separated into 3 categories to make it clear.

Wireless podcasts:

Security podcasts:

Networking podcasts:

If you know any other related podcast, please reach out to me on Twitter and I will add it to the list.

WPA2-Enterprise using a UniFi access point and a Raspberry Pi

Recently I have replaced my home Wi-Fi router by a Ubiquiti network and the experience is really great so far. The UniFi ecosystem of Ubiquiti is a feature-rich wireless solution with an intuitive user interface for configuring and monitoring the wireless network. The products have regular firmware updates, and lots of documentation on the Internet.

My new setup also includes a Raspberry Pi 3 for the UniFi software controller. It manages all the Ubiquiti network devices and collects all the statistics in a MongoDB database. Another role of the Raspberry Pi 3 is to provide EAP authentication to the wireless clients with a FreeRADIUS server.

The following article describes how to setup EAP authentication using UniFi and a FreeRADIUS authentication server. I have examined two cases of authentication: PEAP/MS-CHAPv2 on Windows 10 and EAP-TLS on Android. And finally two extended features are given as application: how to dynamically assign a VLAN per user and how to set up 802.11r fast-roaming.

This document attempts to introduce some examples of EAP authentication mechanisms and their configuration using UniFi. I have tried to apply some topics that I have learnt during the CWSP studies but wanted to explore those principles again. I hope that you will find it useful, and please I would appreciate any feedback that helps reviewing this document.

802.11 Power Management with packet capture examples

This article presents several power saving features with short examples. I was testing 802.11 Power Management using all the laptops and the mobile phones I could get, and there was a lot to learn. Many mechanisms that are described in the IEEE 802.11 standard allow a wireless device to reduce its power consumption, to turn off its radios and to wake up at the correct time to retrieve its traffic. While the APs are generally connected to an external power source, the wireless clients are often running on batteries. The purpose of power saving features is to increase the battery life and to allow longer performance. This battery life extension can be significant for low-powered devices such as smartphones, Voice over IP phones or handheld barcodes scanners.

From the original version in 1997 to now, many features that reduce power consumption have been added to the standard. Some of them have fallen into disuse (PS-Poll), some have been granted certifications (WMM-Power Save) and others relate to specific technologies (MIMO PSPM, 11ac VHT TXOP PS). And there are many other mechanisms related to power-saving that are not discussed in this article (PSMP, TIM Broadcast, Proxy ARP, etc.). Future amendments (802.11ax, 802.11ah) will also introduce new and enhanced power saving techniques.

Power Save (PS) mode

Let's start with the basics. The primary power save mechanism is based on a low-power state in which the radio is not able to transmit or receive.

A radio can be in one of two Power states:

  • Awake: the radio is constantly powered and able to receive and transmit.

  • Doze: the radio is not able to receive and transmit and consumes low power.

A wireless client enters Power Save (PS) mode in which the radio power state can transition between awake and doze according to the 802.11 power management rules.

A client can be in one of two Power Management modes:

  • Active mode: the client is awake all the time. The AP immediately transmits the frames to the client.

  • Power Save (PS) mode: the client is mostly in doze power state, but can also be awake to transmit and receive now and then. In this mode, the AP buffers the eligible frames destined for the client.

One important element to remember is that a client in PS mode is not always in doze mode. A client in PS mode may transmit a frame to the AP at any time, and the AP can transmit some traffic to a client in PS mode following specific rules.

Let’s see how a client switches between the two Power Management modes. At the beginning, a client is in active mode after (Re)Association. When a client wants to change its Power Management mode, it informs the AP via a successful frame exchange. The new mode is indicated by the Power Management subfield within the Frame Control field of a transmitted frame. A (Null) Data frame is typically used by the client. The AP needs to acknowledge the frame exchange to validate the change successfully. The AP also maintains the Power Management mode state for each associated client.

In this following diagram, the client begins in active mode. The radio is always awake in active mode and ready to receive and transmit any frames. The AP transmit immediately any unicast traffic addressed to the client.

The following frame picture shows the Null Data frame used by the client to go in PS mode: the Power Management bit is set to 1. Then the AP acknowledges the frame to validate the change.

From then, the AP buffers eligible frames, including the Data frames, Disassociation and Deauthentication frames that are addressed to the client, multicast and broadcast frames. Following specific rules, the client wakes up to receive the buffered traffic and then goes back to the doze state for the rest of the time.

The following frame shows the Null Data frame used by this client to go back to active mode: the Power Management bit is set to 0. And the client waits for the Acknowledgement from the AP.

The 802.11 standard also considers that the Power Management subfield in a frame exchange from the AP is ignored.

Although each vendor has its own proprietary set of rules to switch between Active and PS mode, three modes are often configurable on the client:

  • Constantly Awake Mode (CAM): the radio is active most of the time. This mode consumes the most power and also provides the highest throughput.

  • Fast Power Save Polling (Fast PSP): the radio switches between active and PS mode, depending on the traffic load. When the traffic is idle or very low, the client stays in PS mode. When the throughput increases, the client goes back to active mode until the traffic ends.

  • Maximum Power Save Polling (Max PSP): the radio is in PS mode most of the time. This mode saves the most power but also provides the lowest throughput.

Note that a client in CAM mode isn’t always in active mode. Many clients are periodically going into PS mode in order to search and probe the list of neighbouring APs on the channels that are allowed on the client; the method is called Active Scanning.

In the following Wireshark packet capture, a client in CAM mode is scanning for the neighbouring APs every 10 seconds. The client sends a QoS Null Data frame (packet #1) with the Power Management set to 1 to go from Active to PS mode. Then it sends some Probe Request frames (#6, #9) on several channels and wait to receive some Probe Response frames (#7, #10) to update the list of neighbouring APs. In the meanwhile, the AP is responsible to buffer the frames destined to the client. Finally after a total of 147 milliseconds, the client goes back to Active mode with a QoS Null Data frame (#12) with the Power Management set to 0.

The Power Management value can be added in a Wireshark column with the filter: wlan.fc.pwrmgt

Buffered traffic and Traffic Indication Map (TIM) element

The next question is: How does the client retrieve the buffered traffic? To answer that, the client needs first to know that the AP is buffering some frames. The AP indicates that it has some buffered frames using the Traffic Indication Map (TIM) element present in the Beacon frames. The TIM element contains four fields: DTIM Count, DTIM Period, Bitmap Control, and Partial Virtual Bitmap.

The Association Identifier (AID) is a 16-bit value between 1 and 2007 (the 5 MSB bits are reserved) representing the unique identifier of the client in the BSS. The AP assigns the AID value to a client during its association with the AID element contained in the (Re)Association Response frame.

The AP maintains a Traffic Indication Virtual Bitmap that consists of 2008 bits, each of them corresponding to the unique identifier (AID) of the client in the BSS. A bit number N is set to 1 by the AP to indicate that there is buffered traffic for the client whose AID is N. Otherwise the bit in the bitmap is 0.

The Partial Virtual Bitmap that is contained in the TIM element is the relevant part of the bitmap where contiguous series of 0 in the lowest bits and the highest bits of the bitmap have been removed to save some space. The Partial Virtual Bitmap is determined by the Bitmap Offset value and by the Length field with a specific set of rules. The Partial Virtual Bitmap provides the list of AIDs of the clients which the AP has some buffered traffic individually addressed to them. If the Partial Virtual Bitmap is set to 0, there are no buffered frames.

In the following Beacon frame, Wireshark displays the corresponding AIDs that are translated from the Partial Virtual Bitmap. In this example, the AP signals in the TIM element of the Beacon that it has some buffered traffic addressed to the client whose AID is 1. If this client in PS mode wakes up its radios to listen to this Beacon frame, it can poll the AP to receive its buffered traffic and then goes back to sleep.

A client in PS mode gets awake at the times of Beacon frames and checks if there is any buffered traffic. The client may also stay asleep at some Beacon frames in order to save an extra power, running the risk of missing some buffered traffic.

The (Re)Association Request frame includes a Listen Interval subfield within the Capabilities Information field. It is an integer between 0 and 65535 expressed in units of Beacon Interval. It indicates to the AP how often a client in PS mode wakes up to listen to the Beacon frames. In the AP, the Aging Time of the buffered frames bound to the client is implemented differently by each vendor but must not be shorter than the Listen Interval (or the WNM Sleep Interval in a WNM Sleep Mode Request frame). The Listen Interval from the client is also vendor specific.

In the following Association Request frame, the Listen Interval is set to 20 by the client. If the AP has some buffered traffic addressed to the client in PS mode, the AP can age out the buffered traffic after 20 Beacon Intervals and free the buffers if the client is not retrieving them in time. So the client in PS mode must wake up at least once every 20 Beacon Intervals to check if there is some buffered traffic on the AP.

Buffered group traffic and Delivery Traffic Indication Map (DTIM) element

When there is at least one client in PS mode in the BSS, the AP also buffers the broadcast and multicast (group) traffic and transmits it at specific times to ensure that all the associated clients have a chance to receive it. The buffered group traffic is delivered immediately after a Beacon frame containing a Delivery Traffic Indication Map (DTIM) element.

The network administrator can specify the DTIM Period which is the frequency of DTIM Beacons, expressed between 1 and 255 in units of Beacon Interval. It can converted to the DTIM Interval which is the DTIM Period multiplied by the Target Beacon Transmission Time, expressed in Time Unit (TU). Every Beacon contains a DTIM Count that indicates how many Beacon frames will occur until the next DTIM element, like a countdown timer. When the DTIM Count reaches 0 at every DTIM Interval, the Beacon is a DTIM Beacon. After that DTIM Beacon, the DTIM Count is reset to the DTIM Period minus 1.

When the TIM element is a DTIM (DTIM Count of 0) and there are some group traffic buffered at the AP, the bit 0 of the Bitmap Control field (also called AID 0) is set to 1. The AP immediately transmits the buffered group traffic after that DTIM Beacon. The AP also indicates that there are more group buffered frames using the More Data subfield of the Frame Control field.

In this following Beacon frame, the DTIM Count is 0, so the TIM element of this beacon is a DTIM. In addition, the AID 0 is set to 1 in the Bitmap control (“Multicast: True”), meaning that there are some buffered multicast/broadcast frames. Those frames are immediately sent after that Beacon. A client in PS mode may wake up to receive the broadcast and multicast traffic and then goes back to sleep. The Beacon also shows that the DTIM period is 2, therefore the Beacon frames contain a DTIM indication every 2 Beacons (equivalent to a DTIM interval of 200 Time Units).

The choice of the DTIM Period is a trade-off between power-saving and performance. A longer DTIM Period allows the client to wake up at every DTIM interval rather than every DTIM, allowing more power saving. But it can also affect the performance of applications that are sensitive to the delay of the broadcast/multicast traffic.

A short DTIM Period can also impact power-saving for the clients in PS mode that want to receive all the group traffic, waking up to listen to each Beacon. However some clients don’t wake up at every DTIM Beacon. Depending on driver implementation, some clients in extreme low power mode also choose to skip some DTIM beacons and could possibly miss parts of the group traffic. Apple, for instance, recommends a DTIM Period of 3 to ensure that the group traffic is not missed. The DTIM Period should be chosen according to the type of devices and applications.

In the following Wireshark capture, a client sends a QoS Null Data frame (packet #1) to goes from Active mode to PS mode. From then, the client has to check the DTIM Beacon frames to retrieve the group traffic. The Beacon frames include a TIM element with a DTIM Period of 3. When the DTIM Count is equal to 0 and the AID 0 bit (DTIM+Bcast column) is set to 1, the AP sends a DTIM Beacon frame (#13, #23) that indicates some buffered group traffic. The AP immediately sends the broadcast ARP Request Data frames (#14, #24) after those two Beacon frames. A client in PS mode may retrieve those frames if it listens to those DTIM Beacon frames.

The TIM Count value can be added with the filter: wlan.tim.dtim_count

And the DTIM+Bcast value with the filter: wlan.tim.bmapctl.multicast

Buffered unicast traffic delivery and legacy Power Save (PS) mode

When a client in PS mode sees a TIM element indicating some individually-addressed buffered frames for itself, there are several ways to retrieve the buffered frames. The original method is the legacy 802.11 PS mode delivery mechanism.

The legacy PS mode mechanism is based on the PS-Poll frame to retrieve the buffered frames in the AP. The PS-Poll frame is a short Control Frame containing the AID value of the client.

In the legacy PS mode, when the client receives a Beacon with its AID in the TIM element, the client initiates the frame delivery by transmitting a PS-Poll control frame to the AP. The AP responds immediately (or acknowledges the PS-Poll frame and responds) with only a single buffered frame. The client stays awake and retrieve the buffered frame.

The AP also indicates that there are more buffered frames for the client using the More Data subfield. The client continues to retrieve further buffered frames using more PS-Poll frames until there are no more buffered frames and the More Data subfield is set to 0. Then the client goes back into doze state.

The following packet capture has been done with an old PCMCIA 802.11b radio card. In this example, the client enters in PS mode (Null Data #1 and ACK #2) and listens only to some Beacon frames while keeping the radio in doze state the rest of the time.

The TIM AID value can be added in a column with the filter: wlan.tim.aid

When a Beacon frame (#6) announces in the TIM element that there is some buffered traffic for our client whose AID is 1. The client listens to this Beacon frame and transmits a PS-Poll frame (#7) to retrieve the traffic. The PS-Poll frame tells the AID of the client to the AP.

The AP acknowledges the PS-Poll frame and sends the buffered traffic, in this case an ICMP Request (#9). The More Data bit is set to 0 in the Data frame to indicate that there is no more buffered traffic.

The client responds with an ICMP Reply (#11) with the Power Management bit set to 0 which enables the active mode instead of staying in PS mode. The AP validates the change of Power Management mode with the ACK (#12). As the traffic is idle after, the client switches back to PS mode (Null Data #14 and ACK #15).

Rather than the legacy PS mode, there is a de-facto popular method for a client in PS mode to retrieve the buffered traffic: the client simply exits the PS mode and switches back to active mode. Null Data frames or QoS Null Data frames are generally used for this purpose.

In the next Wireshark packet capture, when the client in PS mode sees a Beacon frame (#11) with a TIM element indicating buffered frames associated to its AID, the client sends a Null Data frame (#12) with the Pwr Mgt bit set to 0. Once the client is in active mode, the AP immediately transmits all the buffered frames destined to the client, an ICMP Echo Request (#14). The client also replies to the ping (ICMP Echo Reply #16). After a little while, the client goes back to PS mode by sending a Null Data frame (#18) with the Pwr Mgt bit set to 1.

A ping connectivity test from the wired network to a wireless client in PS mode could defer the transmission of ICMP Echo Request frames for one Beacon interval (or more if there is a higher DTIM Period). It can result in an additional latency of 100 milliseconds or more to Round-trip delay time.

This mechanism using Null Data frames can be more efficient than the PS Polling mechanism if there are multiple buffered frames to retrieve. A single frame exchange with a Null Data frame allows the client to retrieve all the buffered frames compared to one PS-Poll frame exchange per frame in the legacy PS mode. Note that a PS-Poll frame cannot be used to change the Power Management mode because it doesn’t necessarily result in an ACK frame from the AP.

802.11e and Unscheduled Automatic Power-Save Delivery (U-APSD)

The 802.11e amendment has introduced Quality of Service to the 802.11 standard in 2005, and is also the foundation of the Wi-Fi Multimedia (WMM) certification of the Wi-Fi Alliance.

802.11e is backward compatible with the previous Power Management mechanisms. The legacy PS delivery mechanism is still available, and the delivery mechanism for broadcast/multicast traffic follows the same procedures.

Similarly, many QoS clients retrieve the buffered traffic by exiting the PS mode and switching back to Active mode. The difference is that the clients often uses QoS Null Data frames instead of Null Data frames to switch between power management states.

Most importantly 802.11e has prioritized the medium access with Access Categories, Transmit Queues and several parameters (AIFSN, TXOP Limit, CWmin, CWmax). Another difference with 802.11e is that the AP sends the buffered frames in the order of arrival on a per-Traffic Identifier (AC priority), per-client basis.

Additionally 802.11e has added the optional Automatic Power Save Delivery mechanism (APSD) for time-sensitive traffic such as VoIP. APSD defines 2 new delivery mechanisms as following:

  • Unscheduled Automatic Power-Save Delivery (U-APSD): the buffered frames are delivered during unscheduled Service Periods (SP). The client initiates the unscheduled SP with a trigger frame. Introduced in 2005, the WMM-PowerSave (WMM-PS) certification of the Wi-Fi Alliance is based on the U-APSD implementation. However WMM devices do not advertise the 802.11 QoS formats. They use a different format for the frame elements compared to the elements defined in the 802.11 standard.

  • Scheduled Automatic Power-Save Delivery (S-APSD): the buffered frames are delivered during scheduled Service Periods (SP). In an EDCA environment, a client sends an ADDTS Request frame with the APSD and Schedule subfields of the TS Info field in the TSPEC element both set to 1. The AP responds with a Schedule element in the ADDTS Response frame.

U-APSD is a mechanism used to retrieve the individual unicast buffered traffic. A client in PS mode starts the unscheduled SP by sending a trigger frame which is a QoS Data frame using a trigger-enabled Access Category (AC).

During the unscheduled SP, the AP sends one or more individually-addressed buffered frames that belong to the delivery-enabled ACs and that are destined to the client. The AP must send no more than the number indicated by the Max SP Length field of the QoS Capability element of the (Re)Association Request frame if this field has a nonzero value. The AP sets the More Data bit to 1 using a delivery-enabled AC or a nondelivery-enabled AC to indicate that there are some buffered traffic for the delivery-enabled ACs or a nondelivery-enabled ACs.

Finally the client remains awake until the AP ends the unscheduled SP by setting the EOSP bit to 1 in the QoS Control field of the last QoS Data frame that is sent to the client.

The client may send an additional trigger frame if the More Data bit is set to 1 in a received frame using a delivery-enabled AC, or a PS-Poll frame if the More Data bit is set to 1 in a received frame using a nondelivery-enabled AC. The client must poll until there are no more buffered traffic for that client.

For any nondelivery-enabled AC, the client sends a PS-Poll frame to retrieve the buffered traffic.

In the 802.11 standard, when a QoS AP supports the APSD capability, it enables the APSD bit in the Capability Information field in Beacon, Probe Response, and (Re)Association Response frames.

Within the WMM-PS certification, a WMM-PS AP advertises the U-APSD capability in the U-APSD subfield (bit 7) in the QoS Info subfield of both the WMM Information element and the WMM Parameter element. The QoS Info element may be found in Beacon frames (either a WMM Information element or a WMM Parameter element), Probe Response frames (WMM Parameter element), and (Re)Association Response frames (WMM Parameter element if the corresponding (Re)Association Request contains a WMM Information element).

The following Beacon is captured from a WMM-PS AP.

In the 802.11 standard, a QoS client advertises the U-APSD capability by designating which ACs are enabled for trigger and which ACs are enabled for delivery. The client has 2 methods to enable U-APSD:

  • Static U-APSD: the client uses the per-AC U-APSD Flag bits in the QoS Info subfield of the QoS Capability element carried in (Re)Association Request frames. When the U-APSD Flag bit of an AC is set to 1, U-APSD is enabled for both delivery and trigger in the corresponding AC.

  • ADDTS Request (TSPEC): the client sends an ADDTS Request frame per AC with the APSD subfield set to 1 and the Schedule subfield set to 0 in the TS Info field in the TSPEC element. Trigger ACs and Delivery ACs can be specified differently using TSPEC. APSD settings in an ADDTS Request take precedence over the static U-APSD settings.

Back to the WMM-PS certification, a client signals its U-APSD capability by setting the per-AC U-APSD Flag bits in the QoS Info subfield of the WMM Information element carried in (Re)Association Request frames, or using WMM TSPEC element. The Max SP Length is also specified in the QoS Info subfield.

The following capture shows the procedure when a QoS Data trigger frame from the client in PS mode allows the delivery of buffered unicast frames from the AP.

The application on the client in PS mode sends an RTP G.711 voice packet (#2) with the Power Management bit still set to PS mode. This packet is QoS Data frame tagged with Best Effort which is a Trigger-enabled AC as established in the Association Request, so this packet is a Trigger frame. From this moment, the client is awake to retrieve any buffered traffic. The AP returns any unicast buffered traffic, in this case, an RTP G.711 voice packet (#6) tagged with a Voice Delivery-enabled AC. The traffic from the AP is transmitted within an RTS/CTS mechanism.

Next, the AP sends a QoS Null Data frame (#10) with the EOSP bit set to 1 in order to signal the end of delivery. At this moment, the client switches back to doze state. Then (after 16 milliseconds, defined by the application), the client sends another RTP G.711 voice packet (#12) with the Power Management bit still set to PS mode. This time, the AP has no buffered traffic and sends a QoS Null Data frame (#16) with the EOSP bit set to 1 to indicate the end of delivery. Note that the client stays in PS mode for the whole time.

The EOSP value can be added in a column with the filter: wlan.qos.eosp

U-APSD is a polling method like the legacy PS mechanism; U-APSD is, however, more efficient because an active application can control how often the traffic needs to be retrieved using trigger frames. It will reduce the latency. This is why U-ASPD is well-suited for periodic low latency applications such as Voice over IP. On the contrary, when a client is using the legacy PS mode, the applications are dependent on the listen interval and on the radio driver implementation to retrieve the buffered traffic.

In addition, U-APSD has less overhead than the legacy PS mechanism. For example, the trigger frames may contain application data, whereas the PS-Poll frames are only control frames. U-APSD also allows to retrieve multiple frames instead of polling each individual buffered frames.

802.11v Wireless Network Management (WNM): BSS Max Idle and Sleep Mode

There are 2 features in the 802.11v Wireless Network Management (WNM) amendment that extend the sleeping time for the clients: BSS Max Idle Period Management and WNM-Sleep Mode.

BSS Max Idle Period Management allows an AP to indicate a time period during which the AP will not disassociate a client due to non-receipt of frames from the connected client. It improves the battery life because the client can remain in Doze mode without sending some periodic keep-alive frames for the duration indicated by the AP.

The AP advertises the BSS Max Idle Period Management with the BSS Max Idle Period element in the (Re)Association Response frames.

The Max Idle Period is expressed in unit of 1000 TUs (equivalent to 1.024 seconds). The Idle Options can be used to require that the AP only uses protected frames for keep-alive.

In this following Association Response, the AP informs the client that it can remain idle without transmitting any frame to the AP for a maximum of 3600 TU (3686.4 seconds).

WNM Sleep Mode is an optional 802.11v feature that allows an AP to advertise WNM services to its connected clients. WNM Sleep Mode allows the client to be sleeping for an extended time while it remains associated to the AP. During that extended power save mode, the client may not listen to any DTIM Beacon frames and is not required to perform the GTK/IGTK updates.

A client operating in WNM Sleep mode doesn’t have to listen for the Beacon frames during the Listen interval. The client can specify a longer WNM Sleep Interval during which it wakes up to check for the TIM element. The client can also establish traffic filtering rules with the AP or enable a periodic keep-alive report from the client.

The feature is useful for sensors or IoT devices that are running on batteries for a very long time while the client doesn’t need to listen to the group traffic or when the client only wants to receive a specific type of traffic.

An AP that supports WNM Sleep mode sets the WNM Sleep Mode field of the Extended Capabilities element to 1 in Beacon frames, (Re)Association Response frames and Probe Response frames. A client that supports WNM Sleep mode sets the WNM Sleep Mode field of the Extended Capabilities element to 1 in (Re)Association Request frames and Probe Request frames.

The client sends a WNM Sleep Mode Request frame (WNM Action frame) to the AP when the client enters and exits the WNM Sleep mode. And the AP confirms with a WNM Sleep Mode Response frame as shown in the following diagram.

Those two WNM Action frames include a WNM Sleep Mode element.

The Action Type field identifies the client request (Enter WNM Sleep Mode, Exit WNM Sleep Mode). The WNM Sleep Mode Response Status field provides the status returned by the AP.

The WNM Sleep Interval indicates how often the client wakes up to listen to the Beacon frames to check for the TIM element, in unit of number of DTIM Intervals. A client in WNM-Sleep mode doesn’t need to wake up at every DTIM interval for the group traffic. When the client doesn’t need to listen to the group traffic, a value of 0 indicates that the client doesn’t wake up at any time for the DTIM Beacon frames.

The WNM Sleep Interval can be used by the AP to change the aging time of the buffered traffic for the client. The WNM Sleep Interval must be less than the BSS Max Idle Period as well.

A client may use WNM Sleep mode and PS Mode simultaneously. When a client is in WNM Sleep mode and in PS mode, the AP buffers the unicast frames destined to the client according to the established Traffic Filtering Agreement. When a client is in WNM Sleep mode and in Active mode, the AP buffers the group traffic according to the agreement and to the WNM Sleep Interval.

Note that two of the ten vulnerabilities of the recent WPA2 “KRACK” attack (CVE-2017-13087 and CVE-2017-13088) exploits WNM Sleep Mode Response frames to force a client to reinstall a previously used group key or a previously used integrity group key.

802.11n Spatial Multiplexing (SM) Power Save

The Spatial Multiplexing Power Save (SM Power Save or SMPS) allows an HT client that is capable of multiple spatial streams to operate with only one active receive chain (1x1 SISO) instead of all active receive chains (MIMO) when it is not needed. The feature is also called MIMO Power Save.

There are 2 different methods with SM Power Save:

  • Dynamic SM Power Save: the client enables its multiple receive chains when the AP starts a frame exchange sequence destined to that client. An RTS/CTS sequence is typically used. The AP sends a single-spatial stream frame to that client and the client switches to the multiple receive chain mode to receive the following frame addressed to it. When the frame exchange sequence ends, the client switches back to a single receive chain.

  • Static SM Power Save: the client only maintains a single receive chain active.

A client may use the SM Power Save subfield of the HT Capability Information field in the HT Capabilities element of the (Re)Association Request frame to change the SM Power Save mode. This method enables only one single receive chain after (Re)Association.

The 2 bits of the SM Power Save subfield indicate the SM Power Save mode that is in operation immediately after (Re)Association, as well as a capability. It is set to 0 for Static SM Power Save mode, set to 1 for Dynamic SM Power Save mode and set to 3 when SM Power Save is disabled or not supported.

In the following capture, the client supports and operates in Dynamic SM Power Save mode.

The client may also use an SM Power Save Action frame (HT Action frame) to manage the SM Power Save transition. The SM Power Control element communicates any change about the SM Power Save state.

The SM Power Save Enabled subfield is set to 1 when SM power saving is enabled at the client. The SM Mode subfield is set to 1 for Dynamic SM Power Save and set to 0 for Static SM Power Save mode. The change is validated after the frame has been successfully acknowledged.

In this following capture, a client informs the AP that it operates in Static SMPS mode with an SM Power Save Action frame. The client turns off all the active radios except one and operates as a SISO device.

In the next capture, a client sends an SM Power Save Action frame to operate in Dynamic SMPS mode.

When the client uses Dynamic SMPS, the AP can use a quick frame exchange sequence such as an RTS/CTS to signal the client to wake up all its active receive chains and operate using MIMO. After the frame exchange, the client automatically switches back to a single active receive chain.

802.11ac VHT TXOP Power Save

The VHT TXOP Power Save feature allows a VHT client to enter the doze state when when frames are delivered during a transmit opportunity (TXOP) to other clients. A client can operate in VHT TXOP Power Save mode when its Power Management is in active mode. The client may enter the doze state during a TXOP under specific conditions. The AP must not transmit frames to this VHT client during that TXOP.

First of all, both the VHT AP and the VHT client must support VHT TXOP Power Save. An AP advertises the capability by setting the TXOP PS subfield of the VHT Capabilities Information field in the VHT Capabilities element to 1 in Beacon frames, (Re)Association Response frames and Probe Response frames. A client advertises the capability by setting the TXOP PS subfield of the VHT Capabilities Information field in the VHT Capabilities element to 1 in (Re)Association Request frames and Probe Request frames.

Then the AP allows the client to enter the VHT TXOP Power Save mode during a TXOP by transmitting a VHT PPDU with the TXVECTOR parameter TXOP_PS_NOT_ALLOWED set to 0. This value must not be changed during the rest of the TXOP.

Until the end of the current TXOP, the client may enter the doze state under specific conditions, using some information such as the RXVECTOR parameter PARTIAL_AID (a TXOP SU PPDU that is addressed to another client, but not that client) or the RXVECTOR parameter GROUP_ID for MU-MIMO (a VHT MU PPDU that is not intended to that client).

In the following diagram, a MU-MIMO AP sends data to a group of four clients. After checking the preamble at the beginning, a fifth client in TXOP PS mode would turn off its radios during this transmission.

Additional Resources

IEEE Standard 802.11-2016:

https://standards.ieee.org/findstds/standard/802.11-2016.html

Wi-Fi Alliance WMM Specification v1.2:

https://www.wi-fi.org/file/wmm-specification-v12

Eldad Perahia and Robert Stacey (2013), Next Generation Wireless LANs: 802.11n and 802.11ac, Cambridge Edition:

http://www.cambridge.org/au/academic/subjects/engineering/wireless-communications/next-generation-wireless-lans-80211n-and-80211ac-2nd-edition?format=AR&isbn=9781107352414#UdLgrKAuVsR9T0v6.97

Aruba 802.11ac Networks Validated Reference Design Guide:

https://community.arubanetworks.com/t5/Validated-Reference-Design/Aruba-802-11ac-Networks/ta-p/242637

Aruba Knowledge Base, U-APSD explained and debugged:

http://community.arubanetworks.com/t5/Community-Tribal-Knowledge-Base/U-APSD-explained-and-debugged/ta-p/16471

Aruba Technology Blog, 802.11 - TIM and DTIM Information Elements:

https://community.arubanetworks.com/t5/Technology-Blog/802-11-TIM-and-DTIM-Information-Elements/ba-p/256997

802.11 Power Management and other related articles, Rasika Nayanajith blog:

https://mrncciew.com/2014/10/14/cwap-802-11-power-management/

802.11v Basic Service Set (BSS) on AireOS WLC, Cisco technical notes:

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/201015-802-11v-Basic-Service-Set-BSS-on-AireO.html

Optimisation with Air Time Fairness

I was recently testing an RF optimisation feature called Air Time Fairness (ATF). An ATF-enabled access point can control the medium access based on the airtime utilization. The purpose of ATF is to improve the client performance by enforcing an airtime limit per WLAN and/or per client.

Air Time Fairness is a feature that is provided by many wireless network manufacturers (Meru Networks historically, Aruba, Aerohive, Extreme, Meraki and many others) with some implementation differences. Many consumer-grade access points are also providing a similar feature.

It is also a component of the Cisco High Density Experience (HDX) features. It is designed for use in a variety of environments, including stadiums, public hotspots, education and enterprise, where there are a large number of clients with mixed connection speeds.

Cisco has introduced ATF into 2 phases. At first it was introduced in AireOS version 8.1. This ATF Phase 1 can create ATF policies to allocate a percentage of airtime to each WLAN on a group of AP radios. The WLC will enforce the traffic policies to ensure that the air utilisation of all the clients of the WLAN matches the allocated airtime.

In a second phase (AireOS 8.2), the ATF Client Fair Sharing (CFS) feature was added to improve the client experience on each WLAN. The idea behind CFS is to allocate an equal airtime to each client in the downstream traffic, from the access point to the client. From the version 8.4, ATF is also supported for Mesh APs.

ATF Monitor mode

The first step towards implementing the ATF feature on the network would be to enable Monitor mode. With no control on the traffic, the Monitor mode will provide useful real-time statistics about the airtime utilisation on the APs and on the WLANs. Later, the ATF policies can be designed based on the measurements that were collected in the Monitor mode.

By default, ATF is disabled globally on the controller. The ATF Monitor mode can be enabled or disabled:

  • Per radio

  • Per AP

  • Per AP Group

  • Globally for all APs

The ATF Monitor mode will provide statistics of the Airtime Utilisation at different levels:

  • Per WLAN

  • Per radio

  • Per AP

Note that before configuring ATF, disable all the WLANs at first. You can enable the WLANs after all the changes are done.

To enable ATF Monitor mode for all the APs that are associated to the controller:

(WLC) >config atf 802.11a mode monitor

(WLC) >config atf 802.11b mode monitor

Using GUI:

In WIRELESS | ATF | Monitor Mode, select Network. Check 802.11a and 802.11b for the Radio Type. And click on Enable.

To verify if ATF is disabled or enabled, in Monitor mode or in Enforce-Policy mode:

(WLC) >show atf config all

AP Name                          MAC Address       Slot Admin    Oper        Mode           Optimization Override

-------------------------------- ----------------- ---- -------- ----------- -------------- ------------ ---------

LAP1                             00:6b:f1:29:f4:80 0    ENABLED  UP          Monitor        n/a          Network level

LAP1                             00:6b:f1:29:f4:80 1    ENABLED  UP          Monitor        n/a          Network level

With ATF enabled, the AP will report the ATF statistics to the controller every 180 seconds by default. The WLC collects the number of bytes and frames which are sent and dropped, and the airtime used for the download traffic, per WLAN and per AP radio.

To display the statistics of the AP per radio and per WLAN:

(WLC) >show atf statistics ap AP-NAME {802.11a | 802.11b} summary

 

ATF is in Monitor Mode

 

  Radio Uptime [ Instantaneous | Total ]......... 180 sec | 1075 sec

  Total Radio Air Time........................... 2551ms

 

  STATISTICS PER WLAN............................ Instantaneous    | Total

 

  Wlan 2:

  Network Name................................... OPEN

  ATF Policy ID.................................. 0

  ATF Policy (weight|%allotted).................. 10 | 100%

  Airtime Used .................................. 47ms              | 2551ms

  Relative Airtime % ............................ 100              | 100

  Absolute Airtime % ............................ 0                | 0

 

  Bytes Sent .................................... 247KB              | 19MB

  Bytes Dropped ................................. 0Bytes           | 2Bytes

  Frames Sent ................................... 270              |  17989

  Frames Dropped ................................ 0                |  1

 

The output displays the Instantaneous statistics for the last time interval (the last 180 seconds by default) and the Total statistics that are cumulated since the radio was up or the statistics were resetted. In the example, 247 Kibibytes were sent on WLAN 2 on LAP1 during 47 milliseconds over the last 180 seconds, which means almost 0% of the airtime was used on the downlink. It is a very low usage in this case.

Using GUI:

In WIRELESS | ATF | ATF Statistics, select the AP Name.

The page will display the same statistics (Instantaneous and Accumulated) per WLAN and per radio. Notice that the ATF mode and the ATF measurement interval are also shown on the page.

Click on the WLAN hyperlink to access the statistics of the selected WLAN.

On the ATF Statistics page, the displayed values for Instantaneous statistics are within the period of Measurement Interval. The default is 180 seconds and it can changed for debugging for example.

To specify the ATF Measurement interval in seconds using CLI:

(WLC) >config ap stats-timer PERIOD AP-NAME

To see the actual interval of an AP radio:

(WLC) >show atf statistics ap AP-NAME {802.11b | 802.11a} summary

 

ATF is in Monitor Mode

 

  Radio Uptime [ Instantaneous | Total ]......... 5 sec | 993 sec

Another useful command to reset the cumulative statistics on the controller using CLI:

(WLC) >clear atf statistics

 

This command will clear ATF Statistics!!

Are you sure you want to continue? (y/n) y

 

ATF Policies and ATF Enforcement mode. Phase 1.

The second step is to create some ATF policies for the WLANs and to set the ATF Enforcement mode. The objective is to control the airtime resource with a global limit per WLAN.

The network administrator can manage the policies to control the WLAN airtime budgets, with a strict or an optimised enforcement. The AP will allocate a percentage of the total available airtime (instead of the bandwidth with rate limiting) in order to access the medium. The solution is more efficient than rate limiting to ensure that a client with slow connection speed doesn’t bring down the performance of the clients of the other WLANs.

The mechanism of ATF is controlled by the access point. The AP is passing the traffic if the airtime budget is not reached for the WLAN and/or for the client, by queuing and policing. This traffic policing is done before the frame is transmitted to the EDCA queues. If the budget is reached, the frame is dropped or deferred in another priority queue. But ATF doesn’t replace the standard airtime access mechanism that is EDCA.

Note that ATF is only applicable to the wireless data frames in the downstream direction (from the AP to the clients). The upstream traffic is not controlled by a Cisco access point with ATF.

The network administrator can tune the controller by allocating some weights to the ATF policies. Those weights have no unit of measurement. The allotted airtime utilisation for each WLAN is proportional to the weight of the ATF policy associated to the WLAN. The total airtime utilization is equivalent to the sum of the weights associated to the ATF policies of all the WLANs that are up.

For example, I have configured 2 WLANs:

  • WLAN1 associated to an ATF policy with a weight of 10

  • WLAN2 associated to an ATF policy with a weight of 40

The sum of the weights associated to the 2 WLANs (10 + 40) represents the total airtime utilisation (100%). The AP will enforce the air utilisation so that the traffic on WLAN1 can use the airtime up to 20% (10 out of 50), and the traffic on WLAN2 up to 80% (40 out of 50). Those allotted airtime values in percentage are the maximum airtime traffic on the WLAN in the downstream direction (AP to clients).

At first, disable the WLANs before changing the configuration with ATF. Re-enable the WLANs after all the changes.

To enforce Air Time Fairness with ATF policies:

  1. Create the ATF policies:

  2. (WLC) >config atf policy create POLICY-ID POLICY-NAME POLICY-WEIGHT client-sharing {enable | disable}

    The weight can be any value between 5 and 100. Remember that the weight value doesn’t directly express a percentage of the available airtime. The WLANs can be enabled/disabled anytime and the weights of the remaining up WLAN are dynamically recalculated into percentage.

    The Client Sharing feature is described later in the next section. During the early deployment of Phase 1, the feature was not available (by default, disabled in the default policy).

  3. Map each WLAN to an ATF policy:

  4. (WLC) >config wlan atf WLAN-ID policy POLICY-ID

    By default, all the WLANs are mapped to the “Default” with a default weight of 10 and with Client Sharing disabled.

  5. Enable ATF Enforcement Mode

  6. (WLC) >config atf 802.11a mode enforce-policy

    (WLC) >config atf 802.11b mode enforce-policy

    Those 2 commands enables ATF Enforcement mode for all the APs associated to the controller.

  7. Choose between Strict Enforcement and Optimal Enforcement

  8. (WLC) >config atf 802.11a optimization {enable | disable}

    By default, the optimisation feature is disabled.

    With Strict Enforcement, the maximum airtime utilisation on each WLAN is limited to the allotted value that is calculated from the ATF policies.

    With Optimal Enforcement, the available airtime that is unused by some WLANs is shared among the other WLANs, allowing some traffic bursts beyond the allocated limits.

    The ATF Enforcement mode and the Strict/Optimal Enforcement option can be enabled/disabled:

    • Per radio

    • Per AP

    • Per AP Group

    • Globally for all APs

Using GUI:

In WIRELESS | ATF | Policy Configuration, select a new ID. Enter the Policy Name, the Weight and optionally enable the Client Sharing option. Then click on Create.

Notice that the same ATF policy can be used many times for different WLANs.

In WIRELESS | ATF | Enforcement Mode, select Network. Check the 802.11a and 802.11b Radio Type. Select Optimized or Strict for the Enforcement Type. Then click on Enable.

On the same page, select Network. Select WLAN ID and the Policy ID to associate an ATF policy to a WLAN. Then click on Add.

To verify the ATF policy configuration:

(WLC) >show atf config policy

 

 Policy-Id    Policy-Name    Weight    Client Sharing

 ----------   ------------   -------   --------------

  0           Default        10        Disabled

  1           ATF40          40        Disabled

To verify the WLAN-to-Policy mapping:

(WLC) >show atf config wlan

 

WLAN ID  SSID                  Policy-Name                       Weight  Client Sharing

-------  --------------------  --------------------------------  ------  --------------

1        EAP                   Default                           10      Disabled

2        OPEN                  ATF40                             40      Disabled

To verify if ATF is in Enforcement mode and with or without Optimisation for all APs:

(WLC) >show atf config all

AP Name                          MAC Address       Slot Admin    Oper        Mode           Optimization Override

-------------------------------- ----------------- ---- -------- ----------- -------------- ------------ ---------

LAP1                             00:6b:f1:29:f4:80 0    ENABLED  UP          Enforce-Policy Enabled      Network level

LAP1                             00:6b:f1:29:f4:80 1    ENABLED  UP          Enforce-Policy Enabled      Network level

To find out the percentage of airtime allotted for a WLAN on an AP radio:

(WLC) >show atf statistics ap AP-NAME {802.11a | 802.11b} summary

 

ATF is in Enforce-Policy Mode

 

  Radio Uptime [ Instantaneous | Total ]......... 180 sec | 720 sec

  Total Radio Air Time........................... 0us

 

  STATISTICS PER WLAN............................ Instantaneous    | Total

 

  Wlan 1:

  Network Name................................... EAP

  ATF Policy ID.................................. 0

  ATF Policy (weight|%allotted).................. 10 | 20%

  Airtime Used .................................. 0us              | 0us

  Relative Airtime % ............................ 0                | 0

  Absolute Airtime % ............................ 0                | 0

 

  Bytes Sent .................................... 0Bytes           | 0Bytes

  Bytes Dropped ................................. 0Bytes           | 0Bytes

  Frames Sent ................................... 0                |  0

  Frames Dropped ................................ 0                |  0

 

  Wlan 2:

  Network Name................................... OPEN

  ATF Policy ID.................................. 1

  ATF Policy (weight|%allotted).................. 40 | 80%

  Airtime Used .................................. 0us              | 0us

  Relative Airtime % ............................ 0                | 0

  Absolute Airtime % ............................ 0                | 0

 

  Bytes Sent .................................... 0Bytes           | 0Bytes

  Bytes Dropped ................................. 0Bytes           | 0Bytes

  Frames Sent ................................... 0                |  0

  Frames Dropped ................................ 0                |  0

 

ATF Phase 2 with Client Fair Sharing.

The third step of the ATF implementation consists in enabling Client Fair Sharing. This is the final RF optimisation. The objective of CFS is to avoid the situation where the channel is being monopolized by specific clients with slow connection speed.

Let’s assume a scenario (without CFS) where an access point is sending some traffic with the same flow characteristics to 2 different clients. The frames would be scheduled for transmission alternatively on a per-packet basis to the 2 clients. If one client has lower PHY data rate specifications than the other, then the packet designated to the client with the slowest PHY data rate will consume more airtime than the packet designated to the other client. Without contention, the throughput would be the same for each client. However the airtime utilisation would be greater for the traffic to the slowest client. I have illustrated it in the figure A below.

With Client Fair Sharing (CFS), the airtime is allocated equally per client within the WLAN in the downlink direction (AP to client). In our scenario, the traffic towards each client would be limited to 50% each. The traffic towards the fastest client would have more airtime and more throughput than previously, as shown in figure B. This is particularly useful in high density environments with multiple clients of mixed connexion speed.

To enable Client Fair Sharing on an existing ATF policy:

(WLC) >config atf policy modify client-sharing {enable | disable} POLICY-NAME

Client Fair Sharing requires that ATF is enabled in Enforcement mode. It is also advised to disable the WLANs while changing the ATF policy.

Using GUI:

In WIRELESS | ATF | Policy Configuration, select the ID of the ATF policy. Enable the Client Sharing option. Then click on Modify.

To verify if Client Fair Sharing is enabled on the ATF policy:

(WLC) >show atf config policy

 

 Policy-Id    Policy-Name    Weight    Client Sharing

 ----------   ------------   -------   --------------

  0           Default        10        Disabled

  1           ATF40          40        Enabled

To verify if Client Fair Sharing is enabled on the WLAN:

(WLC) >show atf config wlan

 

WLAN ID  SSID                  Policy-Name                       Weight  Client Sharing

-------  --------------------  --------------------------------  ------  --------------

1        EAP                   Default                           10      Disabled

2        OPEN                  ATF40                             40      Enabled

With CFS enabled, the AP will add the used airtime, the number of bytes and frames for each client into the ATF statistics sent to the controller.

To display the client statistics of an AP, per radio and per WLAN:

(WLC) >show atf statistics ap AP-NAME {802.11a | 802.11b} wlan WLAN-ID

 

ATF is in Enforce-Policy Mode

 

  Radio Uptime [ Instantaneous | Total ]......... 180 sec | 1600 sec

  Total Radio Air Time........................... 2199ms

 

  STATISTICS PER WLAN............................ Instantaneous    | Total

  Wlan 2:

  Network Name................................... OPEN

  ATF Policy ID.................................. 1

  ATF Policy (weight|%allotted).................. 40 | 80%

  Airtime Used .................................. 2197ms              | 2199ms

  Relative Airtime % ............................ 100              | 100

  Absolute Airtime % ............................ 1                | 0

 

  Bytes Sent .................................... 13MB              | 13MB

  Bytes Dropped ................................. 0Bytes           | 0Bytes

  Frames Sent ................................... 10510            |  10517

  Frames Dropped ................................ 0                |  0

                      Instantaneous Airtime               Cumulative Airtime

Clients           [Abs % | Rel % | Airtime]           [Abs % | Rel % | Airtime]           Tx(Sent)Frames           Tx(Dropped)Frames       Usage Status

-------           -------------------------           -------------------------           --------------           -----------------      -----------------

985f.d3bb.35e8     1%| 63%|1391521us                    0%| 63%|1391 ms                      4813                         0                LOW USAGE

ec9b.f332.f140     0%| 37%|806426us 0%| 37%|807 ms 5697 0 LOW USAGE

 

(WLC) >show atf statistics client CLIENT-MAC

 

Client MAC Address............................... 98:5f:d3:bb:35:e8

Client Username ................................. N/A

AP MAC Address................................... 00:6b:f1:29:f4:80

AP Name.......................................... LAP1             

AP radio slot Id................................. 1 

Wireless LAN Id.................................. 2 

ATF Policy ID.................................... 1 

Wireless LAN Profile Name........................ OPEN

  Radio Uptime [ Instantaneous | Total ]......... 180 sec | 1600 sec

  Total Radio Air Time........................... 2199ms

  Airtime Used .................................. 1391ms              | 1391ms

  Relative Airtime % ............................ 63               | 63

  Absolute Airtime % ............................ 1                | 0

 

  Frames Sent ................................... 4813             |  4813

  Frames Dropped ................................ 0                |  0

Using GUI:

In WIRELESS | ATF | ATF Statistics, select the AP Name. It will redirect to the ATF Statistics page for this AP. Then click on the WLAN hyperlink to access the statistics of the selected WLAN.

You can get the client statistics by clicking on the Client MAC address hyperlink.

The experiment.

In the following example, I have setup a WLAN with an ATF policy limited to 90% of the total airtime with Strict Enforcement. To do so, I have another WLAN with an ATF policy with 10% airtime budget.

Three clients were connected to the WLAN using a clean 5GHz channel:

  • 1 client configured with HT disabled (802.11a, limited to 54 Mbps): STA-A

  • 2 High Throughput clients (802.11n, 2 Spatial Streams, limited to m15 i.e. 144 Mbps): STA-B and STA-C

Then I have used the iperf software to send a maximum throughput to all the clients. A local server was setup to transmit 500MB of UDP traffic at a bitrate of 144 Mbps with the same frame size from the AP to each client.

The following graph shows the results. The stacked areas represents the airtime utilisation of each client. The coloured lines shows the throughput of each client and the total throughput.

The graph shows that the airtime utilisation is limited to 90% as configured in the ATF policy.

During the first half of the test, the throughput is not the same between the 3 clients. The 2 High-Throughput 802.11n clients have fluctuated around an average of 24.35 Mbps and 28 Mbps. The legacy 802.11a client has achieved a lower throughput of 7.87 Mbps.

However the airtime utilisation for each client is equally distributed between the 3 clients during that time (cumulative airtime of 32% for STA-A and 34% for the 2 other clients, between 0 and 145 seconds). The ATF policy with CFS was dropping frames to ensure that the airtime between clients stays equal.

During the second half-time of the test, iperf was finished for the 2 802.11n clients. The 802.11a client was still receiving packets from the server at a higher throughput of 18.94 Mbps (20-22 Mbps typical downstream throughput for a data rate of 54Mbps).

To compare, I’ve tried the same experiment with CFS disabled and ATF in Monitor mode:

The result were quite different. The time when the fastest client has finished downloading 500 MB is longer (213 seconds) than in the previous test (145 seconds). During that time, the received throughput on the 802.11a client is also higher (10.95 Mbps). In this case, the 802.11a client has taken more throughput and more airtime than previously, slowing the faster clients. The previous test with CFS enabled was more efficient for the 802.11n clients.

Here are a few more comments about the experiment:

  • I used UDP instead of TCP (to avoid having additional congestion control mechanisms)

  • I used at least 3 clients. I’ve not seeing client fairness working with 2 clients only.

  • Give a bit of buffer to the WLAN maximum airtime when testing with iperf. With an ATF policy of 100% airtime and CFS enabled, the results were not looking fair when the utilisation came close to 100% (hence the 90% policy). In production, the WLAN would hopefully never reach 100%.

  • I've tested each client one-by-one to make sure that the client could maximise the total airtime. If the airtime utilisation is lower than the allocated airtime per client, there are no packet drops and no traffic policing.

 

Troubleshooting and debugging.

There are some show commands related to the ATF statistics on the APs. To see the statistics in real-time on the AP:

(AP) >show controller dot11Radio {0 | 1} atf [detail]

If CFS is enabled on the AP, you can use the following command to see the client statistics in real-time:

(AP) >show controller dot11Radio {0 | 1} atf cfs [client | detail | policy]

For example, you will find the real-time client statistics from the AP command:

(AP) >show controller dot11Radio 1 atf cfs detail

 

ATF CLIENT ENFORCEMENT DEAILED STATS:

--------------------------------------

SSID Name: OPEN Policy Name: ATF90

--------------------------------------

     Active Client Count: 3 Left Client Count: 0 Updated : Since 1977 ms before

     [Category Count]Low: 0 Regular: 1 Over-Use: 0

     SharedPoolTokens: 76554 usecs Total Airtime: 3833956

 

  Clients  [ClientState|Duration]  [PrevState]  [Airtime|Usage%]  [DropCount|Size]  [SharedPoolUsage]  [RefillsTried]  [LeftSince]

  -------  -----------------------    ----------    ----------------    ---------------    ----------------    -------------    -----------------

8c70.5a7c.44f9 OVER USAGE| 153 sec LOW USAGE         1342342us  35 %         84112 |88654048          246840  393             NA

985f.d3bb:35e8 LOW USAGE|   0 sec OVER USAGE             0us   0 %     0 |  0                    0              0             NA

fc75.1661.290a OVER USAGE| 151 sec OVER USAGE        2491614us  65 %         58672 |61840288          922936  400             NA

Notice that the client state is categorized into 3 groups: Low, Regular and Over Usage. It allows for the AP to take the unused airtime of the clients in Low or Regular Usage state for the clients in Over Usage state.

There are also some debug commands associated to ATF on the controller:

(WLC) >debug atf detail enable

 

(WLC) >debug atf error enable

 

(WLC) >debug atf events enable

You can see the messages related to ATF statistics that are sent from the APs to the controller:

*iappSocketTask: Dec 20 19:24:58.804: IAPP-ATF Stats:50 Bytes Sent from AP

*iappSocketTask: Dec 20 19:29:37.109: iapp_decode_update_atf_client_stats for slotid 1 wlanid 2 TotalEntries 2 CurrentPcktCount 2 entry indx 0

*iappSocketTask: Dec 20 19:29:37.109: 985f.d3bb:35e8 1391521us 4813                0                    1

*iappSocketTask: Dec 20 19:29:37.109: ec9b.f332.f140 806426us 5697                 0                    1

*spamApTask2: Dec 20 19:29:37.109: tlvDecodeSpamAtfStatsPayload wlanid 1 airtimeused 0 bytesent 0 bytedrop  0  framesent   0  framedrop 0

*spamApTask2: Dec 20 19:29:37.110: tlvDecodeSpamAtfStatsPayload wlanid 1 airtimeused 2197947 bytesent 13794304 bytedrop  0  framesent   10510  framedrop 0

Those messages are sent periodically by every AP at the interval defined by the stats-timer value (180 seconds by default). The controller will process them to refresh the ATF statistics.

 

Additional Resources

Cisco Air Time Fairness (ATF) Deployment Guide Release 8.4:

https://www.cisco.com/c/en/us/td/docs/wireless/technology/mesh/8-4/b_Air_Time_Fairness_ATF_Deployment_Guide_rel_8_4.html

Enhancing Cisco High Density Experience with Cisco Air Time Fairness White Paper:

https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html

Meraki documentation, Air Time Fairness (ATF):

https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Air_Time_Fairness_(ATF)

Meru Networks videos, Airtime Fairness:

https://www.youtube.com/watch?v=UwmR5nJcTgs

Ruckus videos, Airtime Fairness:

https://www.youtube.com/watch?v=hXEVAuHxZpg