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