At a 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. Depending on client capabilities, an 802.11 WLAN client may roam on the same WLAN between APs within the same frequency band or between the 2.4 GHz and 5 GHz frequency bands. Smartphones and tablets that have simultaneous cellular and Wi-Fi connections may seamlessly roam across networks provided there is a suitable infrastructure network design. When a client roams from a WLAN with one service set identifier (SSID) to a WLAN with another SSID, the roam will not be seamless. The Wi-Fi client logic maintains only one Wi-Fi WLAN authentication at a time.
WLAN clients may roam based solely on their software capabilities or they may rely on assisted roaming capabilities provided by the WLAN infrastructure APs. In the case of client controlled roaming, the client is responsible to determine if it needs to roam, and then detects, evaluates, and roams to an alternative AP. The software that resides in the client evaluates the quality of the current Wi-Fi connection, and executes the connection and roam logic to join an alternate AP to gain a better quality connection.
WLAN standard 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. The roaming algorithms for each vendor are proprietary and are not generally published.
Currently, IEEE 802.11k and 802.11r are the key industry standards for enabling seamless basic service set (BSS) transitions in the WLAN environment. The 802.11r and 802.11k standards support Wi-Fi 802.11r Fast Transition, secure authentication, and 802.11k neighbor list radio management.
With Cisco Unified WLAN controllers running release 7.4 or higher, mobile wireless devices running Apple iOS 6 and higher leverage 802.11k neighbor lists for enterprise roaming.
The following steps describe how an Apple iPhone requests, receives, and processes an 802.11k neighbor list:
The iPhone that is associated to an AP sends a request for a list of neighboring APs on the same WLAN. The request is in the form of an 802.11 management frame known as an action packet.
The AP responds with a list of neighboring APs on the same WLAN with their Wi-Fi channel numbers. This response frame is also an action packet.
The iPhone receives the response frame and identifies which APs are the entrants for upcoming roams.
The use of 802.11k radio resource management (RRM) process allows the mobile client device to roam efficiently and quickly. This is a requirement for good call quality in an enterprise environment where on-call roaming is common. As smartphone vendors adopt the 802.11r and 802.11k standards, their users can experience more efficient roaming along with good call quality during the roam.
The recommended WLAN controller (WLC) 802.11k configuration is to enable the RRM to provide both 2.4 GHz and 5 GHz AP channel numbers in the neighbor list response packets. Cisco recommends the use of 5 GHz band Wi-Fi channels for not only voice and video over WLAN calls but for all applications and devices.
With the neighbor list information, the mobile client device need not examine all of the 2.4 GHz and 5 GHz channels to find an AP it can roam to. This provides the following benefits:
Reduces channel utilization on all channels, thus increasing bandwidth on all channels.
Reduces roam times and improves the decision made by mobile devices.
Increases battery life of the device because the device is neither changing the radio configuration for each channel nor sending probe requests on each channel.
The device does not have to process all of the probe response frames it receives on a channel. It only needs to validate that it can connect to an AP that is provided in the list of APs in the 802.11k neighbor list response frame.
The recommended Enterprise security configuration for devices running Apple iOS 6 or higher is 802.11r Fast Transition. The IEEE 802.11r specification was approved in July 2008, and it follows the 802.11i specification of June 2004.
802.11r reduces the number of packets that are exchanged between the client and an AP. The client preauthenticates to the AP it will roam to before actually roaming. This means the roam itself occurs faster because the AP already has the client authentication credentials cached, resulting in fewer packets required between the client and the AP.
802.11r introduces the following standard-based fast transition:
Allows a client to establish security and QoS state to roam-to AP before (or during) reassociation.
Method 1: Over-the-Air (client to roam-to AP): Exchanges four packets over the Wi-Fi channel.
Method 2: Over the Distribution System (through the roam-from AP): Exchanges two packets over the Wi-Fi channel and two packets through Ethernet
The following guidelines and limitations currently affect 802.11r Fast Transition:
This feature is not supported on Mesh APs.
For APs in FlexConnect mode:
802.11r Fast Transition is supported only in centrally and locally switched WLANs in Cisco WLAN Release 7.3 and later.
This feature is not supported for the WLANs that are enabled for local authentication.
This feature is not supported on Cisco 600 Series OfficeExtend Access Points.
802.11r client association is not supported on APs in standalone mode.
802.11r fast roaming is not supported on APs in standalone mode.
802.11r fast roaming is not supported between local authentication and central authentication WLANs.
802.11r fast roaming is not supported if the client uses over-the-distribution-system (DS) preauthentication in standalone mode. In over-the-DS roaming, packets are sent on the wired infrastructure.
The service from a standalone AP to a client is only supported until the session timer expires.
TSpec is not supported for 802.11r fast roaming.
If a WLAN link latency exists, fast roaming is also delayed. The client must verify the voice or data maximum latency.
The WLAN controller (WLC) handles 802.11r Fast Transition authentication requests during roaming for both over-the-air and over-the-DS methods.
Over-the-DS is recommended because two of the required packets are sent on the wired connection of the APs, with two packets sent on the WLAN. If you do not select the DS option, then all the four packets are sent on the WLAN.
Recommended WLAN controller configuration for fast transition
Use the following WLAN configuration recommendations to add 802.11r Fast Transition clients to the WLAN network.
These recommendations are the result of cooperative work between Apple and Cisco.
Configure an additional WLAN for fast transition 802.1x clients.
Configure an additional WLAN for fast transition PSK clients.
Apple and Cisco recommend that you use separate WLAN and service set identifiers (SSIDs) for legacy clients.
The reason for these recommendations is that the legacy radio drivers cannot interpret the added information in the association response packets of a WLAN with fast transition configurations. Although the 802.11r specification was approved in the year 2008, not all client radio drivers have been updated to handle the changes in management packets with respect to 802.11r. This includes several Apple products.
The 802.11r specification changes the Wi-Fi packet structure. Legacy clients may not be programmed to accommodate the change and they fail to associate to a WLAN that enables 802.11r. Therefore it is recommended that you use a new WLAN for 802.11r-capable devices. iPad2 is an example of a device that cannot join an 802.11r WLAN.
The following figure shows a WLAN infrastructure with multiple WLANs and SSIDs to accommodate a range of client devices with varying specification support.
Figure 1. Example of Multiple WLANs and SSIDs
For information about command line interface (CLI) or graphical user interface (GUI) fast transition configuration options, see the Cisco Wireless LAN Controller Configuration Guide at http://www.cisco.com/ corresponding to the installed version of WLC firmware.
802.11 wireless clients detect that roaming is required when the connection to the current AP degrades. Roaming necessarily affects client traffic because a client scans other 802.11 channels for alternative APs, reassociates, and authenticates to the roam-to AP. Before roaming, a client takes the following actions to improve its current connection without necessitating a roam:
Data retries: The IEEE 802.11 MAC specifies a reliable transport. Every unicast frame that is sent between a wireless client and an AP is acknowledged at the MAC layer. The IEEE 802.11 standard specifies the protocol that is used to retry the transmission of data frames for which an acknowledgment was not received.
Data rate shifting: IEEE 802.11a, 802.11b, and 802.11g each support a variety of possible data rates. The data rates that are supported for a given frequency band (for example, 2.4 GHz or 5 GHz) are configured on the wireless control system server (WCS) or WLC and are pushed down to the APs using that frequency band. Each AP in a given WLAN then promotes the supported data rates in its beacons. When a client or AP detects that a wireless connection is degrading, it can change to a lower supported transmission rate, because 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), the following common situations can typically cause a roam to occur:
Maximum data retry count is exceeded: Excessive number 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 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 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 through vendor-specific protocols.
Cisco Compatible Extensions client roam triggers
Wireless LAN Controllers (WLC) are configured with a default set of RF roaming parameters that are used to set the RF thresholds that are adopted by the client to decide when to roam. You can override the default parameters by defining a custom set. These Cisco Compatible Extensions (CCX) parameters are defined on the WLC once for each IEEE 802.11 frequency band (2.4 GHz or 5 GHz).
WLAN clients that run on Cisco Compatible Extensions Version 4 or later are able to use the following parameters (which are communicated to the client through the Enhanced Neighbor List feature that is described in
Cisco Compatible Extensions channel scanning):
Scan threshold: The minimum RSSI that is allowed before the client can 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 RSSI is above the threshold and scan more rapidly when RSSI is below the threshold.
Transition time: The maximum time that is allowed for the client to detect a suitable neighboring AP to roam to and to complete the roam, whenever the RSSI from the clients 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 (for a definition of hysteresis,see below) these parameters help to design a WLAN network that supports roaming just by ensuring a certain minimum overlap distance between APs.
Minimum RSSI field: A value for the minimum RSSI that is 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 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.
Call admission control (CAC): A call admission control denial from the WLAN infrastructure can cause the client device to roam.
Even though a wireless client may be CCX compatible, it may still rely on 802.11k or its own proprietary roaming algorithm instead of the CCX triggers listed above.
Roaming selection of a new access point
Wireless clients learn about available APs by scanning other 802.11 channels for available APs on the same WLAN or SSID. The wireless clients can scan other IEEE 802.11 channels in the following two ways:
Active scan: Active scanning occurs when the client changes its 802.11 radio to the channel that is being scanned, broadcasts a probe request, and then waits to receive any probe responses (or periodic beacons) from APs on that channel (with a matching SSID). The 802.11 standards do not specify how long the client must wait, but 10 ms is a representative time period. The probe-request frames that are used in an active scan are of the following two types:
Directed probe: The client sends a probe request with a specific destination SSID; only APs with a matching SSID reply with a probe response.
Broadcast probe: The client sends a broadcast SSID (actually, a null SSID) in the probe request; all APs that receive the probe-request respond with a probe-response for each SSID that it supports.
Passive scan: Passive scanning occurs when the client changes its 802.11 radio to the channel that is being scanned, and waits for a periodic beacon from any APs on that channel. By default, APs send beacons every 100 ms. Most clients use active scan because it takes 100 ms to receive a periodic beacon broadcast in a passive scan.
During a channel scan, the client is unable to transmit or receive client data traffic. Clients use the following approaches to minimize this impact to client data traffic:
Background scanning: Clients scan the available channels before they roam. The scans provide information about the RF environment and available APs that can help clients to roam faster, if necessary. The affect to client traffic can be minimized by scanning only 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: On-roam scan occurs after the client determines a roam is necessary. Each vendor or device can implement its own algorithms to minimize the roam latency and the affect to data traffic. For example, some clients might scan only the nonoverlapping 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 scan: Ensures that 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 because of lower latency when roaming.
WLAN clients can use the following informational attributes to dynamically alter the roam algorithm:
Client data type, for example, voice call in progress.
Background scan information that is obtained during routine periodic background scans.
The different ways in which a WLAN client can use the attributes to alter the scan algorithm are as follows:
Scan a subset of channels: For example, the client can use information from the background scan to determine channels that are being used by APs in the vicinity.
Terminate the scan early: For example, if a voice call is in progress, the client can use the first acceptable AP instead of waiting to discover all APs on all channels.
Change scan timers: For example, if a voice call is in progress, the client can use active scan to minimize the time that it spends waiting for probe responses.
Cisco Compatible Extensions channel scanning
While WLAN clients ultimately determine when to associate (or reassociate) to an AP, Cisco APs provide information to clients to facilitate AP selection by providing information (such as channel load in its beacons and probe responses) or by providing a list of neighboring APs.
WLC software Release 4.0 and later support the following Cisco Compatible Extensions, layer 2 client-roaming enhancements:
AP assisted roaming: This feature helps clients to save scan time. Whenever a Cisco Compatible Extensions v2 client associates with an AP, it sends an information packet to the new AP listing the characteristics of its previous AP. The AP uses this information to build a list of previous APs, which it sends (through unicast) to clients immediately after association to reduce roaming time. The AP list contains the channels, basic service set identifiers (BSSIDs) of neighbor APs that support the current SSIDs of the client, and time elapsed since disassociation.
Enhanced neighbor list: This feature is an Cisco Compatible Extension v4 enhancement to the neighbor list that is sent as part of the v2 AP assisted roaming feature. It is always provided automatically by the AP to the client immediately following a successful association or reassociation. Because the AP periodically checks to ensure its neighbor list is up to date, it can also send an automatic update to the corresponding clients. The enhanced neighbor list includes, for each AP, the RF parameters that are discussed in Cisco Compatible Extensions client roam triggers. In addition, it can also include, for each AP in the list, additional information about AP timing parameters, information about the AP support for the clients subnet, and the strength and signal-to-noise ratio (SNR) of the last transmission from the client that is received by the AP.
Enhanced neighbor list request (E2E) The end-to-end (E2E) specification is a Cisco and Intel joint program that defines new protocols and interfaces to improve the overall voice and roaming experience. It applies only to Intel clients in a Cisco Compatible Extensions environment. Specifically, it enables Intel clients to request a neighbor list at anytime. When this occurs, the AP forwards the request to the WLC. The WLC receives the request and replies with the current Cisco Compatible Extensions roaming sublist of neighbors for the AP to which the client is associated.
To check whether a particular client supports E2E, click Wireless > Clients on the WLC GUI, and then click the Detail link for the desired client. Also check the E2E Version field under Client Properties.
Directed roam request: This feature enables the WLC to send directed roam requests to the client in situations when the WLC can better service the client on an AP that is different from the one to which the client is associated. In this case, the WLC sends the client a list of the best APs that it can join. The client can either respond to or ignore the directed roam request. Non-Cisco Compatible Extensions clients and clients running Cisco Compatible Extensions Version 3 or prior must not take any action. No configuration is required for this feature.
WLC software Release 4.0 supports Cisco Compatible Extensions Versions 1 through 4. Cisco Compatible Extensions support is enabled automatically for every WLAN on the WLC and cannot be disabled. The WLC stores the Cisco Compatible Extensions version of the client in its client database and uses it to generate and respond to Cisco Compatible Extensions frames appropriately. Clients must support Cisco Compatible Extensions Version 4 (or Cisco Compatible Extensions Version 2 for AP assisted roaming) to utilize roaming enhancements.
Many smartphones and tablets and other mobile devices are not CCX-aware and therefore do not use these CCX parameters.
Evaluating the list of potential roam targets
After the wireless client receives a list of potential APs to which it can roam, the client uses a client-specific algorithm to choose a specific AP to which it will roam. The roaming algorithm must consider the following factors in its calculations:
Received signal strength indicator (RSSI)
Signal-to-noise ratio (SNR)
Number of clients on the AP
Transmit and receive bandwidth that is being used by the AP
RF channel load information from beacon and probe responses that is sent by the AP
Reauthenticating to a new access point
When a wireless client initially joins a WLAN, it must authenticate before it is granted access to the network. This section describes the following considerations and processes:
Reauthenticating when roaming
You can use the following authentication schemes for WLAN access:
Open authentication: This is a null authentication; any client is permitted to access the WLAN.
Wired Equivalent Privacy (WEP) shared key (static WEP): The static WEP requires both sender and receiver to have the same preprovisioned key to decode messages from each other.
Wi-Fi Protected Access (WPA)-Personal and WPA2-Personal: A shared key, which is not the encryption key, is configured on both the WLAN and the WLAN client, and this key is used in the WPA four-way handshake to generate a per-session encryption key.
IEEE 802.1X/Extensible Authentication Protocol (EAP) authentication used in WPA-Enterprise or WPA2-Enterprise: Depending on the deployment requirements, you can use one of the following EAP authentication protocols for secure wireless deployments:
Protected EAP (PEAP)
EAP-Transport Layer Security (EAP-TLS)
EAP-Flexible Authentication through Secure Tunneling (EAP-FAST)
Regardless of the protocol that you use, all the preceding protocols currently use IEEE 802.1X, EAP, and remote authentication dial-in user service (RADIUS) as their underlying transport. Based on the successful authentication of the WLAN client, these protocols allow network access, and vitally, allow the WLAN network to be authenticated by the user.
The basic flow of an IEEE 802.1X/EAP authentication is shown in Figure 2. In that figure, the portion labeled Authentication conversation is between client and Authentication Server represents the authentication process between the client and the authentication server. This authentication requires the WLC to transmit multiple packets between the client and the authentication server. This portion of the authentication flow also requires CPU-intensive cryptographic processing at both the client and the authentication server. This part of the authentication is where latency can easily exceed one second and is the focus of the fast roaming algorithms that are discussed in the following section.
Reauthenticating when roaming
This section describes roaming with different authentication types:
Roaming with open authentication or static WEP
Roaming with IEEE 802.1X or EAP authentication
Fast secure roaming
Fast roaming with Proactive Key Caching
Roaming with open authentication or static WEP
When a client roams using open authentication (no keys) or using shared keys, authentication adds little roam latency. This is because no additional packets need to be exchanged between the client and the AAA server.
Roaming with IEEE 802.1X or EAP authentication
When a client roams using IEEE 802.1X with dynamic WEP, WPA-enterprise, or WPA2-enterprise, an IEEE 802.1X authentication generally must occur with an AAA/RADIUS server. Authenticating with an AAA/RADIUS server can take more than one second. A one second interruption to latency-sensitive applications, such as voice or video over IP, when roaming is unacceptable, and therefore fast secure roaming algorithms that are developed help to reduce the roam latency.
Fast secure roaming
Fast roaming algorithms include Cisco Centralized Key Management (CCKM), Opportunistic Key Cache (OKC), and Proactive Key Caching (PKC). CCKM and PKC allow a WLAN client to roam to a new AP and reestablish a new session key, namely pairwise transient key (PTK), between the client and AP without requiring a full IEEE 802.1X or EAP reauthentication to a AAA/RADIUS server.
Both CCKM and PKC are Layer 2 roaming algorithms and therefore they do not consider any Layer 3 issues, such as IP address changes. In the Cisco Unified Wireless Network, the subnets are responsible to allocate IP addresses that originate at the WLC to the clients, and not the AP. You can achieve the following benefits from CCKM and PKC:
Helps to group large number of WLAN clients for a given SSID into the same Layer 2 subnet.
Maximizes the scope of the Layer 2 domain-and the fast secure roaming domain.
In addition, multiple-WLC deployments support client roaming across APs managed by WLCs in the same mobility group on the same or different subnets. This roaming is transparent to the client because the session is sustained and a tunnel between the WLCs allows the client to continue using the same DHCP-assigned or client-assigned IP address as long as the session remains active.
Fast secure roaming with Cisco Centralized Key Management
CCKM is a Cisco standard supported by Cisco Compatible Extensions clients to provide fast secure roaming.
CCKM requires support in the client. Cisco Compatible Extensions provides client-side specifications for support of many client functions, including fast secure roaming. The following table summarizes the supported EAP types in each version of Cisco Compatible Extensions.
Table 1 Cisco Compatible Extensions EAP Support
Cisco Compatible Extensions Version
Supported EAP Types
Cisco Compatible Extensions Version 2
CCKM with Lightweight Extensible Authentication Protocol (LEAP)
Cisco Compatible Extensions Version 3
CCKM with LEAP, EAP-FAST
Cisco Compatible Extensions Version 4
CCKM with EAP, EAP-FAST, EAP-TLS and LEAP
CCKM establishes a key hierarchy upon initial WLAN client authentication and uses that hierarchy to quickly establish a new key when the client roams. The following sections describe the initial establishment and roam phases:
Figure 1 through Figure 4 illustrate the initial key hierarchy establishment process. In WPA-Enterprise and WPA2-Enterprise, the outcome of a successful EAP authentication (see Figure 2) is a pairwise master key (PMK).
The following figure shows the establishment of PMK at the client and the AAA/RADIUS server, and the subsequent forwarding of the PMK to the WLC.
Figure 2. CCKM Initial Key (Part 1 of 4)
The WLC and the client both derive a network session key (NSK) from the PMK. After the NSK is established, the WPA-prescribed four-way handshake is performed between the client and the WLC. At the conclusion of the four-way handshake, a base transient key (BTK) and key request key (KRK) are established. See the following figure.
Figure 3. CCKM Initial Key (Part 2 of 4)
WPA and WPA2 differ only slightly from CCKM at this point. WPA/WPA2 uses the PMK directly (instead of deriving an NSK), and after the four-way handshake, establishes a pairwise transient key (PTK), thus concluding the establishment of the WPA/WPA2 unicast key.
Both the client and the WLC hash the BTK, an initial rekey number (RN)=1, and the BSSID to derive a PTK. The WLC then forwards the PTK to the AP over the Control and Provisioning of Wireless Access Points (CAPWAP) tunnel. See the following figure.
Figure 4. CCKM Initial Key (Part 3 of 4)
The client and AP communicate using the PTK to encrypt the data sent between them. See the following figure.
Figure 5. CCKM Initial Key (Part 4 of 4)
CCKM roaming - client roam
CCKM is intended to provide very fast roaming. In the absence of CCKM, a WPA/WPA2 client must perform a full EAP authentication to a remote AAA/RADIUS server, followed by a WPA/WPA2 four-way handshake whenever it roams. This process can take more than one second. With CCKM, the roaming client and WLC can use preestablished keying material to immediately establish a PTK, normally within a few tenths of a millisecond.
When the client roams to a new AP, the client sends a reassociate request with the next sequential rekey number. Protection against spoofed reassociate requests is provided by the Message Integrity Check (MIC) that the client adds to the reassociate request (the MIC is generated using the KRK as cryptographic input). The reassociate request is forwarded by the AP to the WLC and the MIC is validated. See the following figure.
Figure 6. CCKM Roam Key (Part 1 of 2)
The WLC calculates the next PTK, and forwards it to the AP. The client and the AP can now communicate using the new PTK to encrypt the data sent between them. See the following figure.
Figure 7. CCKM Roam Key (Part 2 of 2)
Fast roaming with proactive key caching
PKC is an IEEE 802.11i extension that allows for proactive caching (before the client roaming event) of the WPA/WPA2 PMK that is derived during a client IEEE 802.1 x/EAP authentication at the AP. See the following figure.
Figure 8. PKC Roam
If a PMK (for a given WLAN client) is already present at an AP when presented by the associating client, full IEEE 802.1X/EAP authentication is not required. Instead, the WLAN client can simply use the WPA four-way handshake process to securely derive a new session encryption key for communication with that AP.
PKC is an IEEE 802.11i extension and so it is supported in WPA2, but not in WPA.
In Cisco Unified Wireless deployment, the distribution of the cached PMKs to APs is simplified. The PMK is cached in the WLCs and made available to all APs that connect to that WLC, and between all WLCs that belong to the mobility group of that WLC in advance of a client roaming event.
802.11r Fast Transition roaming
802.11r secure roaming is achieved with the exchange of fewer packets due to caching on the clients, APs, and WLC. The client preauthenticates to the roam to AP before the client actually roams to the roam to AP. So, the actual roams occurs faster because fewer packets are exchanged between the AP and the client. The packets that are exchanged happen while the client is still associated to the roam to AP, therefore no time is lost in the exchange of data packets, because the client is reauthenticated to the roam to AP.
Following are the two options for 802.11r roam configuration:
Fast Transition (FT) roaming only over the air
FT roaming with authentication packets on the infrastructure
The 802.11r Fast Transition authentication request and response can occur over the Wi-Fi channel as shown in the following figure.
Figure 9. 802.11r Fast Transition Roaming over Wi-Fi Channel
Alternatively, the 802.11r Fast Transition authentication request and response can occur over the wired network subnet. This is also known as roaming over the distributed system (DS), as shown in the following figure.
Figure 10. 802.11r Fast Transition Roaming with the Aid of the Wired Network Subnet
When a client roams from one AP to another, it must determine if it requires a new IP address, or if it can continue to use its old IP address. The client must take the following actions while roaming:
In a Cisco WLC deployment, client IP addresses do not change when they roam within the same mobility group. WLC deployments support client roaming across APs that are managed by one or more WLCs in the same mobility group on the same or different subnets. This roaming is transparent to the client because the session is sustained and a tunnel between the WLCs allow the client to continue using the same DHCP-assigned or client-assigned IP address as long as the session remains active.
Clients that roam without a Cisco fast secure roaming protocol (CCKM or PKC), send a DHCP request asking for their current IP address. In a Cisco WLC environment, the WLC infrastructure ensures that the client stays on the same subnet and can continue to use its old IP address. Next, the client performs duplicate address detection by pinging its own IP address to ensure that the WLAN client does not respond with the same IP address that it is using. If a client is running a mobile IP or VPN, those protocols would run after the IP address is verified unique.
Infrastructure impacts of client roaming
When a wireless client authenticates and associates with an AP, the WLC of the AP places an entry for that client in its mobility database. This entry includes the client MAC and IP addresses, security context and associations, QoS context, WLAN, and associated AP. The WLC uses this information to forward frames and manage traffic to and from the wireless client.
When the wireless client moves its association from one AP to another, the WLC updates the client database with the new associated AP. If necessary, new security context and associations are established as well.
Multiple-WLC deployments support client roaming across APs managed by WLCs in the same mobility group on the same or different subnets. This roaming is transparent to the client because the session is sustained and a tunnel between the WLCs allow the client to continue using the same DHCP-assigned or client-assigned IP address as long as the session remains active. The following figure illustrates the roaming in this context.
Figure 11. WLAN Infrastructure-Roam
Measuring roam latency
You can segment a roam into the following components:
Client roam decision
Choosing a new AP to which a client roams
Reauthenticating to the new AP
IP layer configuration
Infrastructure impacts of client roam
Each of the preceding components contributes to add latency to a roam. However, there is no industry consensus on how to measure roam latency. The most realistic measure of roam latency is from the last packet that is sent by the roaming client on the old AP to the first packet that is received by the roaming client on the new AP. This ensures all the preceding components are measured and ensures a two-way communication is established as illustrated in the following table:
Table 2 Summary of Roam Latency Measurement Process
Last packet that is sent by roaming client on old AP
Ensures two-way communication is still established when the roam latency measurement starts. It is common for the frames to continue to be forwarded to the roaming client on the old AP after the client has started the roam.
First packet that is received by roaming client on new AP
Ensures two-way communication by ensuring that the clients new location has been learned by the network infrastructure and that the client is receiving packets as well as sending them.
When comparing roam latency for different WLAN implementations, make sure that you use the same criteria to measure roam latency in each case.
Monitoring client roaming
In addition to the Cisco Compatible Extensions Version 4 channel-scanning capabilities, Cisco Compatible Extensions Version 4 clients also send a Roam Reason Report to indicate why they roamed to a new AP. It also allows network administrators to build and monitor a roam history.
Use the Cisco Wireless LAN Controller command line interface commands that are listed in the following table to view information about Cisco Compatible Extensions Layer 2 client roaming:
Debug reports for the Cisco Compatible Extensions Layer 2 client roaming
802.11k management frame format
The following figure shows a decoded 802.11k neighbor list packet that is captured from a WildPackets sniffer trace. This packet was sent from the AP that an Apple iPhone 5 was associated to. The iPhone sent a neighbor request frame to the AP. The AP responded with a list of the APs that are its current neighbors. Embedded in the 802.11k neighbor list response frame is the MAC addresses of three neighbor APs and the Wi-Fi channel of each of those APs. With this information available, the 802.11k mobile client does not need to scan all the 5 GHz channels looking for candidate AP to roam to. The software of the 802.11k client can roam APs that have matching credentials and are known to be in the coverage area of the client, which saves battery life, reduces unnecessary usage of the Wi-Fi channel, and keeps the phone on the Wi-Fi channel that is doing the call processing to maintain a high-quality call with a higher mean opinion score (MOS) value. The following figure shows all the element information that is requested by the mobile client. The 802.11k specification allows for more elements of information and more detail.
Figure 12. 802.11k Decoded Packet with Neighbor List