In a former blog post, I discussed the limitations of MU-MIMO and hinted at the pending emergence of a competing technology for high-density deployments, called "tri-band". In this post, I'll be again comparing the technologies and encouraging the use of tri-band APs for high-density deployments.
What is Tri-Band?
Strictly speaking, this AP technology should be called "tri-radio", as two of the radios in the access point are on the 5 GHz band. Essentially, a tri-band access point is just two co-located 5 GHz 802.11ac wave 1 APs in one box. The tri-band AP has one 2x2:2 stream 2.4 GHz radio (IEEE
802.11b/g/n) and two 2x2:2 stream 5 GHz radios (IEEE 802.11a/n/ac), with one 5 GHz radio locked
on the low portion of the band (channels 36-64) and the other 5 GHz radio
locked on the high end of the band (channels 100-165).
Tri-band is technically not part of the IEEE 802.11 standard. Broadcom
developed the original chipset for this in mid 2015, and QualcommAtheros recently introduced their own version. Tri-band APs are intended for high density
environments (e.g. lecture halls, conference centers, auditoriums, concert
halls, etc.) and thus compete directly with IEEE 802.11ac wave 2 with MU-MIMO. The tri-band approach, however, has several advantages
over MU-MIMO. Nonetheless, there are still very few vendors who have introduced tri-band access points to the market, despite their obvious advantages.
Why is Tri-Band Better than MU-MIMO?
MU-MIMO requires
the use of beam forming, which is a technique used to create particular zones
of constructive and destructive interference at particular locations. By maximizing the signal for each client
device at the client devices location (and minimizing the signal for the other
clients at each client’s location), a MU-MIMO AP can talk downstream to
multiple client devices.
 |
| Multi-User Multi-In Multi-Out (MU-MIMO) |
The MU-MIMO technique requires the
AP to know the position of the client devices (relative to itself). The AP gathers that information by periodically
transmitting “sounding frames”, essentially tones off of each AP antenna. Compatible client devices will respond by sending a matrix indicating how well the client device heard the tone from each antenna. Based on that matrix, the AP can calculate
the relative position of the client device.
MU-MIMO
has the following limitations, which do not exist with the tri-band approach:
- Increased overhead: The sounding frames and their responses consume airtime. While this is less than the presumptive gains of talking to multiple client devices simultaneously, it does indicate a loss. Most MU-MIMO access points only get a 1.7x - 2.2x increase in speed when talking downstream to three compatible client devices.
- Client device compatibility: The client devices need
to be compatible with MU-MIMO in order to understand the sounding frames and to
send the appropriate response. As of August 2017, there are still surprisingly few MU-MIMO compatible client devices on the
market. There are some USB dongles available for PCs. The flagship mobile client device for MU-MIMO had been the Samsung Galaxy
Note 7, which failed in the market for unrelated incendiary reasons. The Apple iPhone 7, while originally rumored to support it before its launch, quietly did not support MU-MIMO. Given Apple's notorious secrecy, we still don't know whether or not the upcoming Apple iPhone 8 will
or will not support MU-MIMO.
- Client separation: MU-MIMO requires that the client devices it talks to simultaneously must be physically separated from each
other. If the client devices are in
too-close proximity, the beam forming won’t be able to successfully maximize
the signal at one client and minimize the signal of the other (neighboring) clients.
- Downstream only: MU-MIMO only works for downstream traffic, from the AP to the client device(s). Upstream traffic from each client device to the AP must still happen one at a time, otherwise the AP will hear multiple client devices at once and won’t be able to distinguish between them.
In comparison, all 5 GHz Wi-Fi clients can communicate with
the tri-band AP as they would with any other conventional access point, so it
is backwards compatible with all current and future Wi-Fi client devices. There is also no additional overhead on the channel, as
sounding frames are not required, and the positions of the two 5 GHz client devices, both relative to the AP and to each other, doesn't matter. Additionally, since the 5 GHz clients and the channels are independent, the traffic to each client can occur simultaneously in both directions. The AP itself uses an internal mechanism called “client
steering” to encourage 5 GHz clients to connect to one or the other 5 GHz
radio, so as to balance the load across the two 5 GHz radios.
The Takeaway Message
A current four-stream MU-MIMO access point can talk
simultaneously to 2-3 compatible client devices on the 5 GHz band downstream,
sometimes. A two-stream tri-band access point, by
comparison, can talk simultaneously to any two client devices on the 5 GHz band
both downstream and upstream, all the time.
So, about the spectrum and channels separation; the 5mhz channel spacing appers to disallow other configurations for max number of non-overlapping channels. Then there is the DSSS versus OFDM separations and guard bands; How would you update the channels assignment?
ReplyDeleteDSSS has not been used since 802.11b. Everything 802.11g and later is OFDM. You are correct that the 5 MHz channel spacing does not allow for other combinations, though you could, for example, use channels 2 and 7 OR channels 3 and 9 or channels 5 and 10 and these would be non-overlapping, though obviously you only have two vs. three non-overlapping channels in this case on the 2.4 GHz band.
ReplyDeleteThe rules will change with 802.11ax. The use of OFDMA allows for the use of independent 2 MHz sub-channels on both the 2.4 GHz and 5 GHz bands to talk to multiple client devices simultaneously on a 20/40/80 MHz channel. Of course, the big issue will be client device support for 802.11ax, any older client devices will still need to use the full channel width.