It is the latest modulation technique that allows the access point and Wi-Fi client to send even more data over the air than ever before. Effectively, it adds 2 new MCS indexes 12 and 13 and unlocks faster data rates.
4096-QAM MCS indexes, credit to http://mcsindex.net
Achieving it is challenging as it requires very high Signal to Noise Radio (SNR) – that’s very strong signal and low noise. So in practical terms, it is only used quite rarely.
For context, with another client device using Intel BE200 Wi-Fi 7 adapter, I hit MCS 12 with SNR about 60-62 dB. In other words, if my noise floor was -95 dBm, my signal would have to be about -35 dBm.
Does iPhone 16 support it then?
According to the above spec sheet, the maximum Extremely High Throughput (EHT) the iPhone can achieve is MCS 11. 4096-QAM only uses MCS indexes 12 and 13. Check the mcsindex.net site.
So, the answer is no, it doesn’t.
Is it a dealbreaker?
From data rate perspective, even without 4096-QAM, and using 160 MHz wide channel, we are talking 2000+Mbps! Obviously depending on how far you are from the access point.
So I personally can’t complain. I value access to the clean 6 GHz spectrum, low latency and low retransmissions rate over maximum throughput.
My WAN link speed of 900 Mbps is my personal bottleneck and I usually don’t transfer huge amounts of data from the phone.
High Tx (transmit) and Rx (receive) rates
On a laptop, I can imagine 4096-QAM to deliver much more value when it comes to performing backups for moving very large software image or video files. Having said that, don’t forget that there is 2.5, 5 or 10 Gigabit Ethernet for that.
iPhone 16 supports tri-band Wi-Fi 7 and Multi-Link Operation (MLO). More specifically, the Enhanced Multilink Single‐Radio (EMLSR) mode. The client connects using 2 different Wi-Fi bands, only actively uses 1 of them and listens on both bands simultaneously. Let’s enable it on an access point and verify that it works.
Multi-Link Operation
We have a 320 MHz channel configured on the 6 GHz radio. This is for experimental purposes only. Please use narrower channel in production to avoid adjacent channel interference with other 6 GHz access points.
The tri-band SSID is announced in 2.4 GHz, 5 GHz and 6 GHz bands. It is up to the client device to choose the preferred band. MLO-capable Wi-Fi 7 clients can also enable the MLO feature.
Although iPhone 16 supports MLO, the phone itself doesn’t indicate if MLO is active or not. So our only option is to monitor it from the access point’s side. This is a consumer access point and it doesn’t provide a huge amount of detail. I am hoping to retest this with a proper enterprise-grade AP when I can.
Single band at a time
From the Association Request sent by the iPhone to the access point, we can see that it advertises support for only one band at a time.
With the default settings of the TP-Link Deco BE85 Wi-Fi 7 access point in place, the iPhone establishes MLO using 2.4 GHz and 6 GHz. It actively uses 6 GHz. 2.4 GHz is there for backup purposes.
TP-Link Deco app shows MLO using 2.4 GHz and 6 GHz
The iPhone uses its 160 MHz wide channel capability and actively pushes all data using the 6 GHz channel 69 as I am trying to demonstrate below using Oscium WiPry Clarity spectrum analyser. Check the “waterfall diagram” that shows the top 160 MHz of the 320 MHz channel being busy processing the data transmission.
MLO in action with iPhone primarily using 6 GHz band
The 2.4 GHz link just sits there in the background, unused. Using the same method, I verified that there is no spectrum utilisation whatsoever on the 2.4 GHz channel.
5 GHz and 2.4 GHz EMLSR MLO mode
When we change Preferred Wi-Fi Band setting to 5 GHz, the iPhone establishes 5 GHz active MLO link and 2.4 GHz as backup.
TP-Link Deco app
6 GHz and 5 GHz EMLSR MLO mode
Now, how do we force MLO using the two modern bands? For the purposes of the demo, I simply disable 2.4 GHz radio on the access point.
Disable 2.4 GHz using TP-Link Deco app
The phone establishes 6 GHz active data connection and uses the 5 GHz band as a backup. How can I be so sure? I watched the spectrum and generated nearly 900 Mbps of data over the wireless link. While the 6 GHz channel shows high utilisation, the 5 GHz channel shows no signs of use.
TP-Link Deco app shows 6 GHz and 5 GHz MLO
On the iPhone, we see active channels 69 in the 6 GHz band. That matches what I’ve just seen using the spectrum analyser.
Active 6 GHz channel 69 using max iPhone 16 channel width 160 MHz
How to trigger MLO band change?
Now, I connect the iPhone using 5 GHz channel. I am going to saturate the channel with other client’s traffic. My hope is that high channel utilisation makes the iPhone stop using the 5 GHz channel and switch to the backup 2.4 GHz channel.
And the result? It correctly detected and reported high channel utilisation, but the MLO band change did not happen.
High channel utilisation
So channel utilisation on its own did not do the trick for me. Perhaps the algorithm penalises and tries to avoid the 2.4 GHz band which is typically in a much worse condition than 5 GHz? Or high channel utilisation must persist for a longer period of time? Time will tell.
What chipset does it use? To find out we are going to enable Personal Hotspot on the iPhone and see what information we can get from the information elements it broadcasts in its beacons.
As we can see here, iPhone 16 uses Broadcom Wi-Fi 7 chip. That’s about the level of detail we can capture from the beacon frames it sends.
Broadcom chip
Continue reading
Does the iPhone 16 support Multi-Link Operation? Check this blog post.
All iPhone 16 models support tri-band Wi-Fi 7 as you might have seen here. But what is the maximum channel width they support in the 6 GHz band?
iPhone 16
Although my Wi-Fi 7 access point uses 320 MHz wide channel, the maximum 6 GHz channel width iPhone 16 supports is 160 MHz.
AP using 320 MHz wide channel
Here is the client view of the world.
iOS Wi-Fi Diagnostics profile provides extra information
Spectrum view
I am using Oscium WiPry Clarity 6 GHz spectrum analyser to see the spectrum. When we run a WAN speed tool Speedtest.net (it is not designed to be a Wi-Fi test tool) to generate some traffic here and see how it utilizes the 160 MHz channel.
Outside of that, I also checked the 2.4 GHz channel. There was no activity there. So that proves that only one of the 2 bands involved in MLO is active at a time.
Only the 6 GHz channel is active during data transfer, 2.4 GHz isn’t actively used
Updated: Apple’s iPhone 16 Wi-Fi specification
New documentation is now available directly from Apple. Note that 160 MHz is the maximum channel width for all models.
iPhone 16 Wi-Fi specification published by Apple
You normally won’t use 320 MHz wide channel anyway in Europe
Having said that, at least in Europe, we only have one 320 MHz wide channel available. So by the time you add a second access point you will have to downgrade to 160 MHz channels or narrower. That is to prevent the 2 APs from stepping on each other’s toes and causing adjacent channel interference. No support for 320 MHz channel width on the iPhone is not really a problem.
If you were considering using 320 MHz channels, or if your vendor uses that as a factory default setting, please be a good citizen and don’t.
All iPhone 16 models now support Wi-Fi 7 and come with 2×2 MIMO 2-Spatial Stream radio configuration. But Wi-Fi 7 doesn’t make support of 6 GHz band mandatory. So technically there could be Wi-Fi 7 clients that only support 2.4 GHz and 5 GHz.
Do iPhones 16 support all three 2.4 GHz, 5 GHz and 6 GHz Wi-Fi bands?
I tested a standard non-Pro iPhone 16 model.
It indeed supports all three Wi-Fi bands. Here is a proof of iPhone 16 connected to a Wi-Fi 7 access point using 6 GHz channel 69.
iPhone 16 connected using the 6 GHz Wi-Fi band
Using the My Wi-Fi Apple Shortcut we can look into another level of detail. In this case the iPhone is using the 802.11be Wi-Fi 7 standard to communicate with the access point.
iPhone 16 using Wi-Fi 7 802.11be standard
Association Request
As the iPhone associates to the AP, it announces no support for 320 MHz channel width.
Intel NUC 12th generation with Intel BE200 Wi-Fi 7 adapter
Drivers
Download and install latest driver from Intel’s website. Windows Update itself won’t install any driver, so some manual steps are required. I originally tested driver version 23.20.0.4, and now updated to 23.30.0.6.
Setup
We are using TP-Link Deco BE85 BE19000 consumer Wi-Fi 7 router connected to a 10 Gigabit iperf3 server running on MacBook connected via OWC 10 GbE to Thunderbolt adapter. We have done this on Linux before, so let’s see how the same Wi-Fi adapter performs on Windows.
Wi-Fi 7 on Windows 11 test topology
Performance
On the router, we have configured and verified 320 MHz wide Wi-Fi 7 channel. But when we connect the Windows client, looking at the data rate, it is surprisingly low – if you forgive me calling 2882 Mbps ‘low’ 😊 Considering that the NUC is about 1 meter away from the router, I would expect ~5 Gbps data rate. So what’s going on here?
Connected Wi-Fi 7 client, but low data rate
Interestingly enough, it is the same data rate as we see when connected using 5 GHz 160 MHz channel. Yes, I know, that’s a no-no in Wi-Fi design. We are just testing here.
Hmm, 160 MHz wide 5 GHz channel gives us the same data ratenetsh wlan show interfaces command output
Since Windows doesn’t expose the channel width in the UI, we don’t quite know what is happening on the air. Let’s generate some 6 GHz traffic, and check using Oscium’s WiPry Clarity tri-band spectrum analyser. I love this little USB tool. In this example I use a WLAN Pi as a Remote Sensor. It scans for Wi-Fi networks and streams spectrum information to WiFi Explorer Pro on Mac.
WLAN Pi Remote Sensor with Oscium WiPry Clarity scanning 6 GHzWindows client is using 160 MHz instead of 320 MHz
Bingo! Apparently, on Windows Intel BE200 uses 160 MHz channel width and doesn’t support 320 MHz wide channel. That halves our data rate and throughput. I wish Windows made channel width more obvious in the UI. Intel BE200 adapter supports 320 MHz wide channels on Linux without a sweat, so hopefully it will get fixed in a future Intel driver or Windows release.
Updated: Apparently, I didn’t read Intel’s release notes closely enough, my bad 😊 Intel BE200 adapter on Windows 11 is only able to use Wi-Fi 6E today. Windows 11 will introduce Wi-Fi 7 support in a future update. Since Wi-Fi 6E supports channel widths up to 160 MHz, that’s why we are not being able to use full 320 MHz channel width. What really confused me was the “Protocol: Wi-Fi 7 (802.11be)” misleading Wi-Fi network status reported by Windows. Thank you Ben for spotting the note in Intel’s documentation.
What does that translate to? Lower data rate and lower throughput. I would expect download and upload to be around 2.5 Gbps using 320 MHz wide channel. With the latest Intel driver 23.30.0.6, we get 1.71 Gbps TCP download speed with 16 parallel streams, and upload of 2.17 Gbps. But only the upper 160 MHz half of the 320 MHz wide channel is used.
1.71 Gbps TCP download speed with 16 parallel streamsUpload TCP speed 2.17 Gbps with 16 streams
I also ran a quick Speedtest.net test (I know it is not a proper throughput testing tool) on a 900/900 Mbps WAN link.
On a Linux Wi-Fi 7 client, I measured nearly 890/890 Mbps. Original Intel driver 23.20.0.4 performed 383/818 Mbps. The latest Intel driver 23.30.0.6 delivered more symmetric numbers, and results were closer to the actual WAN link speed.
Speedtest.net speeds using the latest 23.30.0.6 Intel driver
Summary
Wi-Fi worked well, but application speeds including Speedtest.net and other tools performed quite poorly and subjectively ‘felt slow’. iperf3 test showed higher performance, but the main problem for the purpose of a throughput test is that the adapter only uses 160 MHz out of the available 320 MHz.
When it comes to recommended channel width in real world, it depends. 80 MHz or 40 MHz wide channels are most likely the best place to start depending on your circumstances and region.
For reference: Disable 6 GHz on Intel BE200 adapter
If you are performing tests on an SSID that has multiple bands enabled, and you want to force the client to drop off 6 GHz and join using a 5 GHz channel instead, Intel BE200 driver has the option to disable the 6 GHz band.
What is a ‘key’? It is formed of the notch on the Wi-Fi adapter PCB, and plastic blob separating pins inside the M.2 slot. The idea is to prevent users from plugging incompatible cards to the slot, and avoid any ‘magic smoke events’. Here is more about M.2 and the individual key types if you are interested.
WLAN Pi upgrade kit
Since Intel adapters use E-key and WLAN Pi M4 uses A-key, we needed to build an adapter. Badger Wi-Fi has the upgrade kit in stock. It comprises of the Oscium M.2 A-key to E-key adapter, Intel BE200 Wi-Fi 7 adapter, and 2 little bolts to secure the adapter and the Wi-Fi module.
Here is how the ‘butterfly’ setup looks like. Intel BE200 sits onboard of the A-key to E-key adapter, installed in the M.2 slot.
We are ready to connect existing tri-band antennas, and assemble the unit.
Software support
Make sure to either upgrade Linux packages to their latest versions using sudo apt update && sudo apt upgrade command, or download and flash the latest WLAN Pi software image on your SD card. Release 3.2.0 supports Wi-Fi 7 Intel BE200 adapter out of the box with no effort whatsoever on your part.
Wi-Fi 7 in action
For this demonstration I use a consumer Wi-Fi 7 router TP-Link Deco BE85 BE19000. Simply because it is available, Wi-Fi 7 certified, and it supports 320 MHz channel width – not that one would deploy that in an enterprise environment, but mainly to test the maximum Wi-Fi throughput of the Pi.
A bug in macOS doesn’t allow Macs to correctly recognise Wi-Fi 7 networks. Instead of Wi-Fi 7 320 MHz wide network, my MacBook reports Wi-Fi 6 and 160 MHz wide channel. So, we will use another WLAN Pi and its Wi-Fi radio as a Remote Sensor in WiFi Explorer Pro – you need the Pro version to do this.
Nice, Wi-Fi 7 AP!
Wi-Fi 7 network
Connecting the WLAN Pi as a Wi-Fi 7 client only takes few lines of wpa_supplicant config.
sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
Wi-Fi 7 network settings
And we have successfully connected the WLAN Pi as a Wi-Fi 7 client to the AP using this command.
Run this command to make sure the WLAN Pi requests an IP address from DHCP server running on the router:
sudo dhclient -i wlan0 -v
What channel are we using? 320 MHz channel width? Indeed.
Adapter and channel details
Before you ask, distance between the Pi and the router is sub 1 meter. What is the Wi-Fi data rate? We are using Wi-Fi 7 (EHT), 2 spatial streams, MCS 12 and 4096-QAM and short guard interval of 0.8 µs.
I hardly ever achieved MCS 13. To maintain MCS 12, I had to stay within about 1.5 meter distance from the router. I got best results with antennas position in this ‘V’ pattern.
My noise floor was -96 dBm and RSSI typically between -29 and -39 dBm.
V-shaped antenna placement
With a different client device designed for Wi-Fi 7 from the ground up (with professional quality antennas and placement), I would hope for slightly longer MCS 12 and MCS 13 range.
With the help of Oscium WiPry Clarity 6 GHz spectrum analyser connected to another WLAN Pi, we can monitor the life spectrum and see how much red the iperf3 test introduces. We are able to achieve download TCP speed of 2.27 Gbps and upload speed of 1.74 Gbps.
I used iperf3 -c 192.168.68.51 -P32 -R to test download speed, and iperf3 -c 192.168.68.51 -P32 for upload. Number of parallel streams set to 32 provided the best performance.
I was expecting 2.5 Gbps-ish throughput, which we have got quite close to. During the test, CPU of the WLAN Pi was running around 80 % utilisation, and interrupts were reaching 100 %. So, hardware of the WLAN Pi itself posed a bottleneck.
mpstat 1 300 -P ALL
High CPU utilisation due to interrupts
Orientation of the antennas mattered more than I expected to. Best position was a ‘V’ shape with antennas positioned away from the board. With AUX antenna placed 90 degrees relative to the Main antenna, data rates and throughput dropped. Perhaps there is RF noise from the board itself coming into play.
