Hello everyone,
I just want to add few lines to Stephane’s email to highlight QTP /TF P2P differences:
As Stephane already mentioned QTP is EDCA based and does not guarantee anything
The existing spec text for QTP say:
QTP AP distribute QTP “schedule” to all devices, but even other QTP STAs may ignore QTP period.
QTP AP send QTP setup frame, but once again, it is not shall, it is “may”. And even if AP send QPT setup frame, a STA still need to do EDCA after that to obtain the channel. Contention inside QTP has no prioritization, i.e. done with regular EDCA parameters.
QTP SP is unprotected from anyone ( common problem of all scheduled/negotiated service periods) – a 3-rd party STA may start transmission before QTP SP and completely occupy start of negotiated QTP.
So, altogether, even if a particular STA negotiated QTP there is zero guarantee it successfully get it. Which mean QTP mostly work for “not important , low priority traffic” when network load is relatively low.
Also, QTP SP is limited to a specific traffic stream.
TF P2P on the other hand is free of this.
AP always send TF to start P2P TXOP.
Because AP send TF, it effectively provide protection of TXOP from other devices in a network.
STA is free to send anything to anyone in provided P2P TXOP
Since it is “AP controlled”, medium control/collision control, etc. is more effective comparing to EDCA.
It is suitable for all types of a traffic - from BE to delay sensitive.
So, to my perspective, although the do look alike, in fact they are different and serve different purpose.
Dmitry
From: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Sent: Thursday, June 11, 2020 12:43 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0
Hello Chao-Chun,
Thank you for reminding people of the existence of the QTP mechanism, I will use this perfect occasion to highlight the need for this new concept that is triggered P2P, and why we should have both mechanisms.
The fundamental difference between QTP and triggered P2P, is that QTP is based on EDCA medium access, while triggered P2P is obviously based on triggered medium access.
Comparing QTP to triggered P2P is like comparing EDCA and MU UL. Both are useful, but for different network conditions (traffic load, number of STAs, OBSS interferences, etc.), and this up to the AP to decide the best access scheme to apply.
11ax defined a new medium access to deal with high density issues (collision, congestion, etc.), that are still valid. But unfortunately, P2P traffic is currently not supported by this mechanism, so peer stations still have to fight against the other STAs including the AP to access the medium (this is EDCA right ?).
QTP doesn’t address the same issue and let the full control on stations to try to access the medium using EDCA.
As you mentioned, “Quiet time period (QTP) is an optional feature that defines a period of time(#24439) that is intended to be used primarily for […]“.
So the AP doesn’t really acquire a time period, but broadcasts an indication of time periods that it recommends for P2P traffic. HE STAs may or may not respect this indication (QTP support is an optional feature), and of course legacy or OBSS stations will definitely not (and compete against P2P).
The scheme we propose is a continuation of what 11ax initiated : give more possibility to the AP to reduce collisions and congestion, by sharing its obtained TxOp to its associated stations to send traffic (only UL in 11ax).
To answer Sang question, we do not intend to reinvent the wheel, and to define, a new set of frames nor a new protocol to negotiate a time period.
If a peer station decides to request the AP for transmission opportunities, the STA only have to use existing mechanisms to indicate its need to the AP.
Today, 11ax already defines several mechanism for a STA to indicate its needs to the AP, and we do not intend to create another one.
Just to mention two of its : TSPEC requires no modification because it already contains all the elements to characterize a stream (including the stream direction = P2P), and BSR may need an adaptation to indicate P2P direction.
Regards.
Stéphane.
From: Chao-Chun Wang <ccwangg@xxxxxxxxx>
Sent: mercredi 10 juin 2020 23:47
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0
Sang,
>> On the other hand, STA may initiate P2P transmission by requesting the permission to AP. If so, can your contribution address that?
This is a good question and in case you are not aware, there is a similar feature "Quiet HE STA in an HE BSS" in 11ax, clause 26.17.5, already supports the operation.
The name may not be doing justice but the feature is specifically designed to support P2P operations and can be easily enhanced to support 11BE BSS.
Please review the clause.
Quote:
"Quiet time period (QTP) is an optional feature that defines a period of time(#24439) that is intended to be
used primarily for the exchange of specific frames between a STA requesting a QTP and its peers using
peer-to-peer links. "
WIth QTP, the AP acquires a time duration (could be periodic) for a specific type of P2P operation (upon request) and allows the P2P operation has a better opportunity to access the channel by requesting HE STAs which are not participating in the P2P operation to remain quiet if possible. Other than QTP is using a "setup frame" not a trigger frame, the operation flow is exactly the same as proposed by Dibakar.
I would suggest not reinventing the wheel when there is already a feature in the 11ax specification.
QTP can be enhanced/revised to address issues unique to 11BE.
Regards.
Chao-Chun
On Wed, Jun 10, 2020 at 1:53 PM SANG GOOK KIM <sanggook.kim@xxxxxxx> wrote:
Hello Dibakar
Thanks for sharing the contribution and your thought for the questions from Rojan below.
I have a few more my understanding:
1. Based on your contribution, it seems that P2P transmission is initiated by AP. Is it correct? On the other hand, STA may initiate P2P transmission by requesting the permission to AP. If so, can your contribution address that?
2. Even though, you are focusing on data transmission aspect, it is important for AP to know the intention for P2P transmission from STA(s) with that capability. Otherwise, the resource(s) may be wasted.
3. Peer STA may not know the channel between it and other STA for P2P transmission. In slide 6, there is a designation for “ Data from peer STA to other peer”. Can this include the frame exchanges for channel estimation?
I am supportive of this concept, but we need further solid thought for missing parts.
Best regards,
Sang
From: Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
Sent: Wednesday, June 10, 2020 9:23 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0
Hi Rojan,
Thank you for reviewing the document and the valuable feedback. Please see my response inline below.
Regards,
Dibakar
From: rojan.chitrakar@xxxxxxxxxxxxxxxx <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Tuesday, June 9, 2020 6:43 PM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: Clarification question on 813r0
Hi Dibakar,
Thanks for sharing. Few questions:
1) Slide 6: Why is the TBD response frame from peer STA required? Doesn’t the subsequent Data frame suffice? Why is this different from the case of TB PPDUs?
[DD: We were thinking of (a) having a clear signaling to the AP about whether the allocation is going to be used and (b) maintain the 11ax TB operation principle where STA responds in SIFS time to the triggering AP. The mechanism may also work without the Ack part in which case the AP can recover after PIFS if it does not detect energy in medium but that may not be as clean. If there is a huge objection, we can take this part out in next revision until we have more discussion offline.]
2) Slide 6: can you elaborate the sentence “Peer STA uses the allocation for any purpose including peer-to-peer communication.”? E.g. can the allocation be used for uplink transmissions to the AP? I think this will complicate the procedure since now the AP is unsure what to expect.
[DD: We were thinking that the purpose of the TF was simply to grant resource to the peer STA and note that the peer STA is free to transmit any type of frame in that time. Clearly, this does not work if peer STA transmits HE/EHT TB PPDU to AP but works if the peer simply transmits regular SU packets to the AP. However, since the focus of this submission is P2P communication, I agree to remove this text in next revision.]
3) The contribution doesn’t address the issue of how the AP knows when to share the TXOP for the peer STAs. In fact how is the AP even aware of the existence of P2P STAs in the BSS? E.g. TDLP setup frames are transparent to the AP since they are encapsulated in Data frames. Also, BSR reports will likely need special consideration for P2P traffic, right?
[DD: We were trying to focus on just the main feature of frame exchange and did not bring the other discussions here. However, we think only the following are needed beyond whats captured in the slides:
- Basic capability exchange: during association, STA and AP discover each others’ TB P2P capability. We perhaps do not need to say anything about how the P2P STAs find each other as that can be a proprietary or non-IEEE protocol.
- Dynamic resource-request: In general, something equivalent to BSR may be all we need. This can be as simple as using a frame whose QoS Ctrl field has TID > 7 or a new A-Ctrl field at worst. However, we don’t think this is very critical since the usage of BSR is optional in 11ax as well. The AP may as well have an internal scheduling algorithm that allocates resource to P2P STA by observing history of past transmissions without defining new signaling in the spec. There are also other existing things in spec, such as TSPEC with Direction subfield set to “01”, that can be used by some implementations to signal P2P traffic.]
I am supportive of the use case but I think it is important to address #3 as well before we can decide whether this is really as simple as portraited.
[DD: Thank you for the support on the use-case. Please let us know if issue #3 is addressed.]
Regards,
Rojan
From: rojan.chitrakar@xxxxxxxxxxxxxxxx <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Tuesday, June 9, 2020 6:43 PM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: Clarification question on 813r0
Hi Dibakar,
Thanks for sharing. Few questions:
1) Slide 6: Why is the TBD response frame from peer STA required? Doesn’t the subsequent Data frame suffice? Why is this different from the case of TB PPDUs?
2) Slide 6: can you elaborate the sentence “Peer STA uses the allocation for any purpose including peer-to-peer communication.”? E.g. can the allocation be used for uplink transmissions to the AP? I think this will complicate the procedure since now the AP is unsure what to expect.
3) The contribution doesn’t address the issue of how the AP knows when to share the TXOP for the peer STAs. In fact how is the AP even aware of the existence of P2P STAs in the BSS? E.g. TDLP setup frames are transparent to the AP since they are encapsulated in Data frames. Also, BSR reports will likely need special consideration for P2P traffic, right?
I am supportive of the use case but I think it is important to address #3 as well before we can decide whether this is really as simple as portraited.
Regards,
Rojan
From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Wednesday, June 10, 2020 2:20 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0
Hi Stephane and others,
We also think that the Triggered P2P is a very useful feature for supporting P2P applications and improving the overall QoS performance of the BSS in 11be. In order to achieve this in Release 1 without significant spec additions and delaying the timeline, we have uploaded a presentation 11-20-871r1 proposing very simple Trigger based P2P operation. Overall, our thoughts seem to be aligned with what Stephane has. The main features are following:
- Limit scope of trigger based P2P for just the cases where the peer STA is associated to triggering AP (slide 5). This is then similar to TDLS use-cases.
- To simplify AP’s channel access mechanism, allocate either the entire TXOP to a P2P STA or the rest of the TXOP to a peer STA.
Please review offline and share your views.
Regards,
Dibakar
From: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Sent: Thursday, May 28, 2020 10:48 AM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: Clarification question on 813r0
Hi Dibakar,
I see your point, and I agree not to limit the mechanism to the cascading.
I also clarify that at least in R1, the scheduled station is associated to the AP (even if its peer is potentially outside of the BSS)
So I propose to amend my SP text as follow.
“Do you support that 11be defines a procedure for an AP to share a part of the obtained TXOP for peer-to-peer (STA-to-STA) frame exchanges by signaling an RU for P2P communication in a trigger frame, the “UL Length” field specifying the allocated time for the peer to peer communication, and the RU being allocated to a non-AP STA associated to the AP?
Note: The trigger frame may be included in a cascading sequence.”
Best regards.
Stéphane.
From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: jeudi 28 mai 2020 16:17
To: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: Clarification question on 813r0
Hi Stephane,
Thank you for providing the clarification below on the cascade sequence.
At a high-level, we are supportive of this overall simplified sequence for R1 as it requires minimal change in spec while significantly improving medium efficiency and potentially reducing peak latency. Based on the discussion below though we suggest revising the SP text to allow both cascade and non-cascade sequence.
Preferably we will like to remove reference to the Cascade sequence altogether since its more of an implementation choice at AP. We can perhaps instead focus on limiting the scope of the triggered P2P in R1 (e.g., limit only to associated peer STA,…). What do you think ?
Regards,
Dibakar
From: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Sent: Thursday, May 28, 2020 2:51 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0
Hi Ross,
Thank you for your question.
I think this up to the AP to include the TF triggering with a P2P RU in a cascading sequence or not.
So yes, a simplified sequence as you mention is possible.
However, I think that including a TF for P2P transmission in a cascading sequence provides additional benefits:
- The AP have more flexibility to share a TxOp for UL, DL, or P2P.
- By using additional information like a “More TF” information, a P2P station can avoid immediate ack from its peer (and then save multiple SIFS overhead) if it is confident that another opportunity will come later in the same TxOp (for instance another time slot allocated to the other peer).
-
So, to me, the TF triggering a P2P transmission can be in or out of the scope of a cascading sequence, but have more benefits in a cascading sequence.
Best regards.
Stéphane.
From: Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx>
Sent: mardi 26 mai 2020 03:10
To: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Clarification question on 813r0
Hi Stephane,
Thanks for preparing the contribution. Could you clarify if the whole (not part of) TXOP can be shared to the triggered P2P transmission or not? In other words, does it have to be combined with MU cascading sequence in slide 4? How about a simple procedure like this?
PS: I usually attend PHY calls, so may not have the chance to ask questions after your presentation. That’s why I send the clarification question here in advance. Thanks.
regards
于健 Ross Yu
Huawei Technologies
发件人: BARON Stephane [mailto:Stephane.BARON@xxxxxxxxxxxx]
发送时间: 2020年5月26日 2:55
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] TGbe Conf Calls [May-July 2020]: Call For Submissions
Hi Alfred,
Can you please add the following contribution to the list:
- 11-20/0813r0 : triggered p2p transmissions follow up (Stephane Baron, Canon), MAC : Medium Access
Best regards.
Stéphane.
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: dimanche 10 mai 2020 20:14
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] TGbe Conf Calls [May-July 2020]: Call For Submissions
Hello all,
This is a call for submissions for the upcoming teleconference calls meeting.
Please let me know if you have any items to be added to the agenda by sending me an e-mail with a request using the format below:
- DCN-Presentation Title (Author, Affiliation), Topic
Also please ensure that the presentation is uploaded at least one week prior to the conference call as I will include the links to the presentations in the Submission's list. If the contribution is not uploaded by that time then it may not be included in the list.
PS - There is no need to send an additional request for contributions that are already present in the conf call queue as they will be imported by default to the Back-Logged Submission's List.
Best Regards,
Alfred
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
Office #: +1 858 658 5302
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
