Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Maybe delete the part in brackets, because it is not entirely clear if this pertains only to ‘choose not to
transmit’ or also to ‘initiate TXOP’: initiate a or, change along the lines of initiate a I added the parenthesis to match the "each EDCAF shall report an internal collision" para. Arguably it applies to the initiate TXOP case too: however the TXOP ends,
backoff will happen.
I am not happy with your second proposal because we have or/and precedence ambiguity and it does not match the "internal collision" form.
But would you be OK with: At each of the above-described specific slot boundaries, each EDCAF shall
either choose not to transmit (which results in invocation of the
backoff procedure as specified in 10.23.2.2 (EDCA backoff procedure)) or
initiate a ? For the note perhaps add that there might be other reasons as well: NOTE—An EDCAF might choose not to transmit if the available bandwidth (based on the state of the secondary channel(s)) is insufficient for its purposes,
or for other reasons. Perhaps use ‘for’ instead of ‘on’ in e) Transmit nothing and I'm fine with these. Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From:
Menzo Wentink <menzow@xxxxxxxxxxx> --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Maybe delete the part in brackets, because it is not entirely clear if this pertains only to ‘choose not to transmit’ or also to ‘initiate
TXOP’: initiate a or, change along the lines of initiate a For the note perhaps add that there might be other reasons as well: NOTE—An EDCAF might choose not to transmit if the available bandwidth (based on the state of the secondary channel(s)) is insufficient for its purposes,
or for other reasons. Perhaps use ‘for’ instead of ‘on’ in e) Transmit nothing and Menzo From:
Mark Rison <m.rison@xxxxxxxxxxx> Here is my latest proposal, based on the feedback received: Discussion: 10.23.2.4 is extremely clear that exactly one thing happens on slot boundaries (which are also extremely precisely defined): On these specific slot boundaries, each EDCAF shall make a determination to perform one and only one of the following functions: — Decrement the backoff counter. — Initiate the transmission of a frame exchange sequence. — Invoke the backoff procedure due to an internal collision. — Do nothing. and the first three are spelt out too. In particular, for the second we have (note the “shall”): At each of the above-described specific slot boundaries, each EDCAF shall initiate a transmission sequence if — There is a frame available for transmission at that EDCAF, and — The backoff counter for that EDCAF has a value of 0, and — Initiation of a transmission sequence is not allowed to commence at this time for an EDCAF of higher UP. Other locations talk about what a STA shall do when it is “permitted to begin a TXOP (as defined in 10.23.2.4)”, e.g. in 10.23.2.5: If a STA is permitted to begin a TXOP (as defined in 10.23.2.4 (Obtaining an EDCA TXOP)) and the STA has at least one MSDU pending for transmission for the AC of the permitted TXOP, the STA shall perform exactly
one of the following actions: a) Transmit a 160 MHz or 80+80 MHz mask PPDU if the secondary channel, the secondary 40 MHz channel, and the secondary 80 MHz channel were idle during an interval of PIFS immediately preceding the start of the
TXOP. b) Transmit an 80 MHz mask PPDU on the primary 80 MHz channel if both the secondary channel and the secondary 40 MHz channel were idle during an interval of PIFS immediately preceding the start of the TXOP. c) Transmit a 40 MHz mask PPDU on the primary 40 MHz channel if the secondary channel was idle during an interval of (11ax)duration 1) DIFS if the PPDU is transmitted in the 2.4 GHz band or 2) PIFS otherwise,
immediately preceding the start of the TXOP. d) Transmit a 20 MHz mask PPDU on the primary 20 MHz channel. e) Restart the channel access attempt by invoking the backoff procedure as specified in 10.23.2 (HCF contention based channel access (EDCA)) as though the medium is busy on the primary channel as indicated by
either physical or virtual CS and the backoff counter has a value of 0. [more PPDU transmission options for TVHT and HE] “permitted to begin a TXOP” must be cognate with “Initiate the transmission of a frame exchange sequence” (sic) / “initiate a transmission sequence”. But then “e) Restart the channel access attempt by invoking the backoff procedure” is
not within the scope of what is permitted by 10.23.2.4 when the backoff counter is 0, there is something to tx and there is no higher-priority EDCAF also in the same situation -- in this situation a STA “shall” initiate a TXOP. (And additionally it is not
clear: on which EDCAF(s) is the backoff procedure invoked? And is CW[AC] changed?) Proposed changes: Change 10.23.2.4 as follows: On these specific slot boundaries, each EDCAF shall make a determination to perform one and only one of the following functions: — Decrement the backoff counter. — Initiate — Invoke the backoff procedure due to an internal collision. — Invoke the backoff procedure due to choosing not to transmit. — Do nothing. At each of the above-described specific slot boundaries, each EDCAF shall decrement the backoff counter if the backoff counter for that EDCAF has a nonzero value. At each of the above-described specific slot boundaries, each EDCAF shall
either initiate a — There is a frame available for transmission at that EDCAF, and — The backoff counter for that EDCAF has a value of 0, and — Initiation of a transmission sequence is not allowed to commence at this time for an EDCAF of higher UP. NOTE—An EDCAF might choose not to transmit if the available bandwidth (based on the state of the secondary channel(s)) is insufficient for its purposes. At each of the above-described specific slot boundaries, each EDCAF shall report an internal collision (which — There is a frame available for transmission at that EDCAF, and — The backoff counter for that EDCAF has a value of 0, and — Initiation of a transmission sequence is allowed to commence at this time for an EDCAF of higher UP. At each of the above-described specific slot boundaries, each EDCAF shall do nothing if — There is no frame available for transmission at that EDCAF, and — The backoff counter for that EDCAF has a value of 0. Change 10.23.2.2 as follows: The backoff procedure shall be invoked by an EDCAF (11ax)if any of the following events occurs: g) If explicitly indicated, such as in 26.17.2.3.3 (Non-AP STA scanning behavior).(11ax) g2) The EDCAF is permitted to initiate a TXOP (see 10.23.2.4) but chooses not to. In addition, the backoff procedure may be invoked by an EDCAF if: h) […] […] If the backoff procedure is invoked for reason a) or g2) above, CW[AC] and QSRC[AC] shall be left unchanged.
<insert para break> If the backoff procedure is invoked for reason b) or f)(11ax) above, CW[AC] shall be set to CWmin[AC], and QSRC[AC] shall be set to 0. If the backoff procedure is invoked for reason c), d), e), g), h), or i)(11ax) above, CW[AC] and QSRC[AC] shall be updated as follows: Change 10.23.2.5 as follows: If one of a STA’s EDCAFs is permitted to
a) Transmit a 160 MHz or 80+80 MHz mask PPDU if the secondary channel, the secondary 40 MHz channel, and the secondary 80 MHz channel were idle during an interval of PIFS immediately preceding the start of the
TXOP. b) Transmit an 80 MHz mask PPDU on the primary 80 MHz channel if both the secondary channel and the secondary 40 MHz channel were idle during an interval of PIFS immediately preceding the start of the TXOP. c) Transmit a 40 MHz mask PPDU on the primary 40 MHz channel if the secondary channel was idle during an interval of (11ax)duration 1) DIFS if the PPDU is transmitted in the 2.4 GHz band or 2) PIFS otherwise,
immediately preceding the start of the TXOP. d) Transmit a 20 MHz mask PPDU on the primary 20 MHz channel. e) Transmit nothing and and after the bullets add: NOTE—An EDCAF that initiates a TXOP has a frame available for transmission (see 10.23.2.4). There might be another EDCAF of lower priority that invokes the backoff procedure due to an internal collision (see
10.23.2.4). TBD: make similar changes in 10.23.2.6 (3x), 10.23.2.13, 10.23.2.14. Proposed resolution: REVISED Make the changes shown under “Proposed changes” for CIDs 1985, 1986, 1535, 1419, 1536 in <this document>, which address the issues raised. Note to the Editor: this resolution to CID 1536 supersedes the previously motioned acceptance of CID 1536’s proposed change. Please delete the NOTE that was added, and then make the changes above. Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From:
Mark Rison Hello Matt, I think you make a reasonable argument, and I've checked with the commenter and he agrees. So I propose to resolve CID 2187 as follows: REJECTED In the case of reaching backoff = 0, if a STA for some reason does NOT initiate a transmission, then it should always instead do a new backoff. If this is not done, then the STA is left with the condition that whenever the medium next becomes free, then: a) it will have permission to initiate that suspended transmission. b) any number of other STAs might have reached the same condition in the meantime because they had the same event occur while this STA was waiting for a free medium The result is that multiple STA all can initiate at exactly the same time - that is, if the gating condition is the end of some activity on the air, then all of the waiting STAs will see that same gating condition
at the same time. And all of them will then start a suspended transmission at the same time. I.e. this behavior will cause an alignment of their states which, absent this condition, would have been randomly aligned states. E.g. if five STA are waiting to transmit with different backoff values then as long as the primary is idle, they all count backoff and each reaches ZERO at a different time, yet each chooses to not transmit because when it reaches 0, it sees a busy on some secondary Then, at some point, that secondary becomes IDLE and then all five STAs come blasting out at the same time. So whenever a backoff=0 is not used and there is a non-empty TX queue, then a new backoff should be invoked. However, we still have a problem, because 10.23.2.4 only allows "Invoke the backoff procedure due to an internal collision." not "Invoke the backoff procedure because you could but chose not to transmit." So some changes are going to be necessary in 10.23.2.4 anyway. Is there agreement that in the "could but chose not to transmit" case the backoff does not change CW[AC] (i.e. not doubled, not reset), since it is neither failure nor success? Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From:
Matthew Fischer <matthew.fischer@xxxxxxxxxxxx>
Mark, Thanks. I finally found that definition that you cite. I see that this definition matches the language that is being replaced by TXOP, so ok, sort of. That is, I can see the logical equivalence of "initiate frame exchange" with TXOP, so the substitution seems ok, but I do not like this definition of TXOP. I.e. the definition looks like a moment in time, but there are things like TXOP duration and TXOP limit. The definition claims to be more than a moment, as in "interval" but then the definition sounds like someone can initiate frame exchanges at any time within a TXOP, but that's not true. There are limitations. But maybe the definition does not need to mention that, so I probably don't care too much about it. BUT I still question the other change: Specifically, in the case of reaching backoff = 0, if a STA for some reason does NOT initiate a transmission, then it should always instead do a new backoff. If this is not done, then the STA is left with the condition that whenever the medium next becomes free, then: a) it will have permission to initiate that suspended transmission. b) any number of other STAs might have reached the same condition in the meantime because they had the same event occur while this STA was waiting for a free medium The result is that multiple STA all can initiate at exactly the same time - that is, if the gating condition is the end of some activity on the air, then all of the waiting STAs will see that same gating condition
at the same time. And all of them will then start a suspended transmission at the same time. I.e. this behavior will cause an alignment of their states which, absent this condition, would have been randomly aligned states. E.g. if five STA are waiting to transmit with different backoff values then as long as the primary is idle, they all count backoff and each reaches ZERO at a different time, yet each chooses to not transmit because when it reaches 0, it sees a busy on some secondary Then, at some point, that secondary becomes IDLE and then all five STAs come blasting out at the same time. I.e. the proposed language does create a spoiled party This is why I believe that whenever a backoff=0 is not used and there is a non-empty TX queue, then a new backoff should be invoked. Note that if the TX queue is empty, and backoff = 0, then no new backoff is needed because the gating event for transmission initiation is not a common network event. I.e. the gating event for transmission in this case is the entry of a new item into an empty TX queue at a single STA and that is a random event observed by only that one STA. Matthew Fischer Nice Guy Broadcom Inc. +1 408 543 3370 office On Sun, Aug 28, 2022 at 7:59 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 |