| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Matt, Thanks for the reply and please see my follow-up inline. BR, Chaoming 发件人: Matthew Fischer <matthew.fischer@xxxxxxxxx>
936r4 is now on the server: Chaoming, Thanks for the review. Here is a summary of responses to your comments, for details of changes, please see the newest revision of the document. 1. PPDU-based v TXOP-based condition naming You correctly point out that some form of TXOP information is possibly being used to determine the NPCA duration in the PPDU-based condition. Therefore, I have changed PPDU-based to PHY Header based and TXOP based to MAC Header based. [cm] Sounds better. 2. might vs may within condition 2 might is the correct term, so no change is needed here may is the correct term only when an optional action is being described - might is the correct term when describing a possible event, which is the case here [cm] you true. 3. request for modification of a long sentence describing the time window for receipt of the third PPDU I have divided the sentence into a first part and two subbullets [cm] sounds good. 4. request to allow use of PHY header TXOP fields instead of (or in addition to?) MAC DUR field This would be a significant change, and I am not certain if there is widespread support for it, so I would recommend a separate straw poll / document for this requested change [cm] My point actually is what is the DUR field are you referring to in
“the DUR field value obtained from the first PPDU if the first PPDU did not contain an (MU)RTS”.
Is it the Duration/ID field in the MAC header? If so, then that means the STA has to at least receive and decode a few DATA symbols to get that field. 5. request to move the OBSS PPDU condition to earlier in the sequence There is no need to move this requirement - the initial statement of condition 2 is that ALL of the following items must be true, so the order does not matter However, it is noted that the condition says that at least one of the "received PPDUs", but it is not clear that if one receives only the PHY header of the third PPDU, is that a "received PPDU" so I have added the additional
condition "or partially received PPDUs" to allow for identification of the OBSS nature of the TXOP through reception of the OBSS information in the PHY header of the third PPDU [cm] OK. 6. use of triple negative It looks like a double negative to me, as such, I do not think that the language is difficult to parse And your proposed phrasing is inaccurate: "its use of triggered UL transmission only is enabled" There is no process that enables UL triggered UL transmission only. There is only a process that enables or disables UL transmissions that are not triggered [cm] I do suggest change the name of the process from “UL transmissions that are not triggered” to “triggered
UL transmission only” So I have made no change to this text 7. prohibiting UHR ELR PPDU transmission during NPCA You propose removing this restriction I'm a bit on the fence on this one - there was a significant amount of informal support for the restriction I do not know how much opposition there is to including it So I have made no change for now [cm] I do have concern on this since there were no sufficient discussion on this during the past calls. 8. prohibition of the use of DSO with NPCA You propose removing this restriction The arguments that I have heard against using DSO with NPCA are much louder and stronger than ELR I am confident that there is not much support for removal of this restriction So I have made no change for now [cm] May you share the arguments to let more members to know the justification? 9. you propose allowing groupcast frame transmisions on the NPCA channel with a new condition: if All the member STAs corresponding to the group addressed frames are operating on the NPCA primary channel Your argument to support this change is based on the last part of the note of motion 366. I think that we have different interpretations of that note. Here is the last part that you are using to justify your proposed change: the group addressed frame will be buffered and delivered immediately following the next DTIM Beacon, unless explicitly specified otherwise I believe that the phrase "unless explicitly specified otherwise" is referring to the future time at which the frames will be delivered, and not to the text in the normative part of the motion text which says that the
frames shall not be delivered during the NPCA window. So no change at this time to the PDT for this comment. [cm] Sounds like we do have different interpretations. To make progress, could you still keep “unless explicitly specified otherwise” in the draft, and we can clarify it
in the next round? On Sun, Jun 8, 2025 at 8:15 PM
罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx> wrote:
--
Matthew Fischer To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1 |