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