Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Implementation of a Crowd-based Information
Sharing System for Network Performance Maps
av
Jakob Bäcklund and Elias Kärnsund
LIU-IDA/LITH-EX-G--14/066--SE
2014-06-13
Linköpings universitet Institutionen för datavetenskap
Examensarbete
Implementation of a Crowd-based
Information Sharing System for Network
Performance Maps
av
Jakob Bäcklund and Elias Kärnsund
LIU-IDA/LITH-EX-G--14/066--SE
2014-06-13
Handledare: Niklas Carlsson
Examinator: Nahid Shahmehri
Students in the 5 year Information Technology program complete a semester-long software development project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culminates by demon-strating a working product and a written report documenting the results of the practical development process including requirements elicitation. During the final stage of the semester, students create small groups and specialise in one topic, resulting in a bachelor thesis. The current report represents the results obtained during this specialization work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis.
Abstract
This thesis examines ways to improve the user experience of a mobile Internet connection. We discuss how this can be achieved using different techniques, but primarily focus on techniques using network performance maps. We design and implement a proof-of-concept system that allows users to record network performance experience and share these records among each other such as to improve their future performance.
We use bandwidth measurements at locations over an area to create a net-work performance map. We examine what such maps can be used for and how it is best implemented. We also create a proof-of-concept implementation for a system creating network performance maps using multiple mobile devices. The thesis also discusses how information sharing between mobile devices us-ing Wi-Fi networks can be done efficiently. This is also somethus-ing we use in our proof-of-concept implementation, when synchronizing data between mobile devices.
In summary, our Android-based proof-of-concept implementation allows users to perform bandwidth measurements, and to share these measurements among each other, such as to help each other improve their network performance maps. A good such system allows users to get an overview of the network performance over the measured area; information that can be used to optimize the Internet usage via download scheduling or bit rate adaption.
Contents
1 Introduction 1
1.1 Background and motivation . . . 1
1.2 Purpose and contribution . . . 1
1.3 Problem statements . . . 1
1.4 Limitations . . . 2
2 Background and theory 3 2.1 Functions and usages . . . 3
2.2 Network performance map . . . 3
2.3 Quality of service . . . 5
2.4 Bit rate adaptation and scheduling . . . 5
2.5 Priority policy . . . 6
2.6 Ad hoc network and Wi-Fi direct . . . 7
3 System design 9 3.1 System overview . . . 9
3.2 Measurement methodology . . . 9
3.3 Peer-to-peer connection . . . 11
3.4 Peer exchange policy . . . 11
4 Results and system validation 12 4.1 Validation . . . 12 4.2 Example . . . 12 5 Discussion 16 5.1 Methodology . . . 16 5.2 System design . . . 17 5.3 Privacy aspects . . . 18 5.4 Results . . . 19
Chapter 1
Introduction
1.1
Background and motivation
We live in a day and age where more and more mobile devices and Internet reliant software are constantly hitting the market. This results in a growing demand for faster wireless connections in greater areas than ever before. With all this advancement in mobile technology there comes big challenges in meeting the demand for reliable and flexible wireless Internet connections all over the world. The solution may not always be to increase the bandwidth but instead using the existing networks more efficiently. How the existing wireless networks can be used more efficiently is an issue we examine more thoroughly in this thesis.
1.2
Purpose and contribution
In this thesis we examine and demonstrate an effective solution to improve the experience for mobile Internet users using tools at the user end, rather than within the network. We present a solution that allow users to record and keep track of past throughput experiences, share experiences with other users and receive information from them. We base our solution on the implementation of a network performance map [1]. A network performance map is a map over a geographic area containing information about network throughput at different locations in the area. We also discuss and compare our solution in the context of other techniques and solutions.
1.3
Problem statements
We examine if it is possible to create a small network performance map with a proof-of-concept implementation. The performance map should be detailed enough to be used by an algorithm to adapt network bandwidth usage, directly
or indirectly, based on the surrounding network conditions, such as to achieve notably better quality of service.
• How can a geo-location based network performance map be used to im-prove the experience for users with a mobile device downloading a file or streaming content?
• How can network performance maps and peer exchange protocols that allow peers to exchange performance maps in ad hoc networks be imple-mented and combined into a single system?
We survey what different techniques and algorithms are available to optimize quality of service for a mobile device using network performance maps and what makes such improvements possible. We research what other techniques to optimize Internet usage on mobile devices exists today, how they work and what differentiates them compared to usage of performance maps. The reason for this is to be able to put our work in perspective with other solutions facing the similiar problems.
1.4
Limitations
When performing experiments we are limited by the small number of mobile devices we have access to, resulting in a smaller covered area. This is a common limitation when creating and testing real implementations and will affect the results in a couple of ways. The average throughput will be based on quite few measurements which will leave room for small deviations which depends on the hardware of the mobile devices. The map will only cover a small area, which will make us unable to test how the system behaves when handling large amounts of data.
Our application is only capable of creating a network performance map and not able to use the map to adapt the Internet activity with any algorithm. This is because of the fact that we do not have enough time to implement both, thereby we have chosen to focus on the performance map implementation.
Chapter 2
Background and theory
This chapter will further describe the background to the content in this thesis, different scenarios where a network performance map could be useful. It will also describe and explain some terms and techniques that will be used in this thesis.
2.1
Functions and usages
A network performance map can be useful in different ways. One usage is to actively use the data to maximize the performance of a mobile device using the Internet. That is something we will discuss more in this thesis.
Another use for bandwidth measurements is to evaluate working Wi-Fi net-works. One example is, if you want to know how good your Wi-Fi network is and if you need to upgrade it with more access points. A network performance map will then give you a good view over the network performance of the entire area you have covered in the measurements.
2.2
Network performance map
A performance map can be constructed and implemented in various ways but they all include some form of bandwidth estimation over an area. The aver-age throughput is a direct measure of the network quality and shows how fast Internet connection you can achieve. This is in contrary to indirect measures such as packet delays and round-trip times which depends more heavily on the connected server, and only indirectly affect the performance experienced by the end user. For these reasons we focus on the estimated average throughput. A table representing the performance map can also include the time when the measurement was made so you can keep track of how recent and fresh infor-mation you have. The trail of a device, with inforinfor-mation about the location the device is arriving from, could be used to map movement patterns of mobile users. Information about the mobile device that made the measurements and
what 3G provider it used can also be stored. This information could be used to further evaluate the measurement and put it into context since the quality of the equipment and 3G provider will affect the average throughput of the device. A network performance map can be made using either active or passive measurement tools [2]. Active measurements control when the measuring device downloads specific files for which the download throughput is measured, whereas passive measurements on the other hand, simply measure the network activity of a mobile device, without the tool itself actively starting any downloads. The passive approach provides less control since the measurement can only be made when there is network activity. An advantage of the passive approach, however, is that it can be implemented without reducing the effectiveness of the mobile device since it does not inject any additional measurement related traffic.
One way that Yao, Kanhere and Hassan [1] used when creating a network performance map in Sydney was by measuring throughput from a mobile device traveling in a car. They chose a route through Sydney that was supposed to represent a typical daily commute and measured the throughput they got while driving this exact route multiple times over 8 months. This is an effective method to use when researching how effective bandwidth estimation can be done using a network performance map because this method ensures them a good network estimation over this route. The map will be very reliable since they can ensure the validity of the measurement when they use the same equipment and method every time and they have also made repeated measurements during a longer period of time. But, the tests does not cover any wider area other than the exact route and is thus not that effective to use when estimating network quality in a daily use of a mobile device traveling a different route.
Figure 2.1: Visualized bandwidth map over Link¨oping University generated by Bredbandskollen1
Figure 2.1 shows a network performance map taken from a website that is designed for users to measure their download and upload speed, the measured speeds are then also used to generate this map. The purpose of this service is to obtain an overview of network conditions rather than using the information to adapt network activity. Sommers and Barford [3] has used a similar download speed test service to compare the effectiveness of cellular networks versus 802.11 Wi-Fi in metro stations.
2.3
Quality of service
The term Quality of Service (QoS) is often used to measure the network condi-tions affecting the user experience and to guarantee a certain quality level of the data flows [4]. QoS can be defined differently depending on the context. When controlling QoS on a client running a real-time application, for example live streaming, the delay of the data packets should be kept below a certain thresh-old. Another way to control QoS is to make sure that the average throughput always exceeds a predefined threshold value.
QoS can also be combined with the desire to always download the highest available quality of data while still upholding the QoS requirements. A simple example of this is adaptive video streaming where the video player has the option of requesting different video quality segments.
2.4
Bit rate adaptation and scheduling
By estimating how good network performance you will achieve, the device can adapt bit rate or schedule package requests accordingly to maximize throughput and meet the QoS requirements. This can be done with different techniques and algorithms, one is a buffered-based reactive algorithm [5].
This is an algorithm that only makes decisions depending on the buffer size of the device. It measures how much is in the buffer at the time, if the buffer is low it might lower the requested video quality in video streaming or lower the bit rate in other cases. On the other hand, if the buffer size is very large it might raise the video quality or simply stop requesting packages for a while so it does not flood the buffer. This algorithm is purely based on buffer size and does not take any other variable or statistics in consideration.
A similar reactive method is to base bit rate adaption to current and recent measured throughput. Algorithms based on this method makes decisions based on a combination of current throughput and recent measured throughput and adapt the bit rate accordingly.
A different method is history-based bandwidth prediction. Algorithms using this method is predicting how much bandwidth it will achieve in the upcom-ing future. This prediction is based on statistics regardupcom-ing earlier throughput measurements made on the network. When predicting bandwidth on a mobile
device in a wireless network a network performance map is a good tool. It makes the algorithms able to predict bandwidth based on the current location and bandwidth statistics in surrounding areas. The algorithm can either adapt to a specified route and a network performance map over that route or to the general area that surrounds the device if no specific route is specified. The al-gorithm can calculate which areas the device is most likely to enter even if no route is specified. This is if the network performance map contains information about movement patterns of mobile devices in the area. Riiser, Endestad, Vig-mostad, Griwodz and Halvorsen [5] used a history-based bandwidth prediction algorithm to prove that a geo-location based bandwidth lookup service can be used to improve the streaming quality for mobile users.
Hojgaard-Hansen, Madsen and Schwefel [6] used a history-based bandwidth prediction algorithm to schedule TCP downloads. The goal with this algorithm was to reduce the overhead of TCP downloads. The overhead increases when data packets is retransmitted and from duplicate acknowledgement packets. The idea is to only download when experiencing a bandwidth over a prede-fined threshold value, thus reducing the risk of having to retransmit packets or receiving duplicate acknowledgements.
2.5
Priority policy
A priority policy is a policy that defines which data that should be prioritized in certain situations. This will also maximize the efficiency of sharing information. As more and more information is gathered, the database will grow and so will also the information each device wants to share increase. A policy will prevent devices from being flooded with information and will also prevent them from sending too much information in vain. Circumstances may also be such as the number of transmittable records are limited and thus must be prioritized.
In this case we look into a priority policy for rows in the network performance map table, which rows that should be prioritized when exporting data to other devices. This is important if the devices do not have enough time or stable connection to transfer all data from one device to the other. It can also be useful if you want to save energy on the mobile device. The policy can of course be modified to fit certain needs depending on the scenario where the application is used, different parameters will become less and more important and should be weighted accordingly.
Location of measurements. We want the measurements to be somewhat spread out but still rather close to our current position. If we use measurements from some locations that are fairly scattered in an area, we can then use that data to make decent estimations on the locations not covered in the performance map.
Time stamp of measurements. In many cases with stable infrastructure the difference between current time and time of the measurements will not be important. Imagine a catastrophe where a lot of infrastructure is out and the net connection is unstable. In that scenario measurements that are a couple of
hours old might be irrelevant.
Source of the data, which device made the measurement. The reason for taking in this as a factor is that we possibly trust bandwidth measurements from our own device since we know that the bandwidth was measured with the same hardware conditions that we have when using the performance map. We can also ensure that our own measurements are valid estimations and not false data.
Amount of measurements at the location, the more bandwidth measure-ments we have made at a location, the more reliable it is. This means that we have minimized the possibility of a big deviation in a few measurements which has a big impact on the result.
2.6
Ad hoc network and Wi-Fi direct
Ad hoc network is a type of decentralized network structure with no dependence on pre-existing infrastructure such as routers. Instead of routing the traffic through access points an ad hoc network is set up directly between the nodes. This technique can be used to set up networks between mobile devices and thus being able to share information directly between devices. The network will only have the range of the technique it is based on.
An implementation of a wireless ad hoc network is the Wi-Fi Direct stan-dard defined by the Wi-Fi-alliance. Wi-Fi Direct is commonly referred to as Wi-Fi P2P as it functions in peer-to-peer (P2P) mode and some Wi-Fi P2P frameworks are compatible with the Wi-Fi Direct certification program. The implementation of Wi-Fi Direct uses the underlying 802.11 protocol [7] which is standard for Wi-Fi communication. By using the already existing 802.11 pro-tocol the Wi-Fi implementation of Wi-Fi Direct is automatically supported by a majority of mobile devices and does not need any additional hardware. The use of WiFi for connections and data transfer is also more energy effecient than using 3G or 4G.
The architecture of Wi-Fi direct communication is based on P2P groups. Upon establishment of an P2P group the devices will take on different roles. In each group, one device will implement Access Point like functionality thus becoming the P2P group owner (P2P GO). Other devices will serve as P2P clients in the group. The P2P GO-role is negotiated at the time of initial net-work setup. A P2P client can establish another P2P group as a group owner to extend the network further. Depending on the device it may not have two Wi-Fi-interfaces and may have to alternate between the two groups and roles by time-sharing the Wi-Fi-interface.
Figure 2.2: Illustration of P2P group with a group owner and three clients where one of the clients is also acting as a group owner
Devices find each other by Wi-Fi-scanning, this can be either active or pas-sive. Once two devices have found each other they will perform a three way-handshake GO Negotiation Request/ Response/ Confirmation. To determine the group owner a numerical parameter is sent in the request and the device with the highest number will then become the group owner.
The P2P group owner announces itself through beacons containing addi-tional P2P information element. These P2P information elements are also in-cluded in all management frames. Wi-Fi Direct does not allow transferring the role of P2P GO within a P2P Group. So if a group owner leaves, the group will have to disassemble and then reassemble with a new group owner.
Chapter 3
System design
This chapter describes and motivates our system design and implementation.
3.1
System overview
We have implemented a system that creates a network performance map by performing measurement tests over an area. In an overview the implementation can be divided into two parts which are measurement and communication.
• The throughput measurement is done by downloading a test file from a specified website. The system then measures the average throughput at each location the mobile device visits during the download. This informa-tion is saved locally on the mobile device.
• The other part of the system is a connection module which is used to share the location-based throughput information with other mobile devices and to receive throughput information from them. This functionality is implemented using P2P technology.
The network performance map will be realized as a local database table in the mobile device. The database will contain location, bandwidth, time stamp and amount of measurements made at each specific location.
3.2
Measurement methodology
We have chosen to use active measurements over passive in order to have good control over the network activity. Our aim was to build a proof-of-concept implementation which we could run different experiments on, this means that we wanted as much control over the measurement factors as possible. It does not matter if we limit the usability of the mobile device by injecting additional traffic to some extent while running the tests.
Our idea concerning the proof-of-concept implementation is by downloading a test file from the Internet and measuring the average throughput at the dif-ferent locations we visit during the download. In the application you have the option of downloading a 5 MB, 100 MB or 512 MB large file. In more detail we execute a measurement every time the device exits the earlier area to arrive at a new position. We also execute a final measurement when the test download is complete. When measuring the average throughput at a location the device will compare how long time has passed and how many bytes was downloaded since the start of the test or the last measurement. The average bandwidth will then be calculated by dividing the byte difference with the time difference in order to get the bandwidth in bytes per second.
The bandwidth will then be stored in a table together with the current GPS location, the current time and the number of times the throughput has been measured at the current location. If the table already contains a row with that location, that row will then be updated with the new time and the bandwidth will be calculated using following formula:
Biest= s × Bimeas+ (1 − s) × Bi−1est, (3.1)
where Biest is the bandwidth estimation in step i, Bimeas is the measured throughput in step i, and s is a value between 0 and 1 depending on how much we want to emphasis past values. For the tests shown in this thesis we use 0.85 as the value for s, this means we rely pretty heavily on the latest bandwidth estimation.
The table represents the network performance map containing the following columns: auto incremented id, location zone, location band, longitude, latitude, bandwidth, time stamp and number of samples at this location. A row in the table represents a measurement. Location zone and location band are parame-ters we use together with longitude and latitude to define a GPS location. We have chosen to include the time stamp of the latest measurement because it can be useful when creating a priority policy for the system. We have also chosen to store the number of times the bandwidth has been measured at the location since it can be a useful variable in the priority policy; the more amount of mea-surements made on a location makes that bandwidth estimation more reliable since single measurement deviations will be less significant. It can also be used to validate the correctness of the map, if we have a lot of different measurements in the same location the data can be viewed as more reliable.
We designed the application in a way that we are able to change some vari-ables to adapt the measurement and also be able to adapt to different scenarios and create various experiments. This affects the granularity of the GPS mea-surement which will determine how far the device must travel before it enters a new location to measure the average throughput in. We can also choose how big test file we download depending on how long we want the test to run. This combined with the options of using different amounts of mobile devices will let us perform a range of different experiments.
3.3
Peer-to-peer connection
This is how the device creates a performance table by its own but we also want to share and receive data from neighbouring devices running the same application. Our way of doing this is via an ad-hoc network over a Wi-Fi connection. By doing this we are able to gather download information from a wider area than if only sharing our own statistics. The implementation uses Androids Wi-Fi P2P framework2 which is also compatible with the Wi-Fi Direct certification.
By establishing groups as described earlier the local information can easily be shared with other devices. Since it relies on 802.11 it has limited range. But the limited range is in some aspects compensated by the P2P communication. The P2P communication allows each device to share the data further on.
3.4
Peer exchange policy
The peer exchange policy implemented is the same as used in Wi-Fi direct with groups of one group owner and multiple clients. Our implementation uses man-ual searches for peers initiated by the user. The searches can be compared to searching for a regular Wi-Fi network where you retrieve a list of available net-works which in our case is available peers. Devices can then manually connect to available peers, when the peers are connected the devices network performance maps can be transferred. This is done by one peer sending the local bandwidth map as a list with the location-based throughput information. All information in the table is sent except for the sample id since it is a local id and can be different for each device. The device receiving a performance map merges the new map with the map it already has.
2Developer.android/net.wifi.p2p (website), http://developer.android.com/reference/
Chapter 4
Results and system
validation
This chapter will convey what our system is capable of and in some form how we chose to implement it.
4.1
Validation
We chose to implement our proof-of-concept implementation as a android ap-plication using Java as code language. The finished system contains all the main functions that we wanted to implement, it can create a network perfor-mance map and synchronize it with other devices. The application can start a bandwidth test in which it measures the average throughput while downloading a specified test file from the Internet. The bandwidth map is then saved in a local SQLite database3 on the mobile device. The application connects the average throughput to the location of measurement using the GPS provider of the mobile device.
The system is also capable of finding nearby devices running the same ap-plication, connect to them and send them the network performance map from the database. The device receiving the map will update the local bandwidth map of the device with the new data.
4.2
Example
To illustrate the functionality of our implementation, we present a simple ex-periment that we performed on the implementation using two Android devices, measuring bandwidth in one of our apartments and sharing the network perfor-mance map.
During the experiment the throughput was measured at various locations. One peer only made one measurement while the other peer was moved around and measured throughput at different locations. Each measurement was made at at a fixed location and moved to a new location when the measurement was complete.
Table 4.1 shows how the database looks in device 1 before any P2P connec-tion is established. Table 4.2 shows the locaconnec-tion measurements made by device 2. When connected to device 1 it will send all measurements to device 1. Finally Table 4.3 shows the database of device 1 after the two devices have connected and the transaction is complete. The bandwidth is shown as bytes per second as mentioned in the system design.
ID Zone Band Easting Northing Bandwidth Samples Time 1 33 V 53314 647210 7568.59 1 2014-05-19 13:22:38
Table 4.1: Database of device 1 before transaction
ID Zone Band Easting Northing Bandwidth Samples Time 1 33 V 53313 647212 3190.94 29 2014-05-19 09:58:06 2 33 V 53315 647217 117.889 1 2014-05-19 09:59:31 3 33 V 53315 647219 2711.33 1 2014-05-19 09:59:33 4 33 V 53316 647218 656.268 2 2014-05-19 10:00:13 5 33 V 53316 647219 0 1 2014-05-19 09:59:53 6 33 V 53317 647218 1714.48 1 2014-05-19 10:00:25 7 33 V 53312 647217 1248.24 1 2014-05-19 10:01:33 8 33 V 53311 647217 2447.81 11 2014-05-19 13:21:49
Table 4.2: Database of device 2 before transaction
ID Zone Band Easting Northing Bandwidth Samples Time 1 33 V 53314 647210 7568.59 1 2014-05-19 13:22:38 2 33 V 53313 647212 3190.94 29 2014-05-19 13:23:15 3 33 V 53315 647217 117.889 1 2014-05-19 13:23:15 4 33 V 53315 647219 2711.33 1 2014-05-19 13:23:15 5 33 V 53316 647218 656.268 2 2014-05-19 13:23:15 6 33 V 53316 647219 0 1 2014-05-19 13:23:15 7 33 V 53317 647218 1714.48 1 2014-05-19 13:23:15 8 33 V 53312 647217 1248.24 1 2014-05-19 13:23:15 9 33 V 53311 647217 2447.81 11 2014-05-19 13:23:15
Table 4.3: Database of device 1 after transaction from device 2
As the tables show we can see that prior to connecting the two devices, device 1 only have one measurement. After the transaction from device 2, device 1 have nine location measurements. Since ID is a value assigned by the
database they will not be the same on device 2 as when transferred to device 1. The unique identifiers are the columns that represent the location. As of the current application version the time stamp given to each measurement is also set upon insertion to the database which can be seen clearly in Table 4.3 where all the measurements from device 2 have the same time stamp. This is a known bug in the system since the purpose of the time stamps is to show when the measurement was made.
Figure 4.1: Illustration of an example transmission sequence in the application To demonstrate the typical communication sequence for a connection we logged timestamps at certain events. All functions triggered by the user were made in a slow pace to differentiate each of the events. The timestamps in Figure 4.1 are the timestamps the application were able to capture since some events were handled by the Android system. The communication in our example is divided into four main parts:
• Peer discovery - The devices alternates between active scanning where they send probe request and passive scanning where they listen for probe requests. About half the time the device is sending probe requests and the other half it is listening for other devices requests.
• Group Owner negotiation - Once devices have found each other a GO negotiation is initiated. In our case device 2 sent the GO Negotiation Request followed by a Response and a Confirmation. The GO Negotiation request contains a Group owner intent value which is a value of how much the device wants to be the group owner. The response contains the Group Owner intent value of the other device. In our case, device 1 had the highest Group Owner intent value and thus became Group Owner. After a device has become GO it may send GO Broadcasts to inform other of its group.
• WPS Provisioning - After establishing a group and agreed on respective roles a secure communication is setup using Wi-Fi Protected Setup4which is a network security standard.
• Data transfer - After a connection is setup the application uses Java Sock-ets5 to send and receive the data.
4Wi-Fi Protected Setup (website), http://www.wi-fi.org/discover-wi-fi/
wi-fi-protected-setup,May2014
5Java Socket (website), http://docs.oracle.com/javase/7/docs/api/java/net/Socket.
Chapter 5
Discussion
5.1
Methodology
While we have made a real implementation, other people have chosen to sim-ulate or emsim-ulate performance evaluation. Est´evez and Carlsson [8] have made bandwidth prediction maps in similar fashion but examined it using trace-driven emulation.
We have chosen to make a real implementation over only making software simulations or simply analyzing facts and theories because experiments on a real implementation is concrete and gives results directly linked to reality. This is something that you cannot guarantee in a pure simulation environment. We will know how the mobile devices behave and how the throughput information sharing works in smaller networks simply because we can see it in action and analyze it in a series of experiments.
Since we will perform real experiments with a proof-of-concept implementa-tion we will have to automatically consider an array of problems and compli-cations that easily may be ignored or overlooked if we had chosen to only use simulations for evaluation. This include but are not limited to, the occurrence of congestion in the network and connection losses to either the Internet or to nearby devices in the ad hoc network. We will also handle eventual problems with the mobile devices that can affect the outcome of the result of the exper-iments. These are factors that can be difficult to consider and emulate in a simulator and can therefore easily be overlooked. This can lead to results that does not match reality.
Because of the circumstances with limited time the transferred data will not be optimized to send as little information as possible. For this proof of concept implementation the amount of data will be limited since the experiments will only involve a few devices and no mock data. When sharing information between devices the data will be sent as lists in the same way it is represented in the local database. If a larger scale experiment is done, we may have to rethink the way we transfer network performance maps in order to reduce the amount of
data being transferred. For example, compression and careful selection of which data may be input here, as the user may want to maximize the amount of useful information per transferred byte.
5.2
System design
We made an array of different decisions when designing the system, some of which we will discuss more in this section.
We gave the application user the choice of downloading three different sized files, ranging from 5 MB to 512 MB. This allows us to be able to run the test for a longer or shorter period of time, depending on which file size was selected. If you only want to measure the bandwidth in your current position you preferably choose the smallest sized file. If you want to measure the bandwidth in an area around you, the bigger files are preferred since the test will run for a longer time and will give you the opportunity to move around for a while and measure bandwidth on all the visited locations. This is to make the system more flexible and easy to use for measuring larger areas than just specific locations. The different files will all be downloaded from the same server to ensure continuous results, the location of the server is something that can affect the achieved bandwidth but the most important thing for us is that we always download from the same server since the difference between bandwidth on different locations is the most interesting to us. This is something that will be kept when we always proceed from the same prerequisites.
We chose active measurement to give the system more control over the band-width measurement, also because this will give us more reliable results. As men-tioned before is it important that we make measurements on downloads from the same server since the server can affect the bandwidth. This is something we cannot control if we would use passive measurement since the Internet activities would depend on the user. The measurements would not only depend on the network performance but also on the applications and services run by the user which is something we want to avoid. The active approach fits the proof-of-concept implementation very well but if the system was to be commercialized a passive approach could be considered since users may be reluctant to download otherwise useless content. It would also prevent users having to inject extra traffic to the device.
When updating bandwidth estimations with new measurements we use the predefined value of s, a different approach to this problem would be to let s depend on the time stamp of the earlier made estimation. This would make us able to put less emphasis on the earlier estimation the longer time that had passed since it was measured. We have not implemented this function in the system but it is a possible solution and would be something we could have tried if we were to develop the application more.
The use of a decentralized type of network is a main factor in creating a solution that improves the user experience of a network from the user end. If we would have used a central server to share data the user would have to rely
on the existing network conditions to share and receive data. It would also require a server that is always online. By using an Ad hoc network a device can connect to surrounding devices and retrieve useful information about the network conditions, even if the device does not have a connection to the network itself. By using WiFi to share data we can also share the data more energy efficient than sharing it by 3G or 4G. Since the application was made to prove a concept we have not focused on energy efficiency in terms of how often and how much data is shared. To be able to determine how to handle the communication energy efficient, we would have to perform additional experiments and possibly larger scale simulations. Seen from an end user perspective it might be worth some energy loss when sharing maps to get a better network experience.
5.3
Privacy aspects
In this section we discuss some privacy aspects we have considered when cre-ating our system. When handling and storing users Internet activities and geo-locations you have to be careful with what you store and how you use it. This makes it important that the user are fully aware of what the system are capable of and has to give the application permission to execute this.
One factor to consider is the consequences and differences of active or pas-sive measurement. If paspas-sive measurement is used the system will constantly monitor the users Internet activities and the location of the device. This could be a possible privacy intrusion since this makes the system able to store which websites the user are visiting and what content that are requested. It will also constantly keep track of where the user is traveling. Since we have chosen the active route of measurement we do not have to consider this to much since the system only monitor the Internet activities during the manually initiated test downloads. This indirectly gives the user more control over the system.
Another factor to consider is how the data is shared. This can either be done by using central servers or be done by using peer-to-peer. Depending on which technique is used, some data can be collected about a device without its consent. If a central server is used, all devices would share information through the server. By designing the system this way it would be possible to store information about each device and which locations it have visited. Peer-to-peer sharing would instead make it a lot harder to collect information about a specific device. By making it possible for devices to share data directly with each other it would be more difficult to determine where the shared data came from originally. From a privacy aspect none of these techniques can be considered private but by using a decentralised system it is a lot more complicated to link locations to a specific device.
5.4
Results
From the implementation and result gathered we have provided a verification of a Wi-Fi P2P based information sharing system for network performance maps. As the result show, the time parameter is not set correct when receiving data from another device. For the sake of actuality this is a problem since it may seem like a fresh measurement but may be outdated. Whereas this may affect future throughput prediction, it does not affect the validity of our proof-of-concept implementation. The outcome of the transaction is as expected since all data was transferred from one device to the other and inserted into the database. We believe further development of this application would allow for further experiments on how effectively the application shares information. But since the application is in early stages of development it functions best to see that network performance map-sharing can be implemented over Wi-Fi P2P.
Chapter 6
Conclusion and future work
In this thesis we have presented the design and implementation of a proof-of-concept crowd-based information sharing system for network performance maps as well as analyzed the overhead associated with our implementation. The analysis shows that the implementation allow nearby peers to exchange large amount of throughput-map information relatively quickly. While the transfer time increases with increasing round trip times, we expect the protocol to be useful for many applications, including download scheduling, bit rate adaptation and creating a network performance overview. We have also examined the usages of a network performance map and alternative solutions.
Although the implementation is functioning, the prototype is not optimal. If we had more time in this project we would have changed or added some things to the system. One of those things would be to make the system more auto-mated. The current state of the implementation is that you have to manually control when to start a test, when to connect to what other device and when to send the performance map to another device. We would have liked to make the information sharing with other devices automated so neighbouring devices continuously synchronized their performance maps with each other. This would make the application more flexible to use together with other devices.
We would also have liked to implement some form of priority policy for bandwidth map sharing. This was supposed to decide which bandwidth samples to send first when synchronizing the map with other devices. It would have made the system more stable and flexible when the network conditions are poor. The system does not have any priority policy in its current state and simply sends the entire bandwidth map in the order the samples are aligned in the database. Along with a priority policy, some additional parameters could be stored to provide an even better estimation. Such parameter could be a calculated standard deviation to be able to see how stable the connection is at a location. Locations with very high standard deviation may provide such unstable connec-tion that an applicaconnec-tion might want to treat it the same way as a locaconnec-tion with low throughput.
adaptation and download scheduling but we would have liked to implement a better way to visualize it. This is more of a bonus function and is not really necessary for a proof-of-concept implementation but, it would be a better way to provide an overview of network conditions in the area.
Bibliography
[1] J. Yao, S. S. Kanhere and M. Hassan, ”An Empirical Study of Bandwidth Predictability in Mobile Computing”, Proceedings of the Third ACM Inter-national Workshop on Wireless Network Testbeds, Experimental Evaluation and Characterization, WiNTECH, San Francisco, CA, September 2008, pp. 11-18.
[2] J. Yao, S. S. Kanhere and M. Hassan, ”Improving QoS in High-Speed Mo-bility Using Bandwidth Maps”, IEEE Trans. on Mobile Computing, Vol 11, Issue 4 (April 2012), pp. 603-617.
[3] J. Sommers and P. Barford ”Cell vs. Wi-Fi: On the Performance of Metro Area Mobile Connections”, Proceedings of ACM Conference on Internet Measurement Conference, IMC, Boston, MA, November 2012, pp. 301-314. [4] M. Andrews, K. Kumaran, K. Ramanan, A. Stolyar, P. Whiting and R.
Vijayakumar, ”Providing Quality of Service over a Shared Wireless Link”, IEEE Communications Magazine, Volume 39, Issue 2 (February 2001), pp. 150-154.
[5] H. Riiser, T. Endestad, P. Vigmostad, C. Griwodz and P. Halvorsen ”Video Streaming Using a Location-based Bandwidth-lookup Service for Bitrate Planning”, ACM Trans. Multimedia Comput. Commun. Appl. Vol 8, Issue 3 (July 2012), pp. 24:1-24:19.
[6] K. Hojgaard-Hansen, T. K. Madsen and H. Schwefel, ”Reducing communica-tion overhead by scheduling TCP transfers on mobile devices using wireless network performance maps”, Proceedings of the European Wireless Confer-ence, Poznan, Poland, April 2012, pp. 1-8.
[7] Daniel Camps-Mur, Andres Garcia-Saavedra and Pablo Serrano, ”Device-to-device communications with Wi-Fi Direct: Overview and experimentation”, IEEE Wireless Communications, Volume 20, Issue 3, (June 2013), pp. 96-104.
[8] A. Est´evez and N. Carlsson, ”Geo-location-aware Emulations for Perfor-mance Evaluation of Mobile Applications”, Proc. IEEE/IFIP WONS, Ober-gurgl, Austria, April 2014
