Technische Universitat BerlinFakultat IVInstitut fur TelekommunikationssystemeFachgebiet Telekommunikationsnetze

Projekt KommunikationstechnologienSS 2016

DocumentationProject: Advanced Network Technologies

Distributed Adaptation of MAC Access Category Parameters using ResFi inorder to increase downstream fairness between Stations

Viktor SchluterFlorian KnoppMarcin Bosk

Jonathan SchostakSupervisors: Sven Zehl, Dr. Anatolij Zubow

January 26, 2017

Contents

1 Abstract 1

2 Introduction 12.1 Background information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

3 Related Work 23.1 MiFi : A framework for fairness and QoS assurance in current IEEE

802.11 networks with multiple access points . . . . . . . . . . . . . . . . . 23.2 Using the 802.11e EDCF to Achieve TCP Upload Fairness over WLAN

Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

4 Problem statement 2

5 Project Requirements 35.1 Overall Project Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 35.2 Stage 1: Understanding causal Relationships between EDCA Parameters

and the throughput of an AP . . . . . . . . . . . . . . . . . . . . . . . . . 35.3 Stage 2: Building a testing framework which calculates the optimal EDCA

values for each AP in an arbitrary network topology . . . . . . . . . . . . 45.4 Stage 3: Design and Testing of the Algorithm . . . . . . . . . . . . . . . . 4

6 System Model 4

7 Approach 57.1 Creating a testing framework . . . . . . . . . . . . . . . . . . . . . . . . . 57.2 The ns-3 simulation environment . . . . . . . . . . . . . . . . . . . . . . . 57.3 Evaluating the EDCA values . . . . . . . . . . . . . . . . . . . . . . . . . 57.4 Finding the optimal MAC Access Category parameters . . . . . . . . . . . 67.5 Evaluation of an algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 67.6 The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

7.6.1 Design process and requirements . . . . . . . . . . . . . . . . . . . 77.6.2 Working principles . . . . . . . . . . . . . . . . . . . . . . . . . . . 77.6.3 Iterative execution . . . . . . . . . . . . . . . . . . . . . . . . . . . 87.6.4 Chosen algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87.6.5 Convergence Condition Value . . . . . . . . . . . . . . . . . . . . . 9

7.7 The Test Bed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

8 Implementation and evaluation 98.1 Algorithm simulation tool-kit . . . . . . . . . . . . . . . . . . . . . . . . . 108.2 Results and their implementation . . . . . . . . . . . . . . . . . . . . . . . 108.3 Changes made during simulation . . . . . . . . . . . . . . . . . . . . . . . 108.4 Small scale experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

8.4.1 Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118.4.2 System Modifications . . . . . . . . . . . . . . . . . . . . . . . . . 118.4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118.4.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

8.5 Multiple runs in multiple configurations . . . . . . . . . . . . . . . . . . . 12

8.6 Problems encountered during Simulation . . . . . . . . . . . . . . . . . . . 148.6.1 ns-3 testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

8.7 In scope of the network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158.8 Difficulties during testing the Algorithm on real Hosts . . . . . . . . . . . 15

8.8.1 EDCA patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158.8.2 The general TKN IT infrastructure . . . . . . . . . . . . . . . . . . 15

9 Conclusions and future work 169.1 Future Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

9.1.1 Presumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169.1.2 Convergence Condition Value . . . . . . . . . . . . . . . . . . . . . 169.1.3 Time synchronisation in ResFi . . . . . . . . . . . . . . . . . . . . 16

9.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1 Abstract

In this Work, a novel algorithm for in-creasing the downlink traffic fairness inWiFi networks in residential areas run-ning ResFi is introduced. This algo-rithm addresses the problems that arisewhen in a WiFi collision zone two Ac-cess Points (AP) operating on the samechannel have a different number of Sta-tions (STA) to serve with backloggeddownlink traffic. The APs with moreSTAs will have less traffic medium ac-cess per Station than the other AccessPoints. In this work, we solve this un-fairness by manipulating the CWmin val-ues of the APs with the goal of reachingan equal amount of traffic medium ac-cess per client across the whole collisionzone. In a few basic tests that were con-ducted, our proposed Algorithm showspromising results for solving this unfair-ness.

2 Introduction

With the rapid increasing popularity ofwireless networking, especially of theIEEE 802.11 Standard, new problemsarise. Because of the significant num-ber of Access Points, the QoS in heavilyurbanized residential areas significantlydrops. This is clearly observable whilstusing the WiFi in the 2.4 GHz band, as

the bandwidth is legally limited, mak-ing only 13 usable channels, from whichonly those labelled as 1, 6 and 11 couldbe used efficiently, as they don’t inter-fere with one another. As to be ex-pected, this is not enough in such areasto assure even load distribution and re-liable data transfer.

Recently, to combat the problem ofovercrowded 2.4 GHz band a new frame-work, called ResFi [3], has been in-troduced. It allows communicationbetween neighbouring Access Points,which are up to N hops away from eachother, over the Internet. Using thatplatform, dynamic channel allocationfor 802.11 wireless networks has alreadybeen implemented to help solve previ-ously mentioned issue, however it maynot be enough when there are manymore APs than the available number ofchannels.

2.1 Background information

In order to proceed with the projectsome background information wasneeded. As we will be manipulatingthe transmission times of access points,we need to know what the optimal(in terms of STA downlink fairness)medium access time of an Access Pointis. To our knowledge it could be definedusing the following equation:

TxT imeAPi =totalTxT ime

#Stations1·#StationsConnectedToAPi

In order to manipulate these times weare adjusting the parameters of the En-hanced Distributed Coordination Func-tion introduced in the IEEE 802.11e-2005 Standard. The Enhanced Dis-tributed Coordination Function intro-

duces four access categories, for whichdifferent values of Contention Window,as well as Arbitration inter-frame spac-ing (AIFSN) and Transmit Opportunityare set, the default values as shown inthe Table 1.

1Number of stations in the network

1

Access Category CWmin CWmax AIFSN TXOP limit (msec)

Background 15 1023 7 0Best Effort 15 1023 3 0

Video 7 15 2 5Voice 3 7 2 3

Table 1: Default EDCF parameters [2]

In our solution we decided to manipu-late the CWmin value of the Best EffortAccess Category as it is the standardcategory used for most types of traf-fic. We are not changing any parameters

of Video and Voice Access Categories,as they intentionally higher priority formore QoS dependent traffic, which wedo not want to interfere with.

3 Related Work

3.1 MiFi : A framework forfairness and QoS assurance incurrent IEEE 802.11 networkswith multiple access points

To archive the goal of fairness and QoSassurance the MiFi framework[5] hasonly one AP competing for transmissiontime in a given collision zone. This isarchived by deactivating all but one APin this collision zone. A centralized sys-tem assigns every AP a specific time slotto be active. The length of the time slotis depended on the current load of theAP and determent by a scheduling algo-rithm. However, the effectiveness of thismethod is only confirmed by simulation.

3.2 Using the 802.11e EDCF toAchieve TCP Upload Fairnessover WLAN Links

The goal is to archive fairness betweenmultiple TCP upstreams over one Ac-cess Point. If multiple TCP upstreamscompete for bandwidth on one AP, theACKs send back to a STA have a lowerprobability to be send then the up-stream TCP packets. Hence TCP reliesof a symmetrical propagation time ofupstream and downstream the flow and

congestion control mechanisms can’t beused efficient and unfairness betweenthe TCP stream occurs. Because TCPstreams which already have a largethroughput are not as much affected aslow throughput TCP streams the un-fairness increases over time. The pro-posed solution to this problem is us-ing a different Access Category for TCPACKs and by doing this creating a sym-metry in propagation time of the up-stream TCP packets and downstreamTCP ACKs.

4 Problem statement

In some areas, in scope of this paper– apartment complexes, there are stillmany APs too close to one another,for WiFi channels assignment, in a waythat every WiFi network is the onlyone on any given channel. When twoor more WiFi networks are in a closevicinity and share the same Wifi chan-nel, they have to compete for mediumaccess. More precisely, this means thatall Access Points compete for down-link capacity to STAs and all Stationscompete for Uplink traffic to APs. Asdownlink traffic occurs in greater vol-ume and is often required over longer

2

timespans (downloads, video streaming,etc.), we will be focusing on the down-link traffic in further considerations.

In the IEEE 802.11 standard, all APshave the same EDCA parameters andtherefore are granted equal medium ac-cess probability. For the same reason,they have an equal share of the down-link traffic. This is very acceptable aslong as all APs have a similar num-ber of stations to serve, but can resultin highly problematic situations whenone AP has significantly more stationsthan others. Given a situation wheretwo APs share a traffic collision zoneand one AP has 5 STAs but the otheronly one STA, the second AP will beable to send five times as much trafficto its station as the first one. From auser perspective this means that usersin one network will have a five timesslower downlink speed than the singleuser on the other network. It is clearthat this situation is problematic andunfair, which is why research is to beconducted to find a better solution tothis problem.

5 Project Requirements

In the following section, it is to belisted which requirements for a success-ful project result were defined in the be-ginning. The project as a whole can ac-tually be split in several, more or lessindependent subprojects. Even then wehave to define a few boundaries, if wewant to do this research as a one project.Firstly, the overall requirements for theproject solution should be identified.After that, all the subprojects shall beidentified. Lastly the requirements forall specific stages of the project are tobe listed.

5.1 Overall Project Requirements

The project should yield a result which

1. increases the time fairness of allSTAs in a residential WiFi net-work where all STAs and APsin the collision zone are mutuallyable to sense each other

2. incorporates an algorithm whichcan be executed in a decentralizedmanner

3. does not need a ”leading” entity.It should be robust against suddendisconnections of any STA or AP

4. is completely implemented inPython so that it can be easilybuilt into ResFi as an application

5.2 Stage 1: Understandingcausal Relationships betweenEDCA Parameters and thethroughput of an AP

The first part of the project was basi-cally to understand the world around us.In the beginning, after we read throughthe topic specific literature, we onlyknew that higher CWmin values wouldprobably lower the network throughputto a certain degree. We needed to get afeeling for this causal relationship. Therequirements we set to ourselves were:

1. Understand how strongly thechange of EDCA parameters of asingle AP will change each indi-vidual flow in a network

2. Build a rough, qualitative modelof these causal relationships

3. Understand, how big area of thenetwork is affected if EDCA pa-rameters are changed. The dis-tance in the network was speci-fied as ”hops”. Each “hop” is de-fined as two Access Points linkeddirectly to one another.

3

4. Understand how our model of theworld changes with different net-work architectures.

5.3 Stage 2: Building a testingframework which calculatesthe optimal EDCA values foreach AP in an arbitrarynetwork topology

Before we designed the algorithm, wewanted to know which combination ofEDCA parameters actually led to thehighest overall throughput or to thehighest time fairness. We needed a so-lution for a testing framework that:

1. allows to get the perfect combina-tion for arbitrary network archi-tectures

2. is not limited in regards of thenumber of STAs or APs in the net-work

3. allows to build the network topol-ogy in an easy to use way, prefer-ably as a graph

4. allows us to see the resulting idealEDCA configuration in a graphi-cal way, ideally overlaid with theoriginal network structure

5. is modular so we can reuse itsparts for testing the algorithmlater on

6. does not contain ns3 simulationtool, but rather gives a very easyto use way of only pointing thetest bench to the ns3 installationdirectory which would be the onlystep of configuration on a newhost.

5.4 Stage 3: Design and Testingof the Algorithm

In this stage the goal is to find an algo-rithm that fulfils the following criteria:

1. After each round, find a suitable(better) CWmin value for the nodethe algorithm is executed on

2. Fast. After as few rounds as pos-sible, the algorithm should reachthe ideal configuration as calcu-lated by our workbench for anygiven network topology

3. Fully distributed. The Algorithmshould be implemented in a fullydecentralized manner. Each nodeonly gets the other node’s mediumaccess times and can assign itselfa CWmin value for the next round.

4. Robust against sudden disconnec-tion of any nodes

5. As soon as ideal configuration isfound: No oscillation beyond rea-sonable margins

6 System Model

WiFi networks are very complex sys-tems because their system behaviour de-pends on lots of statistical events. Thecomplexity is so high, that modelling as-sumptions have to be made to be ableto make rough predictions about the be-haviour of WiFi networks.For this project, the following Model As-sumptions about small, residential WiFinetwork clusters were made:

1. All entities (STAs and APs) arein the same collision zone. Thismeans that any pair of entities iswithin the transmission range ofeach other. As a result of this,all the STAs and APs compete formedium access time in exactly thesame collision zone. This meansthat the hidden terminal problemdoes not have to be taken into ac-count.

4

2. Because only the fairness of thedownlink can be increased withthis project, we assumed thatthere is no uplink traffic in thenetwork. Secondly, because thisprojects’ scope was more to opti-mize constant downlink traffic asin a video stream, downlink trafficwas assumed to be backlogged.

3. It was assumed that the MediumAccess Time of each WiFi APis proportional to its actual net-work access in terms of trafficshare. With this assumption weare willingly making a small error,because this does not does con-sider the collisions that may occur(These collisions happen when twoentities send at the same time andboth abort their sending. This isa statistical process and cannot bepredicted).

7 Approach

7.1 Creating a testing framework

Goals for the testing framework

1. Test how big the effect of manip-ulation of the EDCA values in anetwork is. See if increased EDCAvalues would have a negative im-pact on the overall throughput ofthe network.

2. Help decide on the structure of analgorithm.

3. Evaluate the algorithm.

Requirements for the testingframework

1. Easily create different networktopologies.

2. Quickly evaluate a network andfind the best possible configura-

tion of MAC Access Category pa-rameters.

3. High modularity, so that it couldbe used, not only to find the bestpossible configuration of EDCAvalues, but also to simulate a dis-tributed algorithm.

7.2 The ns-3 simulationenvironment

ns-3[[1]] is a discrete-event network sim-ulator, targeted primarily for researchand educational use. The simulator isfree, open source and is capable of sim-ulating the scenarios we needed.

One drawback of ns-3 is the lack of angraphical user interface. ns-3 can onlybe operated using a C++ or Pythonscript. This makes it impractical tocope with a vast number of networktopologies.

To overcome this problem we createda Python script that could take a graphin form of JavaScript Object Notation(.json) into ns-3. The graph can becreated or changed with a graph edi-tor. For this purpose we used the freeof charge graph making tool called yEd[7].

Thanks to those extensions, we wereable to quickly create different topolo-gies and easily analyse them in ns-3.

7.3 Evaluating the EDCA values

Our overall goal was to achieve timefairness between all STAs in one colli-sion zone. Unfortunately ns-3 has nomeans to measure the medium accesstime. Under the assumption that wedon’t have any packet loss and each STAhas exactly the same transmission time,we can assume that it is proportionalto the data throughput. Using that as-sumptions we can aim for throughputfairness in our simulation.

5

In the simulation we first load a net-work graph into ns-3. Then we setMAC Access Category parameters andlet the simulation run for a simulatedtime of two seconds. This gives the sys-tem enough time to reach a stable stateand has a relatively short computationtime.

To evaluate the system we can com-pare the deviation of throughputs foreach AP. To evaluate the set of Parame-ters we can look for the minimal averagedeviation of all APs or look for the low-est throughput of all APs.

7.4 Finding the optimal MACAccess Category parameters

To find the optimal set of EDCA valuesfor a given topology we decided to use a

Monte Carlo approach. The drawbackwith this method is the exponentiallygrowing computation time, with the in-crease of topology size and set of possi-ble MAC Access Category parameters.Luckily we only have to analyse smalltopologies and variate the CWmin value,as shown in Figure 1. CWmin = 2n − 1with n in the range of 4 – 10 . With only6 possible values for CWmin its feasibleto simulate all possible combinations ofCW min values in small networks. Thebenefit of this method is that its guar-anteed that we will find the best possi-ble combination of values for any giventopology.

Figure 1: Finding the optimal CWmin values for a network topology

7.5 Evaluation of an algorithm

Because our method of finding the opti-mal values for a topology is fairly mod-ular we can easily modify it for algo-rithm testing. In order to accomplishthat, we no longer iterate the CW min

values but let a round based algorithmchange it, based on the measurementsof the throughput, as shown in Figure2. Each round we collect the measuredthroughputs of all APs and plot the de-viation.

6

Figure 2: Algorithm evaluation

This process can now be applied tomany different topologies. This re-sults in significant computation timebut gives good data on how an algo-rithm performs.

7.6 The Algorithm

After an extensive analysis, and as men-tioned in previous sections, we decidedto manipulate the CWmin (minimal con-tention window) values of the 802.11eIEEE Standard Enhanced DistributedCoordination Function (EDCF). Toachieve a rational solution to the prob-lem, evidently an algorithm is needed,focus of which will be to determine thevalues for EDCF CWmin parameter.

7.6.1 Design process andrequirements

Designing a new algorithm requires ex-tensive knowledge of the problem andspecifications it has to fulfil. Extensiveresearch conducted earlier gave us thatknowledge and allowed for the creationof a requirements list as showed below:

1. Developed algorithm has to beable to run on each Access Pointseparately, using only the datacollected from neighboring APs

2. The algorithm has to work decen-tralized

3. Whole solution should not needexternal maintenance as it wouldbe implemented mostly in net-works with various owners

4. Algorithm has to be suitable towork in residential areas

5. It has to be robust – failure ofany Access Point shouldn’t influ-ence the functionality of the dis-tributed algorithm in the remain-ing nodes

7.6.2 Working principles

The Algorithm has to naturally followsome guidelines as it would be subjectedto real environment which has its rulesand limitations. Time is one of the mostimportant factors we have to deal withon levels.

Firstly it has to be decided when toadjust each Access Point’s settings. Ifevery AP decided independently whento do that, it could potentially lead tochaos, mainly because obsolete, or oldmixed with new, information might beused. That is why we decided to devel-oped an iterative algorithm, which will

7

be executed once every “round”.

Naturally each action requires back-ground information in order to have theintended effect. The algorithm we wantto create is no exception. Each iterationof it has to be preceded by a data collec-tion and processing period. Followingdata types have to be collected from allneighbouring Access Points, assumingall obey the time-frames set for eachround:

• Total transmission time (Tx time)of each AP in respective timeframe (round)

• Number of stations connected toeach AP

7.6.3 Iterative execution

As mentioned earlier, in order for the al-gorithm to work properly, we decided togo with a cycle based algorithm, whichwill be run once each ”round” on ev-ery participating Access Point. Eachiteration has to be well structured tominimize the risk of errors due to badtime synchronisation or previously men-tioned data ”chaos”. We went with thefollowing structure:

1. Data collection phase - Measure-ment of the Tx time and numberof connected stations

2. Data exchange phase - AccessPoints interchange the in 1 col-lected information

3. Setup phase - Here the algorithmis run and, if need be, the CWmin

values are adjusted

For simulation purposes and due toNS-3 limitations when it comes toEDCF values setting ability we simpli-fied the ”round” arrangement to a datacollection phase, where the network wassimulated and a setup phase where thealgorithm was run and values were set.

7.6.4 Chosen algorithm

In case of our algorithm, the hardestpart was to determine when the CWmin

values should be adjusted. Accordingto the 802.11e standard the ContentionWindow parameter may only be set to2n − 1 where n ∈ {1, 10}, what couldlead to sizeable changes of the AccessPoint’s Tx time and further bring thewhole system into a state where twoAPs constantly switch between sameto values, as they influence each otherheavily.A partial solution we found is to onlylower the CWmin value of the AccessPoints which are ”the worst” (meaningthey are supplying the least through-put per station) or increase the min-imal Contention Window variable of”the best” (most throughput per sta-tion). This lowered the probability ofthe system to come into a transientstate, however it still wasn’t enough tofulfil the project requirements. There-fore a further limitation was introduced,namely only the access point which hadthe most throughput could make itselfworse and the one that had the leastthroughput, together with the fact thatit had the biggest deviation from the op-timal TX time from all Access Points,could make itself better.

The resulting algorithm looks as fol-lows:

2 Optimal (ideal) transmission time is calculated based on own number of station, number of stationsin area and summed transmission time of all APs, using the Formula ?? from Section 2

3Discussed in Section 7.6.5, this is our manually set convergence.

8

Algorithm 1 Calculate the new CWmin value based on recent network statistics

delta← own deviation from optimal tx time2

delta list← list of deviations of other APs calculated from gathered dataif max(delta list) == delta thenif old own CWmin exponent < 10 then

own CWmin exponent+ = 1end if

end ifif min(delta list) == delta and max(delta list) < absolute value(min(delta list))thenif old own CWmin exponent > 4 then

own CWmin exponent− = 1end if

end ifif absolute value(delta) <= convergence condition value3 then

own CWmin exponent = old own CWmin exponentend if

7.6.5 Convergence Condition Value

To secure, that the system remains ina static state for the periods, where thedeviations from optimal Tx time are suf-ficiently low, some form of a conditionwas needed. That’s exactly the reasonwhy we introduced the convergence con-dition value. As could already be seenin Algorithm 1 it makes sure that whenthe system is in a near-perfect configura-tion, all CWmin value changes are beingheld up until there is a bigger change insystem’s transmission times.

Originally the convergence conditionvalue was thought to be dynamicallyset, but difficulties in development ofanother algorithm of high complexityand simulations which showed that astatic value would work sufficiently 4,resulted in revaluation of the idea infavour of a constant which for mostcases assures seamless operation of thealgorithm.

7.7 The Test Bed

To test the Algorithm under real worldconditions, a simple testbed was used.The APs were two ResFi Routers hostedon machines in the TKN lab. TheSTAs were 5 ESP8266 WiFi chips, pro-grammed with c++ in the Arduino en-vironment. The tests were done by firststarting the ResFi instances on the hostmachines and after approximately fiverounds switching on the STAs, whichthen joined the WiFi ResFi networks.The measured medium access times ofeach router were saved, as well as theirCWmin values.

8 Implementation andevaluation

Development of an algorithm requiresvarious tools to speed up and simplifythe process. Running an unfinishedproduct on real hardware would notbe feasible due to time concerns such asthe set up time needed to prepare an ex-periment, the availability of hardware,

4Discussed in Section 8

9

etc. That’s where again a simulated en-vironment came to a great help.

To simulate the functionality of our al-gorithm, as previously, NS-3 environ-ment, including modules developed forMonte Carlo simulation and backloggedtraffic precondition, was used. Nat-urally some modifications were made,biggest of which was the substitutionof the CWmin values generator with analgorithmic tester.

8.1 Algorithm simulation tool-kit

In order to simulate the algorithm somesimplifications and adjustments had tobe made. First of all the test sub-ject had to be implemented ”centrally”,meaning that only one instance of thealgorithm was built and then it wassupplied necessary information neededto calculate CWmin values for each Ac-cess Point separately.

Due to the incapability of NS-3 tochange the MAC Access Category Pa-rameters while simulating we simu-lated four second, stopped the simula-tion then changed parameters and thenstarted a new simulation. We foundthat a simulation time of four secondswas enough to reach a stable state anddeliver meaningful results.

Lastly, an additional module has beenadded to NS-3 environment, which au-tomatically presents the results graph-ically, directly after the simulation isfinished.

8.2 Results and theirimplementation

Knowing what describes good results iscrucial to determine which iteration ofan algorithm works the best. The fol-lowing list represents the most impor-tant features of a good working algo-rithm:

1. After some ”rounds” the systemhas to come into a static state 5

2. The fewer iterations it needs toreach a stable configuration, thebetter between packets. In manycases the throughput decreases,even though the system is in thebest configuration possible

Points listed above are perfectly rep-resented in the exemplary simulation re-sults for the final algorithm shown inFigure 6, which was performed on net-work topologies6as shown in Figure 7.

8.3 Changes made duringsimulation

During the simulation period we madenumerous changes to the algorithm.

First major change was to go from try-ing to cover all possible cases manually,towards a more liberal approach - coverthe extremes in a given network. Thisfeature is now the core of our algorithm.

Furthermore, after the introduction ofconvergence condition value, it was finetuned to make the deviations from op-timal transmit time be very small, to-gether with the smallest risk of the sys-tem never finding a stable configuration.

5Yellow square represents an Access Point, the number in the square represents how many Stations areconnected to the given Access Point

6It suffices, as backlogged traffic is used in simulations

10

Those adjustments were made while ob-serving the algorithm behaviour for 18various network topologies as shown inFigure 7.

As previously mentioned a dynamic con-vergence condition value was proposed,but the idea was abandoned due to theinability to achieve definite results insimulation. Dynamic value would alsorequire a complicated algorithm whichis not feasible, where simplicity is de-sired.

8.4 Small scale experiments

8.4.1 Preconditions

After evaluating the concept by simula-tion, we tried to apply it in a real-world-scenario as a ResFi-App. To performthis task, we acquired two of the com-puters ResFi was developed to serve asaccess points to eliminate compatibilityproblems. The units in question wereordinary PCs running Ubuntu and be-ing equipped with Atheros-9000 Wire-less Cards.

Already included in the ResFi-package available on GitHub is a pre-configured version of “hostapd”, a soft-ware tool for setting up an access pointon a UNIX system.

It was important for a successful, vari-able, test environment to have as manyStations as possible. Thus, we used tiny”Internet-of-Things” Devices (ESP8266Module-12e), which are able to connectto a given WiFi-Network and receive aUDP packet dump.

8.4.2 System Modifications

The main goal needed for the concept towork is the manipulation of the EDCA-parameters of the APs. The driver ofthe Atheros-9000 module does not sup-port this by default. As a workaround,we used a modified version which en-

ables this function and lets us edit val-ues with help of “debugfs”, by writing toand reading from a corresponding file.

Furthermore, the standard ResFi-package was not capable of providingan internet connection to the stations.This was necessary to control our sta-tions. Thus, we installed a DHCP-server and modified the IP-tables ac-cordingly. It was possible to connect toone of the access points with an ordi-nary smartphone and surf the internetafterwards.

8.4.3 Implementation

The implementation in the simulatorwas simplified because of the givenstructure concerning the time manage-ment which triggered the algorithm in afixed time interval for each Access Point.Obviously, this was not the case in thereal world scenario. To simplify the im-plementation, we assumed as a require-ment that the access points are synchro-nized time-wise. This is the case any-way on an Ubuntu system as the sys-tem time is synchronized via the NTP-protocol over the internet with a resolu-tion scale of 10ms.

The second unavoidable modificationwas the introduction of a fixed cyclewhich consists of three phases triggeredevery 5 seconds at fixed times. Thephase length was not optimized, sincewe were working in a testing environ-ment with a constant throughput. Theproportion of the measuring phase tothe other phases is not of a great sig-nificance. We also chose a long time toexchange the data between APs to pre-vent errors due to uncompleted trans-missions. To ensure that all the trig-ger times in all ResFi instances wherenearly the same (with the error marginof NTP), a modulo on the seconds com-ponent of the UNIX time was used. Thecycle consisted of the following phases:

11

Figure 3: Sequence of phases of the implementation

In Phase 1 the current medium ac-cess time is measured. As an equalshare of medium access time per sta-tion is intended for every AP, from thecurrent medium access times and theneighbors medium access times, everyAP can know if it has too much or toolittle medium access. The assumptionhas been made, that the medium accesstime is proportional to the throughputof every AP. While in the Simulationthe throughput was used as an indica-tor whether an AP has too much or toolittle medium access, in the real worldimplementation the medium access timecould be used directly. As our algorithmdescribes the medium access share rela-tively to the overall available mediumaccess, it does not matter whether thealgorithm uses the relative throughputor the relative medium access time asan input.

In Phase 2 each AP, and thereforeeach node in the network, sends it’smedium acces time per STA via a broad-cast to all the other APs in the scope.Thus, after this phase, the APs knowone anothers medium access times.

In Phase 3, each AP starts the al-gorithm to alculate their new CWmin

values and assign them to themselves in

preparation for the next round.

Note: All devices were using the2.4GHz-band on channel 1.

8.4.4 Results

Because of limited resources (only 2working ResFi Access Points), we couldonly test our Algorithm on small topolo-gies. Since ResFi organizes the APs tothe best possible channel configuration,either way the number of APs in onecollision zone should be relatively small.

Note: In this scope, ResFi was notyet fully tested, on a bigger scale, in areal environment.

8.5 Multiple runs in multipleconfigurations

To finally evaluate if the proposed ap-proach works as expected, multiple au-tomated tests were performed with ourtest system.All tests finished with expected, positiveresults. Two of these tests with two ac-cess points are displayed below.

12

-20 0 20 40 60 80 100Time since STA connect in s

-100

0

100

200

300

400

500

600

700

800

TX-T

ime

to a

ll ST

As p

er 5

s in

ms

2 APs with 3 vs. 2 STAs, 23 runs

Standard TX time of a single AP in this environmentAP with 3 STAsAP with 2 STAsSum of both TX times

-20 0 20 40 60 80 100Time since STA connect in s

15

20

25

30

35

40

45

50

55

60

65

CW

min

-val

ue

AP with 3 STAsAP with 2 STAs

Figure 4: Test Results for a 3 vs. 2 configuration

-40 -20 0 20 40 60 80 100Time since STA connect in s

-100

0

100

200

300

400

500

600

700

TX-T

ime

to a

ll ST

As p

er 5

s in

ms

2 APs with 4 vs. 1 STAs, 15 runs

Standard TX time of a single AP in this environmentAP with 4 STAsAP with 1 STASum of both TX times

-40 -20 0 20 40 60 80 100Time since STA connect in s

0

100

200

300

400

500

600

CW

min

val

ue

AP with 4 STAsAP with 1 STA

Figure 5: Test Results for a 4 vs. 1 configuration

13

Displayed in figure 4, the configu-ration was a 2 vs. 3, meaning oneAP is connected to three STAs andis thus more stressed, while the otherone is only connected to two. Thethinner lines in the background repre-sent the individual measurements, thethicker lines show the mean value of allruns. The lower figure displays the ad-justed CWmin-value of the less stressedAP. The CWmin-value of the other APis not displayed as it is always the lowestvalue possible to maximize its through-put.

The horizontal lines in the figuresshow the level of transmit time eachof the two APs usually got in our en-vironment without the algorithm run-ning. These times were of course equalfor both APs as EDCA provides statisti-cally evenly distributed medium accesstimes for APs with the same EDCA-parameters. Both times together sumup to a bit over 650ms.

Regarding the mean’s graph, one canquickly, after just two 5s-cycles, see theTX-times of both APs drifting awayfrom each other due to the refitting ofCWmin-values. This results in a muchhigher TX-time in the outcome and con-sequently medium access time for themore stressed AP and a lower for theother one. To be specific, the AP with2 STAs settles down at about two thirdsthe TX-time of the other one (∼250ms

∼380ms).As these two numbers sum up to about630ms it is also visible that the drop ofthe overall TX-time is not as big as ex-pected.

This shows the algorithm generallyworks as intended, as every stationshould get the same amount of TX-time,which should be the case here if all STAsare sinking at the same rate. This is thecase here because the STAs receive anUDP stream controlled by the APs.

As visible at the paler plots in the

background, each individual run doesnot have an equally good output asthe mean’s representation intends. Themain problem here is a serious oscil-lation of the TX-times of over 100ms.This occurs due to the big differencesbetween the possible CWmin-values. Asolution would be a more complicatedtermination algorithm detecting whenthe optimal state is reached, which wasnot treated in this project but would bea possible future improvement.

All features analysed above for figure4 can also be observed in figure 5. Here,a 1 vs. 4 configuration was used and theTX-times do settle down at a 1:4-ratio

(∼ 100ms

∼ 400ms) as it should be analogous to

the above explanations. This shows thealgorithm works reliable in different en-vironments.

8.6 Problems encountered duringSimulation

While the first part of our project wasvery non-technical as it was about un-derstanding EDCA and reading specifi-cations, the second part wasn’t.

8.6.1 ns-3 testbench

While we built the ns-3 test bench, weran into various issues: It turned outthat while a documentation for ns-3 ex-isted, it was more a specification ofthe classes contained in the frameworkthan a thorough explanation about howthings worked. This resulted in us usinga demo application that shipped withns3 and adding additional functionali-ties, until our needs were fulfilled. Abig problem with simulation software istrust, the user needs to trust the simula-tion software that it is sufficiently pre-cise in its modelling of the real world.We all were sceptical how representativeof the reality ns3 was until we finally

14

tested the algorithm on real hardware.Weak evidence for our scepticism werenumeric inconsistencies in the through-put results of ns3 test runs. In caseswhere all throughputs would have to beequally as high, they were not by a fewpercent. We had problems with someAPs reporting a throughput as zero, al-though they were configured to sendbacklogged traffic.

8.7 In scope of the network

A big problem for us was in the begin-ning, that it was not known for howmany hops the network would be af-fected of changes (both EDCA changesand adding/disconnecting clients). Itwas tried to solve this problem bymeasuring the effects of incrementingCWmin value in an increasingly big-ger network, but this did not yield suf-ficient results. In the end the solu-tion was to assume that all consideredSTAs and APs were in the same collisionzone. With this assumption, the net-work topology became very simple andthe problem of scope was solved.

8.8 Difficulties during testing theAlgorithm on real Hosts

Probably the longest stage of ourproject was unsuccessfully trying to setup a small test environment on the TKNIT infrastructure. This can be struc-tured into the following issues:

8.8.1 EDCA patch

It was a very time consuming processof many trial and error solutions un-til we were able to compile and installthe EDCA patch ourselves. This EDCApatch allows the manipulation and re-trieval of EDCA parameters such asCWmin on ath9k cards on Linux. Wewere just given a patch file and the

instruction to patch version a specificof the ath9k driver in backports withit. It turned out that to be success-ful, the folder in which the unpatcheddriver files were located in, needed tohave a very specific, obscure name. Af-ter the patching, some configuration ofthe source code files needed to be done,which also was only found out by trialand error. After being able to build thepatch it turned out that the patch wouldjust not run on one of the given host ma-chines (harry).

8.8.2 The general TKN ITinfrastructure

Many problems were met while usingthe TKN infrastructure, more specifi-cally the following hosts: nuc15, gustavand harry These problems included:

1. WiFi cards. As it turned out,some hosts changed their physicalconfiguration during the time wewere using them. One of the hostslost all of its WiFi cards, whichmade it impossible to use in a test-ing setup

2. ResFi. It was very time consum-ing to get two instances of ResFirunning on hosts that visible toeach other. On some sessionswhere we met up, we failed alto-gether to start up two instances.We were confronted with errormessages that we did not under-stand and most importantly theycame and went on the same hostswithout us changing anything. Itturned out that being able to startup ResFi on a host on one sessionwas not guarantee to be able tostart it up on the next project ses-sion. This was a sometimes frus-trating experience.

15

3. Up and downtime of the hosts as-signed to us. It is highly proba-ble that other teams ot researcherswhere using the same hosts atthe same time, which meant thatother people sometimes turned offthe hosts we were working onthem. At one point we lost a host,fearful that we had destroyed itwith some Linux trial and errorproblem fixing, only to later real-ize that it had been turned off.

9 Conclusions and futurework

9.1 Future Improvements

On numerous occasions some simplifica-tions and assumptions of the real worldwere made. Therefore further researchand improvements of the proposed so-lution are possible and strongly recom-mended in the future.

9.1.1 Presumptions

Major assumptions and simplificationsthat has been made include the follow-ing:

1. Backlogged traffic - In our simula-tions and testing we assumed thateach station would receive an un-limited data dump from the accesspoint. Further development of thesolution to fairness in residentialwireless networks would requiremore randomised approach in thatarea.

2. Only downlink was simulated,while neglecting the uplink. In or-der to conduct further research, itwould be necessary to simulate thenetwork traffic that comes fromthe stations to the access pointsas well.

3. For the development we chose tosimplify the network simulation,assuming that each station re-ceives the data at a maximal ratethe 802.11n standard allows for inthe 2.4 GHz spectrum. Contem-plation of stations using variousdata rates for downlink might benecessary in the future develop-ment.

4. Hidden terminal problem was ne-glected. It would be beneficial tostudy the influence of such sta-tions on our solution further.

9.1.2 Convergence Condition Value

The value that determines whetherthe Contention Windows of the AccessPoints should be adjusted has, as ofnow, been implemented statically in thesolution we propose. Dynamically setconvergence condition value has beenproposed, but due to time constrains theidea was abandoned. It might be bene-ficial to investigate this concept furtheras it might produce smaller deviationsfrom the optimal Tx times on each ac-cess point.

9.1.3 Time synchronisation in ResFi

At the time this documentation is beingcreated, ResFi is relying on NTP (Net-work Time Protocol) for the time syn-chronisation off all access point in a clus-ter. Each AP synchronises it’s clock in-dependently with the time server, whatmight not be sufficient if really high ac-curacy is desired. In this area a pro-posed time synchronisation using PTPin the ResFi itself and introduction ofa separate timeline for such networksmight be beneficial.

16

9.2 Conclusion

The creation of an easy to use testingframework, made the development andtesting of our algorithm possible. Thesimulations showed that the medium ac-cess time of each AP could be effectivelymanipulated by changing the MAC Ac-cess Category Parameters. This allowedus to deliberately slow down APs.

Through the ResFi backbone wecould share the medium access time ofeach AP between neighbour APs. Theinformation could be used as input foran round based and decentralized algo-rithm which choose the CWmin value

for the next round. APs with fewerclients then its neighbours would take ahigher CWmin value then its neighbours,which were under heavier load resultingin time fairness for all STAs regardlessof which AP they are connected to. Us-ing the testing framework we simulateda lot of different topologies to ensurethe functionality of the algorithm. Aftersuccessful simulations, we implementedthe algorithm as an App for ResFi, sothat we could test the functionality ofthe system on real hardware. We foundthat manipulation of the CWmin valuesand the algorithm worked well in realityas well.

17

References

[1] NS-3 Documentation. https://www.nsnam.org/ns-3-25/documentation/

[2] IEEE 802.11e Contention-Based Channel Access (EDCF) Performance Evalua-tion, Sunghyun Choi1, Javier del Prado, Sai Shankar N, Stefan Mangold 2003.http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1204546

[3] ResFi: A Secure Framework for Self Organized Radio Resource Management inResidential WiFi Networks, Sven Zehl, Anatolij Zubow, Michael Doring Adam Woliszhttp://www.tkn.tu-berlin.de/fileadmin/fg112/Papers/2016/zehl16resfi.pdf

[4] 802.11e-2005 - IEEE Standard for Information technology–Local and metropoli-tan area networks–Specific requirements–Part 11: Wireless LAN Medium Ac-cess Control (MAC) and Physical Layer (PHY) Specifications - Amend-ment 8: Medium Access Control (MAC) Quality of Service Enhancementshttp://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1541572

[5] MiFi: A Framework for Fairness and QoS Assurance for CurrentIEEE 802.11 Networks With Multiple Access Points - Bejerano, Bhatiahttp://ieeexplore.ieee.org/document/1357009

[6] Using the 802.11e EDCF to Achieve TCP Upload Fairness over WLAN Links D.J.Leith, P. Clifford http://www.hamilton.ie/peterc/downloads/wiopt05.pdf

[7] yWorks the diagramming company, yEd Graph Editorhttps://www.yworks.com/products/yed

18

Figure 6: Simulation results for our algorithm (Section 7.6) for topologies as shown inFigure 7

19

Figure 7: Network topologies used to simulate the algorithm functionality

20