1. Submission doc.: IEEE 802.11-15/0531r0 May 2015 Michael Fischer, FreescaleSlide 1 A Possible Solution to the Beacon Length Problem Date: 2015-05-09 Authors:

2. Submission doc.: IEEE 802.11-15/0531r0 May 2015 Michael Fischer, FreescaleSlide 2 Abstract It is possible for the frame bodies of Beacon and Probe Response frames to exceed the maximum (non-VHT) MMDPU size of 2304 octets. The existing standard does not specify what is to be done in when this occurs. Leaving this unspecified is likely to yield interoperability problems as new elements continue to be defined. A recommended solution is to permit many elements to be sent with short periodicity, rather than requiring them to appear in every Beacon.

3. Submission doc.: IEEE 802.11-15/0531r0May 2015 Michael Fischer, FreescaleSlide 3 Statement of the Problem Except when using a VHT PHY, the maximum MMPDU size is limited to 2304 octets [clause 8.2.4.7.1]. The large number of elements required and allowed makes it possible for the frame bodies of Beacon and Probe Response frames to exceed 2304 octets. This has been theoretically possible since the adoption of 802.11d, but was not then a actual problem because there were not enough regulatory domains to overflow the maximum MMDPU size. This author first identified the incipient problem in 2000, as a letter ballot comment on 802.11d. Leaving MAC behavior unspecified in this situation creates a risk of interoperability problems.

4. Submission doc.: IEEE 802.11-15/0531r0 Characterization of Beacon Size It is impossible to calculate the actual size of a Beacon frame body without knowing both the set of options implemented and the current operational state. A naïve summation of maximum permitted sizes of the elements present in the frame body yields 4710 octets. This is unrealistic, not only due to the use of maximum permitted sizes, but also due to many optional elements. However this may also be an underestimate, because it does not account for the possibility of multiple copies of certain elements, nor the unknown sizes of vendor-specific elements. The problem is not observed in the field today because a “typical” Beacon size, based on some arbitrary, but reasonable, assumptions is around 1200 octets. Slide 4Michael Fischer, Freescale May 2015

5. Submission doc.: IEEE 802.11-15/0531r0 Characterization of Probe Response Size As with Beacon Frames, calculating the size of Probe Response frames requires knowledge of options implemented and current operational state. Probe Responses are typically shorter than Beacons because they do not contain a TIM element. However, Probe Responses may be longer due to the presence of requested elements following the normal set of elements. The major difference relevant to the current problem is that there are fewer feasible ways to deal with frame body overflow on Probe Responses. Slide 5Michael Fischer, Freescale May 2015

6. Submission doc.: IEEE 802.11-15/0531r0May 2015 Michael Fischer, FreescaleSlide 6 General Observations on Possible Solutions There appears to be little risk to the installed base, because the typical sizes are about 25% of worst case. This problem primarily affects the older PHY types. The 2304 octet limit does not apply to the VHT and TVHT PHYs, nor to the proposed S1G PHY. There is no obvious reason why this should not also be the case for other future PHYs. This problem needs a systematic solution, because future amendments are going to define more elements that need to appear in Beacons. Although it would be possible to limit the use of future functionality to PHYs where the 2304 octet limit does not apply.

7. Submission doc.: IEEE 802.11-15/0531r0May 2015 Michael Fischer, FreescaleSlide 7 A Proposed Approach for Beacon Frames There are many elements that could safely be omitted from some Beacons, provided they appear periodically. We can define mandatory elements that must appear in every Beacon, and elements that may appear in every Nth Beacon. N=2 is currently adequate, but there should be allowance for N=4. A simple way to ensure the proper periodicity is to have each sender of Beacons to maintain a modulo-N count of Beacons, and to require each non-mandatory element to appear when the LSb (or 2 LSb) of the Element ID is equal to the counter value. To minimize impact on the duration of passive scanning, all elements should appear in every Beacon until/unless the MAC constructs a Beacon that is longer than 2304 octets. This is analogous to what is already done by cellular protocols.

8. Submission doc.: IEEE 802.11-15/0531r0May 2015 Michael Fischer, FreescaleSlide 8 A Proposed Approach for Probe Responses Probe Responses are solicited, so the periodic omission of selected elements is not feasible. However, Request Element mechanism already exists to permit retrieval of specific element information. We can define mandatory elements that must appear in every Probe Response, and permit all other elements to be omitted if the frame body would otherwise be longer than 2304 octets. This is probably the same list of mandatory elements as for Beacons. The sender can use a second Probe Request with appropriate Request Elements to obtain omitted information that it specifically requires. Elements requested in a given Probe Request are mandatory in the corresponding Probe Response.