[Article] - Is MU-MIMO Ready For Prime Time?

[sfx2000]

True. Could it also be possible that the STA's firmware makes a decision to do MU in 1x1 only also?

No, because MU is downlink only (AP to Client STA) in 802.11ac - the AP makes the decision on what to do based on the feedback from all clients, MU and SU...

 

[sfx2000]

The AP knows what the clients capabilities are based on the attachment handshake from the client STA's, and if in doubt, can send out a broadcast probe request, the clients will respond (and believe it or not, neighboring AP's and Clients on the same channel, as Broadcast isn't limited to the BSS)...

(That's the danger, FWIW, of VHT in 2.4GHz... but that's another thread perhaps)

 

[paraplu]

No, because MU is downlink only (AP to Client STA) in 802.11ac - the AP makes the decision on what to do based on the feedback from all clients, MU and SU...

In my test case, the MU client (Samsung Galaxy S7) switched to 433 while being the only client on the MU router. No other STA connected since full-reset. Using the same client on a SU AP, I get a 866 link.

 

[sfx2000]

In my test case, the MU client (Samsung Galaxy S7) switched to 433 while being the only client on the MU router. No other STA connected since full-reset. Using the same client on a SU AP, I get a 866 link.

But look at actual throughput - not the connected rate - might actually be the same - background here is probably more complicated than what is appropriate for a forum/bbs post...

 

[paraplu]

But look at actual throughput - not the connected rate - might actually be the same - background here is probably more complicated than what is appropriate for a forum/bbs post...

Actual speedtest.net throughput is around 200mbps on MU router. Same test on SU router gives me around 400mbps.

I have a 500/500 ISP subscription. An IPad air 2 gets 500/500 on both routers.

 

[paraplu]

I think there is something not right on the S7, and/or protocols. During my speedtest.net tests, this device sometimes hangs/reboots.
Bottom line: still a while to go for stable MU implementations.

 

[sfx2000]

I think there is something not right on the S7, and/or protocols. During my speedtest.net tests, this device sometimes hangs/reboots.
Bottom line: still a while to go for stable MU implementations.

Need two or more MU devices to actually trigger any kind of MU activity...

The Samsung GS7 is a very new/fresh device, so no doubt there might still be some bugs in there...

 

[sfx2000]

True. Could it also be possible that the STA's firmware makes a decision to do MU in 1x1 only also?

Sorry for the second reply - perhaps an extension of the previous one...

The AP initiates the activity - it already knows if the client STA's are MU capable or not (and can always check again by sending an 802.11 Probe Request if absolutely needed) - but once it sends out a VHT NDP Announcement to the STA's within the BSS, the clients report back - and here's were a client might be able to suggest that it's in a place where MU won't be of use, when it reports back sounding information to the requesting AP.

That response to the VHT NDP Announcement will be from each STA that it was addressed to, and it's sent as an VHT Action Message, where you'll have items like MIMO grouping (current, SU or MU), SNR, number of streams, and OFDM sub-carrier beam forming metrics.

The client STA's firmware has to build that action message, so, perhaps yes, the client firmware can influence a MU decision by the AP, as the AP takes the reports into consideration for each STA that it thinks could be a good MU grouping provided that beam forming and sounding makes sense, with the current traffic flows and loads...

But the client STA doesn't say yes/no, its already implicit that the MU can do it, but the AP always makes the decision, as it has the spatial understanding of all client STA's within the BSS.

Sorry if this is a complicated answer to what to some folks might seem like a simple answer - but nothing in MU-MIMO, much less 802.11ac is ever simple

 

[sfx2000]

Where things get weird... let's say we have 3 MU capable STA's - two are doing Video (QoS tagged at 802.11) and one doing VoiP (again, tagged traffic there) - if the AP has some level of traffic shaping/media prioritization - the beam forming might work, but since the application flows have very different characteristics - the VoiP client may decide to respond with a VHT Action Message indication, whereas the two Video clients may respond another way...

Then the AP needs to consider the application flow characteristics, along with QoS feedback - and this doesn't consider the Router side Media Prioritization/Traffic Shaping/Quality of Service there (this is all upstream from the AP side of the device) - based on Beamforming feedback and MCS requirements, the AP might just say --- all these 802 packets should go out SU, or try to keep things together...

But that MU frame needs some level of orthogonality across the MU targets, and balance that across the VoiP application flow that's happening concurrently... and while we're talking right now about three MU clients, what about that SU client over there - maybe it's also doing video, or some best effort traffic, or even background from a QoS level...

This is crazy hard stuff - and it's very easy to do it wrong...

Don't be in a hurry to enable MU - can test/play with it for AP's that support it now, but also consider that the chipset vendors (QCA, Broadcom, Quantenna) are also working hard, and we have limited number of clients to test against...

 

[thiggins]

Currently using a MUMIMO Samsung S7 as client to my sitecom Greyhound router (same Qualcomm hardware as tplink ac2600).

Question: is it normal that max linkspeed is 433 in MUMIMO mode, compared to 866 in SUMIMO?

A single MU STA should not be operating in MU mode. There is no advantage to doing this. Would be interesting to know whether the S7's radio is QCA.

 

[sfx2000]

A single MU STA should not be operating in MU mode. There is no advantage to doing this. Would be interesting to know whether the S7's radio is QCA.

GS7 - depends on the Product SKU - both use BRCM in either a Murata or Samsung SIP module...

• G935T - Murata KM5D18098 WiFi module
• G930FD - Samsung 0306S7 WiFi Module

http://www.chipworks.com/about-chip...axy-s7-snapdragon-chipsets-vs-exynos-chipsets

 

[thiggins]

both use BRCM

Thanks, sfx.

Well, there you go. Most likely compatibility problems. BRCM is still low on the MU learning curve.

 

[devz]

Hi Tim,

I'm wondering if you can share the filter used on the wireless capture used to get the last graph: STAs with MU frames
I've tried to get similar graph and saw the some AMPDUs are MU and some are not.

From your article: Analysis of STAs with MU frames:
The Linksys EA8500 and NETGEAR R7500v2 were able to work with the highest number of MU STAs - 11.
I suppose you were referrnig to 12 MU STA's

Thank you
dev

 

[sfx2000]

True. Could it also be possible that the STA's firmware makes a decision to do MU in 1x1 only also?

Sorry to drag this up - but this is something I've been sitting on...

1) Client STA's cannot make choices - since MU is DL only, this is entirely in the Access Point's domain, knowing the membership of the potential MU frames based on association with the AP.

2) The AP has a complicated job - it has to balance SU/MU opportunities, along with the MU group, the QoS of the frames scheduled to be transmitted, and the overall beam-forming opportunities...

What some might thing of MU vs. SU in the context of a single frame...

On the RF level, once a frame is committed to a MU transmission, this would be right... but let's throw a problem at MU scheduling...

Not all frames are equal... and this is where QoS comes into play with queue management and client capabilities... and the traffic across the WLAN, and whether it's tagged or not...

Now you can see where the challenge is - Voice/Video frames might not be suitable for MU, whereas Best Effort/Background might - and this is before we get sounding feedback on the Beamforming Matrix - and there, one has to look at beamforming in general, and the MU group in context within the beamforming group...

This stuff is incredibly hard - and very time sensitive.... if the AP is doing MU right, even if a MU client is present, it might not be suitable to include in a MU transmission once the channel is sounded - if it's not good, then it should treat the client as SU, and then you still have the QoS demands upstream...

I can appreciate the challenges there...