Application SmartApSelection

The code is here.

This proactive application uses the auxiliary wireless interface of each AP to scan in the channels used by Odin's APs. It creates a database with the heared STAs and their associated wireless parameters seen from each Wi-5 AP. Once the data is processed, it decides if any STA needs to be handed off to another AP.

It has different working modes (expressed in the Mode parameter of poolfile):

• RSSI: Each STA is assigned to the AP in which it has the best RSSI.

• FF: Each STA is assigned to the AP in which the Fittingness Factor is the highest and its RSSI is above the Threshold, i.e. the available throughput is close to the required throughput.

• BALANCER: It performs load balancing and manages mobility at the same time.

• JAIN-BALANCER: It performs load balancing and manages mobility at the same time as the previous mode, but in this case using Jain's Fairness index algorithm.

• DETECTOR: It uses the flows detected by the Detector Agent to move the STAs to a VIP AP.

Getting monitoring information

The application sends to each AP a scanning order, requesting the RSSI level received (uplink) of each of the STAs heared.

An example can be found in the following link:

In this case, it will store the RSSI for each STA seen by each of the APs (not only by the one where it is associated).

            AP1             AP2            AP3
STA1      RSSI1,1         RSSI1,2        RSSI1,3
STA2      RSSI2,1         RSSI2,2        RSSI2,3
STA3      RSSI3,1         RSSI3,2        RSSI3,3

In order to keep some historical data, the value of the RSSIi,j is obtained as:

RSSIi,j = alpha x new_RSSIi,j + (1-alpha) x old_RSSIi,j

Parameters of the application in poolfile

• TimeToStart(sec): There is an initial time interval after starting of the application, which gives the user a margin to start the APs.
• ScanningInterval(msec): It is the interval during which the AP scans on each channels, in order to build the RSSI matrix.
• AddedTime(msec): Interval after each scan to give time the agent to perform other tasks. For testing, recommended value = 0.
• SignalThreshold(dBm): It is used in all modes. It represents the minimum RSSI value which is considered acceptable for moving a STA to an AP.
• Hysteresis(sec): After a handoff, a node will not be moved again until this time has passed. Recommended value = 4.
• Alpha(0-1): A parameter that gives a different weight to historical RSSI data. Recommended value = 0.8.
• Pause(sec): Interval after each assignation to give time the controller to perform other tasks. For testing, recommended value = 0.
• Mode: It selects the different modes for running the application. It can be RSSI, FF, BALANCER, DETECTOR.
• TxpowerSTA(dBm): Only used in FF mode. It is an estimation of the transmission power of the STAs. The FittingnessFactor algorithm uses it to calculate the available throughput. It may range between 10 and 15 dBm.
• ThReqSTA(kbps): Only used in FF mode. It represents the bandwidth required by the STAs. The FittingnessFactor algorithm uses it.
• Filename: Name of the file where the log will be stored.

Behaviour of the application. Different algorithms

RSSI mode

The application decides if a handover is needed when three conditions are accomplished:

• there is an AP with better RSSI

• a hysteresis time has passed

• a power threshold is reached

See the application running in the following video:

FF mode

The controller moves the STAs to the AP where the Fittingnes Factor has its max value and its RSSI is above the Threshold parameter.

FF coef is calculated with the theoretical available throughput and the required one.

This is the loop it follows:

See the application running in the following videos:

And a screenshot:

BALANCER mode

It assures good link (RSSI > SignalThreshold). At the same time, the number of STAs associated to each AP will be close to the average.

This is the loop it follows:

A single STA can be handed off per cycle.

The pseudo code implemented in the "calculate best load balance" algorithm is:

Find all the APs able to hear any of the STAs with ( RSSI > SignalThreshold )

Between these APs:

	identify

		APmin: AP with the minimum number of associated STAs (=minSTAs)

		APmax: AP with the maximum number of associated STAs (=maxSTAs)

	calculate

		avgSTAs: Average number of associated STAs per AP


if ( minSTAs < avgSTAs ) AND ( maxSTAs > avgSTAs )

	STAtomove: STA that has the maximum RSSI in APmin

	handoff STAtomove to APmin

JAIN-BALANCER mode

It assures good link (RSSI > SignalThreshold). At the same time, the number of STAs associated to each AP is based on Jain's Fairness index algorithm.

See the application running in the following video:

DETECTOR mode

It allows to move an STA when a designated type of flow is detected by the Detector Agent. The controller orders a handoff of the STA to a VIP AP. Once the flow is no longer active, the STA returns to the previous assigned AP.

In addition to the application and its parameters, it is needed to define in the poolfile the IP address of the detector agent and the IP address of a "VIP AP" (also included in the NODES section)

This is the loop it follows:

In this example, all STAs with an SSH session (--dport 22) to 192.168.2.131 will be moved to the VIP AP (192.168.1.2):

Firstly, all STAs are associated (green) to other AP different from the VIP AP (brown):

A SSH flow is detected from STA 192.168.202, the controller moves it to the VIP AP (gold):

Other SSH flow is detected from STA 192.168.208, the controller moves it to the VIP AP (gold):

Configuration in poolfile:

NAME pool-1
NODES 192.168.1.13 192.168.1.14 192.168.1.15 192.168.1.2
NETWORKS wi5-demo

DETECTION 192.168.1.200

APPLICATION net.floodlightcontroller.odin.applications.SmartApSelection
SMARTAPSELECTION 50 200 0 -60 4 0.8 0 DETECTOR 10 2000 SmartApSelectionLog.txt

VIPAP 192.168.1.2

Command in router:

iptables -t mangle -A PREROUTING -p tcp -d 192.168.2.131 --dport 22 -j TEE --gateway 192.168.100.200

See the application running in the following video:

Implementing the decisions of the algorithm

The figure shows the handoff scheme, in which we suppose that an STA is associated to AP1 (in channel 1). AP2 is in channel 6.

The handoff scheme follows the next process:

• The application orders the Wi-5 APs to scan (only in the channels used by any of the Wi5-AP) and retrieves the data.

• It updates previous RSSI data matrix and makes a decision.

• Next, if any handoff decision has been made, the controller tells the origin AP (AP1) to send a series of CSAs to the STA. They are understood by the STA like a countdown, meaning “after N beacons, switch to channel 6.”

• When the countdown ends, three events must occur in a specific order: a) the STA switches to channel 6 (while AP1 does not); b) the controller sends an Add LVAP message to AP2, which starts sending beacons to the STA in channel 6, and c) a Remove LVAP message is sent to AP1.

After that moment, the STA starts receiving beacons from AP2 in channel 6. The synchronization of these events is the most critical part of the handoff, as we will see in the subsequent tests and measurements. It should be noted that the STA interprets this as a channel switch carried out by the same AP, so Layer 3 and upwards are not aware of the handoff. Therefore, on-going communications are only interrupted briefly due to the channel switching.