There is a rash of discussions regarding 802.11ac wave 2 with multi-user MIMO, and how this is going to "dramatically change the Wi-Fi industry". According to the analysts and marketeers, everybody needs to run out immediately and buy new enterprise switches that overdrive existing CAT5e up to 5 Gbps, along with claims that wave 2 APs will obviously displace wave 1 APs, so that you'll be getting MU-MIMO whether you need it or not.
For the record, the overhead in the Wi-Fi protocol generally means that the throughput on the wire is, at best, 40% - 50% of the consumed airtime throughput, so you won't be hitting 1 Gbps on the wire for quite some time. Also, it's been 6 years since 802.11n was introduced, and AP vendors are still managing to sell quite a number of 802.11n 2x2:2 APs; 802.11ac wave 1 APs won't be disappearing from shelves
These discussions have primarily ignored the elephant in the room. MU-MIMO adds A LOT OF COMPLEXITY to Wi-Fi. Given that, even in
high-density environments, can MU-MIMO actually provide any practical benefit?
I've blogged before somewhat obliquely on this topic (see my blogs on how MU-MIMO works and whether MU-MIMO is appropriate for the SMB market). In low to medium density environments, where one is not actually consuming all of the airtime, you need not make the airtime more efficient by talking to multiple clients simultaneously. The benefits of MU-MIMO in such environments are, at best, de minimis.
But does MU-MIMO fair any better in high density environments, where we have a bunch (say >>50) of 802.11ac wave 2 compatible clients all trying to communicate at once? In the past, Wi-Fi engineers would put multiple APs in the area, carefully controlling channel and power settings to minimize co-channel interference, perhaps using highly directional antennas so as to divide the space into the smallest cells possible. But now, we apparently don't need to worry about such things; just put in a big honking wave 2 AP with a ludicrous number of antennas and we'll carry on multiple conversations simultaneously. Easy, right?! Not so much.
The race to push wave 2 product to the market means that not all of the
technical complexities have been solved by the AP vendors, despite
marketing claims. Since there are virtually no 802.11ac wave 2 clients
to actually put these new APs through their paces, these vendors still
have time to fix it in firmware.
One glaring example of this technology shortfall: how does an AP
determine WHICH clients should be part of a simultaneous communication
session? Such an algorithm is NOT part of the 802.11ac spec, and thus
is left to the individual vendors. No vendor has published how they are
doing this, and it is by no means an easy problem to solve. It has been observed that for each MU-MIMO group, you need your clients spatially separated with respect to the location of the AP, and you need their transmissions to take roughly the same amount of time (though not necessarily the same volume of data or MCS rate). Now add in QoS, because all client devices are equal, but some client devices are "more equal" than others. In a high density / very high density environment, we have by definition a lot of clients to choose from, and these choices have to be made in near real-time (every few milliseconds) for processing that 5 Gbps torrent of data streaming in on the wired port(s). This, of course, assumes that the AP is frequently winning contention, though the hundreds of client devices that are now able to associate to a single AP are also competing for the same air time, quite effectively cutting down the number of contention rounds that an AP can win in a given interval.
While I personally lack the multiple mathematics Ph.D.'s required, I can envision that such algorithms can be defined to take all this information into account, and make some rational and reasonably fair set of choices for selecting groups of APs for MU-MIMO. Alas, however, we cannot just solve the problem once, or even once per client device either connecting to / disconnecting from the AP. Transmit beamforming updates the position of
each client at a rate of 40 times per second (i.e. every 25 ms). While
this loop of sounding PPDUs and feedback is (presumably) happening in parallel on
top of the data or other overhead packets being exchanged with client devices, it does mean that the grouping of clients won't remain fixed because clients devices may be in motion, so the determination of these groups of clients must be recalculated continuously.
Accordingly, I'm highly skeptical about the efficiency of such an algorithm to solve the problem "well", defined as a noticeable improvement in client capacity (# of clients per AP) and/or client throughput (i.e. download speed per client device) when compared to the "conventional approach" of using multiple APs with tightly controlled coverage areas.
For those of us who've suffered through the CWAP, we know that there are plenty of technologies cluttering up the 802.11n spec that
increase complexity in the name of improved performance that never got
implemented in practice. Remember the multiple ways of doing transmit
beamforming, including implicit and explicit with a bunch of calibration
and antenna selection parameters? How about Space Time Block Coding
(STBC)? DSSS/CCK mode? L-SIG TXOP Protection? Reverse Direction (RD)
protocol? How about asynchronous MCS rates, where the different streams
transmit at different MCS rates? For that matter, what about A-MPDU? All of
these technologies looked interesting enough on paper to get themselves
put in the 802.11n spec, yet few if any vendors offered these features commercially.
The main difference with MU-MIMO and the other deprecated performance technologies
above is the huge marketing push in time and dollars that's been spent
on promoting it. This is undoubtedly because "talking to multiple
clients at once" is undeniably sexy; the concept is really easy to explain and the
result of either higher throughput per client and/or increased
client count is readily obvious.
Just because it's sexy, however, doesn't mean it's going to work.