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

Re: [STDS-802-11-TGBE] Initial Revision of Agendas for Sept-Nov Telcos Uploaded



Hi Vishnu,

 

Thanks for the response.  See my feedback in-line.

 

Best Regards

 

Yonggang

 

From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Friday, October 21, 2022 2:02 PM
To: Yonggang Fang <Yonggang.Fang@xxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Initial Revision of Agendas for Sept-Nov Telcos Uploaded

 

Hi Yongang,

 

Thank you for the response. In the scenario you mentioned, where there are many neighboring APs and all of them are primarily using EPCS traffic, I agree that disallowing spatial reuse will be bad. But in my opinion this is a less likely scenario. The more likely case is that the majority traffic in the OBSS is non-EPCS traffic, in which case disallowing SR is better.

[YG] The EPCS service is provided and operated in the service provider’s networks.  When an emergency event occurs, the EPCS is enabled not only in a single AP, but also in neighbor APs for most case.  As EPCS devices use higher priority EDCA parameters to access to medium and the access priority of non-EPCS devices are lowered by the EPCS AP/MLDs according to the current 11be spec,  most traffic in the EPCS enabled network are from EPCS devices.  Therefore,  prohibiting OBSS devices to use SR actually results in blocking EPCS devices associated with neighbor APs to share the medium in the emergency situation. 

 

Now, I agree that this can be dealt with in implementation as you said. But the issue with leaving it to implementation is that we are leaving room for a vendor to always allow SR independent of scenario, which can be bad for EPCS performance. So for critical traffic like EPCS, I think it may be preferrable to rather specify it in the spec, at the cost of reduced flexibility.

[YG]  If the 11be spec mandates “set PSR_AND_NON_SRG_OBSS_PD_PROHIBITED in SPATIAL_REUSE subfield”, how does an EPCS device allow the case that OBSS traffic is from an EPCS device? 

 

Regards,

Vishnu

 

From: Yonggang Fang <Yonggang.Fang@xxxxxxxxxxxx>
Sent: Friday, October 21, 2022 2:28 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Initial Revision of Agendas for Sept-Nov Telcos Uploaded

 

Hi Vishnu,

 

Thank you for review and comment.

 

From the point of improving the reliability of an EPCS traffic, I would agree with your comment.  On the other hand,  an EPCS network may have many APs (or AP MLDs), and an OBSS traffic could be from another EPCS non-AP STA or MLD associated with a neighbor AP.  If we mandate not allowing spatial reuse in the spec, then the EPCS traffic from OBSS would be blocked.  This will reduce the possibility of support multiple EPCS traffic sharing the medium.  It is a disadvantage of prohibiting SR.

 

So I think it might be better to let the network implementation or configuration to decide whether or not to set PSR_AND_NON_SRG_OBSS_PD_PROHIBITED in SPATIAL_REUSE subfield, so as to provide more flexibility for EPCS transmissions.

 

Best Regards

 

Yonggang

 

 

From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Friday, October 21, 2022 8:38 AM
To: Yonggang Fang <Yonggang.Fang@xxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Initial Revision of Agendas for Sept-Nov Telcos Uploaded

 

Hi Yonggang,

 

I have a comment on your resolution to CID 11991 in CR 1452. The comment is asking to prevent spatial reuse over PPDUs sent under the EPCS category, i.e., to prevent an OBSS from using the same TXOP as an EPCS PPDU. This is to improve reliability of the critical EPCS PPDUs since spatial reuse can potentially harm the reception of the EPCS PPDU at the intended receiver. The resolution seems to assume the OBSS will also be using EPCS traffic only which in my opinion is unlikely (and more importantly not known to the first BSS). Even if the OBSS it is using EPCS traffic, reliable packet reception for the first TXOP holder will be important in EPCS.

 

Kindly note that spatial reuse already has a mechanism to prevent such reuse by the OBSS, so the comment is just asking to mandate using that mechanism for EPCS traffic.

 

Regards,

Vishnu

 

From: Yonggang Fang <00001a2738812321-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, October 11, 2022 7:39 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Initial Revision of Agendas for Sept-Nov Telcos Uploaded

 

Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hi Alfred, Liwen, Jeongki,

 

Please help to add the following CRs in the MAC queue

 

11-Oct-2022 ET

2022

1452

1

TGbe

LB266-CR-for-35-17-3 part 3

Yonggang Fang (MediaTek)

11-Oct-2022 20:27:20 ET

Download

11-Oct-2022 ET

2022

1661

1

TGbe

LB266 CR for 35-17-3 part 4-rTWT

Yonggang Fang (MediaTek)

11-Oct-2022 17:11:10 ET

Download

15-Sep-2022 ET

2022

1200

1

TGbe

LB266-CR-for-35-17-3 part 2

Yonggang Fang (MediaTek)

15-Sep-2022 15:40:07 ET

Download

 

Thanks

 

Yonggang

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Saturday, September 24, 2022 11:58 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Initial Revision of Agendas for Sept-Nov Telcos Uploaded

 

Hello all,

 

I uploaded the telco agendas for the Sept to Nov time period. Please take a look at the submissions list and let me know if any of the contributions are missing from the queues. 

 

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