| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi all,
There were a number of questions on the presentation 23/1874r0 Reverse TXOP Sharing. I tried to answer them online. For clarity, I have enumerated the questions and their response below. There were other members in the queue who were not able to ask their questions. Please use this thread to add them.
Comment 1>Triggered access leads to smoother operation. In the presence of OBSS especially, this scheme is disruptive (Brian)
>>Reverse TXOP sharing is not an alternative to AP-scheduled triggered access. It can be performed in addition to it. In fact, it increases the scope of triggered access by the AP by allowing traffic to be scheduled by the AP even if the non-APs win channel access. For latency-sensitive traffic, reliance on only triggered allocation can be detrimental as the non-AP first has to wait for a possible poll from the AP, subsequently send a BSR, get the adequate allocation and then transmit the latency-sensitive traffic. For such traffic, it is more efficient to allow non-APs to contend and send traffic. If they do so, the TXOP lengths are often underutilized at the non-AP. If such TXOPs are shared with the AP, the AP just like traditional triggered access can allow other non-APs to be scheduled in that TXOP.
Another example we provided was that in the case of hidden nodes. Even for DL data transmission initiated by an AP, hidden nodes in the vicinity of a non-AP can prevent transmission of such DL data. This may happen when for example, a non-AP fails to respond with a CTS to an RTS. Reverse TXOP sharing alleviates this problem, as once such a non-AP wins channel access it can pass on the TXOP to the AP for transferring DL data to it.
In the presentation, we have proposed all these levels of TXOP sharing to properly regulate its usage and maximize the benefits. The system has to be adequately configured so that this sharing improves efficiency and performance. So, an AP and a non-AP have to jointly decide if it can activate this feature for the AP - non-AP pair and to what extent.
Comment 2>non-APs may reserve a long duration of the medium and this will lead to unfairness and TXOP wastage. It will also cause other non-APs to go to sleep for the unused duration and harm their latency performance (Vishnu)
>>This scheme does not require non-APs to reserve the medium in excess of their own transmission requirement. In fact, they must not do so. For example, medium reservation through (MU-)RTS and CTS is sensitive to the transmitting and receiving pair of devices for its efficacy in eliminating hidden nodes. If the AP intends to transmit to another non-AP in a TXOP initiated and shared by one non-AP, it should extend the medium reservation using MU-RTS/CTS. So the initiating no-AP just informs the AP that it has completed its transmission. If the AP wants to transmit DL or schedule UL in it, it starts doing so after a SIFS gap and including a fresh MU-RTS/CTS if needed. If the AP does not want to use this TXOP, it simply doesn’t transmit and regular EDCA kicks in for all devices.
Comment 3> How will it help UL low latency if the clients have to depend on the AP for scheduling (Vishnu)
>> This scheme does not prevent an AP from performing scheduled access in a TXOP initiated by itself nor a non-AP from contending for the channel and transmitting its latency sensitive traffic in a TXOP initiated by it. Rather, it is an additional provision for sharing the remaining duration of a TXOP acquired by a non-AP with its AP. So now, a non-AP X with latency sensitive traffic can transmit such
a) in a TXOP initiated by itself or
b) in a TXOP initiated by the AP (i.e by legacy triggered UL) or
c) in a TXOP initiated by another non-AP Y, which after using its resources shares with its AP which then triggers the non-AP X.
This additional provision c) helps in low-latency while also omitting intermediate channel access durations.
Comment 4> non-APs who share their TXOPs need to know the buffer status of the AP or/and other clients (Ming/Rubayet)
>> As also explained above, non-APs do not need any awareness of the amount of traffic the AP or its other non-APs have. It just hands over the TXOP indicating the specifications like access category and remaining duration. The AP utilizes the TXOP if it has anything to transmit on DL or schedule on UL conforming to the access category, remaining duration and the sharing policy (only to the sharing non-AP, only latency-sensitive traffic, etc). If it has nothing to utilize, it just doesn’t transmit anything after a SIFS gap of the last frame in the exchange with the sharing non-AP, thus automatically terminating the TXOP. If it has something to transmit on DL or schedule on UL satisfying the specifications, it continues those with SIFS gap.
Comment 5> What is the recovery mechanism if the client shares the TXOP and the AP has nothing to transmit or schedule on UL (Ming)
>>See response to comment 4
Comment 6> Longer TXOPs would harm the latency of OBSS (Mohamed)
>>There are several arguments:
It is proposed to regulate the sharing such that for example, only latency sensitive traffic gets transmitted. This traffic is typically low-rate and high inter-arrival time. So, the TXOPs are extended by the duration of latency sensitive traffic available at that time. The benefit to latency sensitive traffic is that they don’t have to wait for the next TXOP after intermediate TXOPs won by other devices. Look at it this way: for a given amount of traffic in a system, this scheme would reduce the number of separate TXOPs (and hence also reduce the number of separate EDCA accesses) to transmit that traffic, relative to what is possible in the legacy schemes.
11ax introduced UL triggered transmissions which could be used to schedule UL traffic. These would reduce the chances of individual non-AP initiated TXOPs. An obvious outcome is that a TXOP with UL traffic scheduled from multiple non-APs would be longer than that initiated by the same individual non-APs. So, this lengthening is already present. In this scheme, it is proposed to do it also in a TXOP initiated by a non-AP and in a regulated manner.
Also note that while this scheme can increase the duration of the non-AP TXOPs that are shared with the AP, it will also reduce the duration of some other TXOPs. For example, it will naturally reduce the duration of the TXOPs which the AP acquires for scheduling UL latency sensitive traffic. It will also reduce the number of TXOPs that non-APs initiate to transmit their own latency-sensitive traffic (as some of the traffic may be transmitted in TXOPs won by other non-APs) and may also reduce their duration.
The simple argument that longer TXOPs lead to higher latencies holds when AC_BE traffic TXOPs are allowed to be long which higher priority traffic may need to wait for to end. If AC_VO traffic is transmitted in the lengthened TXOPs, this argument is not decisive.
Simulation results will also show the above points. We will share them shortly
In addition to 11ax triggered operation, there are several other schemes like 11be TXS mode 2 or which can also elongate TXOP and the latter is not regulated to the extent we propose to regulate reverse TXOP sharing.
Regards,
Sindhu
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature