Orbi - MU-MIMO looks to be supported for clients now...

[sfx2000]

As of 1/16/2019 - took a deeper look at the Orbi next door...

Looks like they've turned on MU-MIMO for the user facing SSID's - would be interesting to see some real world insight if folks have Orbi and a few MU capable devices...

        Tag: VHT Capabilities
            Tag Number: VHT Capabilities (191)
            Tag length: 12
            VHT Capabilities Info: 0x338959b2
                .... .... .... .... .... .... .... ..10 = Maximum MPDU Length: 11 454 (0x2)
                .... .... .... .... .... .... .... 00.. = Supported Channel Width Set: Neither 160MHz nor 80+80 supported (0x0)
                .... .... .... .... .... .... ...1 .... = Rx LDPC: Supported
                .... .... .... .... .... .... ..1. .... = Short GI for 80MHz/TVHT_MODE_4C: Supported
                .... .... .... .... .... .... .0.. .... = Short GI for 160MHz and 80+80MHz: Not supported
                .... .... .... .... .... .... 1... .... = Tx STBC: Supported
                .... .... .... .... .... .001 .... .... = Rx STBC: 1 Spatial Stream Supported (0x1)
                .... .... .... .... .... 1... .... .... = SU Beamformer Capable: Supported
                .... .... .... .... ...1 .... .... .... = SU Beamformee Capable: Supported
                .... .... .... .... 010. .... .... .... = Beamformee STS Capability: 3 (0x2)
                .... .... .... .001 .... .... .... .... = Number of Sounding Dimensions: 2 (0x1)
                .... .... .... 1... .... .... .... .... = MU Beamformer Capable: Supported
                .... .... ...0 .... .... .... .... .... = MU Beamformee Capable: Not supported
                .... .... ..0. .... .... .... .... .... = TXOP PS: Not supported
                .... .... .0.. .... .... .... .... .... = +HTC-VHT Capable: Not supported
                .... ..11 1... .... .... .... .... .... = Max A-MPDU Length Exponent: 1 048 575 (0x7)
                .... 00.. .... .... .... .... .... .... = VHT Link Adaptation: No Feedback (0x0)
                ...1 .... .... .... .... .... .... .... = Rx Antenna Pattern Consistency: Supported
                ..1. .... .... .... .... .... .... .... = Tx Antenna Pattern Consistency: Supported
                00.. .... .... .... .... .... .... .... = Extended NSS BW Support: 0x0

So Netgear is continuing to update configurations for the WiFi -- challenge here is that you see the same info for 2.4GHz (including all the VHT 802.11ac stuff - for two reasons - (1) client interoperability and (2) it's rare to see clients get there) - but hey, if it's good enough for WiFi Alliance, it's good enough for me...

In any event - with 20/40MHz channels, many 2.4GHz clients that support VHT will get VHT MCS7, which is basically the same thing as it would be for 802.11n MCS7/15/23/31 (1/2/3/4 SS accordingly) - so why bother?

I'm sure Netgear and Qualcomm have their reasons for this...

Now if they can fix the item below they'll be super shiny as client STA may use this information for Rate Adaptation and other decisions that can affect performance.

        Tag: VHT Tx Power Envelope
            Tag Number: VHT Tx Power Envelope (195)
            Tag length: 4
            Tx Pwr Info: 0x02
                .... .010 = Max Tx Pwr Count: 2
                ..00 0... = Max Tx Pwr Unit Interpretation: EIRP (0)
                00.. .... = Reserved: 0
            Local Max Tx Pwr Constraint 20MHz: 63.5 dBm
            Local Max Tx Pwr Constraint 40MHz: 63.5 dBm
            Local Max Tx Pwr Constraint 80MHz: 63.5 dBm

Enjoy!

 

[sfx2000]

confirmed - Orbi, at least some models, is using MU...

The tell is the VHT NDP Announcement packet - if it is sent as Broadcast, it's MU, if it's sent to a specific STA, it's SU...

MU only happens if

1) 2 or more MU capable STA's are associated
2) conditions are met for MU frames - which includes things like type of traffic, beam forming results, etc...

Below you see one of the Orbi's doing a sounding with Broadcast, ID'ing two Client STA's as candidates...

IEEE 802.11 VHT NDP Announcement, Flags: ........C
    Type/Subtype: VHT NDP Announcement (0x0015)
    Frame Control Field: 0x5400
        .... ..00 = Version: 0
        .... 01.. = Type: Control frame (1)
        0101 .... = Subtype: 5
        Flags: 0x00
            .... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x0)
            .... ...0 = To DS: Frame is not entering DS
            .... ..0. = From DS: Frame is not exiting DS
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = Order flag: Not strictly ordered
    .000 0000 0110 0100 = Duration: 100 microseconds
    Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
    Receiver address (resolved): Broadcast
    Hardware address: Broadcast (ff:ff:ff:ff:ff:ff)
    Hardware address (resolved): Broadcast
    Transmitter address: bb:b9:8a:5f:8c:66 (bb:b9:8a:5f:8c:66)
    Transmitter address (resolved): bb:b9:8a:5f:8c:66
    Hardware address: bb:b9:8a:5f:8c:66 (bb:b9:8a:5f:8c:66)
    Hardware address (resolved): bb:b9:8a:5f:8c:66
    Sounding Dialog Token: 0x34
        .... ...0 = Reserved: 0x0
        .... ..0. = HE: VHT NDP Announcement frame
        0011 01.. = Sounding Dialog Token Number: 13
    STA list
        STA 0
            .... 0000 0000 0001 = AID12: 0x001
            ...1 .... .... .... = Feedback Type: MU feedback requested
            001. .... .... .... = Nc Index: 2 (1)
        STA 1
            .... 0000 0000 0010 = AID12: 0x002
            ...1 .... .... .... = Feedback Type: MU feedback requested
            001. .... .... .... = Nc Index: 2 (1)
    Frame check sequence: 0x6f4d6aa1 [correct]

 

[e38BimmerFN]

I presume this is in most current v210 FW code?

 

[sfx2000]

I presume this is in most current v210 FW code?

I don't have physical access to that Orbi system - just reported what I saw over the air...

 

[e38BimmerFN]

Kewl. I have seen on post where a user was having problems streaming 4k over Orbi. After turning on MIMO, seemed to fix his issue. I know NG has has the UI feature in there FW for last several builds. Hopefully making improvements.

 

[sfx2000]

Kewl. I have seen on post where a user was having problems streaming 4k over Orbi. After turning on MIMO, seemed to fix his issue. I know NG has has the UI feature in there FW for last several builds. Hopefully making improvements.

Orbi's are fairly complex under the hood - so enabling features like MU-MIMO, Implicit Beamforming, Fast Roaming, and other items are likely going to be location and client dependent...

 

[e38BimmerFN]

I know. Been working with others on support problems. No issues seen with Beamforming, MIMO being enabled. Fast Roaming is kind hit and miss.

 

[Razor512]

Always good to see firmware improvements, though for the transmit power thing, it seems that they just use a high value there because the transmit power is limited elsewhere, and to an unreasonably low level compared to the already crazy low limit that the FCC already set, it is like looking at a speed limit sign of 20MPH and then deciding to just take your foot off the breaks and let the car creep forward.

2.4GHz:

It gets even worse for 5GHz, imagine someone noticing a 20MPH speed limit and in an attempt to follow it, they turn the engine off, put the parking brake on, and then walks to the back of the vehicle and attempts to push it down the road.

5GHz:

 

[sfx2000]

Always good to see firmware improvements, though for the transmit power thing, it seems that they just use a high value there because the transmit power is limited elsewhere, and to an unreasonably low level compared to the already crazy low limit that the FCC already set, it is like looking at a speed limit sign of 20MPH and then deciding to just take your foot off the breaks and let the car creep forward.

the actual Tx power is fine... consider that the user facing SSID's are common channel, so too much power there and the mesh starts to jam itself.