Any update on Quantenna products?

[tzhang4284]

Anyone heard anything new about quantenna based products? Has anyone heard anything new regarding the AC-87U or if that's even happening?

Their 4x4 MIMO tech looks interesting but it doesn't seem like there will be anything out there that can really take advantage of it. Been thinking about upgrading my company's wifi setup to get some better coverage in our building and faster speeds in our laptops, which are mostly N and AC equipped.

 

[L&LD]

http://pcdiy.asus.com/2014/01/rt-ac87u-the-ultimate-router-4x4-mu-mimo-ces-2014/


MU-MIMO doesn't necessarily need client support, the router will decide whether to implement it for the Tx stream in a given situation (the router acts as a switch when multiple clients are downloading but each client is using less streams than the most possible the router has).

MU-MIMO is not for client uploads (the router acts as a hub and each client takes turns to upload to the router).


If most clients are downloading instead of uploading on your network, then a true MU-MIMO based router will benefit all clients as the network will seem less busy to each one. Because the timeslices each client gets will be closer together for a given network load.

 

[tzhang4284]

http://pcdiy.asus.com/2014/01/rt-ac87u-the-ultimate-router-4x4-mu-mimo-ces-2014/


MU-MIMO doesn't necessarily need client support, the router will decide whether to implement it for the Tx stream in a given situation (the router acts as a switch when multiple clients are downloading but each client is using less streams than the most possible the router has).

MU-MIMO is not for client uploads (the router acts as a hub and each client takes turns to upload to the router).


If most clients are downloading instead of uploading on your network, then a true MU-MIMO based router will benefit all clients as the network will seem less busy to each one. Because the timeslices each client gets will be closer together for a given network load.

Thanks for the clarification re: MU-MIMO. The AC-87U seems like it's vaporware given that they announced an AC3200 router (granted the theoretical peak speed per connection is capped at 1.3mbps still). Any idea when they'll release that?

 

[L&LD]

I don't think the RT-AC87U is vaporware. Did you read the link?

The AC3200 class routers (at least the current incarnations) are to be avoided imo. But they're supposedly being released in July.

http://www.smallnetbuilder.com/wireless/wireless-news/32429-ac3200-routers-by-july

 

[RMerlin]

I can confirm that the RT-AC87U is not vaporware.

Asus still doesn't have any concrete release date for it however.

The RT-AC3200 does not obsolete the RT-AC87U. The two devices are targeting different usage scenarios. The RT-AC87U will provide best single-client performance (since it's 4x4), while the RT-AC3200 will provide best multiple client performance (since it's dual 3x3, meaning two devices could get 1300 Mbps simultaneously).

 

[sfx2000]

I can confirm that the RT-AC87U is not vaporware.

Asus still doesn't have any concrete release date for it however.

The RT-AC3200 does not obsolete the RT-AC87U. The two devices are targeting different usage scenarios. The RT-AC87U will provide best single-client performance (since it's 4x4), while the RT-AC3200 will provide best multiple client performance (since it's dual 3x3, meaning two devices could get 1300 Mbps simultaneously).

In MU-MIMO - two devices cannot get max at the same time - they can split it somehow... they have to share the common streams, and shannon limit applies here...

 

[RMerlin]

In MU-MIMO - two devices cannot get max at the same time - they can split it somehow... they have to share the common streams, and shannon limit applies here...

That's why I said "single client performance" on the RT-AC87U.

 

[thiggins]

MU-MIMO doesn't necessarily need client support, the router will decide whether to implement it for the Tx stream in a given situation (the router acts as a switch when multiple clients are downloading but each client is using less streams than the most possible the router has).

MU-MIMO does require support on both ends of the link because it uses a more complex form of beamforming.

But MU-MIMO enabled routers can handle clients that do and don't support MU-MIMO. You just don't get the advantage of MU-MIMO with clients that don't support it.

I will have more details on both MU-MIMO and Broadcom xStream soon. I am out in the Valley this week doing research. I'll just say for now I am much less skeptical of AC3200's benefit.

 

[azazel1024]

In MU-MIMO - two devices cannot get max at the same time - they can split it somehow... they have to share the common streams, and shannon limit applies here...

One correction here, it depends on the clients and the router. A 3:3 MU:MIMO router could do max CLIENT data rate to a 1:1 and 2:2 client, or to three 1:1 clients or a single 3:3 client. Though I am sure exact method of implementation will vary exactly what net yield you get in the end, but in theory each client can get max in that situation instead of lots of air time sharing and reduced overall bandwidth.

A 6:6 MU:MIMO router can conceivably to max rate to three 2:2 clients AFAIK.

I think the issue is, and I don't know if it is a limit on how MU:MIMO is being implemented, processing issues or just early introduction limitations (or maybe all early MU:MIMO routers are going to be 3:3, I just don't know) is that the MAX is 3 clients. More than that and you are back to some amount of air time sharing. It probably also depends on client location. If the clients are physically very close to each other, there may not be enough physical seperation with beam forming to have seperate Tx streams to the clients and you are back to airtime sharing.

Also I was under the impression that with some implementations of MU:MIMO you could do multiuser concurrent Tx AND Rx on the router (obviously the clients would all need to support MU:MIMO). With some implementations of MU:MIMO only being able to do MU Tx.

 

[L&LD]

Also I was under the impression that with some implementations of MU:MIMO you could do multiuser concurrent Tx AND Rx on the router (obviously the clients would all need to support MU:MIMO). With some implementations of MU:MIMO only being able to do MU Tx.

I am probably very wrong here, but I can't see Rx MU-MIMO possible?

How would 2+ clients coordinate their radios to transmit at the exact same time?

 

[azazel1024]

I am probably very wrong here, but I can't see Rx MU-MIMO possible?

How would 2+ clients coordinate their radios to transmit at the exact same time?

MIMO MAC apparently http://en.wikipedia.org/wiki/Multi-user_MIMO

You have to know the exact channel state information for each client. I assume based on knowing the CSI, the access point can then break out the signal based on this from each client when it receives the aggregated signal. You can work out the time delay in reception on each antenna so you can compare the received signal on each one, combined with the CSI on each client and determine what is coming from what client.

Again, probably very limited in the number of clients this can work with at once, which might be why I keep hearing a limit of 3 clients at most can work with MU:MIMO at once.

Anyway, at least on everything I have read, MU:MIMO is possible for Tx AND Rx, at least with the right technology and signal processing (and not star trek stuff either).

 

[IAAI]

One correction here, it depends on the clients and the router. A 3:3 MU:MIMO router could do max CLIENT data rate to a 1:1 and 2:2 client, or to three 1:1 clients or a single 3:3 client. Though I am sure exact method of implementation will vary exactly what net yield you get in the end, but in theory each client can get max in that situation instead of lots of air time sharing and reduced overall bandwidth.

A 6:6 MU:MIMO router can conceivably to max rate to three 2:2 clients AFAIK.

I think the issue is, and I don't know if it is a limit on how MU:MIMO is being implemented, processing issues or just early introduction limitations (or maybe all early MU:MIMO routers are going to be 3:3, I just don't know) is that the MAX is 3 clients. More than that and you are back to some amount of air time sharing. It probably also depends on client location. If the clients are physically very close to each other, there may not be enough physical seperation with beam forming to have seperate Tx streams to the clients and you are back to airtime sharing.

Also I was under the impression that with some implementations of MU:MIMO you could do multiuser concurrent Tx AND Rx on the router (obviously the clients would all need to support MU:MIMO). With some implementations of MU:MIMO only being able to do MU Tx.

Thank you i m now really confused about the MU-MIMO thing .

 

[azazel1024]

Don't worry, its confusing. There are also different standards in how it can be implemented and this will impact the capability of MU:MIMO. To the best of my knowledge, 802.11ac does not specify the exact type of MU:MIMO...though I could be (hopefully?) am wrong. It would be a shame if MU:MIMO is a chipset specific feature where you have to have a Broadcom router and Broadcom clients to get it to work, or a Qualcomm router an clients, etc. Hopefully just MU:MIMO router and clients to work with some/most/all benefits of MU:MIMO.

 

[thiggins]

Azazel, you are off a bit on a few things. Just as with beamforming, 802.11ac contains an implementation standard for MU-MIMO. It uses a more complicated sounding technique than standard beamforming that concentrates on creating spatial nulls to isolate beams from each other vs. combining them for higher power.

The maximum number of MU-MIMO streams supported is 1 minus the # of streams supported in the AP. So a 3x3 AP supports a max of two MU-MIMO streams, which would be two 1x1 STAs or one 2x2. The maximum # of MU-MIMO streams supported in 802.11ac is four.

Of course you can have more than four MU-MIMO capable STAs. But only four can be supported concurrently.

802.11ac MU-MIMO is for downlink (AP to STA) only. Uplink is normal single user MIMO.

MU-MIMO must be supported by both AP and STA. There are currently no clients with MU-MIMO enabled. MU-MIMO capable chipsets have been seeded into mobile devices for awhile (mostly phones). But none have MU-MIMO enabled.

 

[sfx2000]

MU-MIMO is not about speed, it's about capacity.

It originated in the WWAN community - where you have many more users per cell (sector in CDMA speak) - rule of thumb there is 200 users per cell (sector) - here MU-MIMO makes a tremendous amount of sense, as either they're FDD (Transmit/Receive are on different frequencies) or they're TDD (Tx/Rx on common channels) - in any event, the downlink from the Cell is scheduled, and MU-MIMO does allow different code masks to be used (over simplifying here a bit), and send data to multiple subscriber terminals in the same frame.

In WiFi space - there isn't as much benefit, first due to the nature of WiFi in that it's OFDM, not OFDMA, and it's not as tightly scheduled as one would have with a WWAN setup.

Some of the challenges with WiFi is that the chips themselves have to be relatively simple and small - silicon is a fixed price, so how do we allocate resources on the chip - we can either

a) put a lot of SU-MIMO streams - 3 streams are common enough in 802.11n, and perhaps 4-streams here soon - most of this is in the MAC/Baseband in any event - this is fairly easy actually, even thought we need to put discrete RF chains for each stream - but we can them blast lots of bits per frame...

b) TxBF - Now we have to put more computation on the MAC to determine which streams to put the bits on, and on the Baseband for the extra time delays needed to push the analog waveforms out to the RF chains...

c) Add MU-MIMO - now we have to do some resource sounding and scheduling of the frames at the MAC layer - even more computation...

Option A - this is the general trend - when you add B, you get a bit more gain, about 2-3dB is the best of cases, and C adds a whole world of hurts, as this is a lot more transistors on the die, and at a given geometry node, MU-MIMO is expensive, and for the typical SOHO/SMB WLAN, it's just not a net-positive, as a MU-MIMO frame can support more users, but at a lower data rate per user.

Not to say that Qualcomm, Broadcom, Marvell, Ralink, Mediatek won't do it, but it does add much complexity to what is a commodity chip - and complexity is cost, and what we're finding at the moment -

$249USD is about as far as customers are willing to pay for AP's at this point in time.

Just my thoughts...

sfx

 

[remixedcat]

it will take longer in the enterprise, as the consumer companies and their customers are the beta testers.

 

[azazel1024]

Azazel, you are off a bit on a few things. Just as with beamforming, 802.11ac contains an implementation standard for MU-MIMO. It uses a more complicated sounding technique than standard beamforming that concentrates on creating spatial nulls to isolate beams from each other vs. combining them for higher power.

The maximum number of MU-MIMO streams supported is 1 minus the # of streams supported in the AP. So a 3x3 AP supports a max of two MU-MIMO streams, which would be two 1x1 STAs or one 2x2. The maximum # of MU-MIMO streams supported in 802.11ac is four.

Of course you can have more than four MU-MIMO capable STAs. But only four can be supported concurrently.

802.11ac MU-MIMO is for downlink (AP to STA) only. Uplink is normal single user MIMO.

MU-MIMO must be supported by both AP and STA. There are currently no clients with MU-MIMO enabled. MU-MIMO capable chipsets have been seeded into mobile devices for awhile (mostly phones). But none have MU-MIMO enabled.

Nice info. Thanks! I guess a lot of the stuff bouncing around out there is "research project" level MU:MIMO. Might be something we see in 802.11ax? Or some other future wireless standard? Anyway, it is interesting.

I am glad however that MU:MIMO in 802.11ac has set standards so interoperability should work well.

 

[thiggins]

Glad to help Azazel. I have been meeting with the chip set guys this week and have learned a lot.

 

[remixedcat]

Are you at a conference or something?

 

[thiggins]

Are you at a conference or something?

Private meetings.