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.
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.
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.
Thanks,
Behnam
From:
Sunshine Qi <sunshine.qi@xxxxxxxxxxx>
Date: Thursday, June 19, 2025 at 7:52 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] Defer request on LLI PDT
|
|
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 ----
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
|