Re: [STDS-802-11-TGBN] 11bn LB291 CR request

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

From: Samat Shabdanov <0000490d4a372b74-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Monday, 10. November 2025 at 15:01
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request - CR 25/1934

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

Hi Arik,

Please note, what you are suggesting is to introduce additional rules/constraints/restrictions on sharing AP.

During the early stages of C-TDMA framework discussions with members, we raised a concern that sharing AP need to follow some criterias so that the below (as indicated by you ) are met

Second, even if AP2 has traffic pending traffic of the AC that satisfy the Primary AC rule, AP1 does not have to select it again in the next TXOP AP1 has obtained:

It depends on how many MAPC agreements AP1 have with other AP
What is the preference of AP1 for allocating its TXOP resources with (and for which purpose)
And the last criterion I suggest: the last AP that was selected as coordinated AP in the former TXOP obtained by AP1, should not be reselected again for a limited period of time (if there are other candidates to select).

The members (including Huawei) did not share our concerns at the time and members have decided not to impose constraints on sharing AP except the fairness rule(s) described in Section 37.27.

Therefore, I am not sure, members (including us) want to revisit it now again after the framework of C-TDMA has been agreed and looks solid.

Bullet 3, the use of timeout, among possible other methods/solutions, for us, seems very unattractive due to the delta t factor to the LL wait time.

Note, C-TDMA (in contrast with CBF/CSR) targets LL traffic and delta t factor literally adds to the latency.

Thank you,

samat

From: Arik Klein <arik.klein@xxxxxxxxxx>
Sent: Sunday, November 9, 2025 11:36 PM
To: Samat Shabdanov <Samat.Shabdanov@xxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: 11bn LB291 CR request - CR 25/1934

External email : Please do not click links or open attachments until you have verified the sender or the content.

Hello Samat,

Thanks for your response.

First, let me clarify that my proposal is not unique only to Co-TDMA MAPC scheme, but also for other MAPC schemes, such as: Co-BF, Co-CR (less issue with Co-RTWTW, Co-CR).

Second, even if AP2 has traffic pending traffic of the AC that satisfy the Primary AC rule, AP1 does not have to select it again in the next TXOP AP1 has obtained:

It depends on how many MAPC agreements AP1 have with other AP
What is the preference of AP1 for allocating its TXOP resources with (and for which purpose)
And the last criterion I suggest: the last AP that was selected as coordinated AP in the former TXOP obtained by AP1, should not be reselected again for a limited period of time (if there are other candidates to select).

Regards,

Arik

From: Samat Shabdanov <0000490d4a372b74-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: יום ב 10 נובמבר 2025 13:16
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request - CR 25/1934

Hello Arik,

Thank you for the comment.

In the example that you have provided, we are not sure there is a fairness issue:

“ The problem that the comment raises is that since AP2 was already selected (by AP1) as a coordinated AP, we need to provide a tool (in the 802.11bn specification) to prohibit its reselection as a coordinated AP for a period of time after it has successfully was coordinated by another AP (or the same AP).

During the polling phase in C-TDMA, AP2 will be allocated a portion of the TXOP only if it has traffic pending traffic of the AC that satisfy the Primary AC rule.

For this reason, AP2 is polled again bkz

AP1 has the C-TDMA agreement with AP1
gains a TXOP sequentially
and AP2 responded in the ICR about its intention to obtain a portion of the TXOP.

if we introduce somewhat “timeout rule for” AP2, our LL traffic will suffer-> killing C-TDMA latency gains.

Thank you,

samat

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Sunday, November 9, 2025 9:55 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request - CR 25/1934

External email : Please do not click links or open attachments until you have verified the sender or the content.

Hi Arik,

As I mention offline, I think we should not add more constraints to the protocol. I would like to hear others’ opinion on this issue too especially from AP vendors about the complexity of adding another timer.

Some questions I have:

What is the duration of this timer ?

Is this an MU EDCA timer ?

Is it per AC ?
Is it a function only of last access time or also of the allocated duration ?

Regards,

Dibakar

From: Arik Klein <arik.klein@xxxxxxxxxx>
Sent: Thursday, November 6, 2025 6:16 AM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: 11bn LB291 CR request - CR 25/1934

Hello Dibakar,

Thanks for sharing the doc.

Regarding CID 8004, I really do not understand your rejection reason. Can you please clarify your technical reasoning for rejecting this comment???

I think that this comments raises another issue corresponding to fairness between APs that have established MAPC agreement and are being shared in Co-TDMA/Co-SR/Co-BF transmission as coordinated APs that has not been handled in clause 37.27.

Just to make sure that I have clarified my comment well, I hereby summarize the content of CID8004 and the proposed resolution:

Problem statement of the comment (I use an example here for illustration purpose):

Let’s assume the following scenario: we have 3 non-collocated APs: AP1, AP2, AP3 – all support MAPC operation (i.e. Support at least one MAPC scheme, e.g. Co-TDMA).

AP1 and AP2 have established MAPC agreement.
AP1 and AP3 have established MAPC agreement.
AP1 has obtained TXOP. During this TXOP it polls AP2 (which accepts the invitation),thus AP2 has obtained a portion of AP1’s TXOP for In-BSS transmission (i.e. with its associated non-AP STAs).
AP1 has obtained another TXOP. During this TXOP it polls AP2 (again).

The problem that the comment raises is that since AP2 was already selected (by AP1) as a coordinated AP, we need to provide a tool (in the 802.11bn specification) to prohibit its reselection as a coordinated AP for a period of time after it has successfully was coordinated by another AP (or the same AP).

This is done to keep the fairness among all APs that have established a MAPC agreement with AP1 but have not became a coordinated AP (denial of “starvation”).

The proposed solution in CID8004:

For each agreement define MAPC coordinatedAP Timer for each AP, where it defines the time for which this AP can’t become coordinated AP.
Once 2 APs have established a MAPC agreement (for specific MAPC scheme), define MAPC_coordinatedAP_Denial_Counter as the max{ MAPC coordinatedAP Timer of MAPC Requesting AP, MAPC coordinatedAP Timer of MAPC Responding AP}
Add a rule in 37.27 that an AP that has successfully used a TXOP as a coordinated AP:

Shall update its MAPC coordinatedAP Timer to the value in MAPC_coordinatedAP_Denial_Counter.
A polled AP with a MAPC coordinatedAP Timer that has a nonzero value shall not respond with ICR frame that it receives from a polling AP (with which it has an agreement) till the value of MAPC coordinatedAP Timer reaches zero.

Hope the above clarifies my point. Obviously, you may suggest an alternative resolution to the problem stated in CID8004.

Other interested members – your comments are highly appreciated on this topic.

Regards,

Arik

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: יום ג 04 נובמבר 2025 02:27
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request

Hi Alfred,

Please note that I have uploaded 1934r0 to the mentor.

All members who are interested in that section please review.

Regards,

Dibakar

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Thursday, October 30, 2025 9:13 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request

Hi Alfred,

Please add the following CR documents to the MAC queue:

11-25-1934 -CR for MAPC fairness – Technical (31 CIDs)
11-25-1935- CR for SCS related text – Technical (34 CIDs)

Regards,

Dibakar

From: Arik Klein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, October 30, 2025 1:09 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request

Hello Alfred,

Can you please help queue the following CR docs to the TGbn MAC agenda?

11-25/1912 LB291 - CR for MAPC element - Editorials 1 (14 CIDs)
11-25/1913 LB291 - CR for 37.15.1 MAPC common procedures - Editorials 2 (18 CIDs)

Regards,

Arik

From: Abhishek Patil <0000297b717f2a04-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: יום ד 29 אוקטובר 2025 23:10
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request

Hi Alfred,

Can you please help queue the following CR docs to the TGbn MAC agenda?

11-25/1835 LB291: CR for CIDs assigned to Abhi - Part 4

11-25/1836 LB291: CR for CIDs assigned to Abhi - Part 5

Regards,

Abhi

From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Monday, October 27, 2025 2:19 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: 11bn LB291 CR request

Hi Alfred,

Can you please help queue the following CR docs to the TGbn MAC agenda?

11-25/1826 LB291: CR for CIDs assigned to Abhi - Part 2

11-25/1834 LB291: CR for CIDs assigned to Abhi - Part 3

Regards,

Abhi

From: Abhishek Patil <0000297b717f2a04-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, October 23, 2025 2:03 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Alfred,

Can you please help queue the following CR doc to the TGbn MAC agenda?

11-25/1825 LB291: CR for CIDs assigned to Abhi - Part 1

Regards,

Abhi

From: wangkaidong (E) <00004ea939387e7b-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, October 23, 2025 1:53 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hello Alfred,

Please help add the CR document to the MAC queue. It resolves 1 CID. Thank you!

23-Oct-2025 ET 2025 1859 0 TGbn 11bn LB291 CR for CID 4983 Kaidong Wang (Huawei)

Best regards,

Kaidong Wang

From: Fang, Juan <juan.fang@xxxxxxxxx>
Sent: Thursday, October 23, 2025 6:36 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request
Importance: High

Hi Alfred,

Please help to add following to the PHY queue, it has 8 CIDs.

22-Oct-2025 ET

2025

1837

TGbn

PHY-lb291-CIDs_subclause_38.3.15.12_ELR_SIG

intel

22-Oct-2025 18:29:52 ET

Download, Revise

Thanks,

Juan

From: Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, October 22, 2025 2:59 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 11bn LB291 CR request

Hi Alfred,

Pls add the following to the MAC queue. It resolves 15 CIDs.

17-Oct-2025 ET

2025

1820

TGbn

LB291: CR for CIDs on UHR Parameters Update element - part 1

Gaurang Naik (Qualcomm)

All, please let me know if you have any feedback.

Thanks

Gaurang

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Thursday, October 16, 2025 12:09 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>; ross.yujian@xxxxxxxxxx <ross.yujian@xxxxxxxxxx>
Subject: Re: 11bn LB291 CR request

Hi Alfred,

Please add the following CR document to the MAC queue. It resolves 23 CIDs.

2025

1816

TGbn

LB291: CR for CIDs on UHR Mode Change element - part 1

Gaurang Naik (Qualcomm)

Thanks

Gaurang

From: Yujian (Ross Yu) <00001792b51ef4ea-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, October 15, 2025 6:15 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGBN] 11bn LB291 CR 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 CR documents into the queue, it contains 20 editorial CIDs.

https://mentor.ieee.org/802.11/dcn/25/11-25-1791-00-00bn-lb291-editorial-comments-part-1.docx

regards

于健 Ross Jian Yu

Huawei Technologies

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