Forum

I have a very basic question about UL OFDMA in 802.11ax. The MU PPDU format of 802.11ax shows the legacy fields (L-STF, L-LTF and L-SIG) with the objective that legacy devices identify such transmissions and back-off. 

My question is that since MU transmissions (in case of OFDMA) may be sent across one or more RUs would that not mean that legacy devices cannot decode such fields? Moreover, if every 802.11ax STA sends such PPDUs over the entire 20 MHz channel, wouldn’t this lead to collisions at the AP and/or legacy STAs?

I apologize if I’m missing something obvious. Thanks!

I'm making a guess, but I believe that non-ax clients are only able to use CSMA/CA by waiting for unused RU's, and depend on the "generosity" of the AP's to provide/generate them.

Because /ax clients have to wait for trigger frames, they will have no collisions with other /ax clients (in UL), and because they also have to use CSMA/CA they (hopefully) won't step on non-ax transmissions.

This process seems a little too optimistic to me, and I'm betting that at some point in time, non-ax devices will become nearly useless in the target (stadiums, arenas, large lecture hall) areas.

Expecting all /ax AP's to play fair, is a little like expecting Apple not to tweak their QoS algorithms to benefit   non-Apple devices. 

Question: Have you ever wondered why homogeneous Apple networks get (slightly) better performance than non-Apple 802.11  half-duplex  networks running at the same rate?  Answer:   Some people would say that they cheat on the standards.   Others would say they just take advantage of ambiguities in the standard.

I've only recently come to appreciate the benefits of /ax in extremely dense situations - I just haven't had to work in those environments.  

I appreciate your response. 

non-ax clients are only able to use CSMA/CA by waiting for unused RU's

Do you mean waiting until none of the RUs are in use? If, say, a subset of the RUs are being used (e.g. during UORA), then I'm guessing non-ax clients must (ideally) wait until transmissions on individual RUs are completed. Isn't that right?

Because /ax clients have to wait for trigger frames, they will have no collisions with other /ax clients

Collision-free transmissions would occur because ax clients would transmit on orthogonal RUs. But since every client transmitted its PPDU only on the assigned RU(s) and not on the entire channel, would a legacy client be able to decode these fields? If not, I was wondering what is the purpose of the legacy fields in the MU PPDU format.

Yes they have to wait.

They don't need to be able to decode the /ax signals), they just (know they) have to wait.

If the non-ax clients were the intended target, the format would be one they could understand.

Not so much an elegant solution for the non-ax devices, but serviceable, as long as everybody follows the rules.

Great! That clarifies a few doubts that I have!

A follow-up question - does this mean the legacy clients will have to use energy detection to detect MU OFDMA transmissions? Since the length field in L-SIG and Duration/ID field in the MAC header in HE MU PPDUs are not decodable by the legacy STAs, is there any way legacy STAs can set their (respective) NAVs to protect 802.11ax OFDMA transmissions?

From the Aerohive site:

"The MU-RTS frame is transmitted using OFDM (not OFDMA) across the entire 20 MHz channel so that legacy clients can also understand the MU-RTS. The duration value of the MU-RTS frame is needed to reserve the medium and reset the NAV timers of all legacy clients for the remainder of the DL-OFDMA frame exchange."

The catch is the vanilla OFDM, and the RTS frame.

I do have to mention that some chip sets are already sending CTS-Self on EVERY transmission.   This is supposedly to reduce re-transmissions, but it also reduces overall throughput.   I would expect this RTS to have the same effect(s).

In addition, /ax now maintains two separate NAVs — one NAV is modified by frames originated from a network the station is associated with, and the other NAV is modified by frames originating from overlapped networks.   

Much like the predicament created when WPA  was first introduced, /ax requires a lot more horsepower & speed to process it than previous protocols required.

From what I have experienced, it takes a lot more sophistication with ED algorithms, than just looking at the signal level.   Expect variations between manufacturers in this regard.  

RU-Scheduling will also be a big part of an AP's secret sauce.

Thank you so much! That answers it all.