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

Re: [STDS-802-11-TGBN] SP list

Dear Alfred,

Could you please allocate some time for the following SP to the PM2(joint) session? (11-25/0068r1)

•Do you agree to add the following text to the TGbn SFD?
– A STA that transmits a BSRP NTB Trigger frame as the initial Control frame shall use the access category corresponding to the QoS Data frame, QoS Null frame or Management frame it intends to transmit during the TXOP initiated with the BSRP NTB Trigger frame.
•A STA that has no QoS Data frames to transmit can use any AC.
•QoS Data frame(s) corresponding to the secondary AC may also be transmitted during the TXOP, in accordance with the rules defined in 10.23.2.7 (Sharing an EDCA TXOP) and 26.6.3 (Multi-TID A-MPDU and ack-enabled single-TID A-MPDU).

Best regards,
Shawn

Sanghyun Kim, Ph.D 
WILUS Inc.
5th Fl., 216 Hwangsaeul-ro Bundang-gu,
Seongnam-si Gyeonggi-do 13595, Korea 
T +82 31 712 0523
www.wilusgroup.com

2025년 7월 31일 (목) 오전 11:50, Brian Hart (brianh) <00000c7561051aea-dmarc-request@xxxxxxxxxxxxxxxxx>님이 작성:

Fair. -B

 

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Thursday, July 31, 2025 2:19 AM
To: Brian Hart (brianh) <brianh@xxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] SP list

 

It sounds like you view the timing info in ICR to be the main signaling and that in ICF to be of secondary value.  

 

From: Brian Hart (brianh) <brianh@xxxxxxxxx>
Sent: Thursday, July 31, 2025 1:48 AM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] SP list

 

My comments below principally relate to the ICR. Having said that, time signaling in ICF:

  • Allows a peer AP who only has a long low-MCS buffered to pass on the current sharing offer.
  • Perhaps for other secondary purposes (tune its ICR response to make it more realistic for the available time, make preliminary scheduling plans if an allocation occurs etc)

 

Best wishes

Brian

 

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Thursday, July 31, 2025 1:41 AM
To: Brian Hart (brianh) <brianh@xxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] SP list

 

What is the value of time signaling in ICF if ICR anyway indicates how much time shared AP needs ?

 

From: Brian Hart (brianh) <00000c7561051aea-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, July 31, 2025 1:38 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] SP list

 

Hi all

 

Let’s back up for a second.

  • The fundamental use case for Co-TDMA is an AP polling its peers, and trying to figure out who can use medium time most efficiently – itself, this peer, that peer, or this combinations of peers. Specifically, we need to avoid the scenario of a peer AP with lower priority traffic being granted time first (for just video), and that peer AP takes up all the time, such that another peer AP with higher priority traffic (e.g., voice) is thereby denied access.
  • We recognized in 11ax that BSR was the minimum information needed for APs to scheduling UL traffic. I don’t know why we would expect that anything less is sufficient for Co-TDMA.
  • We recognized that BSR could be constructed with acceptable complexity (and that was two generations ago). APs support more clients, but equally have higher capability to support those clients. So BSR can equally be constructed with acceptable complexity
    • Acknowledging that a peer AP’s knowledge of its BSS’ UL requirements may be imperfect – which can be solved by a ICR response that errs on the side of conservatism.
  • If mobile APs etc foresee implementation complexity problems, we can have special values reporting “don’t really know” for each of these fields.

 

Best wishes

Brian

 

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Wednesday, July 30, 2025 9:08 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] SP list

 

Hi Klaus,

 

Just repeating again. Having more info cant hurt theoretically. Whether its significantly useful is not clear. I think while focusing on this ICF/ICR part, we are overlooking quite some stuff about the overall protocol.

 

  1. When the shared AP doesn’t support TB PPDU (which I expect to be many APs in the field), this SP2 proposal is not useful since whatever time ICF signals will anyway be the allocated time. Medium efficiency for this can only be done through TXOP return.  Similarly, for cases where there is only one shared AP active at the time.
  2. The ability for a sharing AP to do back-to-back TXOP grants to multiple shared APs is not very high if the medium is congested and sharing AP loses chance to regain TXOP to another STA during the 1st allocated duration. Based on our understanding that typically trigger based mechanisms are enabled when medium is congested, I would think there will be quite many environments where the sharing AP will do at most one allocation.

 

 

Regarding your comment below about TXOP return being optional, I don’t get why mention that. We don’t need two mechanisms for the same purpose because one is optional. If one cares about the problem, they would implement that feature.

 

Regards,

Dibakar

 

 

 

From: Klaus Doppler (Nokia) <0000320c1b22a542-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, July 30, 2025 8:50 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] SP list

 

Samat: We prefer a simple solution based on the TXOP return mechanism that can achieve the same goal .

 

[Klaus: TXOP return is an optional feature right now. Sending additional frames to return TXOPs increases the overhead and does not make things simpler. From a coordinating AP perspective, it is much simpler to allocate TXOP durations to other APs when it knows approximately how much they need.

 

From: Samat Shabdanov <0000490d4a372b74-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Wednesday, July 30, 2025 at 1:40 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] SP list

You don't often get email from 0000490d4a372b74-dmarc-request@xxxxxxxxxxxxxxxxx. Learn why this is important

 

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.

 

Hello Tong,

 

It is Samat from Mediatek.

The motivation for the params in the ICR is understood.

Please note that this param is not accurate.

 

if the total requested times from the polled APs > the max TXOP duration under consideration,

these params are useless.

 

It is a simple decision on pros/cons. And we think that the complexity of implementing does not justify its promised benefit.

We prefer a simple solution based on the TXOP return mechanism that can achieve the same goal .

 

Thank you

samat

 

From: Tong Bian <tong.bian@xxxxxxxxxxxxxxxx>
Sent: Wednesday, July 30, 2025 4:18 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] SP list

 

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

Hi Dibakar,

 

(Sorry to jump in the discussion suddenly)

 

Regarding your response, you mean the Max TXOP duration in ICF? It’s just some information that the coordinating AP considers to share, right? How much TXOP each polled AP use is based on themselves. Let’s say coordinating AP is willing to share 2.5ms, but polled AP only needs 500us  is not allowed, and it needs to use more than that?

 

For your suggested a and b methods, giving AP3 another allocation after AP2 is not so efficient. Each polled AP is allocated maximum and TXOP return the rest, and repeat for each polled AP.  I think the more efficient way is let each polled AP include the amount they need in ICR, and have more precise TXOP sharing.

 

Thanks for sharing your thoughts, and I’m happy to have more discussions

 

Best regards,

Tong

 

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Wednesday, July 30, 2025 7:00 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] SP list

 

In your example, what is the value of the time signaled in the ICF then ? Seems like that info is ignored by both shared APs..

Also, AP1 can do any of the following:

  1. Give AP3 another allocation after allocating AP2 ?
  2. Always give maximum alloc to each AP..

 

From: Klaus Doppler (Nokia) <klaus.doppler@xxxxxxxxx>
Sent: Wednesday, July 30, 2025 3:35 AM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] SP list

 

Hi Dibakar,

 

Thanks for the comment and good debates. 

 

Let’s say the coordinating AP1 is willing to share up to 2.5ms and receives a response from AP2 and AP3 that they would like to get an allocation. AP2 might just need 500us and AP3 2ms. In the current spec, there is no way for AP2 and AP3 to indicate to AP1 how much they need. Let’s say AP1 allocates 1.25ms to AP3 and then 1.25ms to AP2. So AP3 is short 750us from its needs. Having the Requested Time Allocation in the response frame helps the coordinating AP to make a proper allocation. I agree with you, there will still be variations due to retransmissions and imprecise knowledge of UL buffer, but the allocation will still improve - especially in cases when we have such an imbalance on the allocation needs.

 

Br, Klaus

 

 

 

 

 

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Date: Wednesday, July 30, 2025 at 10:44 AM
To: Klaus Doppler (Nokia) <klaus.doppler@xxxxxxxxx>, STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBN] SP list

 

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 Klaus,

 

Thanks for sharing the SP2. Since the sharing AP indicates how much time its willing to share for the TXOP, what added value does this SP bring ?

While in general I agree more information is good, in this case the benefit may be small. Suppose, sharing AP indicates the max time in the ICF and polls 3 APs. Out of them 2 (AP-2, AP-3) reply saying they can use this allocation (with current signaling) and moreover, how much precise time they need (with SP2) .

 

Then, in baseline the sharing AP would allocate time to those APs with some logic. If there is unused time, first allocated AP would return it and remaining time can be allocated to other etc.

 

With your signaling, sharing AP may be able to provide slightly more precise allocation in the TXS frame. But given there could be retransmissions etc. during the allocated time or some data requirements might have changed, this is not entirely full-proof either and the TXOP return will likely need to be used to make the allocations efficient.

 

 

As such given polling is always included in each CTDMA TXOP the information doesn’t seem necessary.  

 

Another q: if shared AP doesn’t support TB PPDU, there is only AP to allocate to in that TXOP. So, even the above problem about how much time in TXOP AP shall allocate to each shared AP doesn’t exist.

 

 

Regards,

Dibakar

 

 

 

From: Klaus Doppler (Nokia) <0000320c1b22a542-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, July 30, 2025 12:59 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] SP list

 

Hi Alfred,

 

I would like to run the SP 2 either later today or tomorrow: 

 

SP2: Do you support to add an information field to the Co-TDMA ICR that the coordinated AP can use to indicate the time duration it would like to be allocated by the sharing AP as part of the Co-TDMA TXOP sharing procedure. The sharing AP can use this information to allocate time to the coordinated AP(s). Note: The indicated time duration to be allocated is a recommendation to the sharing AP.  The PDT already includes the primary AC as a parameter in the ICF to help the polled AP to decide if it has wants to receive part of the TXOP from the sharing AP.

 

Supporting Document 25/1163r1

 

I have discussed offline with the members commenting on SP1. The concerns were with the SP itself, for example it is not needed to run the SP or that it should also include additional information fields in the ICF. Since the SP received 60% support and the negative comments did not directly object adding additional parameters to the Co-TDMA ICR, I feel SP2 has a chance to pass and I would like to run it.

 

Thank you,

Klaus

 

 

From: Rubayet Shafin <r.shafin@xxxxxxxxxxx>
Date: Tuesday, July 29, 2025 at 12:41 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] SP list

 

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 Alfred,

 

For the CR document 11-25/764, I worked with the commenters and addressed their comments.

 

Could you please queue the SP for the MAC/Joint session?

 

Best

Rubayet

 

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Sunday, July 27, 2025 2:59 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] SP list

 

Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hello all,

 

Please review the SP list and let me know if anything is outdated or is missing:

 

May 13

Do you agree to enhance the existing SCS framework in 11bn to enable a non-AP STA to dynamically switch from one QoS profile to another QoS profile for an SCS stream?

 

·          The new QoS profile is selected from one of the previously accepted QoS profiles for that SCS stream.

 TBD on mechanism for QoS profile switch indication.

Supporting document: 24/0825, 24/0660, 24/1752, 25/0494

 

Yue Qi

Pending

QoS

MAC

June 6

Do you agree to include overlapping bandwidth sounding in 11bn?

-          The relevant indications and frame exachanges are TBD.

 

Supporting document: ??

Qisheng Huang

Pending

Sounding

PHY

June 6

Do you agree to include overlapping bandwidth sounding in 11bn?

-          The overlapping bandwidth could be negotiated through exchange of invite/response frames before the transmission of UHR NDPA.

-          The sounding bandwidth announced by UHR NDPA might be less than the operating bandwidth of the UHR beamformee.

Supporting document: ??

Qisheng Huang

Pending

Sounding

PHY

June 12

Do you support that Co-BF and Co-SR transmission TXOP shall follow the same frame exchange sequence framework?

-          Co-SR does not need to support EHT eMLSR non-AP STA

 

The reference docs for all the SPs are: [24/412, 25/879]

Sherief Helwa

Pending

CBF/CSR

Joint

June 17

Do you agree to define a new NDP flavor (UHR NDP), that will be designated as OFDMA PPDU, thus be able to support OFDMA puncturing schemes?

Supporting document: 25/694r2

Avner Epstein

Pending

Sounding

Joint

June 17

Do you agree to define a UHR Sounding Operation procedure, that will be based on EHT Sounding Operation but using UHR NDP instead of EHT NDP, in order to be able to perform fresh sounding for Partial BW DL MU-MIMO?

Supporting document: 25/694r2

Avner Epstein

Pending

Sounding

Joint

July 17

SP1: Do you support to include additional information field(s) in the Co-TDMA ICR to what is already present in Draft 0.3 [1]. 

Klaus Doppler

Pending

CTDMA

MAC

July 17

SP2: Do you support to add an information field to the Co-TDMA ICR that the coordinated AP can use to indicate the time duration it would like to be allocated by the sharing AP as part of the Co-TDMA TXOP sharing procedure. The sharing AP can use this information to allocate time to the coordinated AP(s). Note: The indicated time duration to be allocated is a recommendation to the sharing AP.  The PDT already includes the primary AC as a parameter in the ICF to help the polled AP to decide if it has wants to receive part of the TXOP from the sharing AP.

Klaus Doppler

Pending

CTDMA

MAC

July 17

SP: Do you support that:

·          A Shared (Responding) AP may reject a Co-BF/Co-SR transmission or Co-BF sounding invitation received from a Sharing (Initiating) AP.

·          In case of rejection, the Shared (Responding) AP can include the reason for rejection in the Co-BF/Co-SR Response or Co-BF Sounding Response frame.

o    Reasons for rejecting a Co-BF/Co-SR transmission or Co-BF sounding invitation are TBD.

 

Mahmoud Hasabel Naby

Pending

CBF/CSR

Joint

 

--

Alfred Asterjadhi, PhD

IEEE802.11 TGbe/TGbn Chair,

Qualcomm Technologies Inc.

asterjadhi@xxxxxxxxx

aasterja@xxxxxxxxxxxxxxxx

Cell #:    +1 858 263 9445

Office #: +1 858 658 5302

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

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

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

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