| Hi Behnam, Thanks for your feedback. Please see responses below. Thanks, Mohamed On Jun 20, 2025, at 1:41 PM, Behnam Dezfouli (Nokia) <00003e2cd320f8c4-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Mohamed, Please find a few more additional comments on the LLI PDT below: 1. The end of Page 15 and the beginning of Page 16 do not clarify whether the two tasks, (a) establishing an SCS stream and (b) requesting LLI for that stream, are accomplished through a single SCS negotiation or two separate ones. If both tasks are achieved through a single SCS negotiation, and the LLI request is made by setting the Minimum and Maximum Service Interval fields to the reserved value of 0, then the stream would not be eligible for UL scheduling. However, in practice, there are traffic streams that can benefit significantly from UL scheduling while still using LLI when necessary. Alternatively, if the two tasks involve separate SCS negotiations, one for SCS establishment and another for the LLI request, then the PDT must specify certain details, such as reusing the same SCSID in the SCS Descriptor Element of the LLI Request negotiation to associate the two requests.
[MA] once SCS request with value not equal to zero can be used to enable both LLI and AP scheduling. LLI Request =1 would enable LLI with minimum and maximum interval equal to zero or non zero value
2. Section 9.3.1.8.6.2 specifies that a STA may set the Low Latency Indication subfield to 0 to indicate the absence of buffered LL traffic. However, it is unclear what benefit there is in explicitly indicating the lack of such traffic. Doing so requires the inclusion of a Per AID TID Info field, which adds an overhead of 8 octets. Therefore, it would be more efficient for a STA to include a Per AID TID Info field only when it actually has LL traffic to report.
[MA] STA can decide not to add it or add it with value zero. Some implementations prefer to have a fixed length for the control response frame for hardware issues.
3. While I agree that using a single bit to indicate LLI can simplify decision-making by APs, we should not prohibit the inclusion of additional information that can enable more efficient decisions when available. This means that, following the one-bit LLI indication, a STA may optionally include supplementary data to support more informed scheduling decisions. The AP, based on its processing capabilities, may choose to either consider or ignore this additional information. For instance, consider a scenario where a non-AP STA signals the presence of LL traffic but does not indicate the amount or urgency of that traffic. In such cases, the AP might need to perform the BSRP/BSR procedure before allocating UL resources, which introduces delay. As an alternative, we could allow the inclusion of BSR/EBSR information within the 4-octet BA Bitmap field of the Per AID TID Info field. Including such data could improve scheduling efficiency. Without it, the tradeoffs between single-user and multi-user UL operation become more difficult to assess and optimize. Additionally, the current PDT does not address LL P2P traffic. One or more additional bits following the LLI bit could be used to indicate the destination type of the LL traffic. This would enable the AP to make more informed decisions regarding UL scheduling, TXOP termination, or other relevant actions.
[MA] this can be further discussed for future addition based on members preferences
Thanks, Behnam | CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. |
Hi Mohamed and Rae, Thanks for the discussion. From my understanding, the plan is to utilize Link Reconfiguration as a general enablement. Specifically "A UHR non-AP STA that supports the LLI mode and that intends to enable or disable the LLI mode shall follow the procedure defined in 37.X (Procedure for operating mode and parameter updates)." and Gaurang's doc 25/0882 also provides clear guidance on this matter. I believe we can effectively enable the LLI mode by leveraging the 11be SCS in conjunction with OMP, while incorporating feedback in the MBA. This approach should suffice, also mentioned by Rae. Besides, I have some concerns that the SCS may become overloaded, which could complicate the implementation. Regarding the AP's behavior, it seems that the AP can already utilize SCS with BSR to trigger additional actions. I’m not seeing a significant difference in the AP's behavior when sending LLI with out any enhancement on AP's behavior, especially since it is closely tied to SCS. Regards, Yue From: Mohamed Abouelseoud <mohamed.a.abouelseoud@xxxxxxxxx>
Sent: Thursday, June 19, 2025 9:26 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] Defer request on LLI PDT Hi Rae, Once the AP receives the LLI requested bit, the LLI mode is enabled Actions from AP side: AP sends ICF to solicit LLI if it decided to do so and to allocate time for BA to carry the feedback whether in the immediate response M-BA or in the ICR. Actions from non-AP STA side: STA starts sending M-BA with feedback as an immediate response instead of Ack or BA. STA adds the LLI feedback in the M-BA Allocating time for LLI feedback is needed and will only happen in the LLI mode is enabled for at least one SCS Thanks for providing the PDT. in the curretn PDT, there is no AP cation after it receives the LLI Requested bit, which makes the SCS procedure meaningless. No matter the non-AP STA uses the SCS procedure, it can still send the LLI in the M-BA frame. So the AP action corresponding the LLI requested bit and the non-AP further behaviour is missing. I am kind of agree with Yue that some traffic needs fast transmission not only due to its serivce characteristics, maybe due to the congestioned queue or insufficient internal resource. So using the SCS procedure can be optional? ---- Replied Message ---- From | | Date | 6/18/2025 11:31 | To | | Subject | Re: [STDS-802-11-TGBN] Defer request on LLI PDT |
Hi Mohamed, I’m happy to go over the PDT, but I’d like to explain why I believe a deferral would be beneficial. Regarding the CIDs related to the Enablement procedure, are you still planning to use SCS? As we’ve raised multiple times, using SCS introduces ambiguity — it assumes detailed traffic characteristics are known in advance, while LLI is intended to address urgent, unpredictable traffic. We’ve submitted a contribution (25/0495) with further explanation on why SCS may not be the appropriate container for LLI enablement, which has not yet been presented. For the CIDs addressing subsequent actions by the TXOP holder, we believe more discussion is needed around what mechanisms can ensure the AP appropriately considers the LLI. As for the CIDs on More Indications, many commenters have proposed enhancements to convey more information/Feedbacks. I think it would be helpful to align further on what can be included and how. Given the above areas, I believe it would be more productive to make additional progress and reach better alignment before presenting the PDT. Regards, Yue | Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. |
Hi Yup, This contribution has been on the server and shared with you for more than a month. I would like to move forward with the presentation and we can have discussion and see which CIDs you need to discuss further.
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
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
|