Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Dmitry, Stephane, Thanks for your explanation. It’s clear that the intention is only to create a TB P2P communication. @ Dmitry, What I want to see is the benefit compared to current P2P technology, I think the following explanation is based on WIFI forward mechanism. IMHO, except increasing the burden on AP side, I don’t see any benefit compared to other P2P SPEC. I’m confused why we need such new P2P mechanism. Actually, as the use cases you mentioned, I prefer that STAs set up P2P connection by themselves, and AP can spatial reuse the TXOP in some scenarios. For instance, both the
P2P peers are far from AP, and AP can perform SR operation in this moment(OBSS PD SR-NON SRG). Besides, For the case2, How the green STA decode the TB frame sent from blue AP if they’re not in the same BSS. See the following P2P concurrent device graph in current SPEC, it can meet the case1 and case2 mentioned in your contribution, and also meet the SR operation.
Thanks Best Regards Jay Yang From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Hi Yang, I think the benefits are very obvious. It is like asking what are the benefits of TB over EDCA.
There is not much you need to simulate to prove benefits of triggered p2p.
Normally, all the traffic in the network goes through the AP.
But, there are scenarios where source and destination of a traffic are within same network, for example, wireless printing or picture transfer from camera to computer or camera
remote control over WiFi , or wireless docking. W/o p2p this traffic first go from STA 1 to AP, than from AP to STA2. Which mean you have to spend 2x time (i.e. 2x more latency) to deliver this traffic and occupy medium
twice (i.e. reduction of overall network performance). Also, STA 1 and STA2 can be close to each other but far away from an AP meaning STA1 to AP and/or AP to STA2 effective TX rate much lower than STA1 to STA2.
Quite often in order to deliver such traffic STAs organize their own BSS which act as “interferer” to the main BSS. So from our perspective, having p2p link under control if a single AP beneficial from many perspective – trigged operation reduce latency, increase system capacity and/or eliminate
additional contentions with p2p links (i.e. better network control). Existing Spec mechanisms address only part of this problems but not all of them. Dmitry From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Dibakar, Thanks for your explanation. I wonder whether it’s a more efficient way to let the AP take part in the P2P communication between two STAs?(for instance, as mentioned in your
contribution, AP need to send BSR frame to understand the buffered data status on STAs side, and then send a trig frame to let the P2P STAs perform TX/RX operation ). It’s not clear whether the new mechanism can get the latency and TP benefit as expected compared
to current Spec. Do you have some simulate data on this? Thanks Best Regards Jay Yang From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Jay, Thanks for your question. Unfortunately I am not sure what you mean by “similar rule to previous one”. I was therefore wondering if you could please clarify so we can better
understand the question. Note that the goal of the proposal is not to replace any existing IEEE or non-IEEE defined P2P mechanisms (i.e., P2P device discovery, direct link establishment, security between
P2P STAs etc.) by inventing yet another P2P mechanism from scratch. We simply want to enable a way in which the AP can trigger a peer STA for P2P communication and thereby improve latency performance for both the AP and STA. We expect this feature to work
with existing P2P mechanisms that are defined in IEEE or other forums and requires only few small changes to the 11ax TB mechanism.
Regards, Dibakar From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Arik,Dibakar, Could you have a look the SPEC “Wi-Fi Peer-to-Peer (P2P) Technical Specification” published by WFA in 2010, I think the case2 mentioned in your
presentation also be covered. And almost all of cellphones have already support such technology in the market. Why do we create a similar rule to the previous one? I hope some experts can explain the benefit compared to the previous P2P SPEC. Thanks Best Regards Jay Yang From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Arik, Thanks for the clarifications. For the topology 2, our intention is to just highlight the case where only one peer STA is associated to the triggering AP. Soft-AP is a clear
example. The other example (w green AP) is also possible where we assume the two peers have some proprietary discovery mechanism to find each other. I agree with you that in this case
the green STA can only talk to the blue peer STA when it is not already talking to its associated AP. However, I am not sure if this requires us to define a new notification scheme (e.g., in addition to going to PS mode) or even need to mention it. Note that
there are already cases in IEEE where non-AP STA performs operation with other STAs (APs). For example, in 11az and baseline FTM a non-AP STA can perform 11az TB or NTB ranging with another unassociated AP or non-AP STA at any time; whether the STA explicitly
informs its associated AP prior to a range measurement exchange is left out of scope. I assume therefore, we do not need to define it in spec here either for P2P.
To reach consensus and for simplicity, maybe we can remove the part about ESS from the slide and just highlight that only one peer STA is associated to triggering AP.
Regards, Dibakar From: Arik Klein <arik.klein@xxxxxxxxxx>
Hi Dibakar, Thanks for the clarification.
Please See my comments inline. Regards, Arik From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Arik and Jeongki, Sorry I missed the question in chat.
“@dibakar - in this case you propose to have a "managed" P2P (as opposed to the 11ax/current P2P), so if you add TF from the triggerring AP so the P2P wil be allocated RU and
time so no other session will take place by this AP with any other STA, the same applies for the second BSS (where the DLP STA is associated). Otherwise - you do no improve anything with your proposal.....”
[Arik Klein]
ESS does not mean that both AP are managed by the same entity (which entity?!) – according to 802.11REVmd D3.3 section 4.3.5.2 Extended service set (ESS): the large
coverage network, the ESS is defined as “An ESS is the union of the infrastructure BSSs with the same SSID connected by a DS. The ESS does not include the DS”
[Arik Klein]
That’s correct. “@dibakar, the existing TDLS mechanism can cover the case 2?”
Regards, Dibakar From: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Hi Rojan, Following the feedbacks we received, we created a new revision
11-20-813r3 of the document, to highlight the simplicity of the proposed solution for R1. This revision is a
joint effort from several contributors, to merge
the two documents dealing with the triggered P2P communications (11-20-871r2
, and
11-20-813r0.), and to present a common view of the solution, capturing the discussion
we had offline and on this reflector. The straw poll text has been slightly amended to explicitly mention the scope of the solution for R1 (triggered time sharing for a single peer station associated to the AP),
and we added a note to clarify our intentions regarding some related elements that are out of the scope of this joint contribution : “Note :
“ Best regards. Stéphane. From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Hi Dibakar, Yes, if you can add such a Note, that would be really helpful. Regards, Rojan From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Rojan, Thanks a lot for the constructive feedback. From all the comments so far it seems like we are all aligned that we can have a simple solution for signaling existence of P2P traffic using existing mechanisms or a small
tweak to them. If we run a SP, do you prefer to add a note to emphasize this. For example, “signaling of P2P traffic presence is TBD. Existing mechanisms may be used (e.g., TSPEC, a TID value > 7..)”. Regarding “TBD response frame”, okay, we can remove this until we have more discussion on that. I have removed it in the latest revision.
Regards, Dibakar From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Hi Dibakar and all, Thanks for your clarifications and inputs. I agree with Chao Chun that we should reuse existing mechanisms as much as possible, please consider making use of TSPEC, QTP etc. if they can serve your purpose. Reusing existing
mechanisms would make this proposal much easier to accept. I think just having a non-AP STA indicate a P2P capability is not enough for AP to know whether there really is on-going P2P traffic in the BSS. I think your suggestion of using TSPEC (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.) is good and should be used for
non-AP STA to signal its intention of using P2P traffic to AP, this would also allow AP to refuse such traffic if needed. The TSPEC TID/TSID can then be used to signal P2P buffer report to the AP, we don’t need to define a new mechanism. QTP is also useful
to quiet the channel for the P2P traffic, the triggered P2P exchange could happen with a QTP. Regarding the “TBD response frame”, AP can still recover the medium within PIFS even without it, for
e.g. if it doesn’t detect the Data frame within SIFS. I don’t understand why that wouldn’t be as clean; unless there’s a compelling reason, I would prefer it to be taken out for now.
Regards, Rojan From: SANG GOOK KIM <sanggook.kim@xxxxxxx>
Hello Chao-Chun. Thanks for your expert suggestion. I got your point. Best regards, Sang From: Chao-Chun Wang [mailto: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
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 |