
IEEE 802.11-24/2145r0 Unavailability Information Indication in December 2024
This document discusses the mechanisms and scenarios related to unavailability information indication within IEEE 802.11 networks, focusing on reporting unavailability at the TXOP level and defining frames for indicating availability or unavailability. Various motions and proposals related to unavailability information reporting by non-AP STAs are elaborated, including using BSRP frames and multi-STA BlockAck frames. The document also addresses rules for responding to BSRP Trigger Frames and unsolicited unavailability information indication options.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
December 2024 doc.: IEEE 802.11-24/2145r0 IDC Scenarios and unavailable period indication Date: 2024-12-31 Authors: Name Yingqiao Quan Affiliations Spreadtrum Address Phone email Yingqiao.quan@unisoc.com Yingqiao.quan@gmail.com Xiangxin Gu Spreadtrum Lei Zhou New H3C Submission Slide 1 Yingqiao Quan, Spreadtrum
December 2024 doc.: IEEE 802.11-24/2145r0 Recap. Unavailability information could be used for Co-ex and even for power save. TGbn has passed several motions on TXOP level unavailability information indication and we have following items in SFD [1] [2] : [Motion #30] 11bn defines a mechanism for a non-AP STA to report unavailability at TXOP level and define or reuse/update existing mechanism for a non-AP STA to report long term (periodic) unavailability. [Motion #146] A non-AP STA that is a TXOP responder can indicate in a response frame 1) for how long it will be available, if known and/or 2) whether it will be unavailable after a specific point in time and, if known, for how long The response frame is a multi-STA BlockAck frame sent by the non-AP STA in response to the initial control frame or to MPDUs that solicit an immediate response. [3] and [4] proposed that BSRP frame can be used as ICF to trigger the M-STA BA as ICR indicating the unavailability information. [5] proposes to use BSRP as ICF to indicate availability/unavailability information directly. Submission Slide 2 Yingqiao Quan, Spreadtrum
December 2024 doc.: IEEE 802.11-24/2145r0 response to a BSRP TF We have following rules for the response to a BSRP TF in current SPEC (26.5.5 Buffer status report operation in REVme D7.0) : The non-AP STA shall include in the HE TB PPDU one or more QoS Null frames containing one or more of the following: The QoS Control field(s) with Queue Size subfields for each of the TIDs for which the non- AP STA has queue size to report to the AP. The BSR Control subfield with the Queue Size All subfield indicating the queue size for the ACs, indicated by the ACI Bitmap subfield, for which the non-AP STA has queue size to report to the AP if the AP has indicated its support in the BSR Support subfield of its HE Capabilities element. The non-AP STA shall set Delta TID, Scaling Factor, ACI High, and Queue Size High subfields of the BSR Control subfield as defined in 9.2.4.7.4 (BSR Control). For allowing the solicited unavailability information indication by carrying in a multi-STA BA solicited by a BSRP TF as a ICF, the aggregation rules (A-MPDU context :control response A-MPDU contexts) and the response rules for BSRP might be changed. A QoS-Null data frame with BSR and a multi-STA Block ACK frame with unavailability information will be aggregated in an A- MPDU as a response in a TB PPDU for the BSRP TF. Submission Slide 3 Yingqiao Quan, Spreadtrum
December 2024 doc.: IEEE 802.11-24/2145r0 unsolicited unavailability information indication For unsolicited unavailability information indication, there might be two options at present. 1. BSRP TF 2. Multi-STA BA; Both of them need to change aggregation rules in some cases Both of them can t be acked to make sure the peer get the information Submission Slide 4 Yingqiao Quan, Spreadtrum
December 2024 doc.: IEEE 802.11-24/2145r0 unavailable period indication by (A-)control field [6] has mentioned that a new (A-)control field for IDC Info can be included in QoS Data/Null frames, Management frames (similar to BSR). Indicating unavailable period by A-control field might be an alternative option for both solicited or unsolicited case. -Can be piggyback in QoS Data/Null frames Easier indicate a sudden IDC event during a TXOP. The aggregation rules may not change. -May reduce the signaling overhead. -May be suitable for the burst cases of co-ex event. Submission Slide 5 Yingqiao Quan, Spreadtrum
December 2024 doc.: IEEE 802.11-24/2145r0 unavailable period indication by (A-)control field There are two options for unavailable period indication by A-control field: Opt1. use 9 or more bits to indicate unavailability duration. Imply that the unavailability duration will start after this PPDU or the response PPDU of this PPDU Opt2. use 9*2 bits to indicate unavailability start time and duration [5] [7] . Unavailability duration Unavailability start time Unavailability duration Control ID Control ID 4 bits 9 or more bits 4 bits 9 bits 9 bits Submission Slide 6 Yingqiao Quan, Spreadtrum
December 2024 doc.: IEEE 802.11-24/2145r0 Summary This presentation proposes to use A-Control field for the unavailable period indication. Submission Slide 7 Yingqiao Quan, Spreadtrum
December 2024 doc.: IEEE 802.11-24/2145r0 SP 1 Do you agree to add the following text to the 11bn SFD? A UHR STA can indicate in an A-control field 1) for how long it will be available, if known and/or 2) whether it will be unavailable after a specific point in time and, if known, for how long. Submission Slide 8 Yingqiao Quan, Spreadtrum
December 2024 doc.: IEEE 802.11-24/2145r0 References [1] 11-24-0171-21-00bn-tgbn-motions-list-part-1 [2] 11-24-0209-07-00bn-specification-framework-for-tgbn [3] 11-24-1550-01-00bn-in-device-coexistence-follow-up [4] 11-24-1558-02-00bn-in-device-coexistence-follow-up [5] 11-24-1893-00-00bn-icf-follow-up [6] 11-24-0834-01-00bn-some-details-on-in-device-coexistence [7] 11-24-1974-03-00bn-detailed-text-proposal-on-coexistence Submission Slide 9 Yingqiao Quan, Spreadtrum