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 ?
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
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.
- 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.
- 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
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.
|
|
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
|
|
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
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:
- Give AP3 another allocation after allocating AP2 ?
- Always give maximum alloc to each AP..
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
|
|
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
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
|
|
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
|
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
|