>
The new sentence doesn't mandate (no shall/should/etc) any
behavior; it's just informational; and there is already similar text in
subclause 9.4.2.20.5/6/7/8, etc.
Yes, all those "shalls" are bogus and need to be moved out of Clause 9.
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:
Morteza Mehrnoush <morteza.80211@xxxxxxxxx>
Sent: Monday, 15 May 2023 22:18
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] CID 17266 in 11-23/733r2
Hi Youhan,
The new sentence doesn't mandate (no shall/should/etc) any behavior; it's just informational; and there is already similar text in subclause 9.4.2.20.5/6/7/8, etc.
This is to accommodate the commenter's concern. If Zinan is OK with that, I am OK with D3.0.
Thanks, Morteza.
Clause 9 is about frame format, and the new sentence being proposed is a behavior, not a ‘format’.
And Clause 35 already has behavioral requirement.
So, I think D3.0 is fine as-is.
Regards,
Youhan
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Youhan,
Agree that the current text in 35.15.3 is fine as it is. I was suggesting to add below text to subclause 9, which will be used
by the CSA/eCSA frame and element.
i.e. add below text to: "9.6.7.7 Extended Channel Switch Announcement frame format", "9.6.2.6 Channel Switch Announcement frame
format", and "9.4.2.162 Channel Switch Wrapper element".
"If a Bandwidth Indication subelement is received by an EHT STA, the EHT STA uses the Bandwidth Indication subelement for determining
the EHT BSS operating channel bandwidth and ignores the Wide Bandwidth Channel Switch subelement indication."
Hi.
Thank you Morteza and Zinan for this.
CID 17226 (on 35.15.3) is about channel switching, and 9.4.2.20.7 is about measurement report. Hence, they are not related to
each other, and we should mix the two up.
I find the current language in 35.15.3 to be fine, and do not see a need to change the text there.
The current language is clear that it is up to the (non-AP) STA on whether it determines the EHT BSS operating channel bandwidth
based on the Bandwidth Indication element or not.
(“If” an EHT STA determines…)
Alternative is for the non-AP STA to determine the BSS operating channel bandwidth from the Beacon frame after the channel switch
has occurred.
Both are valid under the current draft.
The proposal discussed below in this email thread will now make it mandatory for non-AP STAs to determine the EHT BSS operation
bandwidth based on the Bandwidth Indication element before the channel switch has occurred.
I don’t see a need to make such technical change at this point.
Regards,
Youhan
Hi Morteza, thanks for your response!
CID 17226 is about 35.15.3. Do you suggest to replace the sentence you indicated below to replace the highlight part in35.15.3?
Thanks,
Zinan
Hi Zinan,
The "shall'' requirement is removed from the sublcuase 9, 11/23-733r3; as Mark pointed out too. And it reads
as below now:
How about adding below text to subclause "9.6.7.7
Extended Channel Switch Announcement frame format", "9.6.2.6 Channel
Switch Announcement frame format", and "9.4.2.162 Channel Switch
Wrapper element"
which covers the cases used in 35.15.3?
"If a Bandwidth Indication subelement is received by an EHT STA, the EHT STA uses the Bandwidth Indication subelement
for determining the EHT BSS operating channel bandwidth and ignores the Wide Bandwidth Channel Switch subelement indication."
>
802.11be D3.1 shows that “When the Bandwidth Indication
subelement is present, an EHT STA for determining the EHT BSS operating channel bandwidth for which the measurement request applies shall use Bandwidth Indication
subelement indication and shall ignore the Wide Bandwidth Channel Switch
subelement indication.”
There shouldn't be any "shall"s in
Clause 9 (except
Subclause 9.1)!
Clause 9 is for format/encoding, not behaviour.
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
Hi Morteza,
Thanks for presenting 11-23/733r2!
Regarding CID 17266, my concern is the text (35.15.3) states that “ If an EHT STA determines the EHT BSS operating channel bandwidth
based on the Bandwidth Indication element in the frame, then..” It does not specify if it allows the EHT STA ignore the EHT BSS operating channel bandwidth based on the Bandwidth Indication element in the frame or not. However, the original text in 9.4.2.20.7
(which is being modified in the your CR document) of 802.11be D3.1 shows that “When the Bandwidth Indication subelement is present, an EHT STA for determining the EHT BSS operating
channel bandwidth for which the measurement request applies shall use Bandwidth Indication subelement indication and shall ignore the Wide Bandwidth Channel Switch subelement indication.”
Therefore, I would suggest that the specs may need to specify it in 35.15.3 to be consistent with what has been stated in
9.4.20.7 unless different rules are applied in the measurement request and BSS operation.
Thanks,
Zinan
17266
|
Zinan Lin
|
35.15.3
|
651.11
|
Does this allow the EHT STA ignores the EHT BSS operating channel bandwidth based on the Bandwidth Indication element in the element and determines the EHT BSS based on the BSS bandwidth
in the Wide bandwidth Channel Switch element?
|
Please clarify it
|
Rejected
At the start of this subclause 35.15.3, it mentions that the EHT STA follows the legacy rules and additional rules defined in this subclause. Potentially it can follows the legacy
behavior and it can use the Wide Bandwidth Channel Switch element without follow the rules in this subclause.
|
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
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
|