Broadcast Probe Responses July 2006 Broadcast Probe Responses Date: 2006-07-18 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

Abstract Probe Requests and responses are excessive July 2006 Abstract Probe Requests and responses are excessive This proposal is exploring ideas of enhancing probe responses, to make them more efficient. Sudheer Matta, Trapeze Networks

July 2006 Probe Requests: Why? Probe requests are sent for any or all of the following reasons…(and for reasons not obvious to the author) To find a network that can provide service Initial connection to the network To find a “better” network Current connection is not satisfactory or degrading For Rogue detection (by access points trying to figure out other access point This is done by the access points primarily. For location application To let the receiver know where the transmitter is … and numerous other application. Sudheer Matta, Trapeze Networks

Probe Requests: How often? July 2006 Probe Requests: How often? Probe requests are sent as often as the application needs or the developer feels like To find a network that can provide service Once every 20ms or continuously until an AP accepts the client To find a “better” network From 1 second to 2 minutes For Rogue detection (by access points trying to find out other access point) This is done by the access points primarily. This is again is very application specific and the conventional wisdom leans towards more probing than less, faster detection of rogues ..etc. For location application To let the receiver know where the transmitter is Another very time sensitive application … and numerous other applications. Sudheer Matta, Trapeze Networks

Current Probe Response Format July 2006 Current Probe Response Format Enhance probe responses to let everyone receive them. Broadcast the probe responses. Current standard, Probe Response In the header there are 3 address fields Address 1 – Unicast/Multicast/Broadcast address Address 2 – AP’s Mac address (sender) Address 3 – BSSID (AP’s mac) Sudheer Matta, Trapeze Networks

Proposed Probe Response Format July 2006 Proposed Probe Response Format Proposed enhancement, Probe Response address field definitions In the header there will be 4 address fields Address 1 – Broadcast address Address 2 – AP’s Mac address (sender) Address 3 – BSSID (AP’s mac) Address 4 – Probe requestor The Probe requestor will acknowledge the broadcast probe response Sudheer Matta, Trapeze Networks

July 2006 Proposal Details What we are proposing here is that all probe responses will be heard by all devices. How does this work: Devices that hear the broadcast probe response don’t have to probe again! For stations that are not moving (RSSI not bouncing all over the map ..as an example), just listen for probe responses, and if you hear one, in your last ‘re-probe interval’ because someone already did the probe for you, don’t probe! If not send a Probe request and solicit a response, and let the rest of the devices benefit. Sudheer Matta, Trapeze Networks

July 2006 Proposal Advantages The proposal does NOT add any additional frames on the channel. Has a potential of dramatically reducing the probe requests on air Who are the beneficiaries: Non-power saving windows laptops that are sitting in one place That is all of your devices (right now, could be benefitting from collaborative probe request/responses) APs trying to figure out where other APs are, now they will constantly be updated The reliability of existing probe request response is retained at status quo Sudheer Matta, Trapeze Networks

July 2006 Legacy Operation Legacy devices will probe normally, without the new capability indicated. So they get a Probe response like they normally do. 802.11v capable devices will probe with the capability indication set. Sudheer Matta, Trapeze Networks