Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Jay, Let me synthetize our view: As Dibakar explained, we only intend to address the way a peer station, associated to an AP, obtains a txop for its P2P transmission.
This is, as today, independent from other mechanisms dealing with P2P session management (discovery, establishment, etc.), so we do not need nor intend to address those mechanisms. The peer sta also have to inform the AP of its P2P traffic needs, but only small modifications of existing 802.11 mechanisms may be
required (e.g TSPEC, BSR, …) This is why we believe that the necessary spec modifications are limited and can fit in R1. Regards. Stéphane. 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 |