Integra Systems, Inc. has engineered some of the toughest environments for voice over IP. Not only do you have to the right signal strength but also the correct CCI. In reality the clients algorithms also dictate the quality of the ability to maintain a call while roaming.

Voice over WLAN Roaming

At its most basic level, roaming in an enterprise IEEE 802.11 network occurs when an IEEE 802.11 client changes its access point (AP) association from one AP to another AP within the same WLAN.
Roaming is a client decision. The client is responsible for deciding it needs to roam, and then detecting, evaluating, and roaming to an alternative AP.

Roaming is a client decision. WLAN standards bodies (such as the IEEE) and industry bodies (such as the Wi-Fi Alliance) do not specify when a client should roam, or how the client determines to which alternative AP it should roam. Each vendor’s roaming algorithms are proprietary and are not generally published.

Client Roaming Decision
IEEE 802.11 clients typically decide to roam when the connection to the current AP becomes degraded. Roaming necessarily has some impact on client traffic because a client scans other IEEE 802.11 channels for alternative APs, re-associates, and authenticates to the new AP. Prior to roaming, a client may take some actions to improve its current connection without necessitating a roam:
• Data retries—The IEEE 802.11 MAC specifies a reliable transport. Every unicast frame sent between a wireless client and an AP is acknowledged at the MAC layer. The IEEE 802.11 standard specifies the protocol used to retry the transmission of data frames for which an acknowledgment was not successfully received.
• Data rate shifting—IEEE 802.11a, IEEE 802.11b, and IEEE 802.11g each support a variety of possible data rates. The data rates supported for a given frequency band (such as 2.4GHz or 5GHZ) are configured on the WCS/WLC and are pushed down to the APs using that frequency band. Each AP in a given WLAN then advertises the supported data rates in its beacons. When a client or AP detects that a wireless connection is becoming degraded, it can change to a lower supported transmission rate (lower transmission rates generally provide superior transmission reliability).
Although the roaming algorithms differ for each vendor or driver version (and potentially for different device-types from a single vendor), there are some common situations that typically cause a roam to occur:
• Maximum data retry count is exceeded—Excessive numbers of data retries are a common roam trigger.
• Low received signal strength indicator (RSSI)—A client device can decide to roam when the receive signal strength drops below a threshold. This roam trigger does not require active client traffic in order to induce a roam.
• Low signal to noise ratio (SNR)—A client device can decide to roam when the difference between the receive signal strength and the noise floor drops below a threshold. This roam trigger does not require active client traffic in order to induce a roam.
• Proprietary load balancing schemes—Some wireless implementations have schemes where clients roam in order to more evenly balance client traffic across multiple APs. This is one case where the roam may be triggered by a decision in the WLAN infrastructure and communicated to the client via vendor-specific protocols.
• Scan threshold—The minimum RSSI that is allowed before the client should roam to a better AP. When the RSSI drops below the specified value, the client must be able to roam to a better AP within the specified transition time. This parameter also provides a power-save method to minimize the time that the client spends in active or passive scanning. For example, the client can scan slowly when the RSSI is above the threshold and scan more rapidly when below the threshold.
• Transition time—The maximum time allowed for the client to detect a suitable neighboring AP to roam to and to complete the roam, whenever the RSSI from the client’s associated AP is below the scan threshold. The scan threshold and transition time parameters guarantee a minimum level of client roaming performance. Together with the highest expected client speed and roaming hysteresis, these parameters make it possible to design a WLAN network that supports roaming simply by ensuring a certain minimum overlap distance between APs.
• Minimum RSSI field—A value for the minimum RSSI required for the client to associate to an AP.
• Hysteresis—A value to indicate how much greater the signal strength of a neighboring AP must be in order for the client to roam to that AP. This parameter is intended to reduce the amount of roaming between APs if the client is physically located on or near the border between two APs.
Roaming Selection of a New AP
Channel Scanning
Wireless clients learn about available APs by scanning other IEEE 802.11 channels for available APs on the same WLAN/SSID. Scanning other IEEE 802.11 channels can be performed actively or passively as follows:
• Active scan—Active scanning occurs when the client changes its IEEE 802.11 radio to the channel being scanned, broadcasts a probe request, and then waits to hear any probe responses (or periodic beacons) from APs on that channel (with a matching SSID). The IEEE 802.11 standards do not specify how long the client should wait, but 10 ms is a representative period. The probe-request frames used in an active scan are one of two types:
– Directed probe—The client sends a probe request with a specific destination SSID; only APs with a matching SSID will reply with a probe response
– Broadcast probe—The client sends a broadcast SSID (actually a null SSID) in the probe request; all APs receiving the probe-request will respond, with a probe-response for each SSID they support.
• Passive scan—Passive scanning is performed by simply changing the clients IEEE 802.11 radio to the channel being scanned and waiting for a periodic beacon from any APs on that channel. By default, APs send beacons every 100 ms. Because it may take 100 ms to hear a periodic beacon broadcast, most clients prefer an active scan.
During a channel scan, the client is unable to transmit or receive client data traffic. There are a number of approaches clients take to minimize this impact to client data traffic:
• Background scanning—Clients may scan available channels before they need to roam. This allows them to build-up knowledge of the RF environment and available APs so they may roam faster if it becomes necessary. Impact to client traffic can be minimized by only scanning when the client is not actively transmitting data, or by periodically scanning only a single alternate channel at a time (scanning a single channel incurs minimal data loss)
• On-roam scanning—In contrast with background, on-roam scanning occurs after a roam has been determined necessary. Each vendor/device may implement its own algorithms to minimize the roam latency and the impact to data traffic. For example, some clients might only scan the non-overlapping channels.
Typical Scanning Behavior
Although most client roaming algorithms are proprietary, it is possible to generalize the typical behavior.
Typical wireless client roam behavior consists of the following activities:
• On-roam scanning—This ensures clients have the most up-to-date information at the time of the roam.
• Active scan—An active scan is preferred over a passive scan, due to lower latency when roaming.
There are some informational attributes that may be used to dynamically alter the roam algorithm:
• Client data type—For example, voice call in progress
• Background scan information—Obtained during routine periodic background scans
Ways in which attributes can be used to alter the scan algorithm include:
• Scan a subset of channels—For example, information from the background scan can be used to determine which channels are being used by APs in the vicinity.
• Terminate the scan early—For example, if a voice call is in progress, the first acceptable AP might be used instead of waiting to discover all APs on all channels.
• Change scan timers—For example, if a voice call is in progress, the time spent waiting for probe responses might be shortened during an active scan.

Screen Shot 2014-08-06 at 12.40.29 PM