Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] [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,

 

There are multiple reasons to not mix AP PS with this:

  1. Once the AP comes out of Doze it will be blind and miss the preamble of frames transmitted by some OBSS.
  2. In order to get any tangible benefit from AP PS one needs to enable it for more general cases as Triggered P2P usage is not likely the main data transmission activity in network and wont provide the AP with many opportunities for PS. You need a more general solution for that.

 

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>
Sent: Wednesday, April 28, 2021 6:41 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,

 

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.

  1. 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.
  2. 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)     

 

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

Image removed by sender.

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

Image removed by sender.

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

Image removed by sender.

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

Image removed by sender.

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