Re: [STDS-802-11-TGBE] Clarification question on 813r0

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi Jay,

We deeply appreciate your detailed comments which we hope has been very useful to help the group have a clearer understanding of this topic. Thanks for the support on at least the case with both P2P STAs being in the same BSS. We agree we could focus on this case in R1 for simplicity if we discover the second use-case is more complicated.

The reason we wanted to bring up the use-case #2 is to highlight that the TB P2P mechanism only requires one non-AP STA to be associated to the AP. The actual peer-to-peer link setup by that STA need not be known at the AP. This is also in-line with language we currently have in the spec for some other P2P topics (e.g., for QTP, we have “Quiet time period (QTP) is an optional feature that defines a period of time (QTP period) 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.”).

Now, onto your specific question on whether the blue STA is a soft-AP, it depends on whether the current definition of peer-to-peer links includes the soft-AP case. We think current language in IEEE spec is a bit vague on that. If it does, then we cover the soft-AP case. If it does not, it can still cover other P2P mechanisms defined for non-AP STAs inside or outside IEEE. So, in IEEEE maybe we don’t need to say anything about the role of the peers inside the P2P link and just use the baseline language and call them peers. If the soft-AP case is not covered with this language, we can bring it in R2.

Regards,

Dibakar

From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Wednesday, July 1, 2020 1:40 AM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Clarification question on 813r0

Hi Dibakar,

Thanks for your explanation. It makes sense. I think I can support you for the intention of TB P2P within same BSS.

As to the TB P2P across different BSS, It’s not very clear through your following comment.

The blue AP simply allocates rest of its TXOP to the blue STA. After that it is the prerogative of the blue STA to transmit packets to green STA. If the blue STA is a soft-AP it may be able to trigger the green STA and get UL packets.

<Jay> Do you mean the blue STA has two roles, one is STA connected to blue AP, other one is Soft-AP connected with green STA?

Thanks

Best Regards

Jay Yang

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: 2020年7月1日 11:14
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Clarification question on 813r0

Hi Jay,

I think there is some misunderstanding with the concept so let me try to explain what Dmitry is saying. I apologize for the long email.

Consider a typical pre-11ax BSS with one AP and N STAs associated to it with all of them having non-P2P traffic in DL and UL respectively. Now, we know that as N or traffic load increases the performance of the BSS goes down due to collision and contention as all the N+1 contend for medium all the time. That’s why 11ax proposed triggered operations (including unicast TFs) to allow STAs to transmit in UL to AP when triggered. Intuitively, this improves the BSS performance by reducing contention among the STAs and also can lead to better QoS management at the AP side in such scenarios. Note that to improve efficiency of the trigger mechanism we have developed other tools such as BSR. They have an overhead for sure but for high load scenarios it is expected that there is benefit even after accounting for the overhead of TF and feedback collection.

Now, consider the same scenario as above but pretend that one of the above N STAs has P2P traffic instead of UL traffic to the associating AP. In this case with current mechanism the STA has no choice but to do regular EDCA for such transmissions which again re-creates the problem above. This is the gap we are trying to close with this proposal by allowing the AP to trigger even P2P transmissions. As you can see this is merely a very small extension to 11ax TF mechanism.

Clearly, as with regular 11ax TB operation the benefits are not universal. For example, if N = 1 and/or load in UL is low, I agree with you that regular EDCA might give you good performance in both scenarios above. However, as N or load increases and collision or contentions become the bottleneck, then we can expect trigger operations to give you better performance as in 11ax. This is mostly just a regular tradeoff between TB operations and EDCA.

On your other question: “Besides, For the case2, How the green STA decode the TB frame sent from blue AP if they’re not in the same BSS.” , the green STA does not decode the TF from AP. The blue AP simply allocates rest of its TXOP to the blue STA. After that it is the prerogative of the blue STA to transmit packets to green STA. If the blue STA is a soft-AP it may be able to trigger the green STA and get UL packets. Note that we are not proposing to reinvent another P2P mechanism like TDLS or the ones proposed in other WiFi non-802.11 forums (as you show below). We expect those mechanisms already define how the peer STAs find each other, security sessions established between them, any P2P schedules established between them etc. As such there is no need to redefine them again.

Regards,

Dibakar

From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Tuesday, June 30, 2020 7:09 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0

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.

A screenshot of a cell phone

Description automatically generated

Thanks

Best Regards

Jay Yang

From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Sent: 2020年7月1日 3:58
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Clarification question on 813r0

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>
Sent: Monday, June 29, 2020 11:08 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0

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>
Sent: 2020年6月30日 12:28
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Clarification question on 813r0

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>
Sent: Monday, June 29, 2020 6:24 PM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Clarification question on 813r0

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>
Sent: 2020年6月30日 2:55
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] Clarification question on 813r0

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>
Sent: Monday, June 29, 2020 10:05 AM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Clarification question on 813r0

Hi Dibakar,

Thanks for the clarification.

Please See my comments inline.

Regards,

Arik

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: יום ב 29 יוני 2020 19:13
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0

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.....”

Thanks for clarifying the question. I understand it a bit better now. The topology in case 2 actually cover two cases:

One where the green STA is connected to another AP that is part of the same ESS as the blue AP. In this case we assume that since both APs are managed by same entity, the TF transmission can be done efficiently using some proprietary coordination algorithm at the AP side without affecting any other session.

[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”
So if you propose that the two APs in your diagram (blue on green) are managed by the same entity it might be either part of Multi AP set or any other proprietary solution.

If you refer to first option (Multi AP) – you need to show explicitly the frame exchange among the P2P triggering AP (blue AP in your diagram) and the “Another AP in the ESS” (i.e. green AP in your diagram) prior to the P2P session.
However in the latter option – it is very hard to see how you can assure that the green AP will not interfere with any frame exchange to the P2P session in which the DLP STA (i.e. the green non-AP STA in the diagram) is currently involved….

Unless the DLP STA has to explicitly indicate its associated AP that it is going to participate within a P2P session. If this is the case – you should explicitly include it in your diagrams.

One where the green STA is connected to the blue STA (soft-AP). In this case clearly there is no simultaneous session issue.

[Arik Klein] That’s correct.

“@dibakar, the existing TDLS mechanism can cover the case 2?”

The TDLS mechanism does not cover Case 2. Do you see a problem with this approach ? Note that how the P2P STAs discover each other is out of scope of 11be and can be done with some other existing non-IEEE or proprietary protocol.

Regards,

Dibakar

From: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Sent: Tuesday, June 23, 2020 5:09 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0

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 :

Type of trigger frame is TBD.
Signaling to the AP of P2P traffic needs, may be based on existing mechanisms (e.g., TSPEC, a TID value > 7, BSR ..). Exact signaling is TBD.
Peer STA may not be allowed to use EDCA for some time after being triggered (e.g., by extending MU-EDCA rules).

“

Best regards.

Stéphane.

From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: vendredi 12 juin 2020 04:37
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0

Hi Dibakar,

Yes, if you can add such a Note, that would be really helpful.

Regards,

Rojan

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Thursday, June 11, 2020 10:17 PM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Clarification question on 813r0

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>
Sent: Wednesday, June 10, 2020 8:16 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0

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>
Sent: Thursday, June 11, 2020 6:45 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarification question on 813r0

Hello Chao-Chun.

Thanks for your expert suggestion. I got your point.

Best regards,

Sang

From: Chao-Chun Wang [mailto:ccwangg@xxxxxxxxx]
Sent: Wednesday, June 10, 2020 2:47 PM
To: SANG GOOK KIM/Team Leader/LGEUS NA Research & Standards(sanggook.kim@xxxxxxx)
Cc: 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.

asterjadhi@xxxxxxxxx

aasterja@xxxxxxxxxxxxxxxx

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