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 assgned to the AP in which the Fittingness Factor is the highest, i.e. the available throughput is close to the required throughput.

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

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

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

FF mode

The controller moves the STAs to the AP where the Fittingnes Factor has its max value.

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

BALANCER mode

It assures good link (RSSI > SignalThreshold).

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

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.