Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGBE] Discussion on 11-20/0362r4 (Proposals on AMPDU-BA mechanisms)

Hi All,

 

I had presented the following document in a TGbe MAC call: https://mentor.ieee.org/802.11/dcn/20/11-20-0362-04-00be-proposals-on-ampdu-ba-mechanisms.pptx

 

There were several questions some of which could not be addressed due to lack of time. We have collated the questions below and inserted our responses. Please add anything else that is missed:

  • Handling of latency-sensitive traffic: 
    • There seemed to be a misunderstanding among delegates that the contribution proposes to delay the acknowledgement for latency-sensitive data. 
    • Slide 14 of the presentation describes a solution where anticipating the arrival of latency-sensitive data, the transmitter assembles a sequence of shorter duration PPDUs with existing BE traffic instead of a single long PPDU (as is common for transmitters to send) . Whenever the latency-sensitive data arrives, at the end of the ongoing PPDU, the transmitter inserts the PPDU containing the latency-sensitive data and elicits the BA. The right hand side diagram on slide 14 only illustrates how the latency-sensitive packet can be inserted. It does not say that the ACK/BA for latency-sensitive data should be delayed. The transmitter can stop concatenating any back-to-back PPDUs after the latency-sensitive packet is transmitted which will elicit an immediate ACK
    • Multi-TID aggregation in a single PPDU was suggested by some delegates as an alternative. However, it does not satisfy the purpose described above
      • The PHY header of the PPDU cannot be changed after transmission and so, the transmitter would need to replace an existing MPDU in a PPDU whose transmission is ongoing, with a latency-sensitive MPDU and without changing the overall PPDU length
      • Even if such an insertion in an ongoing PPDU was possible, it would not be possible to end it prematurely and elicit a BA
      • Latency-sensitive traffic typically has a lower target BLER and therefore, may occasionally need a lower MCS than what can be supported for best effort data. Multi-TID aggregations doesnâ??t allow it.
  • Link adaptation:
    • There was again some misunderstanding that the contribution proposes to assist link adaptation by delaying the acknowledgement. That is not the case
    • The contribution proposes that the transmitter be optionally allowed to send back-to-back PPDUs without any gaps each of which can have a different MCS/NSS and then get a consolidated feedback for all of them. The PPDUs can be short and the loss of efficiency due to having short PPDUs can be minimized by omitting SIFS gaps and having back to back PPDUs. This will allow  faster convergence of the link adaptation algorithm.
  • Omission of SIFS between PPDUs:
    • There was a comment that omitting SIFS between PPDUs does not add much efficiency compared to the case where the PPDUs are sent with SIFS gap between them and without eliciting intermediate acknowledgements. 
    • The proportion of overhead due to SIFS can be significant depending on the length of the smaller duration PPDUs that the transmitter chooses to transmit.
    • For example, if the transmitter intends to choose to transmit PPDUs not longer than 200us in a TXOP of length 6ms.  The additional overhead due to having a SIFS gap between PPDUs is going to be 8%. This can be avoided by omitting the SIFS gaps
    • We checked the device implementation that it is possible at the PHY and MAC to transmit and receive back-to-back PPDUs with possibly different MCS/NSS and without any SIFS gap between back-to-back PPDUs in the same direction. Further, as the proposal is to make this feature optional, a device that supports it can indicate the support via a capability indication.  
  • Selective omission of acknowledgement response by the receiver:
    • This was another component of the proposal in which even though the transmitter indicates that it needs an immediate acknowledgement, the receiver can selectively omit the acknowledgement response based on other limitations like IDC or processing constraints. In such cases, the proposal allows the transmitter to attribute the lack of  acknowledgment to the occurrence of such constraints at the receiver; and  to continue to utilize the remaining TXOP.
  • Sync packets in video:
    • There was a comment that the proposed mechanism can help in transmission of sync packets in video. We agree that this proposal can be used to enable more robust transmission of any intermediate frame in a sequence of frames by using a lower MCS/NSS. The overhead of doing so will be reduced by omission of SIFS.

 

Please let me know your comments.

 

Regards,

Sindhu

 


This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature