--- This message came from the IEEE 802.11 ARC Reflector ---
Harry/All, In reference to: https://mentor.ieee.org/802.11/dcn/23/11-23-0880-05-0arc-revised-annex-g-containing-example-frame-exchange-sequences.docx: First, thank you very much for your continued work on this contribution and topic, so that ARC is making progress. I personally think we are moving in a very useful direction, and we are uncovering some concepts which are quite tricky to understand and are not well defined in the current 802.11 standard/draft, thanks to your efforts. I do have the following comments that might be useful to discuss as a group in today’s ARC meeting: - I think it would be useful to step back just a bit from the text details, and think about the way we’d like to organize the Annex. For example:
- I think it would be good to start with some introduction that explains why this Annex is useful, which could be pulled from the material at the start of your section G.1 (up to, but not including, the table and its introduction, on page 14). In particular, that the concept “frame exchange sequence” is used in the standard (in the locations you cite), and that this Annex is trying to help explain the concept and how it relates to other concepts (like WM, etc.), and provide examples of frame exchange sequence in context. Also, the sentence (and maybe stuff around it) “This can affect the timing for when certain procedures within a given STA that cannot be initiated when an ongoing awake state (or active mode) is required can be initiated” could go up-front, too. (Although we’re now mixing medium control with awake state/active mode, which is more mess – do we really want to get into these at all in this Annex?)
- Then we can dive into the material you have at the start of Annex G in this draft (introducing “frame exchange” (but see detailed comment below), WM, beam forming, etc.).
- And, then, go into the table followed by the examples
- There is also some redundancy sprinkled around, but that is more easily removed later after organization (and other detailed changes) are settled.
- Some “bigger topics” that I think we (you and I, or the ARC group as a group) should discuss further, before trying to nail down text details:
- I don’t think MU operation/behavior is or has anything do with separate WM instances. I think it is a special type of encoding where a single PPDU (using a single WM) is carrying information to/from multiple peers. There a few places where your current draft seems to say this.
- I also don’t think different PHYs are different WM instances. That is true when the PHYs are mutually distinct (they are uniquely for different bands, for example), but when they share bands they are generally interoperable, and are all sharing a single channel and therefore a single WM. (For example, an HE STA that happens to send an HT format frame because it has dropped MCS rates to particular peer.)
- I’m not sure sectors are different WM instances, either. I don’t think an AP can send/use different sectors in parallel, can it?
- Should we consider relating a “WM instance” to a BSA? (Although this gets really messy when dynamic BSA (WM?) are considered, for example with beamforming or sectorization.) And, then relate all this to OBSS, where the WM sharing is “accidental”. (And, TGbn is going to complicate this with AP coordination.)
- The relationship between beamforming and WMs is complicated. I don’t think different beamforms are really different WMs – they can’t operate in parallel. But, OBSS situations can be resolved (and remove the “accidental sharing” of the same WM) by beamforming each BSS’s transmissions to avoid each other. This also relates back to the concept of coverage area (BSA), for a given WM. I’m still trying to make sure I understand subclause 10.38.12.4.4 (REVme D7.0), but I think that it trying to say that even with different beamforms, an MU transmission is a atomic operation across all the peers.
- A couple specific/details comments, below. Although, I had quite a few of these (my history as an Editor for other projects tends to raise its head when I review stuff like this), which we can deal with later, after the big stuff above is sorted out:
- We don’t generally say “normative text” within the document, we say “this standard”. I think we should check for uses of “normative text”/”normative description” and probably change them all to some form of “this standard”.
- At the bottom of page 3, you have stated that Figure 10-14 is showing BAR and BA/Ack over separate beams. I think the intention of Figure 10-14 is to show BAR and BA/Ack in the simple “omnidirectional”, “single WM” situation. I’m not even sure something like Figure 10-14 can happen over separate beams, as then I don’t know what the “AP” row/line in the figure is meant to represent, and I don’t think the current standard supports a single AP operating each of the beams as independent concepts (WMs?), per my last comment in the list above.
- There are some subtle differences between “frame exchange” and “frame exchange sequence”, that I think we need to review carefully. For example, the text starting the “Frame Exchange Sequence Examples” section (bottom of page 4), implies that a single frame transmission and reception is a frame exchange sequence, when a frame exchange sequence usually/often includes the acknowledgement and potentially other control frames associated with the main MPDU.
Thanks! Mark
To unsubscribe from the STDS-802-11-ARC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-ARC&A=1 |