Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Sang, Thank you for the detailed questions and feedback. Please see inline below.
Regards, Dibakar From: SANG GOOK KIM <sanggook.kim@xxxxxxx> Hello Dibakar Thanks for sharing the contribution and your thought for the questions from Rojan below. I have a few more my understanding:
[I interpret questions 1 and 2 as whether we also allow the P2P STA to request an AP to be allocated, followed by TF+P2P exchange as shown in the slides. If so, this is related to the question #3 from
Rojan. We feel its not critical to define new signaling in spec for this purpose as such signaling already exists in spec (e.g., TSPEC) or that some AP implementations can estimate the need based on internal algorithms.
However, if the group feels strongly about it, we can also consider a simple signaling for non-AP STA to indicate presence of P2P traffic to an AP. As a simple example, we can consider a solution similar
to 11-20-463r3 (the SP for which the group passed unanimously today) where a new TID value was used in QoS Control field to signal the presence of P2P traffic. We can also consider other even simpler solutions.]
[Yes, this was just an example. The intention is to allow any frame exchange subject to individual peer’s capabilities. Btw please note that we are not defining the capability exchange between the P2P
STAs as that could be proprietary.] I am supportive of this concept, but we need further solid thought for missing parts. [Thanks for the support of the concept. It seems to me based on both yours and Rojan’s comments the main missing part is about signaling P2P traffic to the AP. Hopefully we now have a complete picture about the
whole concept and scope of the solution-space. We can discuss more offline.]
Best regards, Sang From: Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
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>
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:
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>
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>
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:
Please review offline and share your views. Regards, Dibakar From: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
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>
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>
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:
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>
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]
Hi Alfred, Can you please add the following contribution to the list:
Best regards. Stéphane. From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
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. 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 |