1. Broadcast Probe Responses
July 2006
Broadcast Probe Responses
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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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