Hi Yunbo,
I think we should look at the complexity with a bit wider view.
At a high level, C-TDMA is just extending basic triggering from non-AP STAs only to also AP. Now, if you compare the fairness rules for a STA versus and an AP, a STA needs to follow MU-EDCA rules which are
more aggressive (once you use TF for access, you may be effectively disallowed to use EDCA in some cases) and more resource constrained (e.g., maintaining other EDCA counter values, timer etc.). On the other hand, for AP we are only proposing to add some threshold
based rules without touching channel contention that are not as aggressive and resource-intensive.
So, even with all the proposed fairness rules for AP, channel access is still going to be asymmetrical to client; further weakening those rules could be worse. Secondly, note that typically a STA has low UL
traffic while AP has tons of DL traffic. So, if a shared AP gains excessive channel usage opportunities, the impact to legacy will be more than say, a STA doing regular EDCA (w/o MU-EDCA) plus TF-based channel access.
My point is that all the above point deserve bit more attention before we rush to adopt a particular direction regarding the TBD. Eventually if the group ends up choosing the direction you prefer, that’s also
fine. Meanwhile we should be able to make progress on the parts that are agreed.
Regards,
Dibakar
Hi Dibakar and Sanket,
I expressed similar comments before, Sanket’s
suggestion looks fine for me. I don’t think it is good to introduce too much number/thresholds. Simply
mandate myBSS transmission before share to OBSS AP is good enough.
Regards,
Yunbo
Hi Sanket,
I will ask for the chair guidance here regarding whether we need to clarify every detail in a section before the corresponding PDT being motioned.
I think I am currently following same approach as others to make incremental progress on topics to meet timeline. This PDT document is capturing the group consensus on the motion text. There was a TBD in the
motion because this part was not resolved. So, the PDT also has a TBD for that aspect.
Regards,
Dibakar
Hi Dibakar,
We have at least two weeks until the May F2F meeting, which can be used to address these issues. So, we need not rush into running a motion on a PDT that contains text which is ambiguous and imprecise.
Do you see a technical concern with the suggested text in my earlier e-mail?
WARNING: This email
originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Sanket,
I think we need to make some progress to meet the 11bn draft 1.0 timeline. As such given this text is capturing the motion that passed, we should try to follow what we have done for every other PDT: make progress on the parts that are agreed and work on
resolving the details.
If the issue is really about not having a
“TBD” we can follow what we have typically done for such issues: have a place-holder/imprecise text for now until the group finds the precise solution.
Regards,
Dibakar
Hi Dibakar,
Thank you again for preparing the PDT on the fairness topic. I have a couple of technical concerns as follows:
The current PDT (11-25/479r3)
states: "Within a TXOP in which a TXOP owner AP performs either Co-TDMA or TXS mode 2 procedure, the AP shall use at least a
TBD portion of the obtained TXOP for
data communication with its own associated STAs before sharing the TXOP with other STAs."
1.
From a spec language point-of-view, the term "data communication" is ambiguous. So, I suggest the following revision:
"Within a TXOP in which a TXOP owner AP performs either Co-TDMA or TXS mode 2 procedure, the AP shall use
at least a TBD a portion of the obtained TXOP for
at least one individually addressed frame exchange with its associated non-AP STAs data communication with its own associated STAs before
sharing the obtained TXOP with other STAs."
2.
Suggest not to introduce a new TBD. The above suggestion takes care of it as well. We can always add to the PDT if there is a need to add a specific value later.
If you think we need more offline discussions, we can defer the motion to give us more time to revise the PDT.
Best,
Sanket
From: Das, Dibakar
Sent: Thursday, April 3, 2025 11:07 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] CR MAC Request
WARNING: This email
originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Alfred,
Please add the following (presented) CR doc to agenda for MAC queue for SP:
https://mentor.ieee.org/802.11/dcn/25/11-25-0479-01-00bn-cr-for-cid-1378.docx
Regards,
Dibakar
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