Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- 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.
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
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 NOTE—This is not element fragmentation as defined in 10.28.11.
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
The The More Frame Body Fragments field is set to 0
Change 9.4.2.21.7 Beacon report as follows: If the Reporting Detail field equals 1, a Request element
[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 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 |