Coexistence Protocols for UHR in IEEE 802.11-24 Standard
Explore the Coexistence Protocols for Ultra-High Rate (UHR) in the IEEE 802.11-24 standard, focusing on time unavailability and reporting structures to enhance Wi-Fi and CoEx activities coexistence, ensuring efficient resource sharing among different technologies and improving overall system complexity and reliability.
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
July 2024 doc.: IEEE 802.11-24/0543r1 Coexistence Protocols for UHR Follow Up Date: 2024-07-08 Authors: Name Affiliation Address Phone Email Sherief Helwa shelwa@qti.qualcomm.com George Cherian Alfred Asterjadhi Abhishek Patil Qualcomm Inc. Gaurang Naik Duncan Ho Sanket Kalamkar Giovanni Chisci Submission Slide 1 Sherief Helwa, et. al.
July 2024 doc.: IEEE 802.11-24/0543r1 Introduction STAs supporting multiple wireless technologies can share resources among different technologies to achieve Lower system complexity More efficient use of the available resources Improving coexistence in UHR is important; absence of which leads to Data losses, increased delays, reduced reliability, etc. Resources of interest from a coexistence perspective are: 1. Time: Link becomes unavailable at certain times 2. Frequencies/Antennas: affects the available BW and NSS 3. Other Resources : Other resources such as a shared processor, HW accelerators, memory units, etc. In this contribution, we focus on time unavailability and discuss the proposed frame structures for reporting such unavailability to the peer STA(s) to avoid conflicts between Wi-Fi and CoEx activities. Submission Slide 2 Sherief Helwa, Qualcomm Inc.
July 2024 doc.: IEEE 802.11-24/0543r1 CoEx Unavailability Reporting Framework While operating in the CoEx mode, intermittent activity of CoEx technologies take place in the background. The 11bn CoEx feature adds functionality aiming for no overlap to take place between Wi-Fi data transmissions and CoEx activity. To do so, the Wi-Fi peer STA of the CoEx STA initiates its TXOP with an ICF soliciting unavailability information from the CoEx STA. The CoEx STA responds by including its expected future unavailability in an ICR frame. The peer STA can then take this unavailability information into consideration while planning for its PPDU(s) transmission. Additionally, the CoEx STA can share its updated unavailability information in CRF at the end of the TXOP. Solicit unavailability info Report unavailability info Unavailability period Peer STA PPDU ICF STA with IDC ICR CRF Original intended PPDU end time Report unavailability info and send BA bitmap Available Unavailable Submission Slide 3 Sherief Helwa, Qualcomm Inc.
July 2024 doc.: IEEE 802.11-24/0543r1 CoEx Unavailability Information Two main parameters constitute the needed unavailability information: Unavailability Period Start Time: Reported as a TSF value. For example, use 1 octet field length to report the TSF value with granularity of 128 us. That can give up to ~32 ms of time ahead. Unavailability Period Duration: For example, use a 1 octet field length and granularity of 64 us. That can support duration values up to ~16 ms. Solicit Report unavailability info Unavailability period unavailability info Peer STA PPDU ICF STA with IDC ICR CRF Original intended PPDU end time Report unavailability info and send BA bitmap Available Unavailable Submission Slide 4 Sherief Helwa, Qualcomm Inc.
July 2024 doc.: IEEE 802.11-24/0543r1 ICR Frame Choice Few requirements to take into consideration: Must have room to bear CoEx unavailability information. Flexibility is a key factor since: ICR frame may be required to carry other types of info, e.g., control frame protection-related information. Additionally, other features might have different requirements, hence the benefit of a flexible design. Reuse of a current control frame is a great plus. By reviewing the structure of the existing control frames, Multi-STA BA (M-BA) is seen to be the best candidate frame: Includes the Per AID TID Info field which have plenty of room in replacement of the BA bitmap information. Very flexible with capability to include multiple Per AID TID Info fields each having a variable size BA Bitmap subfield. An already existing frame. Submission Slide 5 Sherief Helwa, Qualcomm Inc.
July 2024 doc.: IEEE 802.11-24/0543r1 ICR Frame Design The Multi-STA BA frame has the following format that allows for multiple Per AID TID Info fields to be included in the BA Information field. The proposed format is to use one Per AID TID Info field to report the unavailability information. Having the flexibility of adding multiple of these fields, we can add one for reporting unavailability info and others for sending acknowledgment information (e.g., BA bitmap(s)) in CRF. Frame Control Duration RA TA BA Control BA Information FCS Octets: 2 2 6 6 2 variable 4 ... Block Ack Starting Sequence Control Block Ack Starting Sequence Control AID TID Info Block Ack Bitmap AID TID Info Block Ack Bitmap 0, 4, 8, 16, 32, 64, or 128 0, 4, 8, 16, 32, 64, or 128 Octets: 2 0 or 2 2 0 or 2 Per AID TID Info Per AID TID Info Submission Slide 6 Sherief Helwa, Qualcomm Inc.
July 2024 doc.: IEEE 802.11-24/0543r1 ICR Frame Design Each Per AID TID Info field can be further broken down as follows: AID TID Info (need to define a Per AID TID Info for control feedback): 11 bits to indicate the AID 1 bit for Ack Type 4 bits for TID Starting Sequence Control (reuse to indicate the feedback info control): Fragment Number: Indicating the length of the BlockAck Bitmap. Re-use to indicate the length of the Control Feedback field Starting Sequence Number: Used to indicate the starting sequence number It will be reserved in the Per AID TID Info for control feedback We can use some of these bits to indicate the feedback type (e.g. coex) Combined are used to indicate if this Per AID TID Info is sent for Ack, BA, control feedback info, etc. Per AID TID Info Block Ack Starting Sequence Control AID TID Info Block Ack Bitmap Octets: 2 2 4 Unavailability period start time Unavailability period duration Fragment Number Starting Sequence Number Reserved Bits: 4 12 Bits: 16 8 8 Submission Slide 7 Sherief Helwa, Qualcomm Inc.
July 2024 doc.: IEEE 802.11-24/0543r1 ICR Frame Design The repurposed BA Bitmap field carrying Unavailability Information can be further broken down as follows: Unavailability Period Start Time: Encoded in a 1-octet subfield. Unavailability Period Duration: Encoded in a 1-octet subfield. Plus 2 reserved octets for possible further unavailability info. Per AID TID Info Block Ack Starting Sequence Control AID TID Info Block Ack Bitmap Octets: 2 2 4 Unavailability period start time Unavailability period duration Fragment Number Starting Sequence Number Reserved Bits: 4 12 Bits: 16 8 8 Submission Slide 8 Sherief Helwa, Qualcomm Inc.
July 2024 doc.: IEEE 802.11-24/0543r1 Conclusion The CoEx time unavailability scenario was discussed highlighting unavailability information reporting mechanism. M-BA is proposed to be the ICR frame due to its extreme flexibility and other favorable features. Unavailability information is proposed to be reported in terms of: Unavailability Period Start Time. Unavailability Period Duration. A proposed M-BA modified frame structure is discussed to include Coex unavailability information in the Per AID TID Info field. Submission Slide 9 Sherief Helwa, Qualcomm Inc.
July 2024 doc.: IEEE 802.11-24/0543r1 Straw Poll 1 Do you support defining the following fields for unavailability indication in M-STA BA frames: An Unavailability Target Start Time field defined as the TSF time at which the STA becomes unavailable (duration and resolution TBD, expectation is to use a portion of the TSF) An Unavailability Duration field defined as the time during which the STA is unavailable (field may be not present or set to an unknown value) Submission Slide 10 Sherief Helwa, Qualcomm Inc.
July 2024 doc.: IEEE 802.11-24/0543r1 Straw Poll 2 Do you support to define a special Feedback Per AID TID Info field (name TBD) that carries control feedback in the M-BA frame? The control feedback (i.e. unavailability indication) is carried instead of the BlockAck Bitmap in that Feedback Per AID TID Info field. The Ack Type subfield of the Per AID TID Info field is set to 0 and the TID subfield of the Per AID TID Info field is set to a reserved value. The AID11 subfield of this Per AID TID Info field is set to a reserved TBD value if the control feedback is addressed to all STAs or to the AID11 that identifies the intended recipient STA. The Starting Sequence Number field of this Per AID TID Info field is reserved. Submission Slide 11 Sherief Helwa, Qualcomm Inc.
