| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
On Wed, Jun 11, 2025 at 8:43 AM Jeongki Kim <jeongki.kim.ieee@xxxxxxxxx> wrote:Hi Matt,Thanks a lot for your CR document.1. I agree with Patrice. It looks like that untriggered UL transmission on the NPCA primary channel is not allowed anymore. Is that your intention?It is one possible, optional mode - you can disable the mode.I.e. the AP can either allow untriggered UL on NPCA or disallow it.
2. PPDU based and TXOP based look better to me than PHY header and MAC header based.Although you changed to them in r4, 1.->b)->ii) is also mentioning the MAC header based NPCA. Condition 2 is the same.You can just mention "either condition 1) or condition 2) is met" rather than "either the PHY Header-based condition 1) or the MAC Header-based condition 2) is met".The labels are handy for referencing the conditions, so it is nice to have some label. (It is possible to just refer to condition 1) and condition 2), but somehow that seemed inadequate earlier which is why these labels were added)The concept that is expressed under condition 1) is that only PHY header information is used, and whenever MAC Header based is allowed, PHY header based is also allowed, hence the reason that MAC header based is included in the PHY header based condition.The labels can be changed at any time - it is only an editorial change, so without a really solid suggestion, I prefer to just leave this alone and concentrate on the technical aspects.3. Do we have a "DUR field"? You may change "the DUR field value" to "a value of a Duration/ID field" or "a value indicated in a Duration/ID field".Changed to Duration/ID - 936r54. "MAC variable NPCA_TXOP_REM_DUR" means only PHY TXOP? In condition 1, what if NPCA STA switches to NPCA primary channel after receiving MAC duration? Does the text of condition 1 cover the operation? Or you just want to focus on the PHY TXOP?I've changed the names of a couple of the variables so that they better reflect the source of their values. 936r5Thanks,Jeongki2025년 6월 11일 (수) 오전 5:44, NEZOU Patrice <Patrice.Nezou@xxxxxxxxxxxx>님이 작성:Hi Matthew,
Thanks for this new revision.
I have some remarks related to the resolution of 1809 about the MU EDCA Timer usage. You notified that the AIFSN[AC] is set to 0 for all ACs on the NPCA primary channel. It means that EDCA is disabled in that case. Only triggered transmissions can be initiated.
What is the interest to define “a mode of operation in which untriggered UL transmissions on the NPCA primary channel by NPCA non-AP STAs is not permitted” (11bn draft 0.3 p.150 l.17) ?
Can you clarify that point ?
Regards
Patrice
From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
Sent: mardi 10 juin 2025 02:16
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11-25-936r4 PDT NPCA update -- was: Reminder: Technical Submissions Queues
BEWARE: This email originated outside of our organization. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Please report all suspicious emails to the ISS department as an attachment.
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.
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
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
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
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
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
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
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
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.
On Sun, Jun 8, 2025 at 8:15 PM 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx> wrote:
Hi Matt,
A few comments on 25/936r3 as attached.
BR,
Chaoming
发件人: Matthew Fischer <matthew.fischer@xxxxxxxxx>
发送时间: 2025年6月8日 9:04
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] Reminder: Technical Submissions Queues
Alfred,
Please update the revision for 11-25-0936 to r3:
Thank you.
Matthew Fischer (Broadcom)
On Sat, Jun 7, 2025 at 5:18 PM Matthew Fischer <matthew.fischer@xxxxxxxxx> wrote:
Alfred,
Please update the revision for 11-25-0936 to r2:
Thank you.
On Sat, Jun 7, 2025 at 9:33 AM Kiseon Ryu <kiseon.ryu@xxxxxxxxxxxxxx> wrote:
Hi Alfred,
Please keep the following contributions in the TGbn MAC queue and update the link to the documents.
2025
873
0
TGbn
P-EDCA Discussion
Kiseon Ryu (WILUS)
07-Jun-2025
2025
874
0
TGbn
UHR BSS Parameter Update
Kiseon Ryu (WILUS)
07-Jun-2025
Thanks,
Kiseon
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
--
Matthew Fischer
--
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
--
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
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
--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