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