What Causes a Probe Response?

The simple answer is that a Probe Request MMPDU does. Under what circumstances is such a frame sent?

A STA seeking to join a WLAN has a choice between listening on successive channels, waiting on each channel to hear a Beacon from an AP (this is known as a passive scan), or performing an "active scan" of the network, in which the STA transmits Probe Request MMPDUs on all available channels until the STA finds an AP, a timer expires and the user gives up, or until the device's battery runs out.

One disadvantage of a passive scan is that the STA does not know a priori which channel(s) are in use in a given physical location, so it must listen for a potential Beacon on each channel for some amount of time before moving to the next channel and listening there. It is possible that a STA might not hear a Beacon frame for quite a while.

In contrast, an active scan puts the STA in the driver's seat. The STA broadcasts[1] a Probe Request on every channel that its physical layer supports waiting long enough to hear a Probe Response before testing the next channel for the presence of an AP by sending a Probe Request on that channel. Figure 5-4 shows the structure of both the Probe Request and the Probe Response MMPDU. The Probe Request has the usual MMPDU header and two mandatory (variable-length) fields in the MMPDU frame body. The Probe Response has many optional Information Elements (IEs), but those that are present must be in the order listed in Figure 5-4.

[1] By using the verb "broadcast," we literally mean that the MAC-DA in Probe Request MMPDUs is 0xFFFFFF-FFFFFF. In Probe Request MMPDUs, the BSSID is also set to the "broadcast address" (since the STA does not yet know the BSSID value of the local BSS). Not surprisingly, the MAC-SA in the Probe Request MMPDU is the STA's own MAC address. The STA will learn the BSSID in the Probe Response MMPDU, if it ever hears one.

Figure 5-4. Structure of the Probe MMPDUs

graphics/05fig04.gif

The first three fields of the Probe Response are mandatory (because they are fixed-length fields) and they can be decoded because the receiver knows how long each of them is. For this to work properly, these must always be in the same order. The TLV-encoded fields may appear in any order. The one that is not listed that may be present is the Robust Security Network (RSN) IE (the RSN IE is being defined by the IEEE 802.11i TG; see Chapter 7, Security Mechanisms for Wireless LANs, for a description).

Certain of the parameter sets are mutually exclusive. For example, if an FH (Frequency Hopping) parameter set is present, then a DS (Direct Sequence) parameter set won't be present (and vice versa). The CF parameter set is only in Beacons or Probe Responses from APs in which a Point Coordinator is operating. The IBSS parameter set is only sent from STAs that are operating in IBSS mode (and, obviously, never from APs).

The Probe Response MMPDU has a much richer structure than the Probe Request, and strongly resembles a Beacon MMPDU. That similarity is not surprising, since the two types of MMPDUs are both sent by APs, and they are both serve similar functions. They both serve to advertise the parameters under which the WLAN operates, and are frequently referred to as a pair (i.e., "Beacon and Probe Response" or "Beacon or Probe Response").



A Field Guide to Wireless LANs for Administrators and Power Users
A Field Guide to Wireless LANs for Administrators and Power Users
ISBN: 0131014064
EAN: 2147483647
Year: 2005
Pages: 60
Authors: Thomas Maufer

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net