Skip to content

Application SmartApSelection

Jose Saldana edited this page Mar 20, 2018 · 38 revisions

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:

SmartApSelection Video

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

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

work in progress

BALANCER mode

work in progress

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.

Proactive Multichannel Handoff

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.