1. Proposals on Latency Reduction
Month Year
doc.: IEEE yy/xxxxr0
January 2020
Proposals on Latency Reduction
Date:
Authors:
Name
Affiliations
Address
Phone
Shubhodeep Adhikari
Broadcom
Sindhu Verma
Matthew Fischer
Vinko Erceg
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
January 2020
Abstract
This contribution discusses proposals to reduce latency in with a focus on supporting low latency traffic.
John Doe, Some Company

3. Month Year
doc.: IEEE yy/xxxxr0
January 2020
Proposal 1: Semi persistent allocation of narrow bandwidth resources at the band edges of a BSS
Proposal: Expedited transmission of low latency data by semi-persistently allocating narrow bandwidth resources. These resources:
Can be allocated within the TXOP of an AP or a non-AP STA and can be used to transmit low latency data. 
Will occupy narrow bandwidths, if possible at the two edges of the occupied bandwidth of the BSS, in order to increase diversity. 
Support time and frequency multiplexing of low latency data to/from multiple STAs. The multiplexing can be made via orthogonal or quasi orthogonal codes.
Can be shared across BSSs via inter-BSS coordination. This can also reduce contention/collision for transmission within such resources.
John Doe, Some Company

4. Proposal 2: TXOP sharing between non-AP STAs and AP
Month Year
doc.: IEEE yy/xxxxr0
January 2020
Proposal 2: TXOP sharing between non-AP STAs and AP
Proposal: TXOP sharing between non-AP STAs and AP to reduce the number of channel access attempts and more efficient utilization of a non-AP TXOP.
In :
In normal operation, only an AP can share its TXOP with its clients with SIFS delay. This is known to increase transmission efficiency by reducing channel access at the clients to transmit UL data.
The Reverse Direction (RD) protocol allows TXOP sharing between an RD Initiator and Responder, where the Initiator can be a non-AP STA. However, the protocol allows only a limited version of such TXOP sharing. For example, the RD Responder (say an AP) can transmit data only to the RD Initiator (say a non-AP STA) and inclusion of traffic to other STAs can only be done in an MU-MIMO fashion and without extending the duration of transmission to the RD Responder.
It is now proposed to allow:
Non-AP STAs to share their TXOP with the AP. The AP can use the shared TXOP to transmit data, at least to the non-AP STA that won the TXOP and low latency control/data to all STAs.
Sharing of TXOPs between nodes across multiple BSSs via inter-BSS coordination.
Note:
If this is done, this will also enable semi-persistent allocation of narrow bandwidths for low latency data (as in Proposal 1) in TXOPs within a BSS and across BSSs.
TXOP sharing by a non-AP STA is allowed by the ETSI-BRAN harmonized standard for 5 GHz (EN ).
John Doe, Some Company

5. Month Year
doc.: IEEE yy/xxxxr0
January 2020
Proposal 3: Unsolicited transmission of Scheduling Request indicator for faster notification and transmission of UL and DL data
Proposal: Unsolicited transmission of a compressed Scheduling Request indicator for a non-AP STA to notify its AP that it has UL data for transmission. This indicator can use the semi-persistent resources as defined in Proposal 1.
At present, if a STA has data to transmit in the UL, it has to either multiplex the information along with other scheduled UL data or wait for the AP to send a BSRP. UL latency can be reduced if instead of waiting for an AP to transmit a BSRP, a STA can use semi-persistently allocated control resources to transmit a compressed Scheduling Request indicator to the AP notifying that it has data to transmit in the UL.
Some versions of the Scheduling Request indicator can also indicate additional information about the UL data, such as the priority and/or latency budget of the UL data. This information can be used by the AP to prioritize resource allocation to such an STA.
The Scheduling Request indicator format can be similar NDP/NDP Report.
John Doe, Some Company

6. Month Year
doc.: IEEE yy/xxxxr0
January 2020
Proposal 4: Provision to preempt an ongoing transmission on arrival of low latency data
Proposal: Provision to preempt an ongoing transmission, such as on arrival of low latency data at either the AP or its client. This would cause the transmitter to pause its ongoing transmission and to either start transmitting or enable transmission at some other node of the low latency data.
The preemption indicator can be used for this purpose as follows:
When received by the intended recipient of the low latency transmission, it prompts the recipient to start receiving or looking for the transmission for itself.
When received by the current recipient of the ongoing transmission that has to be preempted, it prompts the recipient to treat its ongoing transmission appropriately by either discarding the segment not yet received or saving it for any possible later (HARQ) combining.
The preemption indication involves the following:
A mechanism to indicate the presence of continued transmission or preemption of traffic by the transmitter such as by using a signal/bit. This indication can be transmitted for example in the narrow control region as defined in Proposal 1.
John Doe, Some Company

7. Proposal 5: Additional prioritization for low latency data
Month Year
doc.: IEEE yy/xxxxr0
January 2020
Proposal 5: Additional prioritization for low latency data
Proposal: Introduce additional prioritization for low latency data by the following:
Use the Alternate Voice (A_VO) queue for low latency data (reference: Figure in IEEE ).
Define a new access category with higher priority than AC_VO for transmission of low latency data. Introduce strict upper bounds, duty cycle and TXOP limits to restrict transmissions that use the new access category in order to maintain fairness with other data.
Introduction of such a higher priority access category can lead to increase in contention/collision, since such a priority class will use smaller values of backoff.
Therefore, it should be used in conjunction with coordination among nodes of the same or different BSSs (via inter-BSS coordination).
Note: Suggestions on b) have also been discussed in IEEE /1780r0
John Doe, Some Company