| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Vishnu, Thanks for the response. See my feedback in-line. Best Regards Yonggang From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
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>
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>
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>
Hi Alfred, Liwen, Jeongki, Please help to add the following CRs in the MAC queue
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
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 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||