| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Chunyu, See my further comment. Thanks Best Regards Jay Yang From: Chunyu Hu <chunyuhu07@xxxxxxxxx> Hi, Zhijie: Thanks for the questions. See inline. Chunyu On Wed, Aug 26, 2020 at 7:20 PM Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx> wrote:
A: correct. retransmission follows the same rule. à<Jay> Seem the time slot is an addition constraint for HW retransmission. I don’t know how chipset company consider this. We
always increasing the retransmission times through HW+SW retransmission to guarantee no pkt lost in low latency case(VI or VO case) in practice. I’m afraid your proposal will cause more pkts lost due to the slot boundary limitation in low SNR case.
A: For the OBSS, it would have the requirement that the neighboring BSSs understand the same protocol however STAs within OBSS doesn't need to track every slot boundary. Additional OBSS coordination can be designed (see the slot information
format design --> information bitmap that contains OBSS) such that BSS informs each other the protected time periods in its own TSF time domain. It's some work we can extend to. à<Jay> I mean the pre-11be STA don’t support this protocol in current WIFI SPEC. I don’t know how to let them understand this.
A: in this set of simulation, rate is fixed and every STAs can hear each other. No hidden terminal situation is simulated. We are mostly focusing on the protocol effectiveness here. MSDU agg is ON: 2 MSDUs per A-MSDU. A-MPDU is on and BA window of 64 is used -- for all three schemes (VO uses txop limit 0). We set txop limit to 0 for VO for a fair comparison and mean to demonstrate that using an aggressive CW/AIFSN
doesn't solely solve the problem. à<Jay> I hope you could consider my suggestion to add more variant parameters on the simulation. So that we could know your proposal
can cover all the scenarios or it just works in some special case.
A: the requester and granter need to take into account their link operating state: that includes their tx/rx capability, rssi, traffic, to request reasonable amount of time in slots. In practice, one can go through some probing stage to
start the initial assignment. It may need to do so with some margin to tolerate traffic/channel dynamics. It may need to adjust assignment as traffic/channel vary over time but hopefully at slow pace. à<Jay> Seems it requires that the AP will be more intelligent to understand the associated STA status before allocate the time slots according to your description.
In other scenarios, I believe some STA associated with same AP will require more time slots than expected to show their better performance than others, And AP will decide their performance through the number of slots.
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 |