> I am concerned that removing the “… it shall not include a Max Channel Switch Time element in a Beacon or Probe Response frame” is adding a new requirement that an AP that sends a Channel
Switch Announcement with the Channel Switch Announcement element set to 0 shall include a Max Channel Switch Time element.
I don't buy this at all.
Not saying "it shall not include X"
does not imply "it shall include X".
Otherwise every element would
have to have hundreds of "it shall not include X"s specified.
> Alternative proposal: change the clause to: “… it
may shall not include a Max Channel Switch Time element in a Beacon or Probe Response frame”.
> Note: the 802.11 Editorial Style Guide – states that “may not” is ambiguous, however in this requirement I believe it is not ambiguous, as when this may applies is clearly stated in the first part of this requirement: When the Channel Switch Announcement
element is 0.
I would not want a "may not".
I suppose I could live with a
"it may include a
MCSTe".
>
Rejected: There is no known benefit of including the Max Channel Switch Time element in a Beacon or Probe Response frame with a Channel Switch Count field of the Channel Switch Announcement element set
to 0.
I think there are at least two benefits to the
MCSTe:
1) for the STA to be able to lengthen any "AP has gone away, time to roam" timeout
2) for the STA to be able to decide that waiting for the AP to turn up would spoil its latency/throughput expectations, and to immediately roam to another AP instead
Both of these would be applicable in the zero count case.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
From: Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, 29 August 2022 17:21
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] Channel Switch Count question/suggested change in REVme
--- This message came from the IEEE 802.11 Working Group Reflector ---
Dear All,
I am concerned that removing the “… it shall not include a Max Channel Switch Time element in a Beacon or Probe Response frame” is adding a new requirement that an AP that sends a Channel
Switch Announcement with the Channel Switch Announcement element set to 0 shall include a Max Channel Switch Time element. While this may have some benefit to the non-AP STAs, informing it of the maximum time the AP will take to complete the channel switch,
this does put a “new” requirement on the AP to provide this information. I don’t know if this something an AP can do with minimum impact. Also, this is a change in AP behavior and existing APs will not follow this new behavior as the current requirement
clearly states that the element is not included. Therefore it is probably best to not require this a new behavior. If the benefit of adding this additional information to the Channel Switch Announcement is viewed as beneficial it may be preferred to simply
allow the Max Channel Switch Time element to be included, at the discretion of the AP, by replacing the “shall” with a “may”.
Alternative proposal: change the clause to: “… it
may shall not include a Max Channel Switch Time element in a Beacon or Probe Response frame”.
Note: the 802.11 Editorial Style Guide – states that “may not” is ambiguous, however in this requirement I believe it is not ambiguous, as when this may applies is clearly stated in the first part of this requirement: When the Channel Switch Announcement element
is 0.
This alternative proposal allows the current behavior of the AP of not including the Max Channel Switch Time element and the proposed new behavior of including the Max Channel Switch Time
element to both be allowed.
Also it should be noted that there are benefits of having all APs behave in the same manner and existing APs currently follow the requirement not to include a Max Channel Switch Time element.
If it is viewed that the inclusion of the element is beneficial to non-AP STAs then this new behavior should be allowed, however if there is no benefit for this new behavior then the comment should be rejected.
Rejected: There is no known benefit of including the Max Channel Switch Time element in a Beacon or Probe Response frame with a Channel Switch Count field of the Channel Switch Announcement
element set to 0.
Regards,
Joseph
From: Lumbatis, Kurt <kurt.lumbatis@xxxxxxxxxxxxx>
Sent: Monday, August 29, 2022 10:04 AM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] Channel Switch Count question/suggested change in REVme
--- This message came from the IEEE 802.11 Working Group Reflector ---
I am fine with those changes.
Kurt Lumbatis
Distinguished Software Engineer
DOCSIS CPE R&D SW Architecture (Wi-Fi)
ARRIS AND RUCKUS
HAVE JOINED COMMSCOPE
3871 Lakefield Dr, Suwanee, GA 30024 USA
Office: +01-678-473-2921
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Saturday, August 27, 2022 3:51 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] Channel Switch Count question/suggested change in REVme
--- This message came from the IEEE 802.11 Working Group Reflector ---
All,
I’m looking for those interested in Channel Switch Announcement procedures, to consider a change being proposed in REVme (see below).
Does anyone have a comment/concern with this proposed change?
Thanks. Mark
|
1812 |
Mark RISON |
2799.35 |
"When the AP sets the Channel Switch Count field of the Channel Switch Announcement element to 0, it shall |
Delete the cited text |
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
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