Objectives: Definition of the strategy to trigger the handoff.
Work: In the previous week the tests showed that a continuous tracking of RSSI changes would not be possible. However similar tests revealed this week that this can be done. The modifications implemented in the wpa_supplicant made possible a reduction of the scan delay, with a single channel scan. Probably the previous tests did not force correctly the new wpa_supplicant to use the data of the file, or this file was not being modified in the proper way. Therefore, it is possible to perform quick scans in a single frequency in order to obtain RSSI measurements from the next AP, compare them with the current AP and trigger the handoff. This algorithm was implemented in Android and so, when the client is about to perform a handoff, i.e., when it is about 1 second from the handoff point, it will start the RSSI measurements and change to the new AP when this AP starts to be better than the previous one (considering a fixed moving average window for the RSSI).
To complement this approach a simple idea popped up. The handoff point is an estimation, as well as the coverage areas and the AP locations. Considering the scope of this application (urban environments), if the measurements that will be used for these estimations belongs to urban paths measurements (and not to indoor measurements), we will likely obtain better estimations that will take in consideration recordings of AP beacons in the same site, in the past. It consists then in a kind of guarantee that the same AP will be listened in our calculated handoff points.
Problems: The implementation of this solution in Android was not easy, because we need "Broadcast Receivers" to listen to the scanning results. However the application had already other Broadcast Receivers assigned with the same purpose and manage them simultaneously lead to many unexpected bugs.
Next Week Plans: Continue the implementation, tests and evaluate the possible improvement for the AP selection algorithm.