Frame Request-Report Enhancements January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 Frame Request-Report Enhancements Date: 2006-03-07 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks

Abstract 802.11k D3.0 in section 7.3.2.21.7 introduces Frame Request January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 Abstract 802.11k D3.0 in section 7.3.2.21.7 introduces Frame Request Frame request provides a great way to detect the frames transmitted on air on a different channel. So this introduces a great way of understand, who is communicating on a channel, their RSSI, RCPI ..etc. However the existing frame request/report mechanism leaves a lot to be desired Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks

What can’t we use the existing Frame Request/Report for ? January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 What can’t we use the existing Frame Request/Report for ? To identify/locate a particular STA (rogue or interested party for location or for other reasons). For example, with this existing mechanism, a device, cannot query all trusted stations, to go and look for a particular rogue device ! With the existing frame report/request mechanism, we get the full frame report of all frames on the queried channel. This MAY/MAY NOT INCLUDE the desired device, based on the length of the report, and what else might be happening the channel. Also the querying station, has to digest this huge report, when its needs may only be for one device ! Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks

January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 Proposal Add an optional mac address field in the frame request element so that we can query the frame count for a specific station. So? The frame report element generated in response to this frame request shall now contain only a frame report entry about this specific station. .. AND NOT REPORT ENTRIES FOR ALL THE HUNDREDS OF CLIENTS, THAT CAN BE POTENTIALLY HEARD Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks

Let’s Illustrate A very realistic scenario, in any enterprise. AP1 January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 Let’s Illustrate A very realistic scenario, in any enterprise. AP1 Channel 6 25 Clients Rogue on channel 11 Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks

Illustration (contd) We have one AP, and we have 25 client associated. January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 Illustration (contd) We have one AP, and we have 25 client associated. So now if AP1 somehow wants to detect/locate of a rogue who is doing something harmful. It would ask its 25 clients to go look for this one mac address or do what 11k does today, and say tell me who you hear on channels 1, 6 and 11. Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks

Before and After this proposal January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 Before and After this proposal Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks

January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 Proposal Advantages The biggest advantage from this proposal, is if I am interested in a one device, I don’t have to get knowledge of all the 100s of stations on the channel. IT REDUCES PACKET SIZE FOR FRAME REPORT SIGNIFICANTLY. Infact the packet size is fixed irrespective of the number of station on the channel. This proposal will for the first time utilize Trusted Client devices as well as Access Points in the network to efficiently do Rogue detection and device location. It also make implementations easier and simpler. So the APs don’t have sort thru literally the 10s or 100s of entries that are returned in the frame report. Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks

Proposed Frame Request Element January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 Proposed Frame Request Element The proposed Frame Request, measurement element will look like the following. Channel Number Regulatory Class Randomization Interval Measurement Duration Mac Address (optional) Bytes 1 2 6 Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks

January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 Fringe Benefits This proposal addresses comments 222 and 230 in the 802.11k letter ballot. Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks

January 2006 doc.: IEEE 802.11-06/0059r0 March 2006 Motion Instruct the editor to incorporate the normative text in XXX as comment responses for XXX. Mover: Sudheer Matta Second: Yes: No: Abstain. Sudheer Matta, Trapeze Networks Sudheer Matta, Trapeze Networks