I suggest rejection of this comment and all comments whose proposed change is "as it says in the comment".
Even if one wanted to follow the reference and try and divine a proposed change out of the comment there is insufficient detail in the comment to do so. The comment directs one to "reword as…." and then includes text containing the word
it's complaining about ("might"). It ends with "etc" which is supposed to signify that similar items get the same treatment but those similar items are unspecified (!!!).
So yea, reject: insufficient detail. Or reject: inappropriate comment. Pick one.
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
On 9/17/21, 12:38 PM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
I was asked to post to this reflector to check whether any 11k/11v/WNM
SMEs have any recollection of how Beacon reports, and in particular their
truncation or fragmentation, is supposed to work. Here is the proposed
resolution to CID 294; if you examine 21/0829 you will see some Word
comments for which SME input would be most welcome, in addition to a
general review of the proposed changes.
|
Identifiers |
Comment |
Proposed change |
|
CID 294 Mark RISON 9.4.2.21.7 1044.14 |
The "might"s here are actually "may"s. Since "may" are not allowed in Clause 9, reword as "In this case, some of the elements included in the Reported Frame Body subelement might be truncated, and the subelement itself might be truncated or fragmented over multiple Beacon Reports when its size exceeds the maximum element size, as described below: -- Truncation of Reported TIM elements such that only the first 4 octets of the element are reported and the element Length field is modified to indicate the truncated length of 4." etc. |
As it says in the comment |
Discussion:
This is really about behaviour for stuff that won’t fit, rather than format. There are a number of additional issues:
·
There is discussion of “fragmentation” but these are not what is normally understood as fragments, i.e. MPDU fragments, nor are they the element fragments from 11ai
·
There is discussion of support for fragmentation, but it is not clear whether this is at the transmitter or at the receiver. The intent seems to be that support is optional at the transmitter, but a receiver is required to support
this, unless it only requests measurements that will always fit (through the Reporting Detail field)
·
Some locations refer to Request elements but fail to refer to Extended Request elements too
·
The references to the Reporting Detail field are editorially haphazard
Proposed changes:
Change 9.4.2.21.7 Beacon report as follows:
The Reported Frame Body subelement, if present, contains some or all of the
requested fields and elements of the frame body of the reported Beacon, Measurement Pilot, or Probe Response frame. If the Reporting Detail
field of the Reporting Detail subelement of the corresponding Beacon request equals 0, the Reported Frame Body subelement is not included in the Beacon report.
If the Reporting Detail subelement equals 1, all fields and any elements identified in a Request element or Extended Request element in the corresponding Beacon request are included in the Reported Frame Body subelement, in the order that they appeared in
the reported frame.
If the Reporting Detail field equals 2, all fields and elements are included in the order they appeared in the reported frame.
Some elements in the Reported Frame Body subelement,
if present, or the Reported Frame Body subelement itself, might be large. In this case, some of the elements included in the Reported Frame Body subelement
mightcan be truncated or omitted, and the subelement itself
mightcan be truncated or fragmented over multiple Beacon Rreports (see 11.10.9.1.1). when its size exceeds the
maximum element size, as described below:
NOTE—This is not element fragmentation as defined in 10.28.11.
— Reported TIM elements might be truncated such that only the first 4 octets of the element are reported and the element Length field is modified to indicate the truncated length of 4.
— Reported IBSS DFS elements might be truncated so that only the lowest and highest channel number map are reported and the element Length field is modified to indicate the truncated length of 13.
— Reported RSNEs might be truncated so that only the first 4 octets of the element are reported and the element Length field is modified to indicate the truncated length of 4.
— If the length of the Reported Frame Body subelement would cause the Measurement Report element to exceed the maximum element size, when Reported Frame Body subelement fragmentation is not supported, then the
Reported Frame Body subelement is truncated so that the last element in the Reported Frame Body subelement is a complete element.
— If the length of the Reported Frame Body subelement would cause the Measurement Report element to exceed the maximum element size, when Reported Frame Body subelement fragmentation is supported, then the Reported
Frame Body subelement is fragmented over multiple Beacon Reports. When the Reported Frame Body subelement is fragmented, then the Reported Frame Body Fragment ID subelement is present in each Beacon Report frame that contains a fragment of this Reported Frame
Body subelement. When the Reported Frame Body Fragment ID subelement is present, the reporting STA does not truncate any of the elements included into the Reported Frame Body subelement.
The Reported Frame Body Fragment ID subelement is present if a Reported Frame Body subelement is fragmented, and is not present otherwise. The format of the Data field of the Reported Frame Body Fragment
ID subelement is shown in Figure 9-232 (Data field format).
The Beacon Report ID field identifies the reported frame for which the Beacon
Rreports instance are sent as a response to a Beacon
Rrequest.
<para break>
The responding STA sets the
Fragment ID Number field identifies the fragment of the to 0 for the initial fragment and increments it by 1 for each subsequent fragment in a multi-fragmented Reported Frame Body subelement of a Beacon Report identified by the Beacon
Report ID.
The More Frame Body Fragments field is set to 0
wheneverin the final fragment of a the fragmented Reported Frame Body subelement is being transmitted, otherwise it is set to 1.
The Reported Frame Body subelement is fragmented so that the last element in every Reported Frame Body subelement fragment is a complete element.
Change 9.4.2.21.7 Beacon report as follows:
If the Reporting Detail field equals 1, a Request element
isand/or an Extended Request element are optionally present in the list of optional subelements. If included,
the Request element liststhese identify the Element IDs of the elements requested to be reported in the Reported Frame Body
subelement of the Beacon report.
[in Table 9-106] All fixed-length fields and any requested elements in the Request element and/or Extended Request element if present
Change 11.10.9.1 Beacon report as follows:
If a STA accepts a Beacon request it shall respond with a Radio Measurement Report frame containing Beacon reports for all observed BSSs matching the BSSID and SSID in the Beacon request, at the level of detail
requested in the Reporting Detail field of the Reporting Detail subelement:. If the Reporting Detail is 1 and the optional Request subelement is included in the Beacon request, the corresponding Beacon report shall include the list of elements listed
in the Request subelement.
·
If the Reporting Detail field equals 0, the Reported Frame Body subelement shall not be included in the Beacon report(s).
·
If the Reporting Detail field equals 1, all fields, and any elements identified in a Request element and/or an Extended Request element if present in the corresponding Beacon request, shall be included, subject to Beacon report
truncation (see 11.10.9.1.1), in the Reported Frame Body subelement (or the Reported Frame Body subelements of multiple Beacon reports, in the case of Reported Frame Body subelement fragmentation), in the order that they appeared in the reported frame
·
If the Reporting Detail field equals 2, all fields and elements shall be included, subject to Beacon report truncation (see 11.10.9.1.1), in the order they appeared in the reported frame.
<para break> The RCPI in the Beacon report indicates the power level of the received Beacon, Measurement Pilot, or Probe Response frame. For repeated measurements (when the Radio Measurement Request
frame contains a nonzero value for the Number of Repetitions field), the transmission of the Beacon report may be conditional on the measured RCPI or RSNI value. If the Radio Measurement Request frame contains a 0 value for the Number of Repetitions field,
the Beacon Reporting subelement shall not be included in the Beacon request. If the Radio Measurement Request frame contains a nonzero value for the Number of Repetitions field, and if both dot11RMBeaconMeasurementReportingConditionsActivated and dot11RMRepeatedMeasurementsActivated
are true, and if a Beacon Reporting subelement is included in a Beacon request, the STA shall respond with a Beacon report if the indicated Beacon reporting condition is true. Otherwise, the STA shall not respond with a Beacon report. Table 9-105 (Reporting
Condition subfield for Beacon report) lists the reporting conditions that are based on the measured RCPI or RSNI levels.
Add a new subclause:
11.10.9.1.1 Truncation and/or fragmentation of reported frame body in Beacon report
If a Reported Frame Body subelement in a Beacon report would exceed the maximum subelement size or would cause the Measurement Report element in the Beacon report to exceed the maximum element size, and the STA
transmitting the Beacon report supports Reported Frame Body subelement fragmentation, the Reported Frame Body subelement shall be fragmented as follows:
— The payload of the Reported Frame Body subelement is fragmented across two or more Beacon reports
— A Reported Frame Body Fragment ID subelement is present in each Beacon report
— The Beacon Report ID subfield in the Reported Frame Body Fragment ID subelement of each Beacon report is the same, and is different from that of Beacon reports corresponding to a different reported frame
— The Fragment ID Number subfield in the Reported Frame Body Fragment ID subelement of the first Beacon report is set to 0 and is incremented by 1 for each subsequent Beacon report
— The More Frame Body Fragments field in the Reported Frame Body Fragment ID subelement is set to 1 in all except the last Beacon report
— Elements in the Reported Frame Body subelement are not truncated, split across two Beacon reports, or omitted
NOTE 1—This means the last element in the Reported Frame Body subelement of each Beacon report is a complete element.
NOTE 2—The STA requesting a Beacon report must support Reported Frame Body subelement (de)fragmentation unless it sets the Reporting Detail subelement in the Beacon request to ensure the STA sending the Beacon
report does not use fragmentation.
If a Reported Frame Body subelement in a Beacon report would exceed the maximum subelement size or would cause the Measurement Report element in the Beacon report to exceed the maximum element size, and the STA
transmitting the Beacon report does not support Reported Frame Body subelement fragmentation, reported elements shall be truncated or omitted as follows to make them fit:
— A TIM element may be truncated such that only the first 4 octets of the element are reported and the element Length field is modified to indicate the truncated length of 4.
— A IBSS DFS element may be truncated so that only the lowest and highest channel number map are reported and the element Length field is modified to indicate the truncated length of 13.
— An RSNE may be truncated so that only the first 4 octets of the element are reported and the element Length field is modified to indicate the truncated length of 4.
— Elements may be omitted from the end of Reported Frame Body subelement
NOTE 3—Elements are not truncated or omitted if the STA transmitting the Beacon report supports Reported Frame Body subelement fragmentation.
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
|
|
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