Hi Sindhu,
I like the idea that the originator transmit a sequence of short PPDUs without any intervening gap instead of transmitting a long and uninterruptible PPDU. It provides much flexibility,
especially for transmission of low latency traffic. However, the efficiency would degrade since several PHY headers are inserted compared to a single, long PPDU. And I believe EHT PHY Header would be a larger overhead ( > 40us).
It seems to me that PHY headers except the first one can also be omitted (optionally present) . In most of cases, the payload of each PPDU is best effort traffic and there is no
need to change MCS for successive PPDUs. The originator can set the duration in the first PHY header to be the sum duration of all successive PPDUs. This PPDU sequence would have high spectral efficiency and is interruptible. If low latency traffic arrives
during transmission of this PPDU sequence, it can be inserted to the sequence(in this case, maybe a PHY header should be added to refresh duration)
Of course, Even if the originator does not support low latency traffic, PHY header can still be added to any intermediate PPDU if the originator want to wait for BAs or earn some
time margin.
My two cents
Boyce
发件人: Sindhu Verma [mailto:000011381223f2e2-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2021年1月22日
1:26
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [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
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