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>
Sent: 2021年4月29日 8:56
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] TGbe Teleconferences [02/08/2021]: Agendas Posted
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>
Sent: Wednesday, April 28, 2021 5:50 PM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>;
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] TGbe Teleconferences [02/08/2021]: Agendas Posted
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>
Sent: 2021年4月28日 21:19
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] TGbe Teleconferences [02/08/2021]: Agendas Posted
Hi Jay, all,
The motivation for the two modes is not to restrict particular type of traffic but rather related to channel access.
- If the AP knows that the traffic is only going to be to itself, then the AP can grab the medium anytime the STA does not transmit an expected frame. Now, the case where AP can know
all traffic is going to be for itself is the “only UL traffic” case. Hence, we have Mode 1.
- If the AP
does not know that the traffic is only going to be to itself, then the AP
cannot grab the medium anytime the STA does not transmit an expected frame because it simply does not know for sure what the STA is doing at this time. This would occur when AP gives the STA the flexibility to transmit any type
of traffic without controlling the STA’s priorities. Hence, we have Mode 2.
Regards,
Dibakar
From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Tuesday, April 27, 2021 11:09 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] TGbe Teleconferences [02/08/2021]: Agendas Posted
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
|
TxOP Sharing Mode subfield value |
Description |
|
0 |
MU-RTS that does not initiate MU-RTS TXOP Sharing procedure
|
|
1 |
MU-RTS that initiates MU-RTS TXOP Sharing procedure wherein a scheduled STA can only transmit PPDU addressed to its associated AP
|
|
2 |
MU-RTS that initiates MU-RTS TXOP Sharing procedure wherein a scheduled STA can transmit PPDU(s) addressed to its associated AP or addressed to another STA
|
|
3 |
Reserved |
Thanks
Best Regards
Jay Yang
From: Yongho Seok <yongho.seok@xxxxxxxxx>
Sent: 2021年4月20日
1:22
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] TGbe Teleconferences [02/08/2021]: Agendas Posted
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>
Sent: Thursday, February 18, 2021 7:28 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] TGbe Teleconferences [02/08/2021]: Agendas Posted
Hi Alfred,
Please add the following PDT to queue:
|
11-2021 |
·
268 |
0 |
TGbe |
PDT channel access Triggered SU |
Regards,
Dibakar
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Sunday, February 7, 2021 7:31 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] TGbe Teleconferences [02/08/2021]: Agendas Posted
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