During Wireless LAN Professional Conference 2019 (WLPC_EU) in Prague, I had a presentation where the WiFi AirTime Calculator was presented. You can read about it and download it from here. And I used the results from the calculator to look at data rate versus throughput in a WiFi network.
This is a theoretical approach and we assume it is no other traffic in the BSS or on the channel. And it is on a 20 MHz channel at the 5 GHz.
A Data field size of 300 bytes is used in this article. I call it the Data field size, other common names are payloads, MPDU, A-MPDU or frame body. The Data field is the correct name according to the standard and it embraces all frame format types.
When a station wins a transmit opportunity (TXOP) a series of frames can be sent between the transmitting station and the receiving station. It can consist of the frames Request to Send (RTS), Clear to Send (CTS), the Data frame and the Block Acknowledgment (BA).
In addition to these frames, we have a lot of waiting time in a TXOP. It is the DCF Interframe Spaces (DIFS), the Random Backoff Timer and a number of Short Interframe Spaces (SIFS). In a QoS-enabled network, the DIFS is replaced with Arbitration Interframe Space (AIFS) and it has different values depending on which Access Category (AC) the data frame is sent in.
In our example, we use this data for our TXOP
- AIFS[BE] (best effort). It is the default queue
- CW = 7. In Access Category Best Effort the Contention Window is a random number between 0 and 15
- Control frames at 6 Mbs (lowest mandatory data rate)
- The Data field is 300 bytes. This includes the MAC header and any additional bits
- The TXOP uses protection mechanism, RTS and CTS
For a VHT (802.11ac) frame, which is sent with the OFDM technology, the WiFi AirTime Calculator calculates the TXOP duration to 398µs and throughput of 6,0 Mbs. It is visualized like this
The Data field (A-MPDU) for this TXOP is inside the green rectangle and it is the only part of the TXOP wich uses MCS7 data rate.
In this TXOP duration of 398µs, only 36µs of it is the Data field. Which means only 9% of the TXOP is useful data. The rest is a necessary overhead in the 802.11 protocol.
If we turned off protection (RTS/CTS), the TXOP duration will decrease to 270µs and the Data field would have increased to 13% of the TXOP duration.
Four station scenario
What if we use this to see what will happen in a scenario with four OFDM stations/clients and one AP. We assume the AP will send the same type of data to those four stations in a round-robin fashion. For ease, we use a TXOP duration of 400µs. It will look like this
In this scenario, STA-A has to wait for 1600µs before it wins its next TXOP. Its throughput will be 1,5 Mbs (300 bytes * 8 bit/1600µs).
So, even if the data field is sent at 72,2 Mbs, the throughput is down at 1,5 Mbs because of all 802.11 overhead and the time the station has to wait for the next TXOP.
The example has used MCS7 and one spatial stream. What if we tested with MCS8 and two spatial streams, still short guard interval. The data rate is now 173,3 Mbs and the TXOP duration for one station goes down to 380µs. In our four-station scenario, each station has to wait for 1520µs until the next TXOP wins and the throughput is 1,6 Mbs for each station.
So the difference between a device using MCS7 and 1 spatial stream, and a device using MCS8 and 2 spatial streams is only 0,1 Mbs in throughput in this 4 client scenario even the data rate is 72,2 Mbs vs 173,3 Mbs.
Upgrading to 802.11ax (WiFi6)
What if we upgrade our network to 802.11ax (WiFi6) and enables OFDMA. The WiFi AirTime Calculator has the ability to show us the TXOP duration for a DL OFDMA transmission. We use the new frame Multi-User Request to Send (MU-RTS) and subdivide the channel into 4 times 52-tones Resource Units (RU).
When the AP sends this 300 bytes Data field it will also include a Trigger MPDU, so the Data field is some bytes bigger. I have not taken this into the calculations.
The next figure shows four different bar graphs. The Data field is still 300 bytes for all scenarios
— bar graph 1: VHT (802.11ac) with MCS7 and one spatial stream
— bar graph 2: VHT (802.11ac) with MCS8 and two spatial streams
— bar graph 4: HE (802.11ax) with MCS7 and one spatial stream on a 52-tones RU
— bar graph 5: HE (802.11ax) with MCC8 and two spatial streams on a 52-tone RU
For the MCS7/1SS (bar graph 4) with HE-transmission (OFDMA) on a 52-tone RU, the duration of a TXOP is 560µs. If we compare the duration for this TXOP with the same TXOP sent with VHT frame format (OFDM) the duration has increased from 400µs to 560µs because the Data field is sent on a subdivided channel and therefore with a smaller data rate. The MU-RTS frame is also bigger than the RTS frame. The data rate for this TXOP is 16,7 Mbs.
Bar graph 5 in the figure is the same Data field sent with MCS8 and 2 spatial streams on a 52-tone RU. The duration for this TXOP is 490µs.
Four client scenario with OFDMA
If we have the same scenario with four stations/clients and using OFDMA, the AP can send traffic to all four clients in parallel. For the setup with MCS7 and 1 spatial stream the TXOP duration is 560µs. It will look like this.
Since this is an ODFMA transmission, the AP can now send traffic to the same station every 560µs (in VHT it had to wait for 1600µs).
The throughput for every station will be 4,2 Mbs (for VHT is was 1,5 Mbs), and the aggregate throughput on the channel will be 16.8 Mbs (4 times 4,2 Mbs).
So with a 300 bytes Data field, even if the data rate is decreased, the throughput has increased for each station by using DL OFDMA instead of OFDM.
The main difference between ODFM and OFDMA in this example is that all stations share the same 802.11 overhead with OFDMA.
And for the 300 bytes A-MPDU, sent with MCS8 and two spatial streams the increase is even higher. The duration for the OFDMA version of the TXOP is 490µs and it will give a throughput of 4,9 Mbs, while it was for VHT 1,6 Mbs.
Another look at OFDMA
In the first scenario, the AP sent traffic to four different stations with a VHT frame format and it gives each station throughput of 1,5 Mbs.
What if we are satisfied with the throughput, but the problem is the 100% airtime utilization.
If we upgrade to 802.11ax (WiFi6) and still only need 1,5 Mbs throughput to each station, the AP must send the 560µs TXOP each 1600µs. It will look like this.
As we can see, between each TXOP we have 1040µs unused airtime.
This newly available airtime can be used for other stations to send traffic or the AP can send the traffic with less delay and less jitter.
Let us summarize the data in a table for our 300 bytes Data field
This is some facts we can find in this 300 bytes Data field TXOP
- The difference in TXOP duration for OFDM devices is small, even if the data rate is very different. This because the 802.11 overhead uses the majority of the TXOP duration
- There is a huge difference between data rate and throughput.
- For OFMDA, even if the data rate decreases the throughput increase because it can send its TXOP more often
- For OFDMA, the aggregated throughput in the channel increase because of the subdividing of the channel and several stations share the same 802.11 overhead in a TXOP
- OFDMA can give more available airtime.
- There is a bigger gain of using stations/client with better capabilities in OFDMA versus OFDM, even for smaller data sizes
There is a but here. These calculations are for small Data field sizes (300 bytes). It will depend on the network’s capabilities and how it decides to use ODFMA.
Many of the 300 bytes frames in a WiFi network is control and management traffic, and I’m not sure OFDMA will be used on these frame types
I have used the results from my WiFi AirTime Calculator to show the difference between data rate and throughput on small packets sizes, 300 bytes.
And it is a huge improvement to use 802.11ax(WiFi6) OFDMA technology for those packet sizes, either by improved throughput or more available airtime
I hope it is useful
4 thoughts on “Data Rata vs Throughput, OFDM vs OFDMA”
Thanks once again for a nice article. In the end you have mentioned that the 300 byte example was mostly control and management traffic. During the standardization of IEEE 802.11ax, it was brought to the notice that many frames in the enterprise networks were short frames with examples of network management etc. being given. This was the big reason given for standardizing OFDMA in the first place.
Very good point
Thank you very much for this tutorial, Gjermund! I was acquainted with OFDMA functionality, but did not appreciate the performance benefit. -Kevin
Thanks for the nice tutorial.