Final Report Client Steering - H-BRS · Solarmesh Final Report Client Steering August 27, 2014 Zuwendungsempfänger HochschuleBonn-Rhein-Sieg Förderkennzeichen 01BU1116 Vorhabenbezeichnung

Solarmesh

Final Report Client Steering

August 27, 2014

Zuwendungsempfänger Hochschule Bonn-Rhein-Sieg

Förderkennzeichen 01 BU 1116

Vorhabenbezeichnung SolarMeshEnergieeffizientes, autonomes großflächiges Sprach-und Datenfunknetz mit flacher IP- Architektur

Teilvorhabenbezeichnung Evaluation of LANCOMs Client Steering technique

Laufzeit des Vorhabens 4. March 2014 - 31 August 2014

Berichtszeitraum 4. March 2014 - 31 August 2014

Durchführende Stelle Fachbereich 02 Michael Rademacher

SolarMesh Final Report Client Steering

List of authors

Hochschule Bonn-Rhein-Sieg Michael Rademacher

c© Solarmesh 2014 i


Contents

List of Figures iii

List of Tables iv

1 Introduction 1

2 State of the Art 32.1 Standardized Radio Resource Management . . . . . . . . . . . . . . . . . . . 3

2.1.1 Control And Provisioning of Wireless Access Points (CAPWAP) . . 32.1.2 Institute of Electrical and Electronics Engineers (IEEE) . . . . . . . 4

2.2 Competing products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1 Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Aruba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 LANCOM Client Steering . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Methodology 103.1 Hard- and Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Scenarios and goals of the measurement . . . . . . . . . . . . . . . . . . . . 12

3.3.1 New Client association . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3.2 Client steering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.3 Client Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Experiments 154.1 Aruba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 LANCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Results 24

6 Conclusion 266.1 Possible future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

References 27

c© Solarmesh 2014 ii


List of Figures

3.1 Schematically view on the test-environment. . . . . . . . . . . . . . . . . . . 113.2 OpenWRT routers in client mode . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Client association scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4 Client Steering and Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5 Example for a ping test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

c© Solarmesh 2014 iii


List of Tables

1 LANCOM Client Steering parameter . . . . . . . . . . . . . . . . . . . . . . 82 Used hardware for the Client Steering test . . . . . . . . . . . . . . . . . . . 103 Used client devices for the Client Steering test . . . . . . . . . . . . . . . . . 104 Results Aruba Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Results Aruba scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Aruba Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Average unavailability time . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Results Cisco Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Results Cisco Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910 Average unavailability time . . . . . . . . . . . . . . . . . . . . . . . . . . . 1911 LANCOM Client Steering defaults and adapted values . . . . . . . . . . . . 2112 Results LANCOM Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 2113 Results Lancom Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2214 Aruba Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2315 Average unavailability time . . . . . . . . . . . . . . . . . . . . . . . . . . . 2316 Client connecting based on TXPower of the Access Point (AP) . . . . . . . 2417 Client connecting based on channel number of the AP . . . . . . . . . . . . 25

c© Solarmesh 2014 iv


List of Acronyms

AP Access Point

BSSID Basic Service Set Identification

CAPWAP Control And Provisioning of Wireless Access Points

CPE Customer Premises Equipment

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IETF The Internet Engineering Task Force

ISM Industrial, Scientific and Medical

ISP Internet Service Provider

LCOS LANCOM Operating System

LWAPP Lightweight Access Point Protocol

MCS Modulation and Coding Scheme

PoE Power over Ethernet

QoS Quality of Service

RFC Request for Comments

RSSI Received Signal Strength Indication

SSID Service Set Identifier

SNR Signal-to-noise ratio

UDP User Datagram Protocol

VoIP Voice-over-IP

WLC Wireless LAN Controller

c© Solarmesh 2014 v

SolarMesh Final Report Client Steering 1 Introduction

1 Introduction

Using IEEE802.11 [iee12b] as alternative access technology for Internet provisioning in ruralareas provides different advantages compared to traditional approaches. The hardwareinvolved is well-developed and well-priced compared to cellular networks (3G, 4G) andWiMAX [iee09]. Additionally, the costs are reduced by the fact that customers alreadyown devices equipped with 802.11 radios. This could lead to a situation where there isno need for an Internet Service Provider (ISP) to provide additional Customer PremisesEquipments (CPEs). However, when operating 802.11 APs in the Industrial, Scientific andMedical (ISM)-band serving connectivity to numerous customers several problems occur.

The 2.4 GHz ISM-band is usually crowded and provides only three non-overlapping chan-nels [Rec12]. In contrasts the 5 GHz ISM-Band provides more bandwidth and offers at least23 non-overlapping channels. Additionally, the majority of clients and APs still operatesexclusively at 2.4 GHz so that the overall 5 GHz band is used less. Many devices currentlybuild are using dual-radios1. This provides the possibility to decide either to connect to anAP using the 2.4 or 5 GHz band. However, this decision involves a responsible customerswhich is aware of this problem. The Band steering technique tries to conduct this decisionfor customers by directing their devices to the 5 GHz band if this is a reasonable andpossible opportunity. This intelligent process could lead to a less crowded 2.4 GHz bandand provides a better utilization of radio capacities.

In typical access scenarios several APs will be used to provide a full coverage in a specificarea. Usually the deployment of several APs leads to part of this area where one client canreceive the signal of multiple APs at the same time. Usually the client will try to associateto the AP with the strongest signal2 and stick to this AP as long the Received SignalStrength Indication (RSSI) is found above a certain threshold. This decision is simplebut does not provide the best solution for every scenario. Depending on the placementof the APs, a situation can occur where one AP is crowded with clients while other APshave unused capacities. Publications indicate that in crowed coverage scenarios users areunevenly distributed [BCI+09] in the area and the number of associated clients varies widelyfrom AP to AP. This leads to an unevenly load-distribution which can degrade the Qualityof Service (QoS) for every customer in the network. "Load balancing (Client Steering)aims at solving this problem by forcing clients to roam towards less loaded neighbor AP"[BCI+09]. The IEEE802.11a/b/g/n standards do not provide mechanisms to control theassociation of client to a specific AP. However, amendments to the 802.11 standard,Request for Commentss (RFCs) and networking vendors selling enterprise wireless LANproducts have proposed and implemented different possible solutions.

First, these approaches will be described (section 2) and afterwards evaluated using con-trollable test scenarios (section 4). Experiments have been conducted aiming at evaluatingthe usability of these techniques to provide an increased QoS for 802.11 access networks.The approaches of three different enterprise wireless LAN vendors will be compared: Aruba

1The upcomming 802.11ac standard will be solely operating in the 5 GHz Band2It will be shown in this report that this varies for different client implementations.

c© Solarmesh 2014 1

SolarMesh Final Report Client Steering 1 Introduction

Networks, Cisco Systems, LANCOM Systems3 using different real-world clients. A specialfocus of this report will be placed on LANCOMS Client Steering solution which was devel-oped in the context of the Solar Mesh project4. The report closes with a summarizationof the results and possible future work for additional improvements.

3Hereafter noted as Aruba, Cisco, LANCOM4http://solarmesh.de/



2 State of the Art

This section describes the current state of the art for an improved load balancing in 802.11access networks. The purpose is to provide an overview of competing products and comparetheir functionality and mechanism. This provides the reader with the needed backgroundinformation to understand and rate the conducted experiments in section 4.

The current state of the art when deploying large scale wireless networks implies the usageof a Wireless LAN Controller (WLC). There are numerous types of WLC available on themarket developed by different companies. The main quality feature is the number of APsa single WLC can handle simultaneously [Rec12]. Additionally, WLCs differ in the numberof functionalities which is transfered from the AP to this central control unit. A commonway is to keep the time-critical functions of 802.11 [iee12b] at the AP and use the WLC asa central management and routing approach for the WiFi infrastructure.

The rest of this section is structured as follows. First, standardized radio resource manage-ment protocols are described. Afterwards the implementations of three different vendorsare compared which partly exploit the described standards.

2.1 Standardized Radio Resource Management

2.1.1 Control And Provisioning of Wireless Access Points (CAPWAP)

For the communication between WLC and AP a protocol is needed. At the moment severalvendors provide their own implementation of this communication process. However, severaluniform protocols established [Rec12] over the time. Cisco developed the LightweightAccess Point Protocol (LWAPP) and their afford in standardizing this protocol resultedin the RFC 5412 [CSCW+10] which is today marked as ’historic’. Based on the LWAPPand one additional RFC 4564 [GCY+06] the CAPWAP arose. This protocol is todaystandardized in the RFC 5416 [CMS09] and provides interoperability to LWAPP.

The CAPWAP uses two User Datagram Protocol (UDP) sockets for control and datainformation. The data socket acts as a tunnel to exchange data frames between the APsand WLC. In this mode, layer 2 packets get encapsulated and transported via layer 3.Using this technique it is possible to summarize APs in different subnets to one logicalinfrastructure. This results in the possibility to operate a distributed WiFi network withone Service Set Identifier (SSID) and provide roaming functionalities without the need toexchange the IP address. The authors in [BCI+09] summarized the main goals of CAPWAPas follows:

• Centralize authentication and policy enforcement functions for a wireless network;

• move processing away from the APs, leaving only time critical functions and

• provide a generic encapsulation and transport mechanism.



Load Balancing using CAPWAP Besides an Open Source implementation of theCAPWAP protocol [BCI+09] describes a possibility for load balancing in 802.11 networks.In their definition load balancing "deals with the problem of distributing users to APs.The goal is to balance the resource allocation in order to avoid congestion and improveperformance." An idea to implement load balancing using the CAPWAP by dynamicallysetting the transmission power levels of the AP is described. This results in a techniquecalled cell breathing. The optimization of the power levels follows two main goals:

• Maximize the number of clients associated to the network.

• Minimize the number of clients associated to a single AP.

This optimization process can be conducted by including the PHY specific information ofeach frame (and therefore for each client) in the data traffic from the APs to the WLC. Theconfiguration of the AP can afterwards5 be conducted using the 802.11 TXPower messageelement within the CAPWAP control messages. While the authors in [BCI+09] describecomprehensively their idea, the publication does not include the optimization algorithmand therefore this technique can not be included into the comparison process.

2.1.2 IEEE

Besides the The Internet Engineering Task Force (IETF) also the IEEE provides amend-ments to the 802.11 standard with the goal to provide a better QoS in access networks withnumerous stations. Mainly three different standards provide (in summation) a possibilityfor load balancing.

802.11r IEEE 802.11r-2008 [iee12a] or fast BSS transition (FT) is an amendment to theIEEE802.11 standard on the MAC layer to improve the roaming between different APs[Rec12]. The main challenge is to provide a nearly seamless handover which is especiallyuseful for Voice-over-IP (VoIP) application. Handover of clients between APs has alreadybeen supported in the first 802.11 standard from the year 1999 using just four messages.However, in the newer revisions of the 802.11 standard [iee12b] the number of messagesdramatically increased leading to a larger handover unavailability time. This increase ismainly dedicated to the 802.11i standard which describes the frame exchange for 802.11Xauthentication and to the 802.11e standard which introduced exchange for admission con-trol requests. The 802.11r standard proposes algorithms which reduces the needed numberof frame exchange back to four [MW13]. On the infrastructure site this standard has al-ready been implemented by several vendors like Cisco, Aruba and LANCOM. On the clientside Apple Inc. devices equipped with iOS6 firmware are officially supported.

5After the algorithm.



802.11k IEEE 802.11k-2008 [iee08] or radio resource management is an amendment tothe 802.11 standard to provide client feedback to the APs [Sim04]. This feedback includesdetailed measurements (reports) of layer one and two client statistics. The common practiceis that an AP or and WLC requests reports from the clients associated. In the followingsome examples of these reports are summarized [Sim04]:

• Roaming decisions: Provide a site report to clients.

• RF channel knowledge: AP can request the client to build a noise histogram toprovide an overview about all non-802.11 possible interferences.

• Hidden nodes: Clients can track hidden nodes and provide the information to theAP.

• Client statistics: AP can query additional statistics from every client associated(retries or overall transmitted packets).

• Transmit Power Control (TPC): Extension to the 802.11h standard to meet regula-tory requirements in ISM-bands and reduce interference and the power consumptionof clients.

To provide efficient load balancing roaming decisions measurements shall be used. The802.11k standard triggers a client by sending a beacon request to listen on specific channelsand report a list of all available AP. Using the cumulated data from different clients theWLC generates a sorted list of possible APs called the site report. This report is sent tothe client which will subsequently try to connect to the first AP in this list. The 802.11kstandard also defines a process for roaming between two AP. In [Sim04] this method isdescribed with the following steps:

1. As soon as the AP detects a moving client, it informs this client to prepare roam toanother AP.

2. The client requests a site report from the AP.

3. The client moves to the channel with the best AP listed in the site report and connectsto it.

For a correct operation, the APs as well as the client needs to support this standard. Atthe moment of writing Apple seems to be the only noticeable client vendor which included802.11k since iOS version 6 [App13]. Regarding the AP and the WLC 802.11k has alreadybeen implemented in recent software version by Cisco and Aruba Networks.

802.11v IEEE 802.11v [iee12a] is an amendment to the IEEE 802.11 standard to allowconfiguration of client devices while connected to wireless networks and provides numerouspower saving mechanisms. It was ratified as a formal amendment to the 802.11 standardin February 2011. The following main power saving mechanism are defined:

• BSS max idle period: A time period an AP does not disassociate a client



• WNM-Sleep: A Client can signal an AP that it will go to sleep for specified amountof time.

2.2 Competing products

Besides the client steering solution from LANCOM developed for the Solar Mesh projectseveral other vendors have already implemented techniques to provide load balancing in802.11 access networks. A variety of these vendors and their techniques will be describedin the following.

2.2.1 Cisco

Cisco implemented two different load balancing techniques called Assisted Roaming andAggressive Load Balancing. Both techniques will be briefly described in the following.

Assisted Roaming As presented in [Cis13b] Assisted Roaming builds upon the 802.11kstandard especially on the neighbor list reports. In the implementation of this feature thefollowing procedure is conducted if a WLC receives a request for a 802.11k neighbor list[Cis13b]:

• The WLC searches the neighbor table for a list of adjacent APs

• The WLC rates the adjacent APs according to the RSSI between the AP, the floorinformation from the Cisco infrastructure table and the roaming history present onthe WLC. A list of six neighbors is generated and sent the to client for an assistedroaming decision.

This process requires a 802.11k compatible client, which is as described, currently notwidely implemented. However, Cisco also provides assisted roaming for so called non-802.11k clients.

A WLC can generate a so called prediction neighbor list. Clients usually probe before anassociation so the information in that list is up-to-date and the WLC can predict the APa client is likely to roam to. Clients can be discouraged to roam to less desirable APs bydenying an association request to not preferable APs. Cisco introduced two parametersto parameterize this technique: A denial count which is the maximum number of times aclient is refused and a prediction threshold which describes the minimum number of listentries before the feature is applied.

Aggressive Load Balancing Cisco uses the LWAPP protocol to load-balance wirelessclients across APs controlled by one WLC [Cis13a]. This technique only works at theassociation phase which means that a client is never disassociated from an AP even inhigh-load situations. If the condition to load-balance are met a client can be denied usingan association response packet with status code 17. However, [Cis13a] describes a condition



where a wireless client may ignore this request although it is part of the latest 802.11standard [iee12b]. The aggressive load-balancing feature can be configured using the load-balancing window. If this window is set to five clients and a sixth client tries to connectto the AP, the client will be declined from connecting to the AP.

2.2.2 Aruba

Aruba’s load-balancing technique is called Client Match and is protected by the US patent20130036188 A1 [GIN13]. The only official available source for detailed information aboutthis technique, is unlike to the comprehensive documentation provided by Cisco, a mar-keting influenced tech brief [Aru13b]. Aruba identifies the main load-balancing problem inWiFi networks as sticky clients. These clients attend to stay at the same AP even when thesignal gets weaker. Because of the resulting lower Modulation and Coding Scheme (MCS)the aggregated cell throughput decreases. Aruba identifies three main features of theirClient Match technology:

• Band steering: Move 5GHz capable clients to a suitable AP for higher performance.

• Client steering: Continuously (even after associating to a certain AP) monitoring ofclient throughput and move them if necessary to another AP.

• Dynamic load-balancing: The avoidance of overloading a single channel or AP byevenly distributing clients in a given area.

In their technical document [Aru13b] Aruba describes the need for 802.11k and 802.11vstandards to accomplish the client match control and monitor functions. In addition tothat, they describe the possibility to use a Client Match function without the contemplatedstandards in a different document [Aru13a]. However, these documents does not provideinformation how this task is accomplished.

2.2.3 LANCOM Client Steering

LANCOM’s solution to a balanced 802.11 access network is called Client Steering. Thisfeature has been released to the public with the latest version of LANCOM OperatingSystem (LCOS) 9.0. According to the release notes [Gmb14b], LANCOM also implemented802.11r which can be used for fast roaming as described in section 2.1.2.

The Client Steering feature is comprehensively described in the addendum of LCOS release9.0 [Gmb14a]. It describes client steering as a process where certain criteria are used to helpWLAN clients locate the best AP within their transmission range. For the client steeringtechnique a suitable WLC is required and in general the process works as follows6:

1. All APs in range forward the probe request of an unassociated client to the WLCusing the CAPWAP protocol.

6See [Gmb14a] for a complete description of all necessary steps.



Table 1: LANCOM Client Steering parameter

Pref. Frequency band (Band) Specifies the frequency band to which theWLC steers the AP.

Tolerance level The calculated value for an AP may deviatefrom the maximum calculated value by thispercentage value in order for the AP to beallowed to accept the client at the next loginattempt.

Signal weighting (SignalW ) Specifies with how many percent the signal-strength value is entered into the final value.

Associated-Clients-Weighting (LoadW ) Specifies with how many percent the numberof clients associated with an AP is entered intothe final value.

Radio weighting(BandW ) Specifies with how many percent the value forthe frequency band is entered into the finalvalue.

Disassociation threshold Specifies the threshold value below which theconnection to the client must drop before theAP disconnects from the client and initiates anew client-steering operation.

Disassociation delay Specifies the number of seconds in which nodata is transferred between AP and client be-fore the AP disconnects the client.

2. Every AP generates for every Client a final rating based on a value for signal strength,the number of associated clients on the AP and the used frequency band.

3. APs with the highest rating or a value within a specified tolerance level accept asso-ciation attempts. All other AP will reject the client.

4. If a WLAN client is acting sticky and does not attempt to connect to another APwith a better connection quality the WLC can enforce the client to disconnectedusing the 802.11 status code 17.

Table 1 shows the parameters which can be configured regarding the Client Steering tech-nique on the LANCOM WLC [Gmb14a]. Compared to other vendors the Client Steeringfeature can be influenced significantly by these parameters. When a new client tries tojoin the WiFi network every AP calculates a rating for this client. The interface of an APwith the maximum rating as well as all other within the so called tolerance level acceptan association attempts of a client. The final rating for each interface is calculated as



follows:

Rating = Band ∗BandW +Signal ∗ 100Signalmax

∗ SignalW + Load ∗ LoadW (1)

with (2)

Band = 100 if Band is Pref.Band else 50 (3)

Load = 100−Number of associated Clients on Interface (4)

Signal = 0, ..., 100 | 0 = weak (5)

Every weighting can be set as a percentage value and the default values are shown in table11.

LANCOM’s fast transmission technique is based on 802.11r and can be enabled using twodifferent modes [Gmb14a]: fast transition only and a mixed operation of the default andfast transition mode.



3 Methodology

The purpose of this section is to introduce the materials and methods of the conductedmeasurements to evaluate the capabilities of the different client steering implementations.After describing the hard- and software used, the methods will be described in more de-tail.

3.1 Hard- and Software

Table 2: Used hardware for the Client Steering test

Device Vendor Notation Firmware Client-Steeringfeature

WLC Cisco 2504 Wireless Controller 7.5.120.0 Aggressive LoadBalancing

AP CiscoAIR-CAP3602E-E-K9

with AIR-RM3000AC-E-K915.2.(4)JA1 -

AP Cisco AIR-CAP3602E-E-K9 15.2.(4)JA1 -WLC Aruba 3200XM 6.3.0.0 Client MatchAP Aruba AP-134 6.3.0.0 -WLC LANCOM WLC-4100 9.00.0154 Client-SteeringAP LANCOM L-452agn 9.00.0154 -

Besides their own hard- and software implementation, the project partner LANCOM pro-vided test equipment of the vendors Aruba and Cisco. For each vendor one WLC as welltwo APs are available for the experiments. All devices have been updated to the latestfirmware version. Table 2 provides an overview of the hardware used in the upcomingtests.

On the client side different operating systems on multiple devices have been used. Thisclient variation has been chosen to test the Client Steering techniques with ambiguousdevices. This should reflect real-world build-ups where customers can use their own devicesto connect to the network. All clients have been updated to the latest available softwareversion and are listed in table 3.

Table 3: Used client devices for the Client Steering test

Device Vendor/Name Software-Version NotationSmartphone Huawei Y300-0100 Android 4.1.1 AndroidPSmartphone iPhone 4s 7.1.2 iPhoneTablet-PC Lenovo IdeaTab A2109A Android 4.1.1 AndroidTLaptop MacBook OSX10.6.8 Laptop

Router in Client mode TL-WR841ND OpenWRT Revision Router



3.2 Test Environment

Fixed OpenWRT Clients

WLC

AP2 AP1

Steerable Clients

Test ServerInternal network

Figure 3.1: Schematically view on the test-environment.

Figure 3.1 shows a schematic drawing of the implemented test-environment. The WiFiinfrastructure consists of a WLC connected directly via Ethernet to two APs. The APsinduce a 802.11g/n 20 MHz bandwidth access network protected with WPA/WPA2 mixedmode. The channels of the APs have been set fixed to one and six respectively. This choicewas made to have two non-overlapping 20 MHz channels and additionally to avoid inter-ferences with the local WiFi infrastructure of the university. In addition to the steerable

Figure 3.2: OpenWRT routers in client mode

clients, six routers running OpenWRT [Ope14] have been configured to operate in clientmode to increase the overall number of stations in the network (cf. figure 3.2). During theexperiments they are connected (depending on the scenario) to a fixed Basic Service SetIdentification (BSSID) of one AP and not to the SSID distributed by the WLC.

To generate traffic on the network, a local server was set up and connected to the samesubnet as the WLC and all clients. All needed traffic is generated using the well-knowntool iperf [ipe14]. An iperf server is running on the local server and the fixed OpenWRT



clients connect via UDP saturating the associated AP.

3.3 Scenarios and goals of the measurement

To test the Client Steering technique different scenarios will be defined. The purposeof these tests is to provide a complete view of common situations occurring in 802.11access networks where the Client Steering feature is attended to increase the QoS. Allthe scenarios will be build-up in a controllable environment at the Hochschule-Bonn-RheinSieg.

3.3.1 New Client association


WLC

AP2 AP1

Steerable Clients


?

(a) Scenario 1: Traffic


WLC

AP2 AP1

Steerable Clients


?

(b) Scenario 2: Idle

Figure 3.3: Client association scenarios

Scenario 1: New Client association with traffic The first scenario which will be testedin this work defines a situation where multiple7 clients are already associated to one APand generate traffic on the network. An additional client enters the cell with the goalto access the network as schematically shown in figure 3.3a. The desired behavior of theClient Steering technique is to associate the device with AP number two because it iscurrently idle. It is expected that the RSSI influences the outcome of this test. Therefore,three different positions will be tested for the steerable client leading to equal or differentsignal strengths for each AP. These positions will be realized through different TXPowervalues of both APs. In the first position the client which tries to associate is located inthe middle between the two APs and both AP transmit with same TXPower level. Inthe second position the client is still located in the middle but one AP transmits withan increased power. The third position is the same situation as position 2 vice versa foran increased TXPower level of the second AP. For every different client ten associationattempts will be conducted with a reset of the WiFi interface in between.

7As described before this is realized using the six non-steerable OpenWRT router.



Scenario 2 - New Client association on idle networks The second scenario describesa situation where a new client tries to associate to the network and multiple clients arealready associated with one AP. This is similar to scenario one besides that there is notraffic8 on the network. The desired behavior in this case is again that the new client isassociated with AP two (cf. figure 3.3b). Again 10 association attempts at three differentpositions will be tested.

3.3.2 Client steering


WLC

AP2 AP1


Steerable Clients

(a) Scenario 3: Client Steering


WLC

AP2 AP1


Steerable Clients

(b) Scenario 4: Client Roaming

Figure 3.4: Client Steering and Roaming

Scenario 3 The third scenario is used to test the proper Client Steering technique. Inthis scenario multiple clients are associated to one AP and the fixed OpenWRT router inclient mode start to generate traffic on the network. The traffic shall be parameterized tosaturate AP one while AP two is idle. The desired behavior of the WLC is to move thesteerable client to the second AP for a better load-balancing on the network. Differentclients will be evaluated and it will be measured if the client is steered to the idle APbefore a certain time period has elapsed.

3.3.3 Client Roaming

Scenario 4 Client roaming is an important feature in 802.11 access networks with ahigh fluctuation and moving of devices. In this scenario the two APs are spaced apart indifferent rooms leading to different RSSI values at ambiguous locations. The clients are notgenerating traffic on the network and one steerable client moves away from AP one in thedirection of AP two. At some point the RSSI value of the second AP becomes higher thanthe current connected one and the WLC should move the client to the second AP to avoidthe sticky client problem (cf. figure 3.4b). Besides the general movement to the secondAP the steering time will be evaluated. This is the time the client will be not reachablefor ambiguous network services.

8Despite layer 2 802.11 control frames



The measurement of roaming times can take place with different methods as described in[vN12]:

• Between 802.11 Encrypted Data Packets to/from the client on the old and new AP.

• Between 802.11 Probe Request through EAPoL-Key (or Association Response).

• Between 802.11 Authentication Request through EAPoL-Key (or Association Re-sponse).

The overall roaming time decreases in the enumeration before. In this work the measure-ment of the time between two encrypted data packets has been chosen because if reflectsbest the time the client will be unavailable for any services. To measure this time, thetool ping has been used by generating 2000, 80 Bytes long ICMP packets per second. Theserver pings the device and the longest time interval between two consecutive replies willbe used as an indication for unavailability. The accuracy of this method is bounded to thedelay between server and client which is around 2 ms. The results will show that this timeaccuracy is sufficient.

An example of a conducted ping test is provided in figure 3.5. During the moving processesbetween two AP the client did not reply in the time range between 7.23 s and 12.08 s.

Figure 3.5: Example for a ping test



4 Experiments

In the following section the conducted experiments will be described based on the method-ology defined in the last section.

4.1 Aruba

The WLC 3200XM has four Ethernet ports, one optical fiber, and a port to access theWLC via serial connections. The APs are connected on the Ethernet ports and poweredvia additional Power over Ethernet (PoE) injectors since the WLC does not have a build-inPoE feature. In the upcoming tables of the results the AP will be identified through theirlast two digits of the MAC address. The AP e0 is fixed to channel 1 in the 2.4 GHz bandand the AP 0c is fixed to channel 6 for every test.

Scenerio 1 Multiple associated clients produce a high load on the AP e0. One additionalclient tries to associate with the network. In addition to the different positions and theambiguous clients three complete test rounds have been conducted. The first test roundhas been conducted with the Client Match feature disabled. For the second and third roundthe technique has been enabled using the default values provided Aruba on the WLC andadapted settings which should improve in the authors opinion the results of the ClientMatch technique. The settings have been chosen to the best of the authors understandingto improve the results. To apply the adaption the WLC needs to be accessed via thecommand line and the value ’cm-lb-client-thresh’ was changed from 10 to 3. This valuedescribes the thresholds of associated clients for the WLC to conduct the Client Matchprocess. The results of all three experiments are shown in table 4. The results indicate

Table 4: Results for scenario 1: Position 1: same TXPower, Position 2: :0c higher power,Position 3: :e0 higher power

Client Router iPhone AndroidP AndroidT Laptop∑

%Position 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3

without Client Match0c 6 10 5 2 10 0 0 0 1 9 9 8 2 10 1 82 0.51e0(load) 4 0 5 8 0 10 10 10 9 1 1 2 8 0 9 78 0.49

using Client Match0c 8 10 6 5 9 1 0 1 2 9 10 0 7 5 10 83 0.55e0(load) 2 0 4 5 1 9 10 9 8 1 0 10 3 5 0 67 0.45

adapted settings and Client Match0c 1 4 4 6 10 2 2 3 1 7 9 3 4 6 2 64 0.43e0(load) 9 6 6 4 0 8 8 7 9 3 1 7 6 4 8 86 0.57

no statistical valid benefit in using the Client Match technique. With Client Match andthe default values 55% of all clients connected to the idle AP. The adapted settings do



not provide a benefit for the results. In fact, 57% of the clients connected to the loadedAP. The reference experiment shows that without Client Match the overall associationsare almost evenly distributed between the two AP.

However, by closer analyzing the results several things can be obtained. The Androidphone connected almost every time to the loaded AP. Further investigation showed thatthis mainly dedicated to the fact that this AP runs on a lower channel than the idleone. For other clients like the iPhone the position and therefore the received RSSI ofthe AP influences the association decision. For position one the decision of the iPhoneis unpredictable for position two and tree the iPhone prefers the AP with the increasedTXPower. The data does not reveal a clear tendency for all contemplated aspects. Evenwhen analyzing particular clients the decision process of association seems unpredictablewith or without the usage of Client Match.

Table 5: Results for Aruba scenario 2: Position 1: same TXPower, Position 2: 0c higherTXPower, Position 3: e0 higher TXPower


%Position 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3

without Client Match0c 6 10 7 2 3 0 0 0 0 9 10 5 4 5 2 63 0.42e0(conn) 4 0 3 8 7 10 10 10 10 1 0 5 6 5 8 87 0.58

using Client Match0c 4 10 9 7 4 0 0 0 0 5 8 2 6 7 4 62 0.44e0(conn) 6 0 1 3 6 10 10 10 10 5 2 8 4 3 6 84 0.56

adapted settings and Client Match0c 2 4 4 0 2 0 0 0 0 8 1 2 0 5 0 28 0.19e0(conn) 8 6 6 10 8 10 10 10 10 2 9 8 10 5 10 122 0.81

Scenerio 2 The second scenario is identical to the first one despite the fact that noneof the fixed associated clients produces traffic on the network. The results of this testare shown in table 5. Again no clear tendency for a successful usage of the Client Matchtechnique in this scenario is given. In addition to that, the adapted settings decrease theconnections to the desirable free AP. However, several observations from the first scenariocan be confirmed. The Android phone again connected in almost all cases to the AP usingthe lower frequency. Comparing the results of scenario one and two it is observable thatthe Client Match technique is not influenced by the load on the network.

Scenario 3 Using the default configuration of the WLC and after several tries, no clientsteering attempt could be obtained using the defined scenario. After the contemplatedchange of the ’cm-lb-client-thresh’ value to three, the results in table 6 were obtained. Itindicates the results for steerable clients differentiated by three events. No change describesa situation where no steering was observable after 5 minutes of association to the loaded



AP. Steering indicates a successful transfer from the loaded AP to the idle AP observableon the client as well through the Client Match log files on the WLC. Change describes asituation where the client changed from the loaded to the free AP without a logged steeringattempt on the WLC.

Table 6: Aruba Scenario 3 adapted settings

Event iPhone AndroidP AndroidT LaptopNo Change 2 0 0 XSteering 0 4 5 XChange 3 1 0 X

In the tested scenario client match steered the Android tablet and the phone from theloaded to the idle AP after less than two minutes of association. An attempt to steerthe iPhone was not recorded, however, it changed three times to the free AP. The testusing the OSX laptop were not realizable. After several attempts it was not possible toconnected the laptop to the loaded AP since the initial connection to the network wasalways conducted on the free one.

Scenario 4 In this scenario the average time for unavailability of the devices will beanalyzed while moving the device from one room to another using the contemplated pingtest in section 3.3.3. The results of this test are shown in table 7. Every test was conducted10 times and the mean as well as the standard deviation is shown. It was not possible toobtain results for the iPhone because of problems with in test scenario. The iPhone doesnot reply to ICMP packets after a certain number of packets have arrived. For exampleafter sending 50 ICMP packets, the iPhone blocks additional packets for several seconds.This could be a security feature implemented in iOS but a documentation describing thisbehavior was not found.

Table 7: Average unavailability time

Client iPhone AndroidP AndroidT Laptopwithout Client Match

Unavailability time [s] X 1.07± 0.29 1.19± 0.14 0.43± 0.02

with Client MatchUnavailability time [s] X 0.95± 0.06 1.17± 0.09 0.41± 0.0

with adapted Client MatchUnavailability time [s] X 0.9± 0.08 1.2± 0.29 0.43± 0.02

In general the unavailability time is higher than expected but matches the results obtainedin [vN12] and differs significantly from device to device. While the Laptop was unavailablefor less than half a second the unavailability of the Android tablet was measured morethan one second in the mean. In general the Client Match technique does not decrease theaverage unavailability time for all devices.



4.2 Cisco

The following tests were conducted with a series 2500 WLC and two series 3600 APs. TheCisco WLC has four Ethernet ports with two having ability to power the APs via PoE. Inaddition to that, a serial connection can be used to conduct the initial setup of the device.Both AP have a PoE capable Ethernet port and a serial connection. One AP is also ableto use the upcoming 802.11ac standard.

The two AP are labeled as follows in the following experiments. The first AP will becalled 11:ac. It was set fixed to channel 6 and no connections or load were present on thisAP. The second AP will be labeled 11. For all experiments this AP was fixed to channel1 and for certain scenarios six fixed clients were connected generating load on the AP.

As described in 2.2.1 the aggressive load balancing will be used which can be configuredthrough the web-interface. Since 6 clients were used during the test the aggressive load-balancing window was adapted for all upcoming test and set fixed to 3. This choice wasconducted to ensure that the aggressive load balancing feature is active.

Scenario 1 This scenario again describes the decision process of a client to use a loadedor idle AP for the initial connection to the network at three different locations. The resultsof the experiment for the vendor Cisco are shown in table 8.

Table 8: Results for scenario 1: Position 1 = both APs same TXPower, Position 2 = AP11:ac higher TXPower, Position 3 = AP 11 higher TXPower.


%Position 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3

without Aggressive Load-Balancing11:ac 1 0 0 0 0 0 0 0 0 4 10 0 10 10 4 39 0.2611(load) 9 10 10 10 10 10 10 10 10 6 0 10 0 0 6 111 0.74

using adapted Aggressive Load-Balancing11:ac 2 8 10 1 7 3 0 0 0 8 10 0 10 10 7 76 0.5111(load) 8 2 0 9 3 7 10 10 10 2 0 10 0 0 3 74 0.49

Comparing the accumulated results with and without Aggressive Load Balancing enableda positive trend can be obtained. While enabling the feature, 50% percent of the clientsconnected to the idle AP avoiding the heavily loaded. Without Aggressive Load Balancingonly 26% connected to the idle AP and the majority picked the already heavily loaded.It is again noticeable that the Android Phone connects to the AP with the lower channelnumber regardless of the current load on the AP which has a negative influence on theaccumulated results.



Scenario 2 The same experiments were conducted without load by just connecting sixclients to the AP 11. The results of this scenario are shown in table 9.

Table 9: Results for scenario 1: Position 1 = both APs same TxPower, Position 2 = AP11ac higher TXPower, Position 3 = AP 11 higher TXPower


%Position 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3

using adapted Aggressive Load-Balancing11:ac 9 10 6 0 5 1 0 0 0 0 10 0 5 10 2 58 0.3911(conn) 1 0 4 10 5 9 10 10 10 10 0 10 5 0 8 92 0.61

without Aggressive Load-Balancing11:ac 1 2 0 0 3 0 0 0 0 0 8 2 10 10 0 36 0.2411(conn) 9 8 10 10 7 10 10 10 10 10 2 8 0 0 10 114 0.76

While almost the same results were obtained without the Aggressive Load-Balancing fea-ture the positive results for this technique decreases. In this experiment only 39% of theClient choose the idle AP. While the documentation of the Aggressive Load Balancing fea-ture [Cis13a] does not state out a dependency to traffic the conducted experiments indicatethis.

Scenario 3 In the documentation of the aggressive load balancing feature the follow-ing statement can be found [Cis13a]: "A client that has already been authenticated andassociated is never removed from the system as a result of aggressive load-balancing. Load-balancing only happens at the association phase." A test for this scenario was therefore notconducted since it not expected that clients which are already connected to the networkwill be steered from the loaded to the idle AP.

Scenario 4 Scenario four again describes the roaming process visualized in figure 3.4b.In this scenario and as described in [Cis13b] the assisted roaming feature of Cisco shouldimprove the unavailability time of all devices. The experiments in this scenario are thereforeconducted with and without this feature. The aggressive load balancing feature was enabledduring the test in for this scenario. The results of the test are shown in table 10.


Client iPhone AndroidP AndroidT Laptopwithout Assisted Roaming


with Assisted RoamingUnavailability time [s] X 1.24± 0.47 5.28± 1.64 1.84± 0.21

The results are worse than the ones obtained for Aruba. However, Assisted Roamingdecreases the average unavailability time for the Android phone and especially for the



Laptop. For the Android tablet no significant improvement was obtained and the averageunavailability is found significantly high (above 5 seconds).

4.3 LANCOM

The LANCOM WLC-4100 has been equipped with the latest Firmware Version of LCOS.It has 4 Ethernet ports without PoE support and a serial connection for debug purpose.The L-452agn APs are powered using external power supplies. The configuration of boththe WLC and the APs has been conducted using the ’LANConfig’ windows tool.

Two APs were used in this test called AP1 and AP2. AP1 was set to channel 1 and sixclients were connected for specific scenarios. AP2 was again set to channel 6 with no load.To set the TXPower LANCOM offers a TXPower reduction on the AP which was mainlyused to realize the different positions in scenario one and two.

In contrasts to the other tested vendors LANCOM offers the possibility to define so calledClient Steering Profiles. These profiles can be used to configure the Client Steering tech-nique according to the circumstances of a WiFi deployment. For every Client SteeringProfile the parameters described in table 1 can be adapted accordingly.

During the test a strong dependency of the final rating to the value ’signal’ has beenobtained. This is mainly dedicated to the fixed number 100 in the first fraction of equation2. Since the defined scenarios have been designed under the premise of a strong dependencyon the load on the different interfaces an adapted profile has been created. The values ofthis created profile can be found in table 11. In the following a mathematical explanationfor the choice of these values will be provided.

To conduct a successful steering in scenario one and two the influence of the load whichis determined by the number of connected clients to the networks needs to be superior tothe signal weighting. The first step is therefore to increase LoadW to 100 to strengthen itsinfluence for the final rating. To decline a connection attempt to the loaded AP, the signalweighting needs to be decreased otherwise both APs will allow an association attempt ofa client.

Signalmax ∗ 100Signalmax

∗ SignalW −Signal ∗ 100Signalmax

∗ SignalW ≤ ClientDiff ∗ 100 (6)

100 ∗ SignalW (1− Signal

Signalmax) ≤ ClientDiff ∗ 100 (7)

1− ClientDiff

SignalW≤ Signal

Signalmax(8)

1− 6

SignalW=

1

2(9)

In the first scenarios the number of clients is fixed to six leading to a difference in the finalrating of 600 between both APs. The maximum difference in the final rating resultingfrom varying signal strengths should not exceed this value. This context is mathematically



approximated in equation 6. After some mathematical rearranging, equation 9 defines anexample where the signal of the weaker AP can be half of the maximum obtained signalstrength. This results in a SignalW of 12 for an equality of the influence of signal andload. In other words, the influence of the signal is superior to the influence of the load onlyif one AP ’sees’ the client with more than a doubled signal strength. This value will beused in the adapted Client Steering profile for the upcoming experiments in combinationwith a decreased tolerance level to one percent to force a deterministic behavior.

Table 11: LANCOM Client Steering defaults and adapted values

Value Default AdaptedPref.Band 5 GHz 2.4 GHzSignalW 100 12LoadW 70 100Tolerance Level 10 1Disassociation-Threshold 30 99

Scenario 1 Scenario 1 has been conducted under the same principles as described forthe previous vendors and as visualized in figure 3.3a. Three different test have beenconducted, using the default Client Steering parameters, disabling Client Steering andusing the adapted Client Steering profile described in the last section. The result of thistest are shown in table 12.

Table 12: Results for Scenario 1: Position 1: both APs with same, Position 2: AP2 higherTXPower, Position 3: AP1 higher TXPower


%Position 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3

without Client SteeringAP2 3 2 3 4 10 0 0 0 0 10 10 0 10 10 3 65 0.43AP1(load) 7 8 7 6 0 10 10 10 10 0 0 10 0 0 7 85 0.56

using Client SteeringAP2 2 8 10 1 7 3 0 0 0 8 10 0 10 10 7 76 0.51AP1(load) 8 2 0 9 3 7 10 10 10 2 0 10 0 0 3 74 0.49

using adapted Client SteeringAP2 10 10 10 2 9 0 10† 10† 10† 10 10 10 10 10 10 131 0.87AP1(load) 0 0 0 8* 1* 10* 0 0 0 0 0 0 0 0 0 19 0.13

*unsteerable, †several tries were needed

The usage of Client Steering and the default setting improves the number of connectionattempts compared to the result with disabled Client Steering. The usage of Client Steeringleads to an almost equal distribution to both APs. Without the Client Steering feature74% connected to the loaded AP. Again the Android phone leads to a strain of the resultssince it connected again to the loaded AP operating on channel 1.



A real improvement was obtained by using the adapted Client Steering Profile. In thisexperiment 87% of the Clients connected to the idle AP avoiding the heavily loaded oneregardless of the different measured positions. Only the iPhone was not able to associatedto the desired AP. However, it was possible for the WLC to detect this behavior and theMAC address of the iPhone was marked as ’unsteerable’ in the web-interface. A specialcase occurred while using the Android phone and the adapted Client Steering profile. Forevery attempt to connect to the network several resets of the WiFi interface were needed.This means that a situation occurred where the Android phone was unable to connect tothe WiFi network which is highly unpleasant and non-transparent for customers. However,this situation may be dedicated to the adapted Client Steering Profile.

Table 13: Results for Lancom scenario 2: Position 1: both APs with same TXPower,Position 2: AP2 higher TXPower, Position 3: AP1 higher TXPower


%Position 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3

without Client SteeringAP2 3 3 1 0 1 0 0 0 0 4 6 0 1 10 1 30 0.2AP1(conn) 7 7 9 10 9 10 10 10 10 6 4 10 9 0 9 120 0.8

using Client SteeringAP2 7 0 7 10 1 0 0 0 0 7 10 0 0 0 0 42 0.28AP1(conn) 3 10 3 0 9 10 10 10 10 3 0 10 10 10 10 108 0.72

using adapted Client SteeringAP2 10 10 10 0 6 1 10 10 10 10 10 0 10 10 10 117 0.78AP1(conn) 0 0 0 10* 4* 9* 0 0 0 0 0 10* 0 0 0 33 0.22

**unsteerable, †several tries were needed

Scenario 2 Again the same test were conducted without load by the six connected clients.The results of this scenario are shown in table 13. Unexpected is that the results for theusage of Client Steering and the default settings differ from the result obtained for scenarioone. In fact more Clients (0.72%) have made the undesirable choice and connected to theAP with already six associated clients. The LANCOM documenation however does notindicate a dependency of this feature to network traffic occurring on the AP. The usageof the adapted Client Steering Profile again significantly improves the decision process ofthe clients. While the iPhone still made the undesirable choice of connecting to AP andadditional anomaly was obtained for the Android tablet. During the test of position 3 thetablet was marked as unsteerable and connected to the AP using the higher TXPower.

Scenario 3 In comparison to Cisco, LANCOMs Client Steering feature provides the pos-sibility to dissociate Clients from one AP and force a roaming to a more desirable one. Thisis useful to overcome the contemplated sticky client problem. Similar to Aruba the settingshave been adapted to enforce a desirable behavior in this scenario as far as possible. The



disassociation threshold has been greatly enlarged to 95% to force a disassociation basedon the Client count difference on both AP. The experiment has been conducted as follows.First, the steerable Client has been connected to AP1 and placed in the middle betweenAP1 and AP2. Afterwards the six clients were connected fixed to the BSSID of AP1. Aftera few minutes the results presented in table 14 were obtained.

Table 14: Lancom Scenario 3 adapted settings

Event iPhone AndroidP AndroidT LaptopNo Change 5 0 5 0Steering 0 5 0 5Change 0 0 0 0

For every devices five rounds were conducted. While the Android Phone and the Laptopchanged to AP2 after a few minutes the iPhone as well as the Android Tablet acted assticky clients and stayed on the loaded AP1. LANCOM provides in their web-interface twomarks for such Clients called either unsteerable or stubborn. However, neither the tabletnor the iPhone were marked.

Scenario 4 The roaming and the resulting unavailability time have been tested in thisscenario similar to the other vendors. The test have been conducted with and withoutthe fast transition feature based on 802.11r. The results are presented in table 15. SinceApple is the only vendor implementing fast transition based on 802.11r in iOS6 no realimprovement in the unavailability time was obtained for the other devices and this feature.The overall results are similar to the one already obtained for other vendors.


Client iPhone AndroidP AndroidT Laptopwithout fast transition with Client Steering


with fast transition with Client SteeringUnavailability time [s] X 1.03± 0.16 1.4± 0.47 1.32± 0.81



5 Results

The purpose of this section is to further analyze the results obtained from the experimentsdescribed in the previous section accumulated for all vendors.

By conducting scenario one and two with different TXPower levels of the APs differentlocations of the clients were realized. The purpose of this experiment was to evaluateif the clients select a potential AP based on the RSSI. For some clients this behaviorwas obtained. Table 16 shows an evaluation if clients connected to an AP based on theTXPower level. The percentile numbers in the cell correspond to the number of connectionsto the AP with the increased TXPower Level for scenario one and without any influenceby the different client steering techniques.

Table 16: Client connecting based on TXPower of the AP

Aruba Cisco LANCOM∑

Router 0.75 0.5 0.45 0.57iPhone 1 0.5 1 0.83AndroidP 0.45 0.5 0.5 0.48AndroidT 0.55 1 1 0.85Laptop 0.95 0.8 0.85 0.86∑

0.74 0.66 0.76 0.72

Overall the clients connected in 72% of the cases to the AP with the stronger receivedsignal. Again, a huge variance among the different clients was obtained ranging from 48%(Android phone) to 86% (Laptop). While the results are again not undisputed the RSSIseems to influence the association decision of the clients which was expected beforehand.

The contemplated behavior of the Android phone to connect to a lower channel if multipleAP with the same SSID are available needs further investigation. For this purpose thisbehavior has been analyzed in table 17 for all clients. Using the data of scenario two andposition one the connection to the AP operating on channel one has been analyzed. Theonly client which uses the channel number as the main indicator is the Android phone. It isassumed that the phone scans the medium for the broadcasting of the SSID starting withthe first channel. As soon as it detects a beacon, the client associates to the AP withoutadditional scanning on other channels. For other clients no statistical valid statement canbe done since there is a variance between the different vendors as well.

According to the different documentations (cf. section 2.2) of the tested Client Steeringfeatures no vendors takes the network load into account. However, the results indicate adifference between scenario one and two even without enabling the technique. A possibleexplanation is the relationship between the number of clients and the Signal-to-noise ratio(SNR) resulting in different RSSI for the clients as well as different beacon intervals sendby an AP which is under heavy load conditions.



Table 17: Client connecting based on channel number of the AP

Aruba Cisco LANCOM∑

Router 0.4 0.9 0.7 0.66iPhone 0.8 1 0.1 0.93AndroidP 1 1 1 1AndroidT 0.1 1 0.6 0.56Laptop 0.6 0 0.9 0.5∑

0.58 0.78 0.84 0.73

For LANCOM and Aruba it is known that the WiFi status code 17 is used to prevent aclient to connected to an undesirable AP. The test results show that this status code maybe ignored on some devices (cf. table 8 and iPhone). To overcome this problem a moredrastically approach could be not reposing to an association request of a client. However,this could lead to a situation where a client is unable to connect to the network.

Cisco provides a comprehensive document ’Wireless LAN Design Guide for High DensityClient Environments’ which provides additional techniques to improve the client distri-butions among APs [JFW13]. These techniques should always be considered to furtherimprove the results of Client Steering.

The author of this report was astonished by the complexity regarding the settings on eachWLC. A significant amount of time was spent for the configuration of the WLC regardlessof the Client Steering feature to provide a comparable test environment.

An additional problem for the Client Steering techniques of Aruba and Cisco was thatthe operation could only be observed as a black box. In contrast, LANCOM providesthrough its event table and the transparent rating based decision process the possibilityto understand and influence the results. It is possible to create customized Client Steeringprofiles to adapt the technique to the circumstances of the deployment. Through theusage of this possibility LANCOM was the only vendor where a good result was obtainedfor scenarios where newly connecting clients associate to the network.

A load-balancing for already connected clients is only specified for the techniques of Arubaand LANCOM. Both techniques were not able to steer all clients even after adapting thesettings to the considered scenario.

An unexpected result was the huge unavailability time during the roaming of a client fromone AP to an adjacent one. The variance of this time was significant among the testedclients. While the roaming of the fastest client was measured around 0.4 s the largest timeobtained was 5.7 s. Regarding different services like VoIP this time lead to lost connectionsor huge losses in the Quality of Experience. The only vendor which provide a measurabletechnique to improve the roaming times is Cisco.



6 Conclusion

Due to the obtained results presented in the last two sections it is hard to draw a clearconclusion regarding the state of the art of client steering techniques. It has been shownthat without knowing the used algorithms on the client side as well as on the WLC it ishard to generalize the behavior of clients. The main problem of all client steering solutionsis the huge amount of different clients and ambiguous implementations. A homogeneoususage of specified clients with a tested behavior could overcome this problem. However,this is only applicable for companies and not for public infrastructures.

It has been shown that LANCOM is the only vendor which provides the possibility toadapt their Client Steering solution to the defined scenarios. This leads to a good resultfor the initial decision of client connecting to the network. However, an understandingof the technique is still required and the profiles need to be adapted according to theenvironment. A solution which works out of the box for every possible deployment seemsnot available.

6.1 Possible future work

In [BT05] it has been shown that the maximum saturation throughput as well as the delayof an 802.11 network cell depends on the number of clients connected. This informationcan be used to approximate the current load on an AP. As soon as the capacity of the APtends towards the saturation throughput further connections to the AP should be avoided.In the authors’ opinion this provides a better assessment of load than just the number ofconnected clients.

A possible additional research question is the correlation between the number of beaconssent by the different APs and the association decision of clients. If the beacon interval ofan AP which is under heavy load is decreased, it is perhaps possible to conduct influencea association decision depending on the probability that a client receives a beacon from acertain AP.



References

[App13] Apple Computer Inc. (2013) ios: Wi-fi network roaming with 802.11k and802.11r. [Online]. Available: http://support.apple.com/kb/HT5535

[Aru13a] Aruba Networks Inc. (2013) Client match feature on iap 4.0. [On-line]. Available: https://arubanetworkskb.secure.force.com/pkb/articles/FAQ/Client-match-feature-on-IAP-4-0

[Aru13b] ——. (2013) Clientmatch technology wifi client optimization. [Online].Available: http://www.arubanetworks.com/pdf/solutions/TB_ClientMatch.pdf

[BCI+09] M. Bernaschi, F. Cacace, G. Iannello, M. Vellucci, and L. Vollero,“Opencapwap: An open source capwap implementation for the managementand configuration of wifi hot-spots,” Comput. Netw., vol. 53, no. 2, pp.217–230, Feb. 2009. [Online]. Available: http://dx.doi.org/10.1016/j.comnet.2008.09.016

[BT05] G. Bianchi and I. Tinnirello, “Remarks on ieee 802.11 dcf performance anal-ysis,” IEEE communications letters, vol. 9, no. 8, pp. 765–767, 2005.

[Cis13a] Cisco Systems Inc. (2013) Aggressive load balancing on wireless lancontrollers (wlcs) release 6.0.182.0 and earlier configuration example.[Online]. Available: http://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/107457-load-balancing-wlc.html

[Cis13b] ——. (2013) Cisco wireless lan controller configuration guide,release 7.4 - configuring assisted roaming. [Online]. Avail-able: http://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_01100111.html

[CMS09] P. Calhoun, M. Montemurro, and D. Stanley, “Control and Provisioning ofWireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11,” RFC5416 (Proposed Standard), Internet Engineering Task Force, Mar. 2009.[Online]. Available: http://www.ietf.org/rfc/rfc5416.txt

[CSCW+10] P. Calhoun, R. Suri, N. Cam-Winget, M. Williams, S. Hares, B. O’Hara,and S. Kelly, “Lightweight Access Point Protocol,” RFC 5412 (Historic),Internet Engineering Task Force, Feb. 2010. [Online]. Available: http://www.ietf.org/rfc/rfc5412.txt

[GCY+06] S. Govindan, H. Cheng, Z. Yao, W. Zhou, and L. Yang, “Objectivesfor Control and Provisioning of Wireless Access Points (CAPWAP),” RFC4564 (Informational), Internet Engineering Task Force, Jul. 2006. [Online].Available: http://www.ietf.org/rfc/rfc4564.txt


http://support.apple.com/kb/HT5535

https://arubanetworkskb.secure.force.com/pkb/articles/FAQ/Client-match-feature-on-IAP-4-0

https://arubanetworkskb.secure.force.com/pkb/articles/FAQ/Client-match-feature-on-IAP-4-0

http://www.arubanetworks.com/pdf/solutions/TB_ClientMatch.pdf

http://www.arubanetworks.com/pdf/solutions/TB_ClientMatch.pdf

http://dx.doi.org/10.1016/j.comnet.2008.09.016

http://dx.doi.org/10.1016/j.comnet.2008.09.016

http://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/107457-load-balancing-wlc.html

http://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/107457-load-balancing-wlc.html

http://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_01100111.html



http://www.ietf.org/rfc/rfc5416.txt





[GIN13] S. Ganu, P. Iyer, and P. Narasimhan, “Infrastructure-assisted clientmanagement using synthesized beacon reports,” feb 2013, uS PatentApp. 13/195,720. [Online]. Available: https://www.google.com/patents/US20130036188

[Gmb14a] L. S. GmbH. (2014) Addendum lcos 9.00. [Online]. Avail-able: http://www.lancom-systems.de/download/documentation/Reference_Manual/LCOS-ADDENDUM-900-EN.pdf

[Gmb14b] ——. (2014) Lcos 9.0 ru1 release notes. [Online]. Avail-able: http://www.lancom-systems.de/download/documentation/Release_Notes/LCMS-900-RU1-EN.pdf

[iee08] “Ieee standard for information technology– local and metropolitan areanetworks– specific requirements– part 11: Wireless lan medium access control(mac)and physical layer (phy) specifications amendment 1: Radio resourcemeasurement of wireless lans,” IEEE Std 802.11k-2008 (Amendment to IEEEStd 802.11-2007), pp. 1–244, June 2008.

[iee09] “Ieee standard for local and metropolitan area networks part 16: Air interfacefor broadband wireless access systems,” IEEE Std 802.16-2009 (Revision ofIEEE Std 802.16-2004), pp. 1–2080, May 2009.

[iee12a] “Ieee standard for information technology–telecommunications and informa-tion exchange between systems local and metropolitan area networks–specificrequirements part 11: Wireless lan medium access control (mac) and physicallayer (phy) specifications,” IEEE P802.11-REVmb/D12, November 2011 (Re-vision of IEEE Std 802.11-2007, as amended by IEEEs 802.11k-2008, 802.11r-2008, 802.11y-2008, 802.11w-2009, 802.11n-2009, 802.11p-2010, 802.11z-2010, 802.11v-2011, 802.11u-2011, and 802.11s-2011), pp. 1–2910, March2012.

[iee12b] “Ieee standard for information technology-telecommunications and informa-tion exchange between systems local and metropolitan area networks-specificrequirements part 11: Wireless lan medium access control (mac) and physi-cal layer (phy) specifications,” IEEE Std 802.11-2012 (Revision of IEEE Std802.11-2007), pp. 1–2793, Feb 2012.

[ipe14] iperf. (2014) Iperf project. [Online]. Available: http://iperf.sourceforge.net/

[JFW13] A. C. A. Jim Florwick, Jim Whiteaker and J. Woodhams. (2013)Wireless lan design guide for high density client environments in highereducation. [Online]. Available: http://www.lancom-systems.de/download/documentation/Reference_Manual/LCOS-ADDENDUM-900-EN.pdf

[MW13] P. Macham and J. Wozniak, “On the fast bss transition algorithms in the ieee802.11r local area wireless networks,” vol. 52, no. 4, pp. 2713–2720, 2013.


https://www.google.com/patents/US20130036188

https://www.google.com/patents/US20130036188

http://www.lancom-systems.de/download/documentation/Reference_Manual/LCOS-ADDENDUM-900-EN.pdf


http://www.lancom-systems.de/download/documentation/Release_Notes/LCMS-900-RU1-EN.pdf

http://www.lancom-systems.de/download/documentation/Release_Notes/LCMS-900-RU1-EN.pdf

http://iperf.sourceforge.net/




[Ope14] OpenWrt. (2014) Openwrt - wireless freedom. [Online]. Available: https://openwrt.org/

[Rec12] J. Rech, Wireless LANs - 802.11-WLAN-Technologie und praktische Umset-zung im Detail, 4th ed. Hannover: Heise Heinz, 2012.

[Sim04] D. Simone. (2004) 802.11k makes wlans measure up. [Online]. Available:http://www.networkworld.com/news/tech/2004/0329techupdate.html

[vN12] A. von Nagy. (2012) Cwi-fi roaming analysis part 3 - measuringroam times. [Online]. Available: http://www.revolutionwifi.net/2012/12/wi-fi-roaming-analysis-part-3-measuring.html


https://openwrt.org/

https://openwrt.org/

http://www.networkworld.com/news/tech/2004/0329techupdate.html

http://www.revolutionwifi.net/2012/12/wi-fi-roaming-analysis-part-3-measuring.html

http://www.revolutionwifi.net/2012/12/wi-fi-roaming-analysis-part-3-measuring.html

This page intentionally left blank

Documents

Final Report Client Steering - H-BRS · Solarmesh Final Report Client Steering August 27, 2014 Zuwendungsempfänger HochschuleBonn-Rhein-Sieg Förderkennzeichen 01BU1116 Vorhabenbezeichnung