| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Romain, all, The latest version R6 has been uploaded for review. https://mentor.ieee.org/802.11/dcn/26/11-26-0037-06-00bn-mac-cr-lb291-p2p-lli.docx Thank you for the discussion. I have one clarification question regarding the case you described. If the STA is not a member of the P2P group, would the STA need to indicate traffic of the entire group or just its own P2P traffic to another
STA? Would it left to the STA to decide as an implementation decision? As discussed offline, the current CR is mainly intended to clarify the link scope of the P2P LLI that the spec may not be clear, rather than to define how an individual STA determines whether to indicate its or the group’s low latency traffic.
Of course, we can discuss the implementation considerations further if needed. Please let me know if I have misunderstood your concern or if you have any questions about the updated text.
Regards, Yue From: GUIGNARD Romain <Romain.Guignard@xxxxxxxxxxxx>
Hi Yue, Thank you for your feedback and for updating the proposed resolution to my comment.
However, I couldn’t find the change you described in the r4 of your document. Regarding the BSRP, I’m not proposing to add any additional information to the trigger frame. My understanding is that the BSRP includes the AID12 of the STA from which the AP is
requesting feedback. Therefore, the AP could include the AID12 associated with the P2P group that was previously provided by the AP to the TXSPG requesting STA.
However, if the BSRP includes the AID12 of the P2P group, we need to clarify that only the TXSPG requesting STA should respond to this AP’s request. This behavior would be similar
to the SCS procedure. Overall the TXSPG requesting STA should remain the sole interface between the AP and the P2P group. This would prevent multiple P2P STAs belonging to the same P2P group, and addressed through the same AID12, from responding to the same
BSRP. This was the main purpose of my comment in its second part. I do not believe there is a need for any additional signaling; rather, I believe we only need to clarify the expected
behavior of the TXSPG requesting STA when the AP solicits feedback for a P2P group.
Best regards, Romain From: Sunshine Qi <sunshine.qi@xxxxxxxxxxx>
Hi Romain, Thank you for your questions and suggestions. I have revised the resolution text as follows for r4: The commenter identifies an issue regarding how a non-AP STA indicates P2P LLI when the P2P traffic of a P2P group is associated with the SCS streams. The text has been revised to clarify the indication mechanism, so that the P2P traffic
can be identified and the corresponding resources can be allocated appropriately.
To answer the question, the current spec does not preclude a TXSPG requesting STA to set LLI requested field to 1 if it is also a LLI non-AP STA.
Regarding the question, my understanding is that the current spec does not preclude a TXSPG requesting STA from setting the LLI Requested field to 1 when it also operates as an LLI STA. Thus, I am not sure that an explicit clarification
on this point is necessary in this CR. Similarly, I am not yet convinced that additional information needs to be included in the trigger frame at this stage. Since the QoS parameters have already been negotiated through the SCS procedure, the AP should have sufficient information
to determine how to solicit the LLI feedback and allocate the corresponding resources. This may therefore be left to the AP’s scheduling decision.
That said, I would be happy to consider any specific ambiguity in the current text that you believe still needs to be addressed.
More comments are welcomed from the group. Best regards, Yue From: GUIGNARD Romain <Romain.Guignard@xxxxxxxxxxxx>
Hi Yue, Thank you for your contribution and for handling my CID #9359. I think your CR does not fully address my comment regarding the support of the TXSPG feature by the P2P LLI.
My point was to clarify if the P2P LLI can be used by the TXSPG requesting STA to indicate that its P2P group has pending P2P traffic to transmit. While the current 11bn draft does not appear to prevent this usage, it would be beneficial to explicitly clarify that it is allowed especially since the TXSPG is a newly introduced
concept. A simple note in 37.22.1 could state that the P2P LLI can be used by a TXSPG requesting STA to indicate that the P2P group of which the non-AP STA is a member of has pending P2P traffic to transmit. In addition, I believe a clarification is needed regarding the use of the ICF by the AP to trigger LLI feedback. Specifically, it would be helpful to state that the AP can trigger
LLI feedback from a P2P group by addressing the ICF to the TXSPG requesting STA and including the AID12 of the P2P group in the ICF. The spec has stated that AP may initiate the frame exchanges by transmitting to the LLI non-AP STA an ICF that allows to carry the LLI feedback in the ICR frame.
Regarding the AID12 in the ICF, the current spec
Could you please let me know your thoughts on these points? Do you agree that these clarifications would help avoid ambiguity in the specification, or am I missing something in your
proposed CR? Thank you for your feedback. Best regards, From: Sunshine Qi <sunshine.qi@xxxxxxxxxxx>
Dear all, Thank you for the discussion during the meeting on the past Friday. The latest version r4 has been uploaded for your review.
https://mentor.ieee.org/802.11/dcn/26/11-26-0037-04-00bn-mac-cr-lb291-p2p-lli.docx We would like to clarify that the
proposal does not mandate any AP behavior. The proposed change is only a transmitter-side clarification. How the AP uses the received indication still remains implementation-specific.
The current text states that a non-AP STA may indicate its traffic related to one or more SCS streams, while when multiple P2P SCS streams are associated with different links, the link scope of “one or more
SCS streams” is not stated explicitly. The intent is to clarify that, a P2P LLI transmitted on one link does not imply pending P2P traffic associated with another link, since the corresponding P2P transmission is link-specific.
This differs from UL case. This is particularly relevant because the UL and P2P LLI clauses use similar wording, while their transmission characteristics are different.
------------------- For example ----------------------- P2P SCS1 is associated with Link 1. P2P SCS2 is associated with Link 2. If a P2P LLI is transmitted on Link 1, it is unclear 1) whether the indication is limited to pending traffic for SCS1, 2) or it may also represent pending traffic for SCS2.
We clarify that a P2P LLI transmitted on a link represents pending traffic related to one ore more P2P SCS streams associated with that link.
Comments and feedback are welcome. Regards, Yue Qi (Samsung) To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1 To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1 To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1 To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1 |