Thesis

WiFi Roaming Along an Urban Route.

Motivation

Nowadays, the need for Internet connectivity is growing. With the rise of smartphones, services like email, navigation, VoIP or instant messaging became more popular and are now present in the daily routines of the users. According to a study from Marktest, at the end of August 2012, 28% of portuguese mobile phone users had a smartphone. This percentage increased to 39.6% at the end of August 2013 and tends to increase even more. In another perspective, urban environment sensing platforms like the one that Future Cities holds, requires the user to upload the gathered data, so the user must have an active Internet connection. In the other hand, the data gathered in this project should be processed in order to create innovative services like a quick and automatic WiFi connection service. Continuous Internet connectivity can be achieved with cellular technologies like LTE. However, the usage of this technology is not as cheap as WiFi and an user must have a subscribed data plan with an operator. The increasing number of smartphones and the increasing availability of an alternative to cellular wireless coverage areas creates an opportunity for a service that takes advantage of all that connectivity to provide, as far as possible, ubiquitous connectivity along an urban route.

Objectives

The main objective of this work is the development of a smartphone service that optimizes the client handoff in order to provide fast associations and, as far as possible, continuous Internet access along an urban route.
There are some constraints for the problem that can limit the solution. One of these constraints is the impossibility to modify most of the available access points, because they do not belong to the Future Cities project. For similar reasons, the WiFi infrastructure can not be modified, which implies that mechanisms such as the 802.1X authentication with RADIUS server must remain as they are.

Methodology

This work aims at modifying components of an Android smartphone and making use of the database that FutureCities holds in order to improve different handoff phases:
- Scanning phase: Reduction of duration with a single channel scan approach.
- DHCP phase: Optimization of the message exchange and redefinition of retransmissions delays to reduce the overall DHCP delay and its variance.
To support this, an algorithm will run in the database and will be called via a web service that will return a list with the best Access Points for a given route, as well as their MAC addresses, channel, GPS location and estimated coverage area.
The overall solution may be accessible as an Android application or service that will be used to measure connectivity times and handoff delays to evaluate the possible gains.

Work

Work Plan and Weekly Reports.

Objectives: Familiarization with Android and its DHCP client.
Work: The DHCP client that Android uses is the "dhcpcd", which was developed by Roy Marples. Listing the running processes in an Android, it is possible to confirm this fact. The corresponding code is easy to find under the "external" folder of the Android source tree and particullarly the file responsible for the DHCP retransmissions control is "dhcpcd.c". Hopefully Roy Marples confirmed all these informations by email and he believes that by changing few lines of this code the proposed solution can be implemented. At this moment the DHCP client uses an exponential backoff algorithm for retransmissions, as recomended in RFC 2131, with 4 seconds for the first retransmission.
Problems: After the download of the Android source tree and the preparation of the computer to compile it, there are some doubts about how to compile the proposed modifications. The first approach is to compile the entire Android source, which takes too much time and is not productive. The second and better approach consists in compiling just the dhcpcd module and pushing it into the smartphone filesystem. There are no informations from Google about this but we think it is possible as described by other developers.
Next Week Plans: Modify dhcpcd.c and push it into the smartphone. Prepare the DHCP evaluation tests.
Objectives: Conclusion of DHCP tests in existing networks.
Work: Some tests were made in the networks of Zon_Fon, Porto Digital, Eduroam and Meo-WiFi. They revealed the expected improvements like the previous tests. However the DHCP servers of Zon_Fon do not perform particularly well with this solution. Because of this a new approach was proposed and it consisted in defining the DHCP timeouts in an adaptative way, changing with the networks. This system could also learn by itself with historical information, and so it would be a much better solution regarding engineering decisions. After the tests the DHCP client was modified in order to accomplish this objective, defining the timeouts in a file that the client would read when needed. An unexpected problem occured, and because of that the idea is not implemented yet and other alternatives are being evaluated.
Problems: When trying to put the DHCP client reading a file with the timeouts, the Android never found the location of the file. Reviewing the remaining code of the client (which originally was developed for Linux), we saw that there were several Android directives avoiding files manipulation. Until now, there is no explanation for the error. It is not a permission error neither a file location error, because debugging for this was already done.
Next Week Plans: Try to find an alternative to conclude the adaptative DHCP client. Begin the analysis of the existing AP selection algorithm.
Objectives: Finish the modifications in the DHCP client. Analyze the data present in the databases and design the interface to the service that will return the list of the best APs for a given route.
Work: The last idea for the DHCP client was implemented. The application can now control a part of the DHCP message exchange. Some tests were made in order to evaluate the new modifications and the exchange now has delays in the order of 30ms which is a gain of about 98%. Clearly the time wasted after receiving a "DHCP NAK" was the responsible for the biggest part of the DHCP delay. The reduction of retransmissions delays allow a reduction of the overall delay variance because the client now responds faster in order to get the exchange done.
Apart from this, part of the DHCP chapter was written, the data present in the databases was already analyzed and the interface of the webservice to obtain the AP list was designed. The algorithm will not be changed right now. Instead we will carry on with the location-based algorithm and include the service as it is. The next challenge is to implement the location-based algorithm with the information that will come from the service.
Problems: The work plan was changed but this is not a real problem. The work plan was very tight with few time to the thesis writing. This will allow a focus on the location-based algorithm and more time to write.
Next Week Plans: Continue the thesis writing. Start implementing the general location-based algorithm.
Objectives: Design the location-based handoff algorithm.
Work: In order to get the smartphone performing handoffs in a location-based way a simple algorithm was designed. From the previous work we already have the optimum handoff points defined for each AP in a given route. With that information the smartphone only has to track its GPS position to start the handoff procedure and, as far as possible, making good use of GPS to save battery life. The GPS module of the smartphone under test performs well in open space, with accuracies of 3m to 5m and the Android API for that allows to get the actual speed of the mobile client. This information is then used to calculate the time remaining until the start of a handoff. When this time comes to X seconds the smartphone will start to scan the area for signals of the next AP. When the time comes to Y (where Y is less than X) it starts the handoff procedure. A distance approach is also possible instead of a time approach where X and Y represent distances to the handoff point (with the current accuracy taken into account). An important thing to care about is the scanning phase. This phase should be removed from the handoff phase and so the first approach of this algorithm tries to perform it few seconds before the real handoff procedure, so this way the smartphone will have the scan results in "cache" and will not scan later, speeding up the handoff. This is something that requires some tests to understand if it really occurs in this way.
Another task was the test of some functions in the database required for the webservice that will return the AP sequence. Some errors were find.
Problems: The major problem lies in the definition of the threshold values for the location-based algorithm (X and Y). Which ones are the best values? Why? How to prevent some path deviations?
Next Week Plans: Finish database tests. Try to find good threshold values (and reason for them). Test the behavior of Android when performing a scan before an actual handoff to see if it really caches the results.
Objectives: Continuation of the analysis of scanning procedure in Android.
Work: After several unsuccessful experiments to reduce the scan delay the source code of wpa_supplicant was modified. Looking at the architecture of the WiFi system in Android we see that all the scan processes are controlled by wpa_supplicant and so a modification here can produce the results that we are looking for. In fact, implementing something similar to what happened in the DHCP client, it was possible to force the frequencies to probe in the scan phase. The wpa_supplicant will then read a file, "a priori", where the frequencies are defined, and this allows a considerable reduction in the scan delay. However, when we try to start this scan in Android and listen then the results, we verified that the delay from the start until the answer did not change with our modifications. It seems to take about 700ms to return the scan results with the RSSI measurements. This is not a desirable fact because it does not allow to continually track RSSI variations in order to trigger the handoff. Another strategy must be developed. Anyway, in a handoff situation where a scan phase is needed, the modifications lead to a reduction from about 500ms to 20ms which is a good improvement.
Apart from this, a more detailed DHCP test was made in eduroam, to separate the results from each component of the DHCP solution. These results show a clear reduction in the mean delay and its variance, leading to a quicker and more reliable DHCP solution. A few more pages of the final document were written.
Problems: The modification in wpa_supplicant does not allow a continuous tracking of RSSI to trigger the handoff.
Next Week Plans: Define the strategy to trigger the handoff. Continue the implementation.
Objectives: Implementation, specific DHCP tests and definition of details for the AP selection algorithm.
Work: In conversation with B.Thomas and the supervisors we agreed that the minor improvement proposed would not lead to much better results. In fact the algorithm estimations get better with more measurements and that should be enough to guarantee that the handoff really occurs. Anyway the existing methods that Boris implemented for the AP selection algorithm do not take in consideration several details required for the handoff procedure on the smartphone, like the wifi channel and some GPS points needed to calculate the optimum handoff point. Those modifications are being implemented because they are the core of the main handoff improvements. At the same time some specific DHCP tests were done to evaluate the improvements separately, i.e., the gains with the reduction of retransmission delays, reduction of DHCP NAK timeout and optimization of the message exchange. These tests are now completed for WiFi Porto Digital and eduroam and revealed considerable gains. The gain obtained for the solution with all improvements is about 95%, like previously stated.
Problems: There are no problems to report. The only thing that can be refered is the long time required to analyze the DHCP tests and to perform them, specially in eduroam where there were frequent unknown connection problems.
Next Week Plans: Continue the definition of the web service for the AP selection algorithm and the required modifications in the remaining parts of the system.
Objectives: Test web services. Implementation of the connection to these web services.
Work: B.Thomas and his team gave a list of web services to test. The most important was "getApList" which gives the sequence of APs for a given route. This web service had some problems that we had to solve during the week. The major problem was a geographic reference error. This error did not make possible to return correct data for a given route. At first we found a way for how to deal with it, swapping coordinates. Next we procced with the implementation in Android of the connection to this web services. Again another error appeared due to double quotes and escape characters that were not being correctly handled by the web service. Finally, when this was corrected, printing the data from the web service in a map on the smartphone we found that the "start" and "end" point required to calculate the optimum handoff point were not being calculated as they should. After printing the coverage area on Google Earth, with a KML file returned by other methods on the databse, we found that the APs had a coverage area similar to an ellipse. After several days we found that the initial geographic problem was in the base of this too and then we finally found the source of the error. At this moment the smartphone is capable of getting real data, print it in a map view and procced with the handoff algorithm. Now it is necessary to populate B.Thomas's databases with real data in order to estimate the AP locations. To do this I ran a PHP script during some hours. It revealed memory allocation problems.
The remaining DHCP were done and analyzed. The tests in "MEO-WiFi" revealed similar gains to the previous tested networks, and in "FON_ZON_FREE_INTERNET" the solution had no better results. In fact this is a strange fact but there is an explanation for this. Between two DHCP messages (Discover and Offer), in this network, there is a constant felay of 1.3 seconds that does not exist in the remaining networks.
Problems: The existing problems were explained above.
Next Week Plans: Populate the databases with real data and execute the calculations. Perform some more DHCP tests with FON_ZON_FREE_INTERNET.
Objectives: Retry the database processes, specially the recalculation process. Repeat the tests in FON_ZON_FREE_NETWORK. Write the thesis.
Work: The recalculation process was repeated and analyzed in detail. There are few optimizations possible to make in the PHP script that calls these methods. However, the methods can be optimized in order to produce partial results instead of recalculating the whole data set, which could lead to memory problems in the server. B.Thomas is aware of this problem and is working with his team to solve it. The script was modified to run directly on the server, and to be called directly by the SenseMyCity app, so this way, when there is new data, it is instantly sent to the table to be recalculated when needed.
The tests in "FON_ZON_FREE_NETWORK" were repeated and revealed what we expected. Adapting the retransmission delay to better suit to this network behavior the results are much better than the previous ones. Taking in consideration that the strange characteristic of this network is a delay of about 1.2s between the DHCP Discovery and the DHCP Offer, comparing with the remaining networks where this delay does not exist, a result of about 1.4s of total delay is acceptable.
Some chapters of the thesis document were written.
Problems: The recalculation process is being modified. For this reason there is no way to get results, even for a couple of APs, in order to make connectivity tests to test the handoff control algorithm in a real scenario.
Next Week Plans: Write the thesis. Get data for the scanning improvements. Try to perform calculations for few APs, in order to prepare connectivity tests, if the recalculation process is available.
Objectives: Write the thesis.
Work: Due to the problems with the database methods, it will not be possible to perform tests in a real scenario, to make use of the data calculated and processed by B.Thomas' algorithms. The corrections will not be ready in time. These are the connectivity tests that use the algorithm implemented on the smarpthone. Due to this unexpected problem the thesis report will not present the results of these tests. It will be written expressing the work done, including the algorithm of handoff control in the smartphone, and discussing only the results of the improvements in the DHCP and scanning phase. Some more chapters were written this week.
Besides this, some scanning tests were also performed in different networks. They revealed a strange behaviour, for which there is no explanation for now, that consists in different scanning delays when it is expected no change in this value. In other words, the 3.4 seconds of the previous test is transformed in about 500 milliseconds for a test with the same characteristics, which is hard to explain. It seems that sometimes the smartphone does a pssive scan (~3.4 seconds) and sometimes an active scan (which is about 500 milliseconds, as refered in some articles). However this is not confirmed yet, and there is almost none documentation for this, which makes it difficult to find a logical explanation for this. Problems: The existing problems were explained above.
Next Week Plans: Write the thesis. Investigate the scanning behaviour.
Objectives: Write the thesis and proceed with corrections.
Work: All chapters of the document were wrote. After that some corrections were pruposed by the supervisors and the document was corrected, particullarly the organization of some chapters.
Problems: None.
Next Week Plans: Deliver the document for jury evaluation. Start calculations with real data to prepare the connectivity tests in real environment.
Objectives: Modification of the DHCP client and experimental tests.
Work: The DHCP client was modified, particularly the code responsible for retransmissions and delays. These retransmissions occur spontaneously when the client does not receive answers during some seconds. There is another source of delay present specially when there is a handoff for a different subnet. In this situation the client will receive a "DHCP NAK" when it sends its "DHCP Request". After this, it will wait for about 1 second to restart the DHCP procedure. This was also modified and corresponds to a situation easy to test. For that reason some tests were made in order to understand the gains that our modifications could achieve. The tests consisted in connecting to a given network and then to a different network, and viceversa, while a packet capture was running in background. Different tests were made, with different DHCP timeouts. The tests were very conclusive and significative and revealed that is possible to achieve DHCP delays in the order of 200 ms to 300 ms, when considering inter-network roaming, which is a decrease of about 80%.
Problems: Initially the tests were made with a common router of a domestic network and a smartphone working as WiFi hotspot. The smartphone performed bad, with some unexpected messages being exchanged, and for that reason it did not correspond to a real situation. Then it was replaced by a computer also working as hotspot, and the results were very similar to the router.
Next Week Plans: Repeat the tests with other equipment, in other networks. Conclude the DHCP part of the solution.
Objectives: Preparation of the DHCP client to work in an adaptative way.
Work: The previous problem related to files manipulation in Android was solved. With that the DHCP client can now read the timeouts from a configuration file that will be written "a priori" in the future application/service. Another idea related to the DHCP came up to avoid unnecessary messages exchange when roaming to a different network, that can potentially save 100ms to 200ms.
Apart from this, because we still could not access the database where the AP selection algorithm is implemented, due to lack of credentials, a simple Android application was developed to test the DHCP client and the capabilities of the Android APIs for WiFi management. The application lists available networks, provides an user interface to modify the DHCP timeouts, and shows the timestamp of different supplicant states when the user connects to a specific network. This data showed that we will need to modify the "wpa_supplicant" running on wifi in order to disable the scanning phase always present.
Problems: Sometimes the DHCP client does not correctly modify the timeouts when the user modify them in the application. We think that it is a problem at application level, but we need more tests to debug this.
Next Week Plans: Explore the new idea for the DHCP client. Begin the analysis of the existing AP selection algorithm.
Objectives: Define the general architecture of the system and start implementing the basis of the location-based algorithm.
Work: In conversation with the advisor and co-advisor, we agreed that the best architecture for our system should include a module responsible for generating the route for the user and the optimal handoff points, so this way the smartphone will not waste batery running complex algorithms and this modularity will make possible to define routes based on specific purposes. In this architecture the smartphone will connect to this new module (running as a webservice or a server) asking for the sequence of access points for a route (which the module is responsible to construct based, for example, on data acquired previously from that user). The module will connect to the webservice where the AP selection algorithm is running asking for the access points for the route constructed. With this information the module will calculate the optimal handoff points and return them to the smartphone, as well as the remaining information about the access points required for the handoff process. This architecture was already implemented, at least the new module and the smartphone part. This is the basis that we need to implement the location-based algorithm. With this running is possible to implement the algorithm itself and start optimizing specific processes like the scanning phase.
Problems: None.
Next Week Plans: Continue the implementation of the smartphone and module parts. Design the location-based algorithm.
Objectives: Database tests. Exploration of scanning procedure in Android.
Work: The debug needed in some database functions, required for the webservices, was done in collaboration with Boris. There is a script to obtain the right measurements from the SenseMyCity database in order to estimate the APs location with them.
In a meeting with the supervisors we discussed the best strategy to change from an AP to another. The optimum handoff point calculated in the previous weeks is not enough because it does not guarantee that in that location the client will receive beacons from the new AP, since it is a pure estimation. So this point should only be used as an indication to start a kind of RSSI measurement mechanism. Collecting this information in a short temporal window the actual handoff is performed when the signal of the new AP starts to be better than the previous one. These RSSI measurements are accomplished with a scan and because of that this scan must be very short. This is controlled by wpa_supplicant. As far as we know there is a parameter in the configuration file that forces a single channel scan (scan_freq). However this can not be adopted in practice because it requires a system reboot which is not desirable for our roaming scenario. The next approach to be tested will be the modification of the source code of wpa_supplicant in order to get control of the frequencies to be probed.
Problems: There is very little documentation for wpa_supplicant and the source code is extensive which difficults the work. More than this, even if we get a single channel scan this does not guarantee that we can do a considerable number of RSSI measurements in order to trigger the handoff in a short temporal window.
Next Week Plans: Continue the analysis of the scanning procedure.
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.
Objectives: Definition of the web service for the AP selection algorithm and the required modifications in the remaining parts of the system. Tests of some implemented web services.
Work: The implementation of the web services started by B.Thomas. The required modifications for the methods are not all implemented yet, or at least they are not functional at the moment. The wifi channel was added in the methods as well as the GPS coordinates needed to calculate the handoff point. Some web services were implemented and we tested them. The major web service, related with the AP selection algorithm, is not returning correct data yet and B.Thomas will correct it soon.
Furthermore, some diagrams were made for the thesis report.
Problems: The modifications required for the methods had some errors. For example, the wifi channel frequency was not added properly. More than that, some web services did not take into account those modifications. There were some errors in the web services while we tested.
Next Week Plans: Continue testing the web services. Define the structure of the thesis report and procced with the writing.
Objectives: Populate the databases with real data and execute the calculations. Perform some more DHCP tests with FON_ZON_FREE_INTERNET.
Work: The process of populating the databases consists in a PHP script that copies data from the SenseMyCity databse to B.Thomas's database using the methods developed by him for this effect. Initially the data relative with "eduroam" network was tranfered. A total of about 1 700 000 tuples were transfered in about 10 hours. The data relative to the remaining three networks (Meo-WiFi, WiFi Porto Digital and FON_ZON_FREE_INTERNET) correspond to about 4 700 000 tuples and until now it was not possible to tranfer them because of some speed problems in the server. The next process required is the recalculation of positions of APs. As related by B.Thomas this process is slow and until now it was not possible to finish the calculations for "eduroam". The process was running during more than 24 hours and it was not completed, until a connection problem appears that canceled the whole process.
The tests in "FON_ZON_FREE_NETWORK" could not be repeated because this network was unavailable without reason, at the local where it was tested the last time.
Problems: The database processes are slow. There is no reliability in the recalculation procedure. A better wasy of running the script is needed and maybe more processing capacity of the server.
Next Week Plans: Retry the database processes, specially the recalculation process. Repeat the tests in FON_ZON_FREE_NETWORK. Write the thesis.
Objectives: Write the thesis. Get data for the scanning improvements. Try to perform calculations for few APs.
Work: Some tests were done to evaluate the scanning improvements obtained with the modifications in "wpa_supplicant". The tests show that it is possible to reduce the scanning delay from about 3.4 seconds to about 70 milliseconds, which corresponds to a gain of 98%. The modifications only aimed at forcing the smartphone to do a single channel scan instead of a full scan to all channels. Because this is a modification only in the client side, where the APs do not interfer, the tests were done in just one network. However the gains shall be reflected in every other network, since the single channel scanonly consists in send an AP probe and wait for the response. So, unless the AP is set to delay an answer to a probe, which obviously is not a common situation, every AP, regardless of the network, shall answer immediately to a probe. So the delay of the scanning phase is only a function of the signal strength and the noise that may increase this answer propagation delay.
The recalculation method is not corrected yet, and it is likely to take some weeks to be ready to use. So for now it is not possible to get real data in order to perform tests in a real scenario.
Problems: The recalculation method is not functional yet, and this may make impossible to perform some connectivity tests in a real urban scenario.
Next Week Plans: Write the thesis.
Objectives: Write the thesis.
Work: Some more chapters of the thesis document were wrote. The scanning behaviours were investigated and the tests reflect those behaviours. The driver does passive scans and active scans, and the difference in the delays is due to that. Because the driver source code is not available to investigate, we do not know for sure how and why the driver selects a scanning mode.
Problems: None.
Next Week Plans: Write the thesis and proceed with corrections.

Tasks

Main tasks and development status.

× DHCP solution desing and implementation - 100%
× DHCP tests - 100%
× Scanning solution desing and implementation - 100%
× Scanning tests - 100%
× Smartphone application - 100%
× Handoff control algorithm in the smartphone - 100%
× Route server design and implementation - 100%
× Algorithm to calculate the optimum handoff point in the route server - 100%
× Functional database methods and web services (together with B.Thomas) - 100%
× Final connectivity tests - 100%

Results

Experimental results so far.

DHCP Optimization

The graph shows the results of our solution compared to the original DHCP client of Android. The experiments were done in "Eduroam", "WiFi Porto Digital", "Meo-Wifi" and "FON_ZON_FREE_NETWORK". The results with the default client are the bars named with "Original" and correspond to the larger delays. Then there are the results obtained with a "DHCP NAK timeout" reduction from 1s to 0s. Adjusting the retransmission delay to 100ms (except for FON_ZON_FREE_NETWORK, which revealed a different behavior and, for that reason, this delay was set to 250ms between DHCP Requests and 1500ms between DHCP Discoveries) we see a reduction of the variance of the results. With a "message exchange optimization" we achieve the results of the third group of bars. Finally, joining the partial improvements in a single solution we obtain the final results that illustrate the gains of our solution. It is possible to achieve gains of about 98% on the DHCP delay and very small variances.

Scanning Improvements

The graph shows the results of the improvements in the scanning phase with single channel scans, instead of full scans to all channels, for both scenarios. The first one corresponds to the passive mode, and the second to the active mode. There is a gain of about 98% considering the passive mode, and 89% for the active mode, which is a noticeable gain. For both modes, when it is made a single channel scan the driver acts in active mode, since the obtained results for both scenarios with the improvement are very similar.

Solution improvements

The graph on the left shows the improvements in the time without connectivity taking the average value. The proposed solution reduces this time for 1,7s in eduroam from 8,3s, which is a gain of about 80%. The variance is also much lower. On the right the graph shows the improvements in the average packet loss rate, with a reduction from about 26% to 7,6%, which corresponds to a gain of more than 70%.

Conclusions

Final remarks of this work.

Summary of the results

Gains of more than 90% regarding the DHCP delay, in three of the four networks in study, and more than 50% in the remaining. This is reflected in reductions of delays of more than 3s to less than 100ms for some networks, which is an improvement clearly noticeable by the user.
Gains of more than 90% regarding the scanning delay, accomplished with single channel scans, which corresponds to a delay of about 50ms.
The complete solution presented gains of about 80% for the time without connectivity. The packet loss rate also decreased 70%, leading to a roaming with better quality of service.
The overall solution leads to faster handoffs, with noticeable improvements and much more predictable behaviors than before, and by consequence the user experience is better.

Future work

The present work can be improved in the future from different ways. By collecting more data with SenseMyCity application the AP locations will be more accurate, and the system will become more reliable. This is an advantage of this project, because the whole system will become better and better with the usage. Then it is possible to add an automatic web-based authentication to deal with this handoff phase present in some networks. As far as we know, FON_ZON_FREE_INTERNET changed recently this mechanism and now it is more difficult to do that automatically, however MEO-WiFi keeps its original and simple mechanism. Regarding the existing networks in Porto, the other critical handoff phase is the 802.1X authentication present in eduroam. Modifications in this infrastructure could minimize the delay of this phase, making the solution even better.
The scanning phase was improved but there is a possibility to completely remove this phase because, in this project, the relevant informations about APs are given by the route server to the smartphone. This could be explored. If there is a way to give the relevant informations to the driver without perform a scan, the scanning phase could be removed. This could be accomplished saving more useful WiFi data in the databases that the driver needs. However, in this work the scanning phase is required to measure the RSSI which is the metric to trigger the handoff. A future solution that explores this way should also choose other metric.
As future work it would be interesting to study the possibility of achieving a similar solution without the modifications in the source code, because this makes the solution only possible to implement in rooted devices, unless future Android versions adopt the modifications. However this is really challenging because the fundamental handoff phases are not controlled by the developer, but other roaming solutions could be explored that could potentially eliminate the need of source code modifications.
The major focus of this work was the smartphone, but the architecture has much more entities involved. The methods on the databases could be reviewed and, as proposed by B.Thomas, different geometries could be considered for the coverage areas, which could lead to more precise AP locations and coverage radius and, by consequence, the solution would be improved.

Recommendations for future Android versions

Google can easily adopt the following modifications, resulted from this work, to improve the handoffs in Android and to provide a better experience for the user. Regarding the scanning phase, Google could change the method startScan() for something like startScan(int[] frequency). This parameter could be passed to wpa_supplicant, just like did in this work, to allow only scans in the specified frequencies. This way, if a developer has specific purposes for his application that only require single channel scans for example, he can have much more control of this phase. If the application requires the scanning phase to be quick, this simple modification would allow it, and would open space for an entire new range of applications that would improve the WiFi experience for the users, for sure.
The DHCP process could be also improved changing the DHCP client dhcpcd. The modifications are simple and equal to what was done in this work. The retransmissions delays could be decreased. It is difficult to implement an adaptive mechanism to dynamically change these delays as did in this work, but the existing delays are clearly too high. Android also knows the networks it may hand-off to in the future, because it does periodic scans to keep this information fresh. This simple fact is all what it needs to improve the DHCP process, particularly to implement the message exchange optimization described in this report. Thus, making this information available in the DHCP client, it can replicate the proposed solution putting it working independently and without the need of an application to control it. The client would know, by itself, if it has to optimize the message exchange or not, or in other words, if it is changing to a different network or not. In sum, it would be possible to achieve the noticeable gains obtained here, which would have positive consequences for the user.

Team

Know our team.

Team

Student - António Rafael Rodrigues Franco
Advisor - Tânia Cláudia dos Santos Pinto Calçada
Co-advisor - Ana Cristina Costa Aguiar

Bibliography

Get the references.


For the complete list of references see the PDI report available for download.

Downloads

Get the Thesis Reports.