Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Dibakar, Actually, I don’t think AP need to regain the channel access very urgent in such case. Instead, why not let the AP that wakes up from doze state wait till the blindness traffic is gone at the boundary of the granted TXOP? We can think about the detail technical solution in the future if necessary, but I hope it’s better not close the door when we propose the definition in R1. Therefore, I prefer to separate the P2P only mode from uncontrolled mode. Anyway, as there is only 1 bit reserved in your PDT, we can’t expect the 1 bit can cover everything. Thanks Best Regards Jay Yang From: Das, Dibakar <dibakar.das@xxxxxxxxx> Hi Jay, There are multiple reasons to not mix AP PS with this:
The “uncontrolled mode” is also for SU only and we wont have any MU mode for R1. Whether there is an uncontrolled mode for MU in R2 is something we should debate in R2 as part of discussing the MU combinations of interest. If there is indeed
a MU mode, then we can have another Mode value (say, 3) and possibly have different subtypes in User Info.For now the best we can do is to make the design for the SU case as forward-compatible as possible.
Regards, Dibakar From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Dibakar, I can’t agree with you for the AP doze topic. Since the granted TXOP solution is quiet new in 11be, we can’t use the old eyes to see it. As the AP explicitly claims the granted TXOP is for P2P traffic for one p2p peer, why AP need to notify the other associated STAs before enter doze state in advance. And also it’s impossible to do it. Instead, the AP can do anything as
it wants (except talking) during the granted TXOP duration rather than useless monitor the on-going P2P traffic. BTW, do you mean the AP doesn’t consider uncontrolled mode in MU case? I think the AP supporting SST feature possible to support uncontrolled mode in different sub-channels simultaneously. Again, I don’t object the definition of uncontrolled
mode. Maybe the user info subfield is a better place than common subfield. Thanks Best Regards Jay Yang From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Jay, MU-P2P will likely be a separate mode to consider in R2 and not under mode 2.
AP Power save is a separate problem on its own and not really relevant for this case. Just creating a new mode is not enough as there needs to be additional signaling somewhere for the AP to signal to all STAs in its BSS that its not available
currently. Regards, Dibakar From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Dibakar, Thanks for your illustration. But the mode2 doesn’t work if we consider extending to multiple user case in the future. On the other hand, according to current description, it will increase the burden of AP if the STA claims the granted TXOP for P2P traffic only in advance, because AP need always monitoring the on-going traffic once setting to mode2. An alternative solution may like this: mode1 for UL traffic, mode2 for P2P traffic, while mode3 for un-control traffic. So that AP can have some doze time in mode2. Thanks Best Regards Jay Yang From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Jay, all, The motivation for the two modes is not to restrict particular type of traffic but rather related to channel access.
Regards, Dibakar From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Hi Dibakar, I echo Yongho’s comments, the following rule shall be same for mode1 and mode2 that AP decides whether to regain the channel access or not.
·
The CS mechanism indicates that the medium is idle at the TxPIFS slot boundary after the end of either the transmission of the last immediate response frame sent
to that STA or the reception of the last frame from that STA that did not require an immediate response.
Furthermore, according to following table, as mode1 is defined as UL only, it’s natural to define mode2 as P2P only. Therefore, it makes less sense to do overlap definition. Table 9-31xxx TxOP Sharing Mode subfield encoding
Thanks Best Regards Jay Yang From: Yongho Seok <yongho.seok@xxxxxxxxx>
Hi Dibakar, Please find my comments in the attached file. Thanks, Yongho On Wed, Apr 14, 2021 at 9:40 PM Das, Dibakar <dibakar.das@xxxxxxxxx> wrote: Hi all, I uploaded a new revision of
268r2 (Triggered SU channel access) to mentor. Please review.
I tentatively added as co-author the members who contributed to the spec text. Please let me know offline if you don’t want your name to be included and I can remove it in the next revision. Regards, Dibakar From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Hi Alfred,
Please add the following PDT to queue:
Regards, Dibakar From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Hello all, I uploaded an updated version of the agendas, which contains the agenda for the next conference calls, scheduled on Monday, February 08 (MAC/PHY), 10:00-12:00 ET. The agendas can be found here: DIAL IN DETAILS FOR MONDAY: Join the MAC meeting here:
https://ieeesa.webex.com/ieeesa/j.php?MTID=m0a0a9cac185f64cce900514e8966e029
Meeting number: 179 045 1588 Meeting password: wireless (94735377 from phones and video systems) Join the PHY meeting here:
https://ieeesa.webex.com/ieeesa/j.php?MTID=m974d0a1712c60e96e275d9e504af8977 Meeting number: 179 596 9157 Meeting password: wireless (94735377 from phones and video systems) Please let me know if you have any questions and/or clarifications. Best Regards, Alfred --
Alfred Asterjadhi, PhD IEEE802.11 TGbe Chair, Qualcomm Technologies Inc. Cell #: +1 858 263 9445 Office #: +1 858 658 5302 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
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
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 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 |