Q1: Do products you manufacture/sell use PIFS access for Beacons? If so, how often?
Response: Given no certification body performs compliance to this requirement, the available information is limited to few reports that have performed lab/field tests. Lack of response to this question should not be taken as any evidence of compliance.
Q2: Do you know of products manufactured by others that use PIFS access for Beacons? If so, how often?
Response: As you know, there has been lab tests indicating that the observed distribution of back-off for a given CWS, has less randomness than expected (in the case of Beacon, expected distribution is a uniform random back-off with EDCA/VO CWS).
Q3: Do you believe the use of PIFS access for Beacons is widespread (or not)? On what basis do you have this belief?
Response: Given compliance of this requirement is not tested by certification bodies, there may not be a meaningful response to this question unless widespread tests are performed.
Q4: Assuming the use of PIFS access for Beacons is not widespread, should its use be further discouraged by ETSI BRAN reducing the threshold for using short control signaling without any LBT to 1%?
Response: We argue against any change without thorough analysis and simulation under practical deployment scenarios. A note on the cited reference that shows harm if LBT Cat2 is used up to 5%: it is a “topology with 8 nodes, all of which can hear each other”. This may not be a practical deployment scenario, given all nodes are very close to hear each other (with RSSI>ED=-62dBm) and all have full buffer. Furthermore, in any analysis and simulation for your proposal, it is fair to consider features used in practice, e.g. multiple BSSID feature exercised by managed/enterprise APs that practically multiplies the rate of Beacon frame transmission several times.
--- This message came from the IEEE 802.11 Working Group Reflector ---G’day Ben
Thank you for your questions (although I would have preferred answers to my questions J). You asked:
Can someone point me in the direction of contributions that provide technical analysis, simulation studies and/or empirical studies which quantify the difference in aggregate channel access collision probability between 1% and 5% duty cycle when using short LBT?
And how using longer or more rigorous channel access mechanisms impacts the collision probability in each duty cycle case?
I am not sure I can answer every element of your questions but I will tell you what I know, based on the recent discussions on this topic at the IEEE 802.11 Coexistence Workshop in Vienna.
The link in my e-mail is to a Broadcom submission that looks at the impact on four Wi-Fi systems of four gNBs sending DRS using short LBT access (up to the 5% limit). It shows an adverse effect on the four Wi-Fi systems.
I am not aware of any studies that explicitly examine the proposed 1% limit compared to a 5% limit. However, I should note the 1% limit was proposed as a compromise mainly on the basis that it would improve the current situation compared to a 5% limit , and yet it would leave a little wiggle room for those situations where no/short LBT was absolutely required. For example, even Wi-Fi makes use of no/short LBT when sending a special frame after a radar is detected, but this is a rare event.
Interestingly, a submission from Huawei suggested that there was no significant adverse effect on Wi-Fi from NR-U sending DRS using short LBT access. However, the submission also showed that there was also no substantial benefit to NR-U from NR-U sending DRS using short LBT access, compared to using the normal LBT scheme used for Beacons by Wi-Fi.
Although the Broadcom and Huawei submissions disagree on some points, we don’t actually need to choose between them. The two submissions show there is no harm (to NR-U and Wi-Fi) and a potential benefit (at least to Wi-Fi) from NR-U not using short LBT for access for DRS. In contrast, the use of short LBT has the potential for harm (at least to Wi-Fi) if you believe the Broadcom submission. The obvious low risk solution, given the uncertainty, is to not allow the use of short LBT for DRS.
Andrew
BTW this material will be discussed at the IEEE 802.11 Coex SC meeting in Hanoi. I expect that a LS to both ETSI BRAN and/or 3GPP RAN1 will be proposed that explains the conclusion. Feel free to participate or propose alternatives. All submission on this (and other topics related to coex) are welcome and encouraged.
From: Benjamin A. Rolfe <ben@xxxxxxxxxxxxxx>
Sent: Friday, 23 August 2019 2:17 AM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] Access for Beacons
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Andrew,
Thank you for the informative email. Can someone point me in the direction of contributions that provide technical analysis, simulation studies and/or empirical studies which quantify the difference in aggregate channel access collision probability between 1% and 5% duty cycle when using short LBT? and how using longer or more rigorous channel access mechanisms impacts the collision probability in each duty cycle case?
Thanks
Ben
On 8/20/2019 10:47 PM, Andrew Myles (amyles) wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
G’day all,
The Coexistence SC has been discussing various aspects of a mechanism currently specified in EN 301 893 (the European Harmonised Standard for 5 GHz) that allows each device to access the medium for short control signalling without using any LBT for about 5% of the time.
There is a concern by some people that this mechanism could be misused or overused. There is less concern about overuse by 3PPP LAA for DRS frames (like Beacons) because only eNBs (like an AP) use this mechanism and there are unlikely to many eNBs in a particular area/channel, given eNBs will typically owned and operated by SPs (who also own the paired licensed spectrum). There is concern about overuse by 3GPP NR-U for DRS frames (and possibly other frames) because it is more likely that multiple gNBs (like an AP) will be operating in an area/channel, given NR-U is very similar to Wi-Fi in its deployment model. It should be noted that both LAA and NR-U do not actually use no LBT access but rather use short LBT access (like PIFS). If n independent gNBs were operating in a channel then n x 5% of the medium could be accessed using this super high priority short LBT access mechanism. A presentation at the Coex Workshop asserted the 5% threshold would have significant adverse effects on Wi-Fi, with n as low as 4.
The IEEE 802.11 WG has previously sent both ETSI BRAN and 3GPP RAN1 liaisons supporting changing the threshold for the use of this mechanism from 5% to 1% (possibly with use by LAA grandfathered). The discussion in both organisations has failed to reach any consensus on the IEEE 802.11 WG propoal. 3GPP RAN1 is unlikely to make any change to the status quo unless forced to do so. The discussion continues in ETSI BRAN in the context of the 5 GHz band (EN 301 893) and is likely to start soon in the context of the 6 GHz band (EN 303 687). In this discussion in ETSI BRAN, it has been asserted that some/many Wi-Fi devices do not follow the IEEE 802.11 standard when accessing the medium for Beacons. Rather than using normal EDCA style access, it is asserted some/many Wi-Fi APs are using PIFS access. If PIFS access for Beacons is widespread then it diminishes the argument that NR-U should not use short LBT access too.
So I have some questions for the IEEE 802.11 WG community:
· Do products you manufacture/sell use PIFS access for Beacons? If so, how often?
· Do you know of products manufactured by others that use PIFS access for Beacons? If so, how often?
· Do you believe the use of PIFS access for Beacons is widespread (or not)? On what basis do you have this belief?
· Assuming the use of PIFS access for Beacons is not widespread, should its use be further discouraged by ETSI BRAN reducing the threshold for using short control signalling without any LBT to 1%?
Please send answers to these questions to me as soon as possible.
Andrew Myles
Manager, Cisco Standards
Andrew Myles
Manager, Enterprise Standards
amyles@xxxxxxxxx
Phone: +61 2 8446 1010
Mobile: +61 418 656587Cisco Systems Limited
The Forum 201 Pacific Highway
St Leonards 2065
AUSTRALIA
Cisco.com
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
