MLO: Acknowledgement Procedure
This document discusses the challenges and proposed solutions for a unified framework to support multi-link operation in IEEE 802.11 networks, focusing on improving block acknowledgment procedures and cross-link Rx status gathering.
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
January 2020 doc.: IEEE 802.11-20/0024r0 MLO: Acknowledgement Procedure Date: 2020-01-06 Name Affiliation Address Phone Email Abhishek Patil Qualcomm Inc. appatil@qti.qualcomm.com George Cherian Qualcomm Inc. Duncan Ho Qualcomm Inc. Alfred Asterjadhi Qualcomm Inc. Submission Abhishek P (Qualcomm), et. al., Slide 1
January 2020 doc.: IEEE 802.11-20/0024r0 Overview Past contributions [1, 2, 3] have discussed the benefits of multi-link operation and the need for a unified framework to support various aspects of the feature. Contributions [2, 4] have proposed to increase BA Bitmap length to at least 1024 to account for increases in peak throughput Further, contributions [2, 4, 5] propose to have a single block ack setup and common sequence number space for multiple links This contribution continues the discussion on multi-link acknowledgement procedure and highlight some of the challenges in gathering cross-link Rx status Submission Slide 2 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 Motivation MLO framework needs to account for MLDs with STAs that do not exchange information instantaneously A STA of an MLD may not have knowledge of the most recently received (or transmitted) MPDUs by another STA of that MLD Hence, unable to provide SIFS based responses for the other STA Time [8] [9] [7] MLD 1 [Tx] (STA A) Link 1 MLD 2 [Rx] (STA C) [1] [2] [3] [4] [5] [6] MLD 1 [Tx] (STA B) Link 2 At the time of ACK, STA D doesn t have knowledge of most recent MPDU(s) Rx-ed at STA C Further MPDUs may be in transit on one link when a BA is being sent on another link MLD 2 [Rx] (STA D) [7] [8] [9] Lag in updating Rx status Data BA [X] Therefore, the multi-link BA framework needs to consider these constraints in the design (MPDU SN=x) Submission Slide 3 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 Baseline BA procedure Today, in a single link case, the originator solicits Rx status for MPDUs that it has transmitted. Recipient STA indicates successful reception for an MPDU by setting the bit position for that MPDU to 1 in the BA bitmap Since the originator knows which MPDUs it has transmitted so far, there is no ambiguity when a 1 or a 0 is received. Contributions [4, 6, 7] have suggested that a single BA could acknowledge MPDUs received on multiple links However, in case of multi-link operation, there is an ambiguity when gathering cross-link Rx-status as we describe in following slides. Submission Slide 4 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 BA procedure with multi-link In multi-link operation, MPDUs are assigned from a common queue to each STA for transmission A STA of an MLD may not have knowledge of the MPDUs owned by another STA for transmission Further, on the Rx-side, a STA may not have knowledge of the most recently received MPDUs by another STA of the MLD There can be a lag in updating the MPDU Rx information cross STAs of an MLD Furthermore, each STA of an MLD may have local retransmit policy or MPDUs may be in transit on one link when BA is being sent on another link. Therefore, a transmitting STA can accurately determine the Rx status only for MPDUs that it had transmitted on its own link A value 1 in the BA Bitmap indicates the MPDU was successfully received While a value 0 indicated the recipient STA has not received the MPDU Submission Slide 5 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 BA procedure with multi-link However, the transmitting STA can t determine the status of an MPDU that it had not transmitted (in its own link), if it receives a value 0 in the BA Bitmap. This is because the STA cannot determine if an MPDU was pending assignment or is yet to be transmitted by another STA of the MLD or is in-transit on another link or is indeed lost. This is true even if the recipient STA provides status of MPDUs received by another STA of its MLD. Therefore, a transmitting STA can, if and when available, only make a determination about the successful reception of an MPDU transmitted by another STA of its MLD Submission Slide 6 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 BA procedure with multi-link The transmitting MLD consolidates (ORs) the BA reports from different STAs to update the common BA scoreboard and make decisions regarding: Advancing the Tx window Retransmitting failed MPDUs determination of an MPDU s failure based on the report from the STA to which the MPDU was allocated Time [8] [9] [7] MLD 1 [Tx] (STA A) Link 1 Bitmap=7:[1 1 1 0 0 0 ...] MLD 2 [Rx] (STA C) Tx MLD (MLD 1) ORs BA reports to build a consolidated view of the Rx status [1] [2] [3] [4] [5] [6] MLD 1 [Tx] (STA B) Link 2 MLD 2 [Rx] (STA D) [7] [8] [9] Bitmap=1:[1 1 1 1 1 1 1 0 0 0 ...] Includes ACK for SN=7 STA D has no knowledge of SN = 8 & 9 Lag in updating Rx status Data [X] BA (MPDU SN=x) Submission Slide 7 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 BA procedure with multi-link In conclusion we propose to follow the baseline BA procedures with the following considerations: Recipient STA of an MLD provides receive status for MPDUs received on the link that it is operating on Additionally a recipient STA of an MLD may provide receive status for an MPDU successfully received by another STA of that MLD Note: A 0 in the received BA Bitmap corresponding to an MPDU not transmitted by a STA doesn t provide any status info. for that MPDU Indicating successful Rx status on behalf of another link: Can help the originator quickly advance the transmit window Can also help in scenarios where a BA was lost Submission Slide 8 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 Summary This contribution highlights the challenges in gathering cross-link receive status and provides directions for determining the success of an MPDU transmitted on any link. Submission Slide 9 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 SP #1 Do you support that the 802.11be amendment shall define mechanism for multi-link operation that enables the following: A STA of a recipient MLD shall provide receive status for MPDUs received on the link that it is operating on and may provide information on successful reception of MPDUs received by another STA of that MLD Y: N: A: Submission Slide 10 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 References [1]: 11-19-0773 Multi-link Operation Framework (Po-Kai Huang - Intel) [2]: 11-19-0823 Multi-Link Aggregation (Abhishek Patil - Qualcomm) [3]: 11-19-0821 multiple band discussion (Liwen Chu - Marvell) [4]: 11-19-1512 Multi-Link acknowledgement (Rojan Panasonic) [5]: 11-19-1856 A-MPDU and BA (Liwen NXP) [6]: 11-19-1532 Discussion on Multi-link Acknowledgement (Ryuichi Sony) [7]: 11-19-1887 Multi-Link acknowledgement (Taewon LG Electronics) [8]: 11-19-1262r6 Specification Framework for TGbe Submission Slide 11 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 APPENDIX Submission Slide 12 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 RECAP [8] Motion 36 A single block ack agreement is negotiated between two MLDs for a TID that may be transmitted over one or more links. NOTE The format of the setup frames is TBD. Motion 37 Sequence numbers are assigned from a common sequence number space shared across multiple links of a MLD, for a TID that may be transmitted to a peer MLD over one or more links. Submission Slide 13 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 Inter-module coordination MAC Addr (M1) MLD 1 MAC-SAP-a MPDU assignment & BA scoreboard maintenance Common MAC BA status MPDU assignment STA x STA y Tx-side BA Data / BAR WM Rx-side Inter-STA Comm. STA p STA q Common MAC MAC-SAP-b MLD 2 MAC Addr (M2) Submission Slide 14 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 OTA Rx status MAC Addr (M1) MLD 1 MAC-SAP-a MPDU assignment & BA scoreboard maintenance Common MAC 6 1 7 2 8 3 STA x STA y 9 4 Tx-side 10 5 OTA (BA Bitmap) 4 8 3 OTA (Data) 7 1 1 0 1 0 0 1 0 0 0 0 0 2 6 1 2 3 4 5 6 7 8 9 10 11 12 1 Rx-side STA p STA q 1 0 1 8 6 7 Common MAC MAC-SAP-b MLD 2 MAC Addr (M2) Submission Slide 15 Abhishek P (Qualcomm), et. al.,
January 2020 doc.: IEEE 802.11-20/0024r0 Current interpretation of bits in Block Ack Bitmap 802.11ax D6.0: If bit position n of the Block Ack Bitmap subfield is 1, it acknowledges receipt of an MPDU with sequence number value SN and fragment number value FN with n = 4 (SN SSN) + FN, where SSN is the value of the Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield and the operations on the sequence numbers are performed modulo 4096. If bit position n of the Block Ack Bitmap subfield is 0, it indicates that the MPDU has not been received. Submission Slide 16 Abhishek P (Qualcomm), et. al.,
