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..
|
|
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