Legacy MU-MIMO Acknowledgement and Power Save Procedure

Legacy MU-MIMO Acknowledgement and Power Save Procedure
Slide Note
Embed
Share

This document discusses the legacy MU-MIMO acknowledgement and power save procedures in IEEE 802.11-17/1690r0. It addresses issues related to BAR/BA exchange overhead, reducing duration of MU cycles, and throughput impact. The procedures outline flow optimizations and ordering for efficient BAR/BA exchanges among STAs, highlighting specific case limitations and examples.

  • IEEE 802.11
  • MU-MIMO
  • Legacy
  • Power Save
  • Procedures

Uploaded on Feb 18, 2025 | 0 Views


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


  1. November 2017 doc.: IEEE 802.11-17/1690r0 Advanced MU-MIMO acknowledgement and PS flow Authors: Name Affiliation Address Phone Email Turgeneva 30, Nizhny Novgorod, 603024, Russia +7 (831) 2969444 ilya.bolotin@intel.com Ilya Bolotin Intel oren.kedem@intel.com Oren Kedem Intel cheng.chen@intel.com Cheng Chen Intel alexander.maltsev@intel.com Alexander Maltsev Intel artyom.lomayev@intel.com Artyom Lomayev Intel Submission Slide 1 Ilya Bolotin, Intel

  2. November 2017 doc.: IEEE 802.11-17/1690r0 Legacy MU acknowledgment procedure SIFS SIFS SIFS SIFS SIFS AP EDMG MU PPDU BAR BAR STA 1 BA/Ack STA 2 BA/Ack STA 3 BA/Ack ISSUE 1: BAR/BA exchange causes large overhead increasing the duration of one MU cycle (MU PPDU transmission and its acknowledgement) and therefore significantly reducing throughput BAR/BA exchange overhead, % PSDU, bytes 64 bitmap BA 94.76 93.92 82.23 256 bitmap BA 95.10 94.31 83.26 512 Bitmap BA 95.41 94.66 84.17 1024 Bitmap BA 95.76 95.07 85.24 2048 Bitmap (25+256) 96.38 95.78 87.20 256 4096 65536 Submission Slide 2 Ilya Bolotin, Intel

  3. November 2017 doc.: IEEE 802.11-17/1690r0 Legacy MU acknowledgment procedure To reduce the BAR/BA exchange overhead the following flow could be used (allowed in 11ac): SIFS SIFS SIFS SIFS SIFS SIFS EDMG MU PPDU EDMG MU PPDU EDMG MU PPDU BAR (STA1) BAR (STA2) AP STA 1 ... BA/Ack STA 2 BA/Ack STA 3 BUT!!! adopted MU-MIMO power save does not allow such flow (see next slide) Submission Slide 3 Ilya Bolotin, Intel

  4. November 2017 doc.: IEEE 802.11-17/1690r0 Legacy MU-MIMO power save Each STA knows its specific order of BAR/BA exchange. The BAR/BA order shall be the same as the AIDs appear in the group description present in the EDMG Group ID Set element corresponding to this MU group. This ordered BAR/BA exchange sequence enables each STA to know when it should wake up to receive the corresponding BAR frame addressed to it. SIFS SIFS SIFS SIFS SIFS SIFS A-MPDU for STA 1 pad A-MPDU for STA 2 pad BAR BAR BAR A-MPDU for STA 3 AckTimeout STA 1 in doze STA 1 in doze BA/Ack STA 2 in doze BA/Ack STA 3 in doze AckTimeout STA 3 in doze BA/Ack ISSUE 2: Such approach limits the MU-MIMO acknowledgement flow to only one case: when all STAs are requested for BA after each MU PPDU Submission Slide 4 Ilya Bolotin, Intel

  5. November 2017 doc.: IEEE 802.11-17/1690r0 Legacy MU-MIMO power save Example: PCP/AP elicits BA only from STA 1 SIFS SIFS SIFS A-MPDU for STA 1 pad A-MPDU for STA 1 pad MISSED (because STA2 in doze) A-MPDU for STA 2 pad A-MPDU for STA 2 pad BAR A-MPDU for STA 3 A-MPDU for STA 3 STA 1 in doze BA/Ack STA 2 in doze STA 3 in doze STA 2 is not aware of the exact transmission start time of the next MU PPDU. Submission Slide 5 Ilya Bolotin, Intel

  6. November 2017 doc.: IEEE 802.11-17/1690r0 Explicitly scheduled BA. MU acknowledgment and PS flow To resolve both issues we propose the following MU-MIMO acknowledgement and PS flow: BAR frames are removed from acknowledgement flow in order to reduce overhead. STAs transmit their BA during time slots scheduled by PCP/AP for each STA PCP/AP schedules time slots for BA transmission for each STA considering knowledge about the BA type for each STA. AP informs each STA its BA Transmission Time (BATT) by including scheduling information into the same MU PPDU The scheduling information allows STA to wake up exactly for its BA transmission and MU PPDU reception performing power save in the most effective and accurate way Submission Slide 6 Ilya Bolotin, Intel

  7. November 2017 doc.: IEEE 802.11-17/1690r0 Explicitly scheduled BA. MU acknowledgment and PS flow Scheduling information is STAspecific and should include: BATT Start offset which indicates the beginning of time slot provided by AP for STA to transmit its BA Next PPDU Start offset which indicates the moment when STA should begin listening AP. At this moment AP may either start transmitting the next MU PPDU in current sequence of MU- MIMO transmission or transmit BAR to STA in case if solicited BAwas not received. Next PPDU Start offset At this moment STA2 should start transmitting its BA STA2 BATT Start offset A-MPDU (STA 1) Preamble A-MPDU (STA 1) Preamble + Header + Header A-MPDU (STA 2) A-MPDU (STA 2) AP A-MPDU (STA 3) A-MPDU (STA 3) STA3 STA1 STA1 STA2 STA2 EDMG STA1 BA STA1 in doze STA1 in doze At this moment STA2 should be awake and listen to PCP/AP EDMG STA2 BA STA2 in doze STA2 in doze EDMG STA3 BA STA3 in doze STA3 in doze Submission Slide 7 Ilya Bolotin, Intel

  8. November 2017 doc.: IEEE 802.11-17/1690r0 Explicitly scheduled BA. Scheduling signaling. MU-MIMO Block Ack scheduling information can be delivered from AP to STAs by a special control frame included in the A-MPDU for corresponding STA Block Ack Scheduling Information Frame Control Duration RA TA FCS Octets 2 2 6 6 3 4 BATT Start Offset Next PPDU Start offset EOF Reserved Bits 9 9 1 5 Subfields BATT Start Offset and Next PPDU Start offset indicate the corresponding values (defined previously) in microseconds. The EOF flag indicates that the data part of A-MPDU is over and after correct reception of this Control frame STAmay stop receiving Submission Slide 8 Ilya Bolotin, Intel

  9. November 2017 doc.: IEEE 802.11-17/1690r0 Explicitly scheduled BA. Schedule signaling. The main drawback of this method is low robustness: the Schedule frame may be lost in aggregation. The straightforward solution is repetition of this frame in different parts of A-MPDU (such reliability increase is already used for Block Ack in 11ad, see Table 9-425). E.g., it can be repeated in the beginning and in the end of A-MPDU, or it can be repeated several times in the end of A-MPDU as a rough padding to align durations of A-MPDU for different MU-MIMO streams. Example of A-MPDU transmitted within EDMG MU PPDU Block Ack Schedule (EOF=0) Block Ack Schedule (EOF=1) Block Ack Schedule (EOF=1) QoS Data frame QoS Data frame QoS Data frame MAC Pad ... When RX MAC detects EOF, it can inform RX PHY to stop receiving Scheduling signaling overhead (two frames), % 0.19 0.16 0.05 PSDU, bytes 256 4096 65536 Targeting 0.01 frame error rate we have 0.0001 probability that two Block Ack Schedule frames will not be received correctly Submission Slide 9 Ilya Bolotin, Intel

  10. November 2017 doc.: IEEE 802.11-17/1690r0 Ack policy Combination 01 in Ack Policy subfield of QoS Data frame is not used in 11ad We propose to use Ack policy = 01 for QoS Data frames transmitted in indicate that BA should be sent by STA in a scheduled time slot EDMG MU-MIMO to Submission Slide 10 Ilya Bolotin, Intel

  11. November 2017 Proposed vs. Legacy flow performance comparison Assumptions: Amount of data (PSDU) for all STAs in MU-MIMO is same AP transmits each MU-MIMO stream using MCS 12 (4620 Mbps) BAR and BA are transmitted using MCS 4 (1155 Mbps) STAs send BA of minimal length (25+8 bytes) doc.: IEEE 802.11-17/1690r0 Equivalent throughput gain of Proposed flow over Legacy flow PS gain of Proposed flow over Legacy flow The performance gains are lower for the cases when acknowledgement overhead is lower small number of STAs in MU group and big size of data frames. Submission Slide 11 Ilya Bolotin, Intel

  12. November 2017 Proposed vs. Legacy flow performance comparison Assumptions: Amount of data (PSDU) for all STAs in MU-MIMO is same AP transmits each MU-MIMO stream using MCS 12 (4620 Mbps) BAR and BA are transmitted using MCS 4 (1155 Mbps) STAs send BA of maximal length (25+256 bytes) doc.: IEEE 802.11-17/1690r0 Equivalent throughput gain of Proposed flow over Legacy flow PS gain of Proposed flow over Legacy flow Submission Slide 12 Ilya Bolotin, Intel

  13. November 2017 doc.: IEEE 802.11-17/1690r0 Proposed vs. Legacy flow MAX throughput estimation Assumption: STAs send BA of minimal length (25+8 bytes) 8 STAs in MU-MIMO EDMG SC MCS20 (8662.5 Mbps) is used for all STAs in MU-MIMO CB=4 PSDU, bytes AP Throughput (Legacy flow), Gbps AP Throughput (Proposed flow)*, Gbps AP Throughput (Proposed flow+)*, Gbps 0.04 0.17 0.66 2.62 10.20 36.74 0.10 (+134%) 0.39 (+134%) 1.54 (+133%) 6.06 (+131%) 22.74 (+123%) 73.00 (+99%) 0.35 (+758%) 1.41 (+755%) 5.57 (+744%) 21.02 (+702%) 68.49 (+572%) 157.34 (+328%) 64 256 1024 4096 16384 65536 *Proposed flow all 8 STAs are requested for BA Proposed flow+ only one STA is requested for BA (see Slide #3) Submission Slide 13 Ilya Bolotin, Intel

  14. November 2017 doc.: IEEE 802.11-17/1690r0 Straw poll Do you agree to include the text changes proposed in 11-17- 1691-00-00ay-Draft text for acknowledgement and PS flow to the spec draft? Yes No Abstain advanced MU-MIMO Submission Slide 14 Ilya Bolotin, Intel

Related


More Related Content