Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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> 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>
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:
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 |