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