Hi Rubayet,
Please find some comments. Thanks for working on the PDT.
Regards,
Dibakar
From: SHIRAKAWA Atsushi <shirakawa.atsushi@MAIL.SHARP>
Sent: Thursday, July 3, 2025 2:17 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN]
回复: [STDS-802-11-TGBN] Updated P2P PDT
Hi Rubayet
I made some response to your comment.
And it seems you did not go through my comment from p25 onwards.
Please check those.
BR.
Atsushi.
From: Rubayet Shafin <r.shafin@xxxxxxxxxxx>
Sent: Thursday, July 3, 2025 5:07 PM
To: 白川淳/主任研究員
<shirakawa.atsushi@mail.sharp>;
STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN]
回复: [STDS-802-11-TGBN] Updated P2P PDT
Hi Atsushi,
Thank you so much for carefully reviewing the document. Appreciate it.
Please find my responses in the attached document. Please feel free to let me know if you have any further comments or questions.
Best
Rubayet
From: SHIRAKAWA Atsushi <shirakawa.atsushi@MAIL.SHARP>
Sent: Wednesday, July 2, 2025 7:53 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN]
回复: [STDS-802-11-TGBN] Updated P2P PDT
Hi Rubayet
Thank you for sharing PDT.
I added some comment in attached file, please find it.
BR.
Atsushi.
From: Pei Zhou <zhoupei36@xxxxxxxxx>
Sent: Wednesday, July 2, 2025 4:59 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN]
回复: [STDS-802-11-TGBN] Updated P2P PDT
Hi
Rubayet,
Thanks for your clarification. I understand that the allocated TXOP duration can be protected by MU-RTS TXS TF and CTS.
Current text in your PDT is
“After sending the CTS …, the TXSPG non-AP STA… shall set the Duration/ID field of its following frames(s) to indicate a NAV end time that is no later than
….” I suppose it means that the TXSPG non-AP STA sets NAV to protect the allocated TXOP duration.
But before the TXSPG non-AP STA transmits its following frame(s), it may
“initiate an EDCA backoff procedure” as stated in the previous email.
My suggestion is that we may add description about the Duration/ID field setting of MU-RTS TXS TF. Because it is not clear whether the EDCA backoff procedure
is already protected.
Best regards,
Pei Zhou
TCL
发件人: Rubayet
Shafin <r.shafin@xxxxxxxxxxx>
发送时间: 2025年7月2日 15:11
收件人: zhoupei36@xxxxxxxxx;
STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] Updated P2P PDT
Hi Pei,
Thank you very much for reviewing the document. Appreciate it.
A brief answer to your question is that TXSPG follows the baseline (11be) TXS procedure (35.2.1.2). Therefore, the entire duration of the TXOP allocated to the P2P group is protected by the NAV set
by other users, derived from the MU-RTS TXS trigger frame sent by the AP. So the other STAs won’t be able to jump in, according to the baseline rules.
Elaborating a bit more-- when the Access Point (AP) transmits the MU-RTS TXS Trigger frame to the P2P group, this frame carries duration information. All STAs within the BSS that correctly receive
this Trigger frame are required to update their intra-BSS NAV based on this duration. This prevents other STAs from attempting to transmit during this period, thereby protecting the allocated TXOP from external contention. Furthermore, a non-AP STA that is
a member of the P2P addressed by the MU-RTS TXS Trigger frame shall transmit a Clear-to-Send (CTS) frame in response. This CTS frame, following the MU-RTS, further reinforces the NAV setting for any STAs that might not have heard the initial Trigger frame,
thereby further extending the protection of the TXOP across the BSS.
Hope this clarifies. Please do not hesitate if you have any further comments or questions.
Best
Rubayet
From: Pei Zhou <zhoupei36@xxxxxxxxx>
Sent: Tuesday, July 1, 2025 4:55 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] 回复: [STDS-802-11-TGBN] Updated P2P PDT
|
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.
|
Hi Jonghoe and Rubayet,
Thanks for sharing this P2P PDT. I have one comment regarding the 37.16.1.3 Non-AP STA behavior.
In the last paragraph of page 9,
“the non-AP STA … may initiate an EDCA backoff procedure for the transmission of one or more non-TB PPDUs
…”.
If non-AP STA use EDCA backoff procedure here, which means the channel may be idle for a while, so how to make sure that the current TXOP not be contended by
other STAs?
Best regards,
Pei Zhou
TCL
发件人: Jonghoe
Koo <jh89.koo@xxxxxxxxxxx>
发送时间: 2025年6月30日 20:59
收件人:
STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] Updated P2P PDT
Hi Alfred,
Could you please indicate in the agenda that this document (P2P PDT doc
11-25/764) resolves 14 CIDs when adding it to the agenda?
The Abstract text box in the cover sheet of the uploaded document seems to be positioned in a way that obscures the list of CIDs that the
document aims to address.
As attached, this document proposes resolutions for following 14 CIDs as part of CC50 comments:
229, 230, 849, 875 876, 1997, 2078, 2167, 2521, 2573, 3113, 3129, 3130, 3621
Dear all,
As shared by Rubayet and as described in the revision history of this document, we have made efforts to reflect as many technical comments
as possible that we have received after the first version of the P2P PDT document was shared.
As part of these effort, numerous parts have been modified or removed.
We kindly request that members actively share your feedbacks on the revised contents as well, so that the document can undergo sufficient
offline discussions and revisions before it is discussed.
Any editorial and/or technical comments would be greatly appreciated.
Regards,
Jonghoe KOO
Communications Standards Research Team,
Samsung Research
Samsung Electronics
From: Rubayet Shafin <r.shafin@xxxxxxxxxxx>
Sent: Saturday, June 28, 2025 2:11 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] Updated P2P PDT
Hi Alfred,
Could you please add P2P PDT doc
11-25/764 to the MAC queue for SP?
Dear P2P TTTs,
Hope you all are doing well. I wanted to share some updates on the P2P PDT. Based on extensive discussions and feedback received from numerous members, either
offline, online, or F2F (thanks to you all!), I have made significant changes to address the comments. One major change is that provisioning-related procedures have been entirely removed from the TXSPG for simplicity and ease of implementation. On the other
hand, the Co-CR is now harmonized with the MAPC framework PDT. A summary of the changes is as follows—
TXSPG--
- Removed the Provisioning part and all provisioning-related
procedures/frames/elements
- Added the MIB variable for TXSPG
- Added an entry for the definition of TXSPG in clause 3.2
- Removed Mode-3 based TXOP allocation procedure. Added text to reuse mode TXS
Mode-2
- Added that only AP can assign the Group ID.
- Removed the new Direction field value (3—P2P group) in the QoS characteristics
element; re-using value 2 (Direct Link)
- Added that only the TXSPG requesting STA can send the SCS request for the P2P
group;
- Added that only the TXSPG requesting STA can return the TXOP
- Added that TXSPG shall follow the TXS fairness rules introduced in 11bn for CTDMA
- Changed the AID12 addressee to be the generic P2P group (AID12 = 2047);
Co-CR:
- Harmonized the text with the MAPC framework PDT (11-25/599r16--Giovanni).
- Moved to the subclause 37.13.2 (Procedures for specific multi-AP coordination
schemes) the content of the detailed Co-CR operation between Co-CR requesting AP and Co-CR responding AP described in the subclause (Coordinated channel recommendation (Co-CR)) proposed by this document
- As a part of Co-CR profile, specified the format of MAPC Per-Scheme Info field
and the format of the Co-CR Parameter Set field that is contained in the MAPC Request Parameter Set field
The revised PDT can be found
here and is also attached. I would appreciate it if you could review the document and let me know whether you have any comments on the revised PDT.
Best
Rubayet
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