1. Frame Request-Report Enhancements
January 2006
doc.: IEEE /0059r0
March 2006
Frame Request-Report Enhancements
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Sudheer Matta, Trapeze Networks
Sudheer Matta, Trapeze Networks

2. Abstract 802.11k D3.0 in section 7.3.2.21.7 introduces Frame Request
January 2006
doc.: IEEE /0059r0
March 2006
Abstract
802.11k D3.0 in section 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

3. What can’t we use the existing Frame Request/Report for ?
January 2006
doc.: IEEE /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

4. January 2006
doc.: IEEE /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

5. Let’s Illustrate A very realistic scenario, in any enterprise. AP1
January 2006
doc.: IEEE /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

6. Illustration (contd) We have one AP, and we have 25 client associated.
January 2006
doc.: IEEE /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

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

8. January 2006
doc.: IEEE /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

9. Proposed Frame Request Element
January 2006
doc.: IEEE /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

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

11. January 2006
doc.: IEEE /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