Download - A Measurement-Based Joint Power and Rate Controller for ...

TECHNISCHE UNIVERSITAT BERLIN

A Measurement-Based Joint Power and Rate Controller

for IEEE 802.11 Networks

vorgelegt von

Thomas Huhn (Dipl.-Wirtsch.-Ing.)

von der Fakultat IV – Elektrotechnik und Informatik

der Technischen Universitat Berlin

zur Erlangung des akademischen Grades

DOKTOR DER INGENIEURWISSENSCHAFTEN (DR.-ING.)genemigte Dissertation

Promotionsausschuss:

Vorsitzender des PA: Prof. Dr.-Ing. Adam Wolisz, TU BerlinPrufer der Dissertation: Prof. Anja Feldmann, Ph. D., TU Berlin

Prof. Dr. rer. nat. Jens-Peter Redlich, HU BerlinDr. Cigdem Sengul, Oxford Brookes University

Tag der wissenschaftlichen Aussprache: 11.01.2013

Berlin 2013D 83

Abstract

IEEE 802.11 (WiFi) networks are used to provide Internet access anywhere anytime. However, their

performance is far below the achievable limits when multiple participants share the same frequency

spectrum in an uncoordinated manner. The major reason behind such inefficiency is the lack of practical

resource allocation algorithms that adapt well to the current conditions in a wireless network dynam-

ically and select the appropriate transmission parameters such as transmission rates and power levels.

Most current practical schemes are rather simplistic and only change a single transmission parameter.

For instance, Transmit Power Control (TPC) works at the WiFi PHY layer and commonly assigns a

static and rather high power level to all packets. A per-link or packet scheme is expected to provide

better performance, but typically increases complexity and requires higher-layer information, such as

medium access state from the Medium Access Control (MAC) layer. Therefore, although performance

improvements have been shown in theory, these ideas are largely uninvestigated in practice.

In this thesis, our main goal is to understand the feasibility and performance impact of a joint and

per-link rate and power controller in a real WiFi system. To this end, we first enabled cross-layer

communication of transmission power between the WiFi PHY and MAC layers in the Linux mac80211

subsystem. Based on our Atheros WiFi hardware, we also developed the in-kernel monitoring tool

‘RegMon’ that enables understanding and troubleshooting MAC and PHY-layer operations with a fine-

grained time resolution across different Linux drivers.

We designed and implemented a distributed rate and power control algorithm, Minstrel-Blues, which

does not rely on signal strength or channel state information, but uses local statistics from periodic

sampling of different rate and power combinations. Essentially, Minstrel-Blues can run on any WiFi

hardware that supports packet-level power and rate control capabilities. Minstrel Blues decides the data-

rate, and consequently, the minimum power-level to support the chosen rate using a two-attribute utility

function based on the throughput and power consumption of all rates. To expose the trade-off between

throughput and network interference, we also introduced a weight parameter for the utility function,

which tunes the importance of throughput in utility decisions.

Our results show that if the goal is on maximizing the per-link throughput, Minstrel-Blues can sig-

nificantly reduce transmission power necessary to communicate per link, while maintaining the same

throughput achieved with maximum transmit power. We call this mode of operation - Minstrel Pi-

i

ano. Based on experiments in BOWL, at 5Ghz, Minstrel-Piano shows significant overall throughput

enhancements due to increasing spatial reuse. Our performance analysis concludes with experiments

with different weight factors in a home network scenario, with 2-laptops and one access point. These

experiments were run in the 2.4 GHz ISM band, and hence, they also show that our controller works

well in an typical scenarios. As more and more WiFi Access Points are deployed and with upcoming

IEEE 802.11 n and ac devices using wider channel widths, resource allocation is expected to become

even more important to manage interference efficiently. To this end, our work significantly contributes

to the understanding of rate, power and carrier-sense control in practice.

ii

Zusammenfassung

Die weite Verbreitung heutiger IEEE 802.11 (WiFi) Systeme untermauert das große Potential dezen-

traler Funknetzwerke nahezu uberall und zu jeder Zeit einen Internetzugang bereitstellen zu konnen.

Jedoch besteht eine signifikante Differenz zwischen der theoretisch moglichen und derzeit erreichten

Datenubertragungsleistung, wenn sich mehrere Benutzer gemeinsam einen Funkkanal teilen.

Eine der Hauptursachen liegt in der ineffizienten Ausnutzung des Frequenzspektrums begrundet. Es

fehlen praxisnahe Algorithmen zur dynamischen Ressourcenallokation, die geeignete Parameter, wie

z. B. Ubertragungsrate und Sendeleistungeine an den aktuellen Zustand des drahtlosen Netzwerks an-

passen. Gegenwartige Verfahren zur Ressourcenallokation in WiFi Systemen sind von sehr einfacher

Struktur und beschranken sich auf die Anpassung genau eines Parameters innerhalb der Funkubertra-

gung. Ubliche Praxis ist das Festsetzen einer statischen und vergleichsweise hohen Sendeleistung fur

alle zu ubertragenden Datenpakete. Praktische Verfahren zur dynamischen und verteilten Sendeleis-

tungsregelung auf der physikalischen Schicht (PHY-layer) des IEEE 802.11 Standards gibt es derzeit

nicht. Gleichwohl versprechen solche Allokationsschemen, die pro Paket bzw. pro Kommunikations-

verbindung gezielt Ressourcen zuweisen konnen, eine wesentliche Steigerung der Gesamtdatenrate in-

nerhalb eines drahtlosen Netzwerks. Jedoch steigen mit ihnen typischerweise die Komplexitat und auch

der Informationsbedarf aus hoheren Netzwerkschichten, wie beispielsweise der aktuelle Status des Me-

dienzugriffs aus der Schicht zur Medienzugriffssteuerung (MAC-layer). Deshalb sind derartige Ansatze,

trotz ihres in theoretischen Arbeiten belegten Potentials zur Leistungssteigerung, in praktischen WiFi

Systemen weitgehend unerforscht.

Der Schwerpunkt dieser wissenschaftlichen Arbeit liegt auf der Analyse zur Realisierbarkeit und zur

Leistungsfahigkeit einer gemeinsamen Regelung von Ubertragungsrate und Sendeleistung pro Kommu-

nikationsverbindung unter Verwendung realer IEEE 802.11 Hardware. Zu diesem Zweck haben wir

das Linux mac80211 Subsystem erweitert, so dass eine schichtubergreifende (cross-layer) Kommunika-

tion uber die Sendeleistung pro Datenpaket zwischen PHY-layer und MAC-layer ermoglicht wird. Im

nachsten Schritt haben wir analysiert, inwieweit die relevanten Regelungsparameter Ubertragungsrate

und Sendeleistung in unserem Forschungsnetzwerk “Berlin Open Wireless Lab (BOWL)” parametrisier-

bar sind und welche Wechselwirkungen zwischen ihnen bestehen. Auf der Grundlage unserer Atheros

WiFi Hardware entwickelten wir das neues Monitoringtool “RegMon” fur verschiedene Linux Kernel

iii

Treiber. Mit dessen Hilfe konnen wir die dynamischen Vorgange auf dem PHY-layer, als auch auf dem

MAC-layer der WLAN Netzwerkarte mit hoher zeitlichen Auflosung analysieren, auswerten und zur

Fehlerdiagnose nutzen.

In der vorliegenden Arbeit haben wir den verteilten Algorithmus “Minstrel-Blues” zur dynamischen

Ressourcenallokation von Ubertragungsrate und Sendeleistung entwickelt und implementiert. Unser Al-

gorithmus basiert auf der Auswertung lokaler Statistiken, die Paketerfolgswahrscheinlichkeiten aktiv

getesteter Kombinationen aus Ubertragungsrate und Sendeleistung beinhalten. Daruber hinaus werden

keine zusatzlichen Informationen wie z.B. die Signalstarke der empfangenen Pakete oder Kanalzus-

tandsbeschreibungen benotigt. Tatsachlich funktioniert Minstrel-Blues auf jeder beliebigen IEEE 802.11

Hardware, die eine Unterstutzung zur Regelung der Ubertragungsrate und Sendeleistung pro Datenpaket

bietet. Unter Berechnung einer additiven Nutzenfunktion, die sich aus dem aktuellen Datendurchsatz und

der notwendigen Sendeleistung pro unterstutzter Datenrate zusammensetzt, entscheidet Minstrel-Blues

welche Kombination aus Datenrate und Sendeleistung die hochste Praferenz erhalt. Um die Auswirkun-

gen des Zielkonflikts zwischen der Maximierung des Datendurchsatzes und der Minimierung der Inter-

ferenz im Funknetzwerk analysieren zu konnen, haben wir einen Gewichtungsfaktor in unsere Nutzen-

funktion integriert.

Unsere Ergebnisse zeigen, dass ein auf die Maximierung des Datendurchsatzes gewichteter Minstrel-

Blues in der Lage ist, die fur einen gleichbleibenden Datendurchsatz notwendig Sendeleistung, im Ver-

gleich zur maximalen Sendeleistung, signifikant zu verringern. Diese spezielle Funktionsweise beze-

ichnen wir als “Minstrel-Piano”. Basierend auf unseren Experimenten in BOWL, konnten wir bei der

Nutzung des 5 GHz ISM Frequenzbandes (IEEE 802.11a) belegen, dass Minstrel-Piano den Gesamt-

durchsatz des Datenverkehrs im Funknetzwerk, aufgrund seiner effizienterer Nutzung des Frequen-

zspektrums, maßgeblich erhoht. Unsere Analyse endet mit experimentellen Untersuchungen zu unter-

schiedlichen Gewichtungsfaktoren in einer typischen WiFI Umgebenung im Heimnetzwerk, bestehend

aus zwei Laptops und einer WLAN Basisstation. Anhand dessen konnten wir zeigen, dass unsere dy-

namische Regelung von Datenrate und Sendeleistung auch im lizenzfreien 2,4 GHz Frequenzspektrum

gut funktioniert. Mit steigender Dichte von WiFi Geraten und der kontinuierlichen Vergroßerung der

genutzten Bandbreite, durch die aktuellen Standards IEEE 802.11 n und 802.11 ac, gehen wir davon aus,

dass eine dynamische Ressourcenallokation eine Schlusselrolle zur effizienten Nutzung des Spektrum

bzw. zum Interferenzmanagement einnehmen wird. Zu diesem Zweck leistet diese Dissertations einen

entscheidenden Beitrag zum theoretischen Verstandnis und der praktischen Umsetzung einer dynamis-

chen Regelung von Ubertragungsrate, Sendeleistung und Carrier Sensing in IEEE 802.11 Systemen.

iv

Acknowledgments

At first, I want to thank my girlfriend Anja Werner for all her patience and endless support. Without her

love and respect I would not have finished this thesis.

I wish to express my sincere thanks to my advisor, Professor Anja Feldmann for guiding me during my

PhD.

A big thank you goes out to all senior researchers for working with me. Roger Karrer, Cigdem Sengul

and Ruben Merz - it was a remarkable experience for me to work with you during the MagNets and the

BOWL project.

I also would like to thank the entire FGINET group, student workers and friends that shared all kinds

of thought, ideas, discussion, coffees and intensive rounds of Kicker games during those five years in

BOWL. My greatest appreciation goes to this substantial list of my friends and fellows: Steve Uhlig,

Jan Bottger, Dan Levin, Florin Ciucu, Amir Mehmood, Andreas Wundsam, Slawomir Stanczak, Mario

Goldenbaum, Holger Taubig, Alexander Scheidler, Thomas Wohner, Peter Bank, Rainer May, Bernd

May, Harald Schioberg, Doris Schioberg, Nadi Sarrar, Britta Schneider, Bernhard Ager, Thorsten Fis-

cher, Britta Schneider, Mustafa Al-Bado, Lalith Suresh, Julius Schulz-Zander, Robin Kuck, Benjamin

Vahl, Tobias Steinicke, Theresa Enghardt, Felix Fietkau, Jae-Yong Yoo, Alina Friedrichsen and Adel

Aziz.

Especially while the last months, my whole family was always supporting me. My special thanks go to

Mum, Dad, Hannchen and Roxie.

v

Contents

Resume iii

Acknowledgments v

1 Introduction 1

1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Dissertation outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Resource Allocation in WiFi Networks 7

2.1 A Short Overview of IEEE 802.11 with Respect to Power, Rate, and Carrier Sense Control 8

2.2 Resource Allocation Based on Only Power, Rate or Carrier-Sense Control . . . . . . . . 11

2.2.1 Transmission Power Control (TPC) . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Transmission Rate Control (TRC) . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.3 Carrier-Sense Control - CSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Joint Resource Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 An Inside Look at Our Testbed and Atheros IEEE 802.11 Radios 29

3.1 Our Testbed: Berlin Open Wireless Lab . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.1 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.2 Software Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2 IEEE 802.11 Radio Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.1 Atheros Hardware Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.2 Rate and Power Control Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.3 Carrier Sense Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.4 Noise Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

vii

4 Wireless MAC and PHY Layer Monitoring 474.1 Wireless Monitoring and its Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 RegMon - Design, Implementation and Performance . . . . . . . . . . . . . . . . . . . 49

4.2.1 In-Kernel MAC-Layer Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2.2 Calculating MAC states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.3 Validation and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5 Development of a Joint Power-Rate Controller 615.1 Design and Implementation of a Cross-Layer Power-Rate Control Interface . . . . . . . 62

5.1.1 Linux mac80211 framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1.2 Extending mac80211 for TPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Joint Power and Rate Control Algorithm: MINSTREL-BLUES . . . . . . . . . . . . . . 66

5.2.1 Validating Power-Rate and Throughput Relationships . . . . . . . . . . . . . . . 67

5.2.2 Design Properties and Functionality . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2.3 Utility Function for Joint Decisions . . . . . . . . . . . . . . . . . . . . . . . . 72

5.3 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3.1 Piano Power Control in a Single Link Scenario . . . . . . . . . . . . . . . . . . 74

5.3.2 Piano Power Control in a Multi-Link Scenario . . . . . . . . . . . . . . . . . . 77

5.3.3 Compatibility Experiment with Minstrel-Blues . . . . . . . . . . . . . . . . . . 86

5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6 Conclusion and Outlook 936.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.2 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Bibliography 96

List of Figures 111

List of Tables 114

viii

Chapter 1

Introduction

Wireless networks have the potential to realize the long-standing vision of ubiquitous high-speed Internet

access. Today’s standard for wireless Internet access is currently the IEEE 802.11 Wireless Local Area

Networking (WLAN) technology [1]. Also known as WiFi, this technology is integrated, by default, in

every modern laptop, tablet, or mobile phone and it is used as a typical way to connect to the Internet in

all areas of our daily life: Today’s deployments cover, for example, homes, coffee shops, airports, and

university campuses, and continue to expand. One of the key factors underlying the broad acceptance

of WiFi is its simplicity and robustness, and the fact that it allows Internet access at low infrastructure

costs. These factors also position WiFi as a technology that fosters Internet availability in rural areas

(e.g., in India 1). This has significant potential to close the digital divide, as the investments for running

cables are no longer necessary. Hence, wireless networks will continue revolutionizing the society.

Despite its promise, WiFi networks bring many challenges. Current IEEE 802.11 networks op-

erate in a bandwidth-limited, license-free spectrum within the ISM band. The communication chan-

nel is a broadcast medium accessed in a shared manner, which exhibits much higher dynamics and is

interference-bounded in contrast to a wired-based communication system. Hence, the overall perfor-

mance of such a wireless system is significantly below the possible capacity when multiple participants

share the medium in an uncoordinated manner. Therefore, efficient and fair resource allocation is es-

sential for any performance improvements. The most important mechanisms for resource allocation and

interference management in wireless networks are: congestion control at the transport layer, routing

in the network later, link scheduling in the MAC (Medium Access Control) layer, and power control

in the PHY (Physical) layer [2]. There is also substantial theoretical work on cross-layer approaches,

that leverage information from different layers of the protocol stack to jointly control them e.g., joint

scheduling and routing (e.g., [3] and references therein).

To the best of our knowledge, none of the theoretical cross-layer approaches have been realized

1http://drupal.airjaldi.com/

1

http://drupal.airjaldi.com/

2 1. Introduction

in practical WiFi systems. Most practical resource allocation algorithms realized in commodity WiFi

hardware focus on rate control. Most carrier-sense control solutions are vendor-specific as there is no

agreed-upon standard and power control is often considered infeasible [4, 5, 6].

In contrast to analytical and simulated approaches, wireless systems research lacks applying and

evaluating theoretical ideas for the following reasons: (1) There is no standard for communication across

layers. (2) While some of the theoretical work is not applicable to WiFi, others require disruptive

changes to the MAC (e.g., introducing a new frame type; see Chapter 2). (3) In real networks, not all

elements can be under the full control of a single operator (e.g., stations or access points (AP) belong to

other networks and also compete for common resources), and hence, centralized solutions are typically

infeasible. (4) Some solutions require network-wide state distribution or synchronization, which is

challenging to realize in practice due to their high control overhead.

In this thesis, we attempt to change this picture by investigating the feasibility and the potential gains

of fine-grained resource allocation in terms of rate, power and carrier-sense control based on commodity

WiFi hardware. Our main goal is to understand whether the promising gains from theoretical analysis

can be realized when their assumptions meet a real wireless system.

1.1 Problem Statement

The critical design factors that determine the quality of a wireless network are performance, reliability,

and scalability. Performance of a wireless network is affected by many factors. At the physical layer, the

hardware and the corresponding wireless technology define the maximal capacity of a link. Today’s WiFi

cards and access points achieve throughputs ranging from 54 Mbps as defined by the IEEE 802.11a/g [1]

standard up to 450 Mbps with IEEE 802.11n [7], when directional and smart antennas as well as MIMO

and multiradio/multichannel systems are used. Thus, it seems that at least the lower layers are on a

good path towards Gbps speeds. But how much of this capacity is available at the application level?

As measurements in our Berlin Open Wireless Lab (BOWL) indoor testbed confirmed, the protocol

overhead of the network stack accounts for roughly 50% of the capacity, implying that, for instance,

approximately 30 Mbps out of 54Mbps can be achieved in reality. These results are also confirmed

in our BOWL outdoor, where link speeds reach up to 30 Mbps on some links over 500 m with omni-

directional antennas [8]. However, out of the 48 nodes in our BOWL testbed, only 8 links fulfill the

multiple necessary conditions to achieve this high throughput, which are perfect line of sight, sufficient

antenna gains, and no interference. During our measurements with the outdoor BOWL testbed [9], we

have found up to 30 interfering networks in the neighborhood of one access point – per channel! With

increasing penetration of WiFi in residential areas (e.g., currently, 500 million households worldwide

deploy WiFi nodes [10]), chaotic unplanned deployments are becoming the norm where access points

and stations operate on the same or nearby channels either due to lack of coordination or insufficient

Contributions 3

available frequencies. Therefore, any centralized approach to control resource allocations is infeasible.

Given the rate of deployment, wireless interference is becoming one key component for perfor-

mance degradation due to the broadcast nature of wireless communication and limited unlicensed ISM

bandwidth. Regulators around the world are currently discussing rules and requirements that will allow

for mass-market access to unused UHF spectrum, referred to as ‘TV White Spaces’ [11]. Although

this might relieve interference, we believe throwing more resources on problem does only provide a

temporary solution and we need better resource allocation mechanisms. On the other hand, existing

resource allocation techniques do not scale to the growing demands for wireless capacity [12]. While

non-interfering channels are typically created by dividing time, frequency, code, etc., spatial reuse is

essential for improving capacity, especially, in co-channel interference limited environments [13]. This

also follows from the fact that the aggregate data transport capacity of a wireless network is proportional

to the number of simultaneous active communications it can support.

To improve spatial reuse in IEEE 802.11 networks, there are orthogonal approaches: (1) directional

transmissions and/or (2) specific choice of rate, power, and carrier sense parameters. Directional an-

tennas and beam-forming can be used to focus radio transmissions towards a certain direction, limiting

the interference from transmissions. However, the majority of today’s WiFi devices are equipped with

omni-directional antennas. Directional antennas, which require manual alignment to ensure link quality,

are mainly used in wireless backbone networks [9]. Furthermore, spatial gains from software based

beamforming mechanisms in recent 802.11n MIMO hardware are promising but their true potential is

yet to be understood [14]. In terms of rate, power and carrier sense control, current default WiFi config-

uration is to transmit all packets at the constant maximum power and only adapt the transmission rate,

while there is no standard strategy for adapting carrier sense settings. Jointly adjusting the transmission

power and rate at the wireless sender, and understanding its performance under different carrier sense

settings is mostly unexplored. In this thesis, we contribute to close this gap.

1.2 Contributions

In order to achieve efficient rate and power control in WiFi networks, a key requirement is to understand

the degree of their controllability, the interactions of the relevant factors, and their impact on channel

utilization and network throughput. Improper power, rate, and carrier sense adjustments in IEEE 802.11

wireless networks can lead to under-utilizing or attempting to over-utilize medium, which can stall

communication, or in the worst case result in network breakdowns. To this end, we first implemented

a new in-kernel monitoring tool, which allows us to observe significant effects and interactions at the

MAC layer in addition to common packet trace analysis. Next, we implemented an abstract power

control interface between the Linux MAC and PHY subsystem. To the best of our knowledge, we are

the first to implement such an interface, which enables realizing different power control approaches

4 1. Introduction

using today’s WiFi hardware. Using our implementation, it becomes possible to annotate per-packet

power levels based on hardware capabilities: power-level per packet in IEEE 802.11abg, and four power

levels per packet for retries in IEEE 802.11n. The PHY layer part of our implementation covers several

Atheros-based WiFi chips but it can easily be extended to other hardware drivers.

Finally, based on our cross-layer interface, we designed, implemented, and validated a joint power

and rate controller: Minstrel-Blues. Our controller uses cross-layer information from both PHY and

MAC layer. Our main design goal was to tune transmission power and rate to reduce unnecessary

interference and increase spatial reuse while keeping good throughput performance. Minstrel-Blues

operates in a decentralized manner without additional message passing to allow low overhead.

In summary, the main contributions of this thesis are:

• Tools

– Design and implementation of measurement tool RegMon to collect direct MAC and PHY

layer information: In order to be able to analyze the impact from different rate, power, and

carrier sensing settings, we needed direct measurements from the MAC and PHY layer. The

tool allows us to observe the different states of the wireless hardware, which is not possi-

ble from packet-level measurements. Substantial information about operation state of the

Atheros hardware is stored in hardware registers, such as sending, receiving, energy detect-

ing or idling durations of the transceiver unit. RegMon allow fine-grained measurements of

all possible registers up to a sample speed of 20000 Hz for the Madwifi, the ath5k, and the

ath9k Linux drivers.

• Algorithm & Implementation

– Linux mac80211 sublayer extension to enable power, rate and retry allocation per data

packet: In the current mac80211 subsystem of the Linux kernel, it is possible to specify

four rates per packet (multi-rate retries). To enable a power-level setting per packet within

the MAC layer, we restructured the mac80211 Linux subsystem to provide the necessary

space in the control data structure to allow a power level setting for each of the four rates

per packet. With this extension, we enable a general abstraction to annotate the transmission

power at the MAC layer in the Linux kernel. More specifically, we modified the transmission

path in the ath5k and ath9k drivers to support TPC at the MAC layer.

– Design and implementation of our joint power & rate controller, Minstrel-Blues: We de-

signed and implemented a joint rate and power controller within the Linux kernel. Minstrel-

Blues is a decentralized sampling-based controller that does not require additional control

messages between a WiFi transmitter and a receiver, e.g., to obtain received signal strength

information. Our algorithm supports selecting different throughput-interference trade-offs

Dissertation outline 5

through a tunable weight factor. This enables us to analyze different utilities based on

throughput and interference objectives. We refer to the case where throughput is the main

objective as Minstrel-Piano.

• Measurements

– Feasibility of parameter control and its constraints: We explore the capabilities of today’s

WiFi hardware in terms of rate, power and carrier sense control. In terms of rate control,

we explored the ability to set different modulation rates per packet and different rates per

packet retry attempts (multi-rate retries). For broadcast and unicast data packets, we vali-

date the range of adjustable transmission power per packet and show that the adjustment of

the transmission power for acknowledgment packets can only be done in a global manner.

Finally, we decompose the carrier sensing into its parts that influence the packet detections

mechanisms.

– Validation and Performance Analysis of Minstrel-Blues: We perform several validation ex-

periments that confirm that Minstrel-Bluse is able to adapt data rate and power levels when

operating with different IEEE 802.11a and 802.11g devices. We also validate the correct op-

eration of our utility function to realize different preferences for data rate and transmission

power. The performance analysis of Minstrel-Piano covers measurements of three differ-

ent carrier sense settings with UDP and TCP traffic within the 5 GHz band of our BOWL

testbed. Our results show the feasibility of joint rate and power control and a better spectral

efficiency through increased spatial reuse.

1.3 Dissertation outline

The rest of this thesis is organized as follows:

• In Chapter 2, we discuss the theoretical and practical approaches to resource allocation. We also

present the relevant background information on the IEEE 802.11 standard as well as the related

work in power, rate and carrier-sense control. We conclude with a table that summarizes the

current approaches, their objectives, assumptions and applicability to today’s WiFi networks.

• In Chapter 3, we present our Berlin Open Wireless Testbed (BOWL) in detail. As most of our

experiments are based on this testbed, we provide all the necessary details to understand the set-

up and measurement infrastructure. We also provide a detailed look at the capabilities of our

Atheros WiFi hardware. We dissect the controllability of power, rate and carrier-sense parameters

as well as their operational details.

• In Chapter 4, we present our in-kernel MAC state monitoring tool that enables direct observations

of the WiFi MAC layer. We end this chapter with the results from our investigation of the impacts

6 1. Introduction

of noise-floor calibration mechanisms on wireless experiments.

• In Chapter 5, we present the cross-layer design, the Linux mac80211 implementation, the valida-

tion and performance evaluation of our joint rate and power controller, Minstrel-Blues.

• In Chapter 6, we summarize the contributions and limitations of our systems, and outline several

directions for future work.

Chapter 2

Resource Allocation in WiFi Networks

Nowadays, WiFi network interface cards are part of almost all devices, including printers, beamers,

radios, and music players. All these devices share the WiFi unlicensed spectrum with a plethora of other

technologies, such as Bluetooth headsets, cordless phones, game controllers, and wireless video-link

systems. Even non-communicating appliances, such as microwave ovens, leak energy into the spectrum

and can cause interference with WiFi communication at 2.4GHz [15]. WiFi and non-WiFi interference

both affect how much of the nominal bandwidth is available to users, as bandwidth is determined by the

interference level and location with respect to the interference sources [3]. For instance, it was shown in

the Orbit testbed [16] with more than 100 WiFi nodes that the aggregate throughput of a typical TCP-

dominant workload is characterized by the number of interfering access points (and not by the number

of active clients). Therefore, handling interference among access points is a fundamental challenge to

improve performance, in particular, in uncoordinated and decentralized IEEE 802.11 deployments.

The conventional approaches to mitigate inter-cell interference in WiFi networks are resource allo-

cation schemas, which include control of transmission power, modulation, coding, channel frequency,

channel width, and physical carrier sense parameters at the PHY layer, and scheduling at the MAC

layer. Furthermore, routing and congestion control at the network layer [2] also impacts wireless re-

source allocation. Each of these approaches typically operate oblivious to the others, thus ignoring

possible interactions that degrade their performance. This also results in ignoring potential performance

gains through joint optimization [3]. In this chapter, we present an overview of previous theoretical and

practical work on resource allocation with a special focus on power, rate and carrier sense control. Our

main goal is to understand, highlight the underlying assumptions of the theoretical work and check their

applicability to a real WiFi system. To this end, we start with a short overview of the IEEE 802.11

standard and then present the state-of-the-art of the control approaches. Next, we discuss the current

work on joint control. Finally, we conclude with a summary and open problems.

7

8 2. Resource Allocation in WiFi Networks

Figure 2.1: IEEE 802.11 MAC and PHY layer interactions.

2.1 A Short Overview of IEEE 802.11 with Respect to Power, Rate, andCarrier Sense Control

IEEE 802.11 is the de facto standard for WLANs and specifies both the medium access control (MAC)

and the physical (PHY) layer protocols. The standard allows the same MAC layer to operate on top

of one of several PHY layers, as shown in Figure 2.1. The broad acceptance of WiFi is due to the

simplicity and robustness of the MAC protocol. The 802.11 MAC uses a mechanism called Distributed

Coordination Function (DCF) , which relies on carrier sense multiple access with collision avoidance

(CSMA/CA). DCF prevents transmissions if the wireless medium is sensed busy (CSMA) and avoids

collisions by waiting a DIFS (DCF InterFrame Space) period before sensing the channel. In addition,

all stations (nodes) that overhear a transmission use a Network Allocation Vector (NAV) to remain silent

during the transmission. After transmitting, the sender expects an explicit acknowledgment (ACK) from

the receiver within a given time (SIFS - Short Interframe Space), which completes the 2-way handshake.

Otherwise, the sender retransmits, which is capped by the maximum retransmission threshold. The

so-called hidden terminal problem occurs when two stations are not able to carrier sense each other,

and hence cause collisions at a common receiver that is able to hear both. To alleviate this problem,

the DCF mechanism is extended with a 4-way handshake, which uses Request-to-Send/Confirm-to-

Send (RTS/CTS) messages to reserve the medium for data transmissions. Essentially, sending shorter

RTS/CTS messages allows silencing of the hidden terminals. In addition, it reduces the cost of collisions

by avoiding the loss of larger data packets. These features allow WiFi to operate when multiple stations

attempt transmission simultaneously, which is a key requirement for networks working in unlicensed

bands [17].

At the physical layer, the four most important IEEE 802.11 standards currently available are: b, a, g

and n. Although no power control mechanism is specified in the IEEE 802.11 abgn standards, the term

Transmit Power Control is defined:

A Short Overview of IEEE 802.11 with Respect to Power, Rate, and Carrier Sense Control 9

TPC: Radio regulations may require radio local area networks (RLANs) operating in the

5 GHz band to use transmitter power control, involving specification of a regulatory max-

imum transmit power and a mitigation requirement for each allowed channel, to reduce

interference with satellite services. The TPC service is used to satisfy this regulatory re-

quirement.

Since 2003, the IEEE 802.11h [18] transmit power extension specifies two spectrum management

services: Dynamic Frequency Selection (DFS) and TPC in order to be able to use certain parts of the

5Ghz spectrum at certain power levels and not interfere with other services, such as military radar

systems, satellite, and radio tracking. In order to enable the spectrum management service, the standard

defines new elements and messages (e.g., TPC capability) as extensions to existing management packets

(e.g., beacons, probe responses). These extensions allow the client and the AP to exchange the minimum

and maximum allowable transmission power information during the association or re-association of a

station to the access point, or at another station. Based on this exchange of information, transmission

power is adapted according to the link gains and margins. However, an algorithm for dynamically tuning

the transmit power is not defined by the IEEE 802.11h extension.

In the course of European harmonization of technical standards, the European Commission has de-

cided to unify the technical specifications for wireless networks from IEEE 802.11a [19] and 802.11h [18].

The current version of this harmonized European standard [20] allows different maximal transmission

power levels for each of the two 5GHz sub-bands according to TPC capability of the device. The first

sub-band ranges from 5,150 GHz to 5,350 GHz and is to be used in indoor environments. The sec-

ond sub-band from 5,470 GHz to 5,725 GHz targets outdoor usage. This European directive allows a

maximal output power level of 30dBm (respectively 1000 mW) in the second 5 GHz sub-band if the

following two conditions are met:

(i) Use of a TPC control range from 6 dB to 30 dBm

(ii) Use Dynamic Frequency Selection (DFS) when radar patterns are detected

Without such transmit power control (see (i)), devices are only allowed to use a maximum power

level of 27 dBm (respectively 500 mW). Note that the current Linux mac802.11 subsystem does not

fully support the IEEE 802.11h extensions. While DSF functionality is supported by some experimental

driver specific implementations (i.e., Atheros ath9k), TPC functionality is missing. To the best of our

knowledge there is currently no hardware vendor providing TPC, which fulfills the 6dB adaptation

range required by IEEE 802.11h. Instead, they operate at the decreased maximal output power levels.

Given these shortcomings in practice, we present mostly theoretical approaches to power control in

Section 2.2.1.

While power control support is non-existent in IEEE 802.11abgn standards, there is multi-rate sup-


port. Each IEEE 802.11 standard significantly increased the maximum net data rate: 11 Mbit/s in IEEE

802.11b, 54 Mbit/s in IEEE 802.11ag and 600 Mbit/s in IEEE 802.11n. Here, each rate represents a

distinct combination of symbol modulation (e.g., PSK, QAM, etc) and coding redundancy (e.g., 12 , 3

4 ).

While different modulation coding schemes are available with each standard, dynamically selecting a

modulation and coding scheme according to the current channel quality, i.e., automatic rate adaptation, is

left out of scope of the standards. We review the currently used rate control approaches in Section 2.2.2.

Finally, in addition to power level and rate selection, an IEEE 802.11 radio must implement a

packet/signal detection mechanism and a carrier sensing mechanism to support CSMA/CA. More specif-

ically, the Clear Channel Assessment (CCA) component aims at detecting the presence of ongoing trans-

missions to decide whether the channel is busy or not. The IEEE 802.11 standard specifies also a virtual

carrier sensing mechanism through the use of RTS and CTS messages and a Network Allocation Vector

(NAV) [1], but we focus on physical carrier sensing. Ramachandran categorizes all possible methods of

CCA into three: Energy Detection (ED), Preamble Detection (PD) and Decorrelation-based CCA [21].

802.11 systems use two out of the three methods: preamble detection and energy detection [1]. All

wireless frames across the entire 802.11abgn standards have a common unique preamble sequence at

the beginning of each frame. Hence, the transceiver can sense an ongoing transmission by detecting the

preamble sequence (preamble detection) or sense the carrier busy by detecting any kind of a signal with

signal strength higher than the CCA threshold (energy detection). The operation of CCA and selection

of its parameters play a fundamental role in communication in the presence of interference, and there-

fore, is essential to understanding the performance of WiFi networks. Carrier sense is a core part of

many wireless MAC protocols and has long been known to be an imperfect solution. Note that carrier

sense uses measurements of the wireless channel at the senders to decide whether to transmit, but at the

physical layer, channel conditions at the receivers determine the outcome of a transmission. When all

nodes are tightly clustered in a compact, isolated network, this might be expected to work well, because

channel conditions at all nodes are highly correlated. But, for any network large enough to allow spatial

reuse, the use of carrier sense is arguable [22, 23, 24, 25, 26]. In these networks, two classic failures may

occur: (1) the exposed terminal problem and (2) the hidden terminal problem. In the case of exposed

terminals, nodes that do not transmit at the same time when they could do so and therefore, missing the

potential of spatial reuse cause the problem. The hidden terminal problem, as described earlier, appears

when nodes that should not transmit concurrently do so and interfere with each other. Overall, carrier

sense control is a challenging problem, and hence, current carrier sense research is mostly theoretical.

Furthermore, these works typically consider a single parameter, the so-called carrier-sense threshold,

which does not truly reflect how carrier sensing is implemented in the current hardware. We present

these works in Section 2.2.3. Additionally, we show the details of the carrier sense mechanism imple-

mented in a typical WiFi radio, and its performance under external noise (e.g., from microwave ovens)

and temperature variations in Chapter 3.

Resource Allocation Based on Only Power, Rate or Carrier-Sense Control 11

Figure 2.2: Transmission, carrier sense and interference ranges in IEEE 802.11. [source: Figure 5in [42]]

2.2 Resource Allocation Based on Only Power, Rate or Carrier-SenseControl

There is a significant amount of both theoretical and practical work on independently performing power [27,

28, 29, 30, 6], rate [31, 32, 33, 34, 35, 36] and carrier sense control [37, 38, 39, 40, 41]. In this section,

we discuss these approaches in their separate sections.

2.2.1 Transmission Power Control (TPC)

The potential and challenges of transmission power control in wireless networks have been widely dis-

cussed in literature. As early as 1998, Bambos states [43]:

Transmitter power control can be used to concurrently achieve several key objectives in

wireless networking, including minimizing power consumption and prolonging the battery

life of mobile nodes, mitigating interference and increasing the network capacity, and main-

taining the required link QoS by adapting to node-movements, fluctuating interferences,

channel impairments, and so on. Moreover, power control can be used as a vehicle for im-

plementing on-line several basic network operations, including admission control, channel

selection and switching, and handoff control.

Today, we can roughly categorize wireless networking: (1) Infrastructure-based ’networks such as

cellular networks or WiFi infrastructure networks or (2) ad hoc networks in WiFi. Note also that, while

most infrastructure-based networks assume single-hop communication, in ad hoc networks multi-hop

communication is typical. If we view wireless networks as a collection of interfering links, infrastructure-

based wireless networks is a simpler case of the more general ad-hoc networks [43]. The power control

problem in the general model is especially complex, since the choice of the power level fundamentally


affects many aspects of the network operation [44]:

• Received signal quality at the receiver (PHY layer)

• Carrier sensing and data transmission ranges (see Figure 2.2), hence, the number of nodes con-

tending for channel access (MAC layer)

• Transmission range, and hence, the number of hops in routing (Network layer).

• Interference with other receivers, therefore, congestion (Transport layer).

Note that in infrastructure WiFi networks, TPC does not affect the routing layer. Furthermore, in cellular

networks, the impact of TPC on the MAC layer is less of an issue due to the use of FDD (Frequency

Division Duplex) or TDD (Time Division Duplex) schemes for medium access. The capacity gains

of distributed power control in the context of cellular networks have been well studied in the litera-

ture [45] . However, these solutions for cellular networks cannot be directly applied to WiFi networks,

infrastructure-based, or ad hoc, as WiFi uses CSMA/CA MAC. In the rest of this section, we focus on

TPC for WiFi networks.

Due to its effect on multiple layers of the protocol stack, TPC directly affects throughput, capacity,

delay, and fairness in the network and, may also affect energy consumption and network connectiv-

ity. However, it is typically not possible to achieve multiple performance objectives, e.g., both high

throughput and low energy consumption, simultaneously. Therefore, the majority of the work in power

control, e.g., [46, 47, 48] use these performance objectives as key classifications. We follow the same ap-

proach and consider three main TPC classes: energy-oriented, topology-oriented and capacity-oriented.

Table 2.1 summarizes the related work on TPC.

The main goal of energy-oriented power control schemes is to reduce energy consumption, while

throughput is treated as a secondary objective. For instance, Jung et al [58] present a power control

protocol which does not degrade throughput and yields energy savings. Their nodes use maximum

transmission power to send RTS/CTS packets and minimum power to transmit data packets. To ensure

high throughput, data transmissions periodically are sent at maximum power to mitigate the loss of

ACK packets due to collisions. Gomez et al [49] introduce a power-aware routing system, PARO, to

minimize transmission power needed to forward packets in an ad-hoc network. There are also power-

aware routing protocols, which use transmission power as a routing metric, with the goal of increasing

network lifetime [59]. However, in today’s WiFi systems, energy savings from the proposed solutions

may not be realized. For instance, Piazza et al [60] show that TPC offers marginal energy savings

compared to the average power consumption of IEEE 802.11g WiFi cards. Their results show savings

from 10% to 20% by reducing transmission power from 15dBm to 0dBm (e.g., 32 mW to 1 mW),

assuming the device is constantly sending. Also Halperin et al [61] conclude, after analyzing energy

consumption of the latest IEEE 802.11n devices, that reducing the radiated power via TPC by 97%

still leads to only 10% in overall energy savings. In summary, it can be concluded that TPC does not

bring energy savings with today’s WiFi devices and, therefore, we do not consider reducing energy


Table 2.1: Summary of Transmit Power Control (TPC) Algorithms

Protocol Obj.1 Granularity Type of Control PHY layer assumptions Validation

PARO [49] E Per-packet Dist. Sym2, ideal comm.3,omni4 –

Compow [50] T Per-network Cent. Sym, ideal comm.,omni X(Routing)

ClusterPow [51] T Per-cluster Cent. Sym, ideal comm.,omni X(Routing)

PCMA [52] C Per-packet Dist. Sym, ideal comm., omni –

POWMAC [27] C Per-packet Dist. Sym, ideal comm., omni –

CONTOUR [53] C Per slot Cent., synch. Omni XClick [54] (P)

MIDAS [55] C Per packet Dist. Directional5 X(MAC,WARP)

DIRC [56] C Per slot Cent. Directional X(MAC,Madwifi)

SPEED [57] C Per slot Cent. Directional X(Multi-radio)1 Abbreviations: Obj: Objective, E: Energy, T: Topology, C: Capacity, Dist.: Distributed, Cent.:Centralized, synch: Synchronized, P:

Prototype2 Interference/fading conditions in rx and tx directions are similar in space and time.3 Ideal comm: Overhearing any transmissions is possible by other nodes, hence interference-free MAC (as long a minimum signal level

is reached). Furthermore, any node is capable of measuring received SNR of overheard packets and quantify this as a standard metric.4 Omni-directional antennas are considered.5 Directional antennas with a typical angle of vertical radiation beams between 5◦to 120◦are considered.

consumption as an objective in this thesis.

In the second class of topology-oriented power control schemes, the main objective is to control the

topological properties of the network, such as reducing interference from low-degree nodes while main-

taining overall connectivity [62]. Wattenhofer et al. [63] propose a scheme, where global connectivity

is guaranteed while the resulting network topology leads to an increase in network lifetime. Topology

control is intimately connected with routing in multi-hop wireless ad hoc networks. For instance, COM-

POW [50] selects a common power level to ensure bi-directional links between all nodes by running

several routing daemons, each at a different power level. The minimum power level, which achieves

the same level of network connectivity as the maximum power level is chosen as the common network

power. The authors later extend this work, and propose CLUSTERPOW [51] to avoid settling on an un-

necessarily high common power level in non-homogeneous network deployments. Here, while a higher

power may be used to connect two clusters, the power level used within clusters can be significantly

lower. In this thesis, we focus on single hop communication, and therefore, the TPC impact on and

interaction with routing are left as future work.

The third class, capacity-oriented power control schemes try to increase overall network capacity

while improving end-to-end delay and realizing fair throughput allocation [47]. Power control can im-

prove network throughput in two ways: (1) by reducing interference and (2) by increasing network

spatial reuse. For (1), consider a hidden terminal situation, where two senders are not able to carrier


sense each other, but their transmissions collide at one or both of the receivers. If the senders trans-

mit packets at an optimal power level, it may be possible to guarantee successful packet delivery while

minimizing interference. The collision probability is reduced and consequently, the number of retrans-

missions, which allows the bandwidth to be used effectively. For (2), remember that IEEE 802.11 does

not allow two simultaneous transmissions if the transmitters can carrier sense each other. Reducing the

transmission power may increase the number of simultaneous transmissions and increasing the overall

throughput. It must be noted that power control is not the only approach for avoiding interference and

increasing spatial reuse. Directional transmissions via directed antennas or beam-forming also improve

spatial reuse (e.g., DIRC [56], SPEED [57], [12], MIDAS [55]). However, such approaches require

extensive changes to the upper layers, including the MAC layer. Furthermore, access points with direc-

tional antennas are untypical for current deployments and hence, these approaches are out of the scope

of this thesis.

To improve spatial reuse as well as throughput, Monks et. al present Power Controlled Multiple

Access (PCMA) protocol [52], which allows different nodes to have different transmission power levels

and per-packet selection of transmit power. PCMA uses two channels, one channel for busy tones, and

the other for all other packets. While a node is receiving a data packet, it periodically sends a busy tone

to advertise its interference tolerance level. This bounds the maximum transmission power that can be

used for other transmissions. To this end, the busy tone is transmitted at the power level equal to the

maximum additional noise the node can tolerate. Any node wishing to transmit a packet first waits for

a fixed duration (determined by the frequency with which nodes transmit busy tones when receiving

data), and senses the channel for busy tones from other nodes. The signal strength of the busy tones

received by a node is used to determine the highest power level at which this node may transmit without

interfering with other on-going transmissions. This way, simultaneous transmissions can take place and

hidden terminals do not pose a problem as transmission power levels are bounded. However, PCMA

requires extensive modifications at the MAC layer.

The work of Muqattash and Krunz, POWMAC [48], does not require out-of-band signaling. How-

ever, it still requires significant changes to the MAC layer. POWMAC uses an access window (AW) to

allow for a series of RTS/CTS exchanges to take place before it schedules multiple concurrent data trans-

missions if they create tolerable interference to each other. Hence, the protocol activates multiple links

concurrently while satisfying the interference constraints. Each node maintains a power constraint list

about the surrounding active nodes. This information include node address, channel gain derived from

RSS measurements of the control packets, start time and duration of transmission activities, maximum

tolerable interference and the transmit power level used by the node. Based on simulations, the authors

show that POWMAC improves network throughput up to 50% by increasing spatial reuse in random-

grid topologies. However, POWMAC is not applicable to standard WiFi systems due to proposed MAC

changes. These are often not feasible due to the hardware limitations. Similarly, Countour [53] tries


to increase the spatial reuse through a slotted symmetric power control framework. In this framework,

all access points are assumed to be synchronized and they are expected to operate at the same power

level at any given instant and follow a sequence of power levels, called an envelope. A centralized

controller computes and distributes the envelope. Different than these approaches, in this thesis, we

investigate the feasibility of a fully-distributed capacity-oriented (or interference-aware) TPC scheme,

which works over the existing IEEE 802.11 standard and current WiFi hardware, and does not require

synchronization.

2.2.2 Transmission Rate Control (TRC)

Rate (Mb/s) Modulation Coding

Rate

IEEE 802.11

Standard

IEEE 802.11

Standard

IEEE 802.11

StandardRate

(Mb/s) Modulation Coding Rate

b g a1 DBPSK 1/11 X X2 DQPSK 1/11 X X

5,5 CCK 4/8 X X6 BPSK 1/2 X X9 BPSK 3/4 X X

11 CCK 8/8 X X12 QPSK 1/2 X X18 QPSK 3/4 X X24 16-QAM 1/2 X X36 16-QAM 3/4 X X48 64-QAM 2/3 X X54 64-QAM 3/4 X X

RateSelection

Figure 2.3: Possible transmission rates in IEEE 802.11abg

The choice of transmission rate significantly determines the overall efficiency of a communication

system. More specifically, it is desirable to use a high transmission rate at the sender that can potentially

lead to higher throughput, lower medium occupancy (thus lower contention delays and higher spectrum

efficiency) and lower power consumption [64]. Note that the IEEE 802.11 [1] standard supports mul-

tiple PHY data rates, without defining a method to optimally select one (see Figure 2.3 for the list of

transmission rates in IEEE 802.11abg). However, IEEE 802.11 standard defines a minimum level of re-

ceive sensitivity for all transmission rates and specifies an upper limit of the frame error rate (see Section

17.3.10.1 in [1] for details). Based on the underlying modulation schemes, the sensitivity decreases at

lower rates. Therefore, in the presence of varying channel gains, the higher rate transmissions are more

likely to have errors compared to lower rate transmissions [65]. Therefore, the majority of proposed rate

adaptation schemes respond to any frame loss by decreasing data rates. Note that, however, frame losses

are linked to two root causes: PHY and MAC layer interference [17] . While reducing rate is appropriate

for handling physical channel degradation it is not the best solution at the MAC layer: lower rates may

increase congestion because of their longer frame transmission duration and the ability to be heard at

longer distances. It is not the best solution at the MAC layer: lower rates may increase congestion be-

cause of their longer frame transmission duration and the ability to be heard at longer distances, leading

potentially to more nodes within collision range. Furthermore, a low rate may waste resources when the


channel conditions support a higher rate [65].

In this section, we summarize the rate adaptation algorithms in literature based on the channel es-

timation metric they use: frame loss rate (FLR), SNR or BER. Table 2.2 summarizes the rate-control

approaches considered in this section. For each scheme, we also discuss their ability to differentiate

between congestion losses and, losses due to channel degradation. Furthermore, we explain how the

retries are handled when the data frame cannot be sent at the current data rate. We go into this detail due

to the timing constraints that put limitations to per-frame rate control (i.e., as the earliest time a frame

may be sent is after an SIFS interval, it may not be possible to calculate and write a new rate per-frame).

Essentially, current WiFi chips support either using a single rate for each data packet and all its retries,

or defining different multiple retry rates and retry counts per packet (e.g., rate R1 n1 times, R2 n2 times,

R3 n3 times, R4 n4 times where n1 + n2 + n3 + n4 adds up to maximum retry count). Therefore, these

hardware considerations need to be also taken into account when designing rate control systems.

Table 2.2: Summary of Rate Adaptation Algorithms with Properties

ProtocolChannel

MRR1 AssumptionsImplementation (OSS2)

estimate3 madwifi mac80211 click! ns2/3

ARF [66] FLR – Loss ∼ Rate (direct) – – X X

AARF [32] FLR – Loss ∼ Rate (direct) X – – X

Onoe [67] FLR – Loss ∼ Rate (direct) X – – X

SampleRate [31] FLR X Loss � Rate (mixed) X – X X [35]

PID [68] FLR – Loss ∼ Rate (direct) – X – –

MINSTREL [69] FLR X Loss � Rate (complex) X X – X

CARA [70] FLR – Loss ∼ Rate (direct) X – – X

RRAA [71] FLR & Coll. – Loss + Coll. ∼ Rate (direct) – – – X [35]

WOOF [72] FLR & CBT – Loss + CBT � Rate (mixed) X – – –

RBAR [73] SNR – SNR ∼ Rate (direct) – – – –

FAR [74] SNR – SNR ∼ Rate (direct) – – – –

OAR [75] SNR – SNR ∼ Rate (direct) – – – –

SoftRate [35] BER – BER ∼ Rate (direct) – – – X [35]1 Protocol makes use of multi-rate-retry (mrr) capability of WiFi hardware.2 Open source software (OSS) implementation is available to public.3 Channel estimation based on: FLR = frame-loss-rate, SNR = signal-to-noise-ration, BER = bit-error-rate, CBT = channel-busy-time

Loss-based Schemes: ARF is one of the earliest frame-loss based algorithms, proposed initially for

Lucent Wave-II wireless LAN adapters [66]. The operation of ARF is simple: each sender attempts to

use a higher transmission rate after a fixed number of successful transmissions at a given rate. The orig-


inal ARF algorithm decreases the current rate and starts a timer when two consecutive transmissions fail

in a row. When the timer expires or the number of successfully received per-packet acknowledgments

reaches 10, the transmission rate is increased and the timer is reset. Simulations and experimental results

show that ARF only performs well in comparison to other rate selection algorithms when the channel

conditions support sending at the highest rate [76]. In fact, ARF finds the best rate very fast and without

any feedback from the receiver side (i.e., without the complexity of implementing feedback algorithms).

While ARF responds well to short term channel variation, the way it increases the rate limits its use in

stable environments where long-term channel variations are common. To address this problem, Lacage

et. al [32] proposed Adaptive Auto Rate Fallback (AARF), which uses binary exponential back-off to

adapt the threshold used to increase the rate. In AARF, if the first attempt to switch the rate up fails, then

the next attempt should only be made after doubling the threshold. If the situation persists, the threshold

is doubled again thus reducing the number of rate changes [64].

The practical relevance of rate control algorithms increased with the spread of Open-wrt based em-

bedded router platforms. Especially, the partial open-source driver Madwifi [77] of Atheros WiFi chips

is commonly used in research testbeds. The earliest open source rate adaptation protocol in FreeBSD

and Linux that got integrated into Madwifi was Onoe [67]. The objective of Onoe is to find the highest

rate that provides a loss ratio less than 50%. This rate control algorithm is less sensitive to individual

packet failures as compared to ARF as it accumulates performance credits per link and bitrate. If less

than 10% of data packets require a retry, the number of credits of the corresponding rate is increased.

Every second, a check is performed to see whether the amount of credits add up to a target threshold of

10 or more to switch to the next higher rate. In the case of errors, the number of credits for that rate is

decremented. Whenever the average number of retries is greater than one for 10 or more consecutive

packets, the rate is decreased to the next lower rate.

ARF, AARF and Onoe switch sequentially between a sorted list of available rates to react to channel

dynamics. These protocols assume that there is a linear relationship among rates, which is questionable

both in theory and practice. Several theoretical performance analyses of the IEEE 802.11a MAC proto-

col [76, 78], which take into account different channel fading models, describe a non-linear relationship

between packet reception ratio and rate. Their analysis shows that at all signal to noise ratios (SNR),

12 Mbps always outperforms 9Mbps in terms of throughput (see Figure 2.4, which shows that mode

3 (12 Mbps) performs better than mode 2 (9 Mbps) under both AWGN and Rayleigh fading models).

This implies 9Mbps should never be used under these conditions. Furthermore, when the relationship

between consecutive rates is observed, it becomes clear that a linear search to find the optimal trans-

mission rate does not optimize throughput. This behavior was also confirmed by extensive outdoor and

indoor measurements in [79], where they conclude that: “The joint effect of modulation and physical

layer encoding schemes of the 802.11g transmission rates results in a surprising, undesirable feature

that could not have been predicted theoretically: robustness of Packet Loss Ratio (PLR) to SNR is not a


(a) AWGN fading (b) Rayleigh fading

Figure 2.4: Effective throughput per SNR for IEEE 802.11a at different channel models [78]

monotonic decreasing function of the rate.” They also show that that two rates out of the 802.11g rate

set, 6 and 9 MBit/s, are indeed redundant and should not be considered by any rate control algorithms.

The first rate control algorithm which complies with these non-monotonic rate-loss behaviour is

SampleRate [31], which picks a random rate that may perform better than the current one and period-

ically updates its frame-loss statistics. This randomized rate sampling is performed every 10th packet.

A rate is not eligible for sampling if it experiences four successive packet failures or its lossless trans-

mission time is greater than the average transmission time of the current bit-rate. To calculate average

transmission times, SampleRate calculates the average transmission time for a bit-rate by averaging the

packet transmission times of previous packets sent at that bit-rate. Then, the highest throughput rate is

selected to send out the data packets. Choosing the rate with the shortest average transmission time,

SampleRate tries to achieve the best average throughput performance in the long term. The original

SampleRate algorithm uses the same bit rate for all retries. SampleRate was shown to outperform ARF,

AARF and Onoe based on several measurement experiments using the implementation in the Click

router framework [54].

The successor of Madwifi is the full open-source driver “ath5k” for Atheros 802.11abgn chips,

which is part of the Linux kernel tree. It relies on the split MAC approach where the Linux mac80211

subsystem provides standard MAC functions and wireless drivers can connect to the provided API.

Therefore, rate-control algorithms are placed within the mac80211 subsystem controlling potentially all

drivers beneath it. At the time of the writing of this thesis, there are four main rate control algorithms in

the Linux upstream mac80211 compat-wireless-tree: PID and Minstrel for IEEE 802.11abg, and simple

rate control and Minstrel HT for IEEE 802.11n. In this thesis, we focus on PID and Minstrel as we work

with IEEE 802.11abg cards. PID is based on a classical proportional integral derivative (PID) controller

which tries to minimize the difference of the current and target frame loss ratio (default target frame

loss ratio is 14%) by dynamically switching between transmission rates [68]. However, Yin et. al [33]


showed that operation of PID leads to significant oscillation in rate selection and throughput.

The most commonly used rate control algorithm for IEEE 802.11abg is Minstrel [69]. It builds on

SampleRate and also incorporates several experiences from real WiFi systems into its design. The main

goal of Minstrel is to address responsiveness and reliability issues seen with the other rate algorithms

available in open-source drivers. Briefly, Minstrel operates as follows: It maintains a table of the es-

timated success probability per neighbor and rate. The success probability is calculated as the ratio

of the number of acknowledgements to transmission attempts for a given rate. Every 100ms, Minstrel

evaluates this statistics table and uses Exponential Weighted Moving Average (EWMA) to smooth the

success history of each rate, R, as follows:

p+success[R] = ((1− α)× success[R]

attempt[R]) + (α× psuccess[R]), (2.1)

where p+success[R] is the new success probability, psuccess[R] is the old success probability, success[R]

is the number of packets sent successfully in the current interval, and attempt[R] is the number of

attempts. Here, α is the smoothing factor. Given p+success[R], the maximum achievable throughput is

calculated as R× p+success[R]. This table is used to find the best performing rate and the rates to be used

for the retries (i.e., multi-rate retry chain) in the next interval. To update these statistics, a fixed amount

(10% by default) of the data packets are used to probe a randomly chosen rate out of the possible rate

set. Minstrel’s sampling therefore depends on the data traffic in terms of packet rate and packet length

distributions. The core of Minstrel rate control algorithm is setting the multi-rate retry chain, which

contains the number of retries for the next transmission rate when packet delivery fails at the current

rate. Minstrel fills in these values using the heuristic in Table 2.3, where Best T refers to best throughput

rate, and Best prob denotes the rate with the best success probability. Random is a randomly chosen

rate to probe rates independently across the entire rate set. According to the table, while Minstrel, by

default, assigns the 3rd rate as the best probability rate, and the 4th rate as the lowest basic rate, the

1st and 2nd rates are chosen such that unnecessary sampling of lower performance rates are avoided.

Figure 2.5 depicts how the chosen rates are used to fill the Multi-Rate-Retry chain. The performance of

Minstrel was analyzed in [80]. It was shown that even with its default settings (i.e., without selecting

the best α for the faster adaptation), Minstrel achieves better throughput performance compared to other

rate control algorithms (e.g., Onoe, SampleRate) [33].

A common feature among all the above-described rate adaptation schemes is that they consider all

packet losses to be due to physical channel quality. They do not differentiate between packet losses

caused by MAC layer interference, e.g., by either hidden terminals or congestion. We next give a brief

overview of loss-based schemes that try to distinguish congestion losses from channel losses.

Collision Aware Rate Adaptation (CARA) [70] aims to differentiate between frame errors due to

channel errors and collisions by use of RTS/CTS exchange and the Clear Channel Assessment (CCA)


Table 2.3: How does Minstrel fill the retry chain?Retry chain Sampling packet Data

Random < Best T Random > Best TRate 1 Best T Random Best TRate 2 Random Best T 2nd Best TRate 3 Best Prob Best Prob Best ProbRate 4 Basic rate Basic rate Basic rate

Minstrel Components: Multy-Rate-Retry (MRR) Chain

maximal throughput rate2nd max. throughput rate

highest success probability

I II III IV unicast data payload

Basic rate

Set max. retry attempts such as:

max. transmission time per MRR

segment <= 6ms

modulation rate (IEEE 802.11 a)

throughput[MBit/sec]

success probability

number of attempts

number of successes

6 4 96 % 0 0

9 5,5 98 % 0 0

12 6 90 % 0 0

18 11 80 % 1 1

24 12 65 % 4 4

36 4 20 % 1 1

48 1,5 5 % 1 0

54 0 0 % 0 0

rate[0]

retry[0]

rate[1]

retry[1]

rate[2]

retry[2]

rate[3]

retry[3]

Choose appropriate modulation rates per MRR segment.

Figure 2.5: Diagram of the Multi-Rate-Retry chain (MRR) setup per packet as part of Minstrels ratecontrol


functionality of the IEEE 802.11. To handle collision-based losses, first, CARA turns on RTS upon a

frame loss and turn off RTS upon a frame success. The second method to differentiate collisions from

channel errors is called CCA Detection. After a node finishes its data transmission, it starts assessing

the wireless channel using CCA. Since the node expects an ACK within an SIFS, if the wireless channel

is busy and the expected ACK reception does not start, the station concludes that a collision has hap-

pened. In both cases, data transmission rate is not reduced. Similarly, Robust Rate Adaptation Algorithm

(RRAA) [71] consists of two components: rate adaptation (loss ratio estimation and rate selection) and

collision elimination. The basic idea is again to leverage the per-frame RTS option in the IEEE 802.11

standard, and selectively turn on RTS/CTS exchange to suppress collision losses. However, Wong et al

argue that CARA suffers from the drawback of RTS oscillation: In the worst case, when one of every

two frames is lost, this results in more than 50% throughput reduction. Therefore, RRAA uses adaptive

RTS to reduce collision losses. To this end, RRAA maintains an RTS-window (RTSwnd) similar to TCP

(Transmission Control Protocol) congestion window. Within an RTS window, all frames are sent with

RTS on. RTSwnd is initially set as 0, which disables RTS. It is then adapted as follows. When the last

frame was lost without RTS, RTSwnd is incremented by one as this suggests a collision loss. When

the last frame transmission was lost with RTS, or succeeded without RTS, RTSwnd is halved because

the packet did not experience collisions. When the last frame succeeded with RTS on, RTSwnd is kept

unchanged.

Finally, Wireless cOngestion Optimized Fallback (WOOF) [72] monitors channel busy time (us-

ing Atheros-based hardware) and relies on this metric to estimate the probability of congestion-based

packet loss. The data rate selection is based on SampleRate calculation of expected transmission time.

However, the congestion loss probability is used to adjust the expected transmission time, so that the

congestion-related losses do not play a significant role in rate selection. The authors show that WOOF

outperforms SampleRate and is able to follow the static best rate selection. However, it is not clear,

compared to the previous approaches, how WOOF performs in the presence of hidden terminals.

SNR-based approaches: Receiver Based Auto Rate (RBAR) [73] is the first SNR-based rate adap-

tation protocol that takes advantage of the RTS/CTS control frames transmitted at the basic rate. This

requires modifying the IEEE 802.11 standard in two ways: (1) RTS/CTS messages have to include

packet size and rate, instead of transmission duration; (2) an additional RSH message is sent before the

data frame to finalize the handshake. While RBAR is of little practical interest because it cannot be

deployed in existing 802.11 networks, it is still important because it serves as a baseline for SNR-based

approaches.

The existence of stations that use different rates creates challenging problems. Sadeghi et al [75]

showed that while standard IEEE 802.11 ensures access fairness among competing stations, this leads to

unfair use of the channel by slow transmitters. They propose Opportunistic Auto Rate (OAR) to ensure


time fairness among competing stations. Similar to RBAR, OAR probes possible rates by exchanging

RTS/CTS packets and it differs in its opportunistic transmission of data frames. Over periods of good

channel conditions, nodes that are able to use higher rates, send multiple consecutive data packets that

sum up to the time it would take to send a single packet at slower rates, e.g., the basic rate [81]. OAR,

unfortunately, shares the same practicality issues with RBAR.

Full Auto Rate (FAR) [82] attempts to achieve full data rate adaptation - rate adaptation for control

packets as well as data packets. The authors argue that, if RTS/CTS packets are transmitted at a higher

data rate, rather than the basic rate, better performance should be achieved because transmission at

basic rate underutilizes the wireless channel. In FAR, an idle station which overhears frames from its

neighbor stations uses its received signal strength to estimate the rate to the neighbor station. Then,

when this station needs to transmit an RTS, it uses the pre-estimated rate. If the RTS is transmitted

successfully, FAR follows the strategy similar of RBAR to estimate the rate for a data frame during the

RTS/CTS exchange. If RTS fails, it is retransmitted at a lower rate.

In summary, using receiver feedback is both an advantage and disadvantage for SNR-based ap-

proaches: while their information about what the receiver might be experiencing is more accurate, they

require a feedback mechanism to acquire such information. In [83], it is shown indeed that SNR-based

protocols are more robust compared to loss-based protocols. However, they also conclude that SNR-

based protocols require in-situ training to ensure such robustness.

BER-based approaches: BER-based rate adaption schemes, e.g., SoftRate [35], promise throughput

gains and shorten response time for rapidly varying channel conditions. It differentiates between inter-

ference and channel errors caused by attenuation or fading. The BER-based rate adaptation reduces the

bit rate accordingly only in the latter case. However, in order to use BER-based rate control schemes,

the PHY layer must be able to provide BER measurements or estimates. This is not the case in the

standard 802.11 PHY. This is due to having only a fixed set of error correcting codes to ensure the entire

frame is correct or it should be retransmitted. Therefore, typically, BER-based schemes are realized

using software-defined radios (SDRs). Using a customized firmware on the micro-controller, Han et al.

realized time-critical operations such as blockwise error correction over 802.11 frames but these novel-

ties are very hardware specific [84]. Therefore, the potential of BER-based approaches will be unlocked

as SDRs become more prominent but unfortunately, these approaches do not apply to current hardware.

2.2.3 Carrier-Sense Control - CSC

In addition to selecting a certain power-level and bit-rate to transmit a data packet, an IEEE 802.11 ra-

dio must implement a packet/signal detection mechanism and a carrier sensing mechanism to support

CSMA/CA. Among many wireless MAC protocols carrier sense is a key component of their operation.

Its main objective is to regulate concurrency in wireless medium access by achieving a balance between


interference protection and spatial reuse. Two types of carrier sensing are used, a mandatory physical

carrier sensing and an optional virtual carrier sensing, which is not our focus. Physical carrier sense is

known to be imperfect as a sender is only able to observe its environment and decides to transmit or

not, while the transmission success is actually determined by receiver-side conditions. The underlying

assumption is that channel conditions are highly correlated at all nodes. We observe this might be true

only in artificial cases of tightly clustered nodes in compact and isolated networks. Today’s WiFi de-

ployments contrast these assumptions, as they are not clustered but chaotic, not isolated but overlapping,

not compact but city wide.

Two problems with carrier sense have been identified in the literature: (1) the exposed terminal

problem, where nodes that could have transmitted simultaneously, miss the opportunity of spatial reuse,

and (2) the hidden terminal problem, where nodes that should hold back their transmission, do not and

interfere with others [85]. To address these issues, earlier work looked at tuneable carrier sensing, which

improves network throughput by maximising spatial reuse. Similarly, Schmidt et al. [86] propose a

CCA threshold adaptation but for a different context: vehicular networks. They propose to adapt CCA

threshold stepwise based on the time a packet has waited for channel access. Their approach enables the

possibility to find a sweet spot, where both the collisions and the channel access delays are reduced.

However, these theoretical works assume carrier sense is controlled via a single parameter, CCA

threshold, and adjust it in discrete and absolute steps [39, 87, 86]. Carrier sense that is implemented

on hardware is based on the interplay of different detection mechanisms. For instance, in the case of

Atheros hardware, it is possible adjust up to 6 parameters regarding the operation of carrier sensing.

Furthermore, the computation of the optimal threshold requires strong assumptions, such as all receivers

at a given distance are subject to the same interference [39, 87]. It is assumed that links either interfere or

sense each other. Yet recent experimental results show a more complex relationship: rather than on-off,

a probabilistic transition range (i.e., gray-zone) between interfering or carrier sensing links [88, 89].

The work based on WiFi experiments shows that there is room for improvement for carrier sense.

Jamieson et al. [23] present an experimental study, where they show that carrier sense performance is

poor in the presence of exposed terminals, multiple interferers, or when capture is possible (the receiver

is able to switch to receiving a stronger signal even though it is locked onto another). They argue that

especially at low bit rates, the capture effect allows concurrent transmissions. Furthermore, their results

indicate that carrier sense might be unnecessary at high loads, as nodes cannot keep up with carrier

sensing for each packet and transmissions slow down. Overlay MAC Layer (OML) [90], which was

implemented on top of the IEEE 802.11 MAC, allows scheduling transmissions so that ”unfavorable

interactions” between senders are avoided. The scheduling is based on an interference graph and their

results show significant improvement in fairness, and comparable results in throughput. Vutukuru et

al. [24] address the issue raised in [23] about exposed terminals, by allowing nodes to compute a conflict

map in a distributed manner. Nodes use empirical observations of packet losses to populate their own


piece of conflict map and keep track of those nodes they are able to transmitt to concurrently. This is

done with the help of receivers, which use headers and trailers of colliding packets to identify which

nodes cause a collision. All nodes periodically announce their interferer lists to all others. Note that,

however, all these improvements highly depend on the underlying network graph and the distribution of

traffic.

To better understand the performance of carrier sense in theory, recent work from Brodsky et al. [85]

focuses on both short and long range network links, and considers multi-rate radios. Their model applies

to the common two-sender case, assuming nodes roughly reach Shannon capacity through bit-rate adap-

tation. They consider carrier sensing as a function that switches between concurrent transmissions and

time-division multiplexing. Their analysis shows that carrier sense performance is close to optimal for

radios with adaptive bit-rate (only 15% below optimal). Most importantly, this performance is achieved

in a decentralized manner, and further tweaking offers only limited benefits. Their key results stem from

the observation that interference is a global phenomenon, affecting, to some extent, all nodes everywhere

and benefits from carrier sense adaptation seems to be limited. Compared to the aforementioned work,

their model suggests that hidden and exposed terminals usually cause modest reductions in throughput

rather than dramatic decreases. However, their model provides worst-case analysis and assumes opti-

mal concurrency, which provides interesting performance limits but with little practical relevance (i.e.,

their simple radio propagation models does not take into account the effect of shadowing and noise floor

calibrations, see [21] for an overview of different hardware technics to perform carrier sensing).

In summary, even though major steps have been taken in understanding carrier sense both in theory

and practice, the conclusions do not resolve the question whether carrier sense control is necessary or

not. Therefore, we consider carrier sense control an open problem.

2.3 Joint Resource Allocation

Todays strict layering approach of the protocol stack where fundamental services such as access to the

medium (link layer), routing (network layer), and congestion control (transport layer) are hierarchically

defined and independently provided has been proven as a very successful design paradigm for wired

networks [91]. Srivastava et. al [92] distinguish three main reasons why the presence of wireless links

within a network motivate protocol designers to violate the traditional layered network architecture:

the unique problems created by wireless links, the possibility of opportunistic communication, and the

new modalities of communication offered by the wireless medium. Essentially, the capacity of wireless

networks is not fixed but rather time- and space-varying caused by channel impairments, mobility and

interference [93]. The achievable capacity depends upon local resource allocation decisions: transmit

power and transmit rate adjusted at the WiFi sender and carrier sense settings at the WiFi receiver.

Here, significant inter-dependencies exist. For instance, a rate control mechanism searches for the best

Joint Resource Allocation 25

transmission rate under varying channel quality. A packet can be transmitted at a high rate if the SNR

(Signal to Noise Ratio) at the receiver is high and otherwise, a lower transmit rate achieves more robust

communication. Hence, the transmit rate adaptation algorithms in the literature [32, 31] take packet

loss into account as an indicator to adapt the current rate. However, through transmit power control,

the transmit power can be dynamically tuned, which consequently affects the SNR at the receiver and

hence, whether the rate chosen by the rate control algorithm works or not. Furthermore, using packet

loss as an indicator may lead to wrong decisions, as packet losses occur not only due to low SNR but also

due to congestion. Observing that nodes should not adapt their rates due to losses during congestion,

channel busy time (i.e., the fraction of the time the medium is utilized) is proposed as a new metric [72].

Note that, in this case, the measurements of channel busy time are dependent on the underlying physical

carrier sense mechanisms, which play a fundamental role in avoiding collisions. More specifically,

the channel is declared busy when (i) energy detected exceeds a certain threshold, (ii) a valid IEEE

802.11 signal is detected, or (iii) a combination of both (virtual carrier sensing is excluded here). Again,

this is also affected by transmit power control. Finally, in theory, one can improve spatial reuse, and

consequently network capacity, by reducing the power or increasing the carrier sense threshold. This

intuitively means “if you want to shout, you need to listen more carefully so as not to disturb those who

are whispering” [94]. Hence, given these interactions among the three mechanisms, it is essential to

design joint rate, power and carrier-sense mechanisms to maximize the network capacity [95]. In this

section, we survey recent theoretical and practical work on joint control mechanisms.

While theoretical works show significant potential from joint solutions, their shortcoming is the un-

realistic assumptions they make to simplify the analysis. For instance, they require significant amount

of channel state information, which is challenging to collect, if not infeasible, in practice. An example is

the well-known joint PHY rate and transmit power adaptation mechanism of Miser [96]. The key idea of

Miser is to compute an optimal rate-power combination table with respect to local power consumption

in an off-line fashion and use these pre-calculated results at runtime for each data frame transmission

by a simple table lookup. While Miser shows significant energy savings in simulations, the scheme re-

quires IEEE 802.11h as a pre-requisite for an implementation. Additionally, MISER needs to model the

wireless channel apriori to be able to calculate the rate-power combination offline and requires knowing

the number of contending stations in the network. Thus, it is not much of a practical interest [81].

Interference management schemes (e.g., multi-user MIMO) where interference is not always treated as

source of performance degradation also has several shortcomings [97].

Much of the existing work also considers IEEE 802.11 extensions, where existing messages are

extended or additional handshake messages are proposed. For instance, the RTS/CTS scheme is used

to estimate channel state information, which is further exploited for transmit power and rate adaptation.

In [98] a similar extension of the 802.11 DCF is proposed. However, instead of probing the link quality,

location information is included in the RTS/CTS handshake. By using a propagation model, the nodes


are able to make better interference predictions, which increase the achieved throughput. In contrast,

in [87], it was shown that in the case of discrete data rates, and a sufficient number of adjustable power

levels, tuning the tranmission power offers several advantages compared to carrier sense control. And

spatial reuse depends only on the ratio of transmit power level to carrier sense threshold. This, again,

requires the receiver to piggyback this information to the transmitter, which might be achieved by IEEE

802.11h [18], but is not implemented in any of the current device drivers.

Given the difficulty in changing standards and forcing driver implementations, local algorithms are

more relevant. For instance, in [99], both transmit power and rate adaptation are performed based

on the successful or unsuccessful reception of an ACK at the sender. If an ACK is not received, the

sender concludes that the signal quality was insufficient and it increases the transmit power or lowers

the data rate. If several ACKs are received successfully for several transmissions, the transmit power

is lowered or the data rate is increased. In our proposed joint rate-power controller Minstrel-Blues,

we also build on their strategy of selecting the highest possible data rate and adjusting the transmit

power accordingly. Similarly, in [100], PARF and PERF were proposed, where the authors extend ARF

(as in [101]) and ERF (Estimated Rate Fallback) to work with TPC. Note that ERF is the SNR-based

version of ARF, where each packet contains its power level and the path loss and noise estimate of the

last packet received. Based on this, ERF senders estimate SNR and set the highest transmission rate

that supports this SNR. The authors of [100] have observed that PARF did not perform well when the

receiver decreased the power for ACK transmissions. Essentially, this led to incorrect power decrease

decisions at the transmitter when these ACK frames were lost. They obtain more stable performance

with PERF, where power and rate decisions are based on the measured SNR values. These results

are in-line with [83], which shows that SNR-based protocols are more robust compared to loss-based

protocols. However, they also conclude that SNR-based protocols require in-situ training to ensure such

robustness.

Local approaches were also proposed for joint control that involves carrier sensing. In [101], the

spatial back-off concept was introduced, which allows dynamic tuning of carrier sense threshold together

with ARF (Auto-Rate Fallback) algorithm to achieve high throughput. While the algorithm uses local

search to make rate and carrier sense decisions, the authors assume that carrier sense can be controlled

with a single threshold adjustment. In [102], a joint transmit power and carrier sense adaptation is

proposed relying on a mechanism that differentiates congestion and interference related losses. It is

shown that by tuning the carrier sense threshold, it becomes possible to eliminate interference related

losses, when the interference signal arrives prior to the data signal. On the other hand, power control

suppresses losses when interference occurs after the arrival of the data signal. However, new trade-offs

are introduced when rate control is considered in addition to power and carrier sense control [103, 23].

Here, it becomes necessary to understand the trade-off between spatial reuse and the rate that can be

supported.

Summary 27

The closest work to our work is Symphony [104]. The authors implement a two-phase power and

rate controller in the Linux Madwifi driver. Similar to our work, Symphony also targets at keeping

the throughput performance at the same level as maximum power provides (REF phase), when a actual

lower power (OPT phase) is used. To take care of the hidden terminal situations arising due to the use

of lower power, they employ adaptive RTS/CTS to verify whether losses are due to collisions or channel

degradations. It must be noted that Symphony periodically switches between REF and OPT phases, to

confirm the performance expectations at the REF phase. This requires synchronisation among access

points, as well as additional messages to be broadcasted to client nodes in order to inform them about

those phase change. This is contrary to our work, which does not require synchronisation among nodes

nor additional message passing. Nevertheless, Symphony presents an example where theoretical work

is carried into practice, and our contribution, also lies in further reducing this gap.

2.4 Summary

In this section, we gave an overview of the research on both theoretical and practical power control, rate

control and carrier sense control, as well as joint control approaches. We observe that compared to the-

oretical work, the amount of practical work on these is limited, where rate control may be considered as

an exception. For instance, most interference-aware power control schemes predict interference by using

mathematical or prediction-based models [105]. Clearly, when using such models, the accuracy and the

achieved gains of the proposed power control schemes cannot be achieved due to the imperfection of the

derived models. Therefore, we believe there is a strong demand for testbed implementations to verify

the true potential and the feasibility of performing transmission power control. Furthermore, among the

three, the theoretical work on carrier sense stands out as the least representative of the reality. Indeed,

transmit power control as well as rate control require adapting to a single parameter (i.e., power-level,

and bit-rate or modulation-coding-combination, respectively), which takes a discrete and finite set of

values. The theoretical work on carrier sense also tries to tune a single parameter, CCA threshold, and

adjust it in discrete steps [39, 87]. In contrast, carrier sense control implemented on hardware is based

on the interplay of different detection mechanisms. For instance, in the case of Atheros hardware, it is

possible adjust up to six parameters to tune the operation of carrier sensing. Therefore, it is required to

adapt multiple inter-dependent parameters. The operation of carrier sense adaptation should be consid-

ered as relative to the current noise-floor, which is a time-varying process (it is periodically calibrated by

hardware). In the next chapter, we explain the parameters open to adaptation in carrier sense as well as

power and rate control in Atheros hardware. In addition, we take a closer look at the noise-floor process

in indoor and outdoor environments and its influence on carrier sensing.

Chapter 3

An Inside Look at Our Testbed andAtheros IEEE 802.11 Radios

Building practical joint rate and power control mechanisms requires a clear understanding of transmis-

sion and reception processes performed at the PHY layer, and access and control mechanisms performed

at the MAC layer in current hardware and drivers. To this end, in this chapter, we briefly describe our

testbed, the Berlin Open Wireless Lab (BOWL) testbed, which is the environment we have built, val-

idated, and tested our rate and power controller. Next, we present IEEE 802.11 radios in our set-up

and describe Atheros-specific features that affect our implementation and experimentation. Specifically,

we explain the Atheros receiver unit, its two packet detection mechanisms and the different modes of

carrier sense operation. We also discuss the importance of the noise-floor calibration process of the

CMOS-based wireless hardware as it forms the basis of the carrier sense operation.

3.1 Our Testbed: Berlin Open Wireless Lab

Wireless testbeds are invaluable for researchers to test their solutions under real system and network

conditions. Different than typical testbeds, the Berlin Open Wireless Lab (BOWL) project at Technische

Universitat Berlin (TUB) maintains an indoor and outdoor WiFi network which is used both for Internet

access and as a testbed for wireless research. In addition to these networks, the BOWL project includes

a smoketest network, for early development and testing. In the next two sections, we summarize the

hardware setup and software components of BOWL.

3.1.1 Hardware Setup

The large fraction of the BOWL network [106], formerly MagNets [8, 107], resides in the TU-Berlin

campus. From 2006 on, we have deployed more than 60 nodes on the rooftops of TUB buildings. Fig-

29

30 3. An Inside Look at Our Testbed and Atheros IEEE 802.11 Radios

(a) Outdoor deployment area at TU-Berlin campus

17. floor

16. floor

16-5

16-416-3 16-2

16-1

17-4

17-117-317-2

(b) Indoor deployment area at the two floors of theTEL-building

Figure 3.1: outdoor indoor map

ure 3.1(a) shows the deployment area and node locations of the outdoor network, which has a diameter

of about 1200m from north to south as well as from east to west. The indoor deployment of BOWL

consists of 9 nodes and spans across the 16th and 17th floor in our Telefunken (TEL) office building (see

Figure 3.1(b))

As described in [108], at the time where hardware alternatives were evaluated for the project, only

router designs based on Intel IXP4xx met our requirements (e.g., high programmability, support for

multiple radios, PoE support), and therefore, the 533MHz Avila Gateworks GW2348-4 router with

256MB RAM was chosen as the primary platform. As a secondary platform, we opted for a less powerful

266MHz MIPS based Asus WL-500gP, which comes with 32MB RAM, 8MB flash, one miniPCI slot

and two USB 2.0 interfaces. This board was initially considered as a dedicated passive monitoring

unit at the 2.4GHz and 5GHz frequency bands. In contrast to Avila, the Asus board provides USB 2.0

connectivity and a 2GB USB stick were attached to serve as the local data storage. Therefore, we built a

dual-router node, where the two boards are connected through (1) a one-way RS-232 serial connection

from Asus to the Avila, and (2) through a bidirectional 100MBit Ethernet as shown in Figure 3.2. Each

node is powered by Power over Ethernet (PoE) to simplify cabling and power requirements. For the

outdoor network, we deployed dual-router boxes using Avila and Asus boards at 13 different rooftop

locations (the Asus board is shown in Figure 3.2). Our indoor deployment consists of only dual-router

boxes. For the experiments in this thesis, we rely mostly on Asus boards, and therefore, we will present

more details on this board. For the further antenna and hardware details regarding the Avila platform,

we refer the reader to [108, 106, 109] and references therein.

The Asus router, both in indoor and outdoor setups, has an Atheros based 802.11abg WiFi card 1 but

with different capabilities and antenna setups. The outdoor nodes use a high power Wistron DCMA-82

card with a single Atheros AR5414 802.11abg chip mini-PCI design and output power up to 23 dBm

1The majority of the BOWL hardware was acquired in 2007, at a time when the IEEE 802.11n radios and support for themwere not ready to be considered for a deployment.

Our Testbed: Berlin Open Wireless Lab 31

dual-router box

ethernet

5GHz

2,4 GHz

Avila antennas

Asus antennas

outdoor nodeindoor node

dual-band

armmips x86

Figure 3.2: BOWL dual-router boxes in indoor and outdoor.

connected with high gain omni-directional antennas. Each one of the two MMCX jacks are connected

to a 12dBi 2.4GHz and a 12dBi 5GHz omni-directional antenna from Interline, respectively and marked

with red stars in the Figure 3.2 (labelled as outdoor node). The indoor Asus node is shown Figure 3.2

with label indoor node. This node is equipped with a standard Wistron CM9 WiFi card based on the

Atheros AR5212 802.11abg dual-chipset and maximal output power of 19 dBm. Only one of the two

UFL connectors on the CM9 is used to connect to a basic dual-band omni-driectional antenna from

ALLNET with 2.5 dBi at 2.4GHz and 5dBi at 5 GHz.

One of the main issues about working with routers that are deployed at rooftops is that in case a full

reset of the router is required someone needs to climb up to the actual router location. From the first

days of the BOWL project, we designed and soldered a remote reset circuit in each dual-router box. The

circuit design consists of one reed relay, one diode and one 150 ohm resistor. The relay energizes at

15mA and de-energizes at 5mA with a coil resistance of 10 ohm. This is particularly suitable to trigger

the relay based on the small input signals possible from the GPIO (General Purpose Input Output) lines

from Asus and Avila.

3.1.2 Software Setup

All BOWL nodes run a customized operating system based on OpenWrt [110], a Linux distribution

for embedded devices. It has three main components optimized for size: a Linux kernel, uClibc as a

small C standard library and BusyBox, a stripped-down Unix toolset. By its design, OpenWrt does not

contain executable files or external source code; it is an automated Makefile and script-based system for

downloading sources, patching them to work with the given platform and cross-compiling them correctly


for the chosen router platform. We chose OpenWrt due to the following [110]:

..., if a new kernel is released, a simple change to one of the Makefiles will download the

latest kernel, patch it to run on the embedded platform and produce a new firmware image

– there’s no work to be done trying to track down an unmodified copy of the existing kernel

to see what changes had been made, the patches are already provided and the process ends

up almost completely transparent. This doesn’t just apply to the kernel, but to anything

included with OpenWrt – It’s this one simple understated concept, which is what allows

OpenWrt to stay on the bleeding edge with the latest compilers, latest kernels and latest

applications.

The OpenWrt build system typically produces a minimally configured image that needs to be configured

and distributed to our BOWL nodes.

In our dual-router set-up, the Avila boards were used both for wireless experimentation as well as

providing an access interface to Internet users. Therefore, early on, a lot effort has been put into automat-

ing the configuration of the Avila image and managing its distribution to the nodes [108]. We report on

our experience on managing this dev-ops network (i.e., development and operations network) in [109].

On the other hand, the Asus boards were not used for access and did not face the same challenges.

Therefore, I, single-handedly, maintained the OpenWrt system on the Asus routers and therefore, the

Asus image followed closely the latest development of OpenWrt, its so-called ‘trunk’ version. Such

early adoption to OpenWrt brings several advantages and disadvantages. The major advantage is the

close relation between OpenWrt trunk development and the Atheros driver development: several Open-

Wrt maintainers provide up-to-date patch sets for all three major Atheros device drivers. Since our

objective was to implement a joint power and rate controller in-kernel, a prerequisite was to get early

support from other kernel developers to work on a common and current code base. The main disad-

vantage is, expectedly, the need to constantly adapt the set of local patches to the trunk version. In

Chapter 5, we relate more on our experiences of getting our kernel development accepted into the Linux

upstream codebase.

For device drivers, in 2007, we started using Madwifi driver under OpenWrt. In 2010, the successor

driver, ath5k, became more stable, and we switched to using this fully open source driver which provides

more flexibility and operation transparency compared to any Madwifi version. Additional discussion

about the differences of those two drivers are presented in Chapter 5. On a final note, these open drivers

are the main force behind Atheros-based WiFi hardware to be widely used in research testbeds, creating

a more comparable experimentation landscape.

IEEE 802.11 Radio Characteristics 33

3.2 IEEE 802.11 Radio Characteristics

In this section, we summarize IEEE 802.11 radio [1] operations in terms of rate, power and carrier sense

based on our Atheros WiFi hardware. We first go into the details of Atheros hardware operation as well

as the registers providing important information about the MAC layer states and adjustable registers

that can be controlled to alter the operation of the card. Some of the features that we describe here are

IEEE 802.11a specific, however, most of the discussion applies to IEEE 802.11 in general. While we

mainly focus on rate, power and carrier sensing capabilities in a typical IEEE 802.11 hardware, we also

summarize several Atheros-based optimizations, such as Adaptive Noise Immunity (ANI), which have

significant impact on experimental measurements and therefore, which should be treated carefully [111].

Finally, we conclude with a discussion that noise floor calibration is an important hardware process that

acts as one of the determining factors of packet reception.

3.2.1 Atheros Hardware Design

In Figure 3.3 we have linked several sources of information about Atheros chip design [112, 113, 114,

115] together. In contrast to other WiFi chips like Broadcom BCM4712 or Intel 5300, Atheros chips

do not have a firmware running on a micro-controller (excluding Atheros USB WiFi) but rather 802.11

functions are split into hardware state-machines and software operation [112]. Functions that require

critical timing such as channel access, checksum generation, periodic beacons, and ACKs, are handled

within the protocol control unit (PCU). Other non time-critical functions, such as sending and receiving

of data frames and fragmentation, are performed by the device driver on the host system connected

via PCI bus to the WiFi card. On the sending path, the driver assembles a list of transmit frames in

host memory and passes a pointer to the list of transmit descriptors to the DMA engine (marked as

yellow line in Figure 3.3). The DMA engine traverses this pointer list, fetches the remaining data from

the host memory and passes it to the PCU to follow the 802.11 CSMA/CA access procedure to gain

access to the channel and then forwards the frame (further baseband and radio details can be found in

[112]). On the receiving path (shown as green line in Figure 3.3), after successful packet de-modulation,

the PCU extracts the frame type, verifies the checksum, and generates a response frame (i.e., ACK),

if appropriate, and passes the received frame to the DMA engine, which interprets a series of receive

descriptors to transfer the frame data to the host memory.

Besides the outlined data-path, Atheros MAC design has a dedicated control logic based on 32-bit

registers as shown in Figure 3.3. There are two types of registers: configuration registers that allow

updates, and status registers that allow monitoring of current hardware states [113]. Transmit power and

carrier sense operation are typical examples of function blocks that can be controlled by changing a set of

control register values (e.g., ACK transmission power in dBm or enable preamble-based (weak) signal

detection). The possible usage of each Atheros register value is well-documented (within the Linux


CPU

driver

Memory-Controller /PCI Bridge

RAM

tx-data

Txdescriptors

*Rx-descriptors

tx-data txfifo

rxfifo

CarrierSense

Transmit

DAC

DAC

ADC

ADC

Filte

rFi

lter

Transmitter

Receiver

AGC

Freq. Synthesizer

TPC

diversityswitch

RF-Transreceiver

OffsetControl

SensitivityControl

EDPD

SignalDetection

Viterbi

Auto-correlate

FFT

IFFT

PowerDetector

Receive

MAC state-machine

Baseband

ProtocolControl

Unit(PCU)

crypto engine

checksumlogic

DMA EngineHost HIU

rx-data

tx-fifo

rx-fifo

*

* rx-data

PCIBus

mac80211

Status & ControlRegisters

user-space

Antenna

RegMon

Atheros WiFi hardware

tx-data+

variable gain amplifier (VGA)

frequency mixer

clockrate

PA

noise-floorcalibration

loop

ACK

BEACON

Figure 3.3: Design and interconnections between host and Atheros 802.11 interface with MAC and PHYlayer functions

codebase in file reg.h for 802.11 abg [116] and 802.11 n [117] chips). The status registers represent

the dynamics of the MAC transceiver state-machine (shown in Figure 3.3 in the PCU box) and provide

other useful information. Registers of interest depend on the overall monitor/measurement objective and

within this thesis, we have used:

i Noise threshold is stored with the main energy detection threshold (i.e., the minimum energy

level that triggers the correlation-based signal detection) in a single register. Monitoring it allows

analyzing the noise calibration process in the card, and the interference conditions.

ii Timing Synchronization Function (TSF) is split across an upper and lower 32-bit TSF register.

The TSF is based on a 1-MHz clock and can be used to measure time intervals in microseconds

precision.

iii Receive signal strength indicator (RSSI)

iv The number of successfully received frames

v Mac states: The radio can be in only one of these states at any point in time.

• TX: the radio is actively transmitting.

• RX: the packet/signal detection mechanism triggered a demodulation attempt.


• BUSY: there is sufficient in-band signal energy on the medium but the packet detection mech-

anism does not trigger. This can happen due to interference, e.g., it can be triggered by an

out-of-band activity such as a microwave oven, a Bluetooth transmission or transmissions of

IEEE 802.11 packets on adjacent channels.

• IDLE: if no other state applies.

There are four corresponding MAC state registers reside in the same hardware memory addresses

for all Atheros 802.11 abg chips as well as for newer Atheros 802.11n chips. The actual count of

overall clock cycles at a given clock rate (drafted as clock symbol in the middle of Figure 3.3) is

stored in a separate register that is used as reference point. Additionally, through a dedicated MIB

freeze register, it is possible to stop counting these registers. The ability to freeze the Mac state

registers before reading their content ensures reading consistency among the different states (i.e.,

Clock Cycles, TX, RX and BUSY counters).

We make use of these registers in order to set-up as well as analyse our measurement experiments. To the

best of our knowledge, it is currently not possible to obtain the instantaneous MAC state of the Atheros

radio. We will try to overcome these limitations through a sampling approach in the next section.

3.2.2 Rate and Power Control Capabilities

In this section, we summarize the current rate and power control capabilities of WiFi (IEEE 802.11) ra-

dios. Each IEEE 802.11 frame contains a preamble, which is used for signal detection by the receiving

radio as well as for timing acquisition in order to find out when the payload actually begins. The pream-

ble header also contains information about the used transmission mode, which defines a transmission

rate that corresponds to a particular modulation order and channel coding rate. Note that, management

frames, e.g., ACK frames, are typically sent at the lowest basic rate. The IEEE 802.11ag [1] standard

defines also two additional higher rates, 12 and 24 Mbps for ACKs. For data packets, the current radios

are able to adjust their transmission rate per packet but not for retransmissions, i.e., a rate-lookup is not

performed for retransmissions. In Atheros-based radios, for each data packet, it is possible to specify a

so-called multi-rate retry chain (MRR) within the tx-descriptor that contains four different rates and their

corresponding number of maximal retries. Once the packet is successfully transmitted, the remainder of

the retry chain is ignored. For instance, it is possible to retry sending a packet first at 54 Mbps 4 times,

next at 24 MBps 3 times, next at 9 Mbps 2 times, and finally, at 6 Mbps again 2 times. Essentially, only

a few rate control algorithms (e.g., Minstrel, see Section 2.2.2) operate based on this ability to configure

the entire retry chain for each data packet. Based on the current compat-wireless codebase in Linux, we

find the maximal supported retry rate stages is four and Atheros is the only vendor that supports this (for

chipsets 5212 and later). Therefore, in our case, Wistron CM9 (chip 5212) and DMCA-82 (chip 5413)

support a MRR chain with four stages. On the other hand, Broadcom hardware using b43, b43legacy


and brcmsmac drivers (i.e., 802.11 abgn) support two, Ralink supports three and Intel supports one MRR

stage. However, as we do not have access to the source-code of the firmware running on these devices it

might be possible that a retry rate control is hidden from our view of the codebase.

While rate control per-packet transmission is typical, per-rate power control is not typical. Only sev-

eral chipset vendors, in particular Atheros, have documented implementations that permit adjustment per

packet [4]. It was validated in [118] that with Atheros chipsets it is possible to perform per-packet power

control with a granularity of 0.5 dBm and switching latency of 1 ms. Our experience with the Atheros

5212 and 5413 chipsets also confirms this, and we build our joint rate-power controller, presented in

Chapter 5, based on these capabilities. Note that these chipsets support one power level per data packet

(i.e., all possible retries are also done in the same power level). With newer 802.11n chips from Atheros,

like the AR938X, it is also possible to use four different power levels per retry chain entry. Finally,

ACK frames can only use a single power level per device. The range of adjustable power level values (in

case of Atheros hardware) starts at 0 dBm (lower power levels are not yet supported by the driver). The

upper bound depends on the specific WiFi card, where typical values are 16 to 23 dBm. The power can

be adjusted with a granularity of 0.5 dB. Other vendors seem to support even lower transmission power

levels, as mentioned in [119], Intel 5300 3x3 MiMo 802.11n WiFi cards enable transmit power levels

from −10 dBm to 16 dBm, also in steps of 0.5 dB.

Interaction between Rate and Power: In terms of joint controllability, both rate and power are not

mutually independent but rather exhibit a clear interaction in regions near the maximum output power.

There is a complex trade-off between the following three objectives: (1) sufficient output power (and

therefore sufficient transmission range/coverage), (2) high data rates to realize good network perfor-

mance and (3) low and efficient power consumption with respect to battery usage. Todays power am-

plifiers (PA) in WiFi radios (class A and AB are typical designs) can only achieve two of the three

objectives at the same time. They can work quite efficiently if the point of operation is near the maxi-

mum power saturation level (about 80 % max. efficiency). A key challenge is the power amplifier design

since in OFDM modulation, the resulting RF signal has a large peak-to-average power ratio, which can

theoretically have an amplitude as high as 17 dB and in practice, up to 10 dB [112]. Essentially, the PA

for OFDM systems must be sized to support possible peak power levels, but operate on average up to

10dB below this peak and therefore, at much lower efficiency levels for most of the time (at about 10%

average efficiency) [112]. There are two requirements that restrict the actual power level to stay below

its maximum amplification potential: (1) each device must meet the spectral mask given by the 802.11

abgn standard and any applicable regulatory requirements and (2) an individual transmit signal quality

per modulation rate specified by an error vector magnitude limit (EVM) must be met [1, 7, 112]. With

higher order modulation schemes (in terms of encoded bits per symbol), the EVM requirements defined

in the IEEE 802.11 standard get stricter. This translates into rate specific demands of linear amplification


Figure 3.4: Measurement setup: Rohde & Schwarz FSP spectrum analyzer connected via pigtail to aWistron DCMA-82 WiFi card powered by an Asus wl-500gP

with bounded distortion level across the peak-to-average power range. But amplifiers do have non-linear

areas above a certain gain level and different pre-distortion techniques in the digital domain are used to

compensate for this nonlinearity and we refer to [112] and references therein. In can be summarized

that based on EVM requirements for each data rate and the limited linearity at different gains across the

peak-to-average range, higher modulation rates can only be supported at lower maximum output power

levels. In [113], it was explicitly shown for an Atheros 802.11a transceiver, at low data rates, the mea-

sured output power is about 18 dBm and limited by the spectral mask requirements. On the other hand,

at higher data rates (above 24 MBps), a reduction of up to 5 dB is needed to meet the dynamic range

requirements (peak to average ratio) of the transmitted OFDM signal.

Output Power Limitations of BOWL Radios: To understand the output power limitations of BOWL

radios, we performed particular spectrum power measurements with our Wistron CM9 and DCMA-82

WiFi hardware at the Microwave Engineering Research Laboratory at TU-Berlin. Using their spectrum

analyzer, we conducted several measurements to validate that adjusted transmit power levels lead to the

desired amplification and measurable output power. The left part of Figure 3.4 displays our experimental

setup while the right part presents a typical measurement output as a screenshot taken from the R&S

FSB spectrum analyzer. A dedicated Asus router was utilized to measure our two different Atheros

based WiFi cards used in our BOWL network. OpenWrt Linux revision 23015 was used as operating

system and its corresponding Madwifi version as wireless device driver. A laptop connected via Ethernet

to the router served as control instance to adjust specific data rates and power levels. The so called AUX

antenna port of the WiFi card was connected by a 15cm pigtail cable to the input port of the Rohde &

Schwarz FSP spectrum analyzer [120]. The attenuation introduced by the pigtail and the connectors on

both ends (N and UFL, MMCX) is estimated, based on the data-sheet values, to be in the range of 3 ±


●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

● ●

●

●

●

●

●

●

●

●

●

●

●

●●

● ●

●

●

●

●

●

●

●

●

●

●

●

●●

● ●

●

●

●

●

●

●

●

●

●

●

●

●

● ●

●●

●

●

●

●

●

●

●

●

●

●

●

●

● ●● ●

●

●

●

●

●

●

●

●

●

●

●

●●

● ● ●

●

●

●

●

●

●

●

●

●●

● ● ● ● ●●

●

●

●

●●

●

●

●

●

● ●● ● ● ● ●

0

3

6

9

12

15

18

21

0 3 6 9 12 15 18 21 24adjusted tx−power [dBm]

mea

sure

d tx−p

ower

[dBm

]

DataRate

●

●

●

●

●

●

●

●

69121824364854

●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

● ● ●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

● ● ●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

● ● ●

●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

● ● ●

●

●

●

●

●

●

●

● ●

●

●

●

●

●

●

●

● ● ●

●

●

●

●

●

●

●

● ●

●

●

●

●

●

● ● ● ● ●

●

●

●

●

●

●

● ●

●

●

●

●

● ● ● ● ● ● ●

● ●

●

●●

●

●

●●

●

●

● ● ● ● ● ● ● ●

0

3

6

9

12

15

18

21

0 3 6 9 12 15 18 21 24adjusted tx−power [dBm]

mea

sure

d tx−p

ower

[dBm

]

DataRate

●

●

●

●

●

●

●

●

69121824364854

Wistron CM9 (at 5.825 GHz, 802.11a channel 165)Wistron DCMA-82 (at 5.825 GHz, 802.11a channel 165)

Figure 3.5: Measured output power vs. adjusted power level for 802.11a data-rates at channel 165 (8.525GHz)

2dB. This uncertainty in absolute attenuation is acceptable as we are interested in the measured signal

power as a function of adjusted transmit power. Therefore, measurements that show relative changes of

the signal power are sufficient for our objective. To measure the output power from wireless devices,

one may choose among several methods like measuring average, peak envelope power, instantaneous

peak power and average peak power [121]. We chose to measure the average peak power in compliance

with R&S WLAN test procedures. Since IEEE 802.11a signals are pulsed signals, it is important to

(1) generate a continuous output signal and (2) ensure a continuous reading for the spectrum analyzer

to measure the output power correctly. To generate such continuous output signals, we performed two

different experiments: (1) iperf on the router itself to generate back-to-back broadcast traffic with a

packet length of 2200 B to reduce inter-packet gaps and (2) a Madwifi specific continuous mode (tx-

cont-mode) that sends garbled packets without any inter-frame spacing nor back-offs continuously on

air. In the case of iperf packets, we changed the actual modulation by changing the multicast rate, and

in the case of txcont mode, appropriate ‘iw priv’ commands were used to change rate and power levels.

We explored all possible power levels, from 1 dBm to 24dBm for Wistron DCMA-82 and 1dBM-19

dBm for CM9, in steps of 1dBm and all the eight data rates of IEEE 802.11a on channel 165. For

each adjusted power level and rate combination, we dwell for 30 seconds in order to ensure steady-state

conditions with a sufficient sweep interval used by the spectrum analyzer. Every measured output power

level in dBm was read from the screen of the spectrum analyzer ( as shown in Figure 3.4) and manually

recorded, as it was not possible to automate this experiment since the spectrum analyzer did not have an

Ethernet port (only USB connectivity).

Figure 3.5 presents the results of our measurements conducted over 5 days and is limited to a single

20MHz channel in the 5GHz band (channel 165). Both traffic generation methods: iperf and txcont

mode produced equivalent results in terms of measured output power, hence we show only the iperf

results. Both WiFi cards show a nearly linear relation between the adjusted and measured power level

up to a certain limit, that seems to be rate specific. Both plots confirm the feasibility of power control

through adjusting transmit power levels in the driver that get translated to changed output power levels

accordingly. Abdesslem et al. [4] published results that were skeptical in terms of the feasibility of


power control on WiFi chips (Atheros included). Their concerns have been disproved by Kowalik et al.

[118] by demonstrating that power control is feasible and can be implemented in current IEEE 802.11

cards with per-packet granularity and low power switching latency. Our results confirm those findings in

terms of feasibility. Furthermore, we confirm the results of [113] that a rate dependent maximal output

power level and the 5 dB difference between the highest modulation rate of 54MBits and the lowest

6MBits.

In order to ensure that both spectral and EMV limits are respected, the device driver itself ensures that

the power level annotation per packet does not exceed those power level limits stored in its EEPROM.

During device initialization, driver-level functions read eight supporting points stored in EEPROM that

provide maximal allowed power levels in 0.5 dBm steps as a function of the frequency and data rate. In

case of IEEE 802.11a, out of the eight possible data rates, the first five rates (6 to 24 MBits) are grouped

and have one common maximal power limit per frequency. The remaining three higher modulation rates

(36, 48 and 54 MBits) have individual limits that support less maximal output power.

Based on our output power results, we were able to find and fix a critical driver bug in the ath5k code

that caused unnecessary low throughput. In all of our experiments using the ath5k driver, we observed

that link throughput even on a small scale desktop setup was limited to approximately 15 MBits when

802.11a 5GHz channels above a center frequency of 5.720 GHz (typically 5GHz outdoor channels)

were used. Regardless of which type of Wistron model we tried (CM9 or DCMA-82), the rate set that

provided the maximal link throughput was always lower than or equal to 24 MBits. Our guess, which

turned out to be true, was that the rates higher than 24 MBits did not perform as expected due to high

amplification gain, which consequently led to signal distortion above the EVM requirements. When we

lowered the global transmit power limit in the ath5k driver from default 17dBm to 12 dBm in the case

of CM9 model and from 23dBm to 18 dBm in the case of DCMA-82 model, the throughput increased

significantly up to 26 MBits and, all the data rates up to 54 MBits performed as expected. We discovered

that this was caused by erroneous EEPROM readings, which led to assigning maximum power level to

all data rates. We fixed this problem and our ath5k driver patch is included in Linux kernel version 3.6 2

(since 21st of August 2012).

In order to understand the distribution of those power limitations across different Atheros cards,

we patched the ath5k diver to print EEPROM readings. We analyzed again the two different hardware

models: (i) Wistron DMCA-82 WiFi cards and (ii) Wistron CM9 WiFi cards. All cards from the same

model showed identical EEPROM values. Our results for both hardware models are shown in Figure 3.6.

Comparing the maximum power levels at the lower data rates, the DCMA-82 supports up to 24 dBM

(i.e., 251 mW) in the 802.11a band while the CM9 is limited to 19 dBm (i.e., 79 mW). In reference

to the highest data rate of 54 MBits, the maximal allowed output power of the DCMA-82 is limited

down to 18 dBm, while the CM9 goes down to 12 dBm. Furthermore the maximum transmit power

2https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=3a245cbef6a9e4398456bd733b0b4b7cb3f11994


802.11a 802.11b 802.11g

02468

101214161820222426

5.0 5.2 5.4 5.6 5.82.41 2.43 2.45 2.47 2.42 2.44 2.46frequency [GHz]

max

. tx−

powe

r [dB

m]

DataRate

1−116−24364854

Wistron DCMA-82 (EEPROM limits)802.11a 802.11b 802.11g

02468

101214161820222426

5.0 5.2 5.4 5.6 5.82.41 2.43 2.45 2.47 2.42 2.44 2.46frequency [GHz]

max

. tx−

powe

r [dB

m]

DataRate

1−116−24364854

Wistron CM9 (EEPROM limits)

Figure 3.6: Output Power Limits stored in EEPROM

differences between the lowest and highest data rate represents the amplifier performance in terms of

linearity. Referring to the operation in IEEE 802.11b mode, both cards show similar results as there

is no rate dependent maximum power limitation. In 802.11a mode, the differences between maximal

output power at highest and lowest data rate vary from 5 to 6 dB in case of CM9 and between 3,5 to 5

dB in case of DMCA-82. The difference of 5 dB between maximum power levels of lowest and highest

data rate at a frequency of 5.825 GHz correspond to our measurement result from the spectrum analyzer

in Figure 3.5. Furthermore, we marked the four rate dependent transmit power limits from EEPROM at

5.825 GHz (i.e., channel 165) with four blue dotted lines in Figure 3.5. The power limits read from the

EEPROM and our output power measurements are in agreement.

In summary, we can conclude that transmit power and data-rate in IEEE 802.11 a and g modes

are not independent. Higher modulation rates have increased quality demands on the linearity of an

amplifier and in order to realize them, each modulation rate has an upper bounded transmit power level

per frequency. For instance, in case of our Wistron CM9 card operating at 17dBm in IEEE 802.11a

mode on channel 165, switching the data-rate from 54 MBits to 24 MBits, output power reduces by

5dB, down to 12 dBm (this equals to a reduction in transmission power by more than one third). To

the best of our knowledge, this relationship is not considered by any related work on transmit power or

rate control for IEEE 802.11 devices. In contrast to the common reasoning that power control in 802.11

networks [94, 44, 122, 104] is the main factor that creates asymmetric link conditions, our measurements

show that such asymmetric link conditions are likely to be already present in today’s wireless networks

due to rate adaptation, which effects maximum transmission power. In Chapter 5, we discuss the use of

this rate-power interactions in the design of our specific joint power and rate controller.

3.2.3 Carrier Sense Details

An IEEE 802.11 radio must implement a packet/signal detection mechanism and a carrier sensing mech-

anism to support CSMA. Essentially, carrier sensing mechanism is used to detect whether there is any

ongoing transmission before a transmission, in which case, a station must withhold its transmission.

Note that the IEEE 802.11 standard also specifies a virtual carrier sensing mechanism [1], which is out


of the scope of this thesis.

IEEE 802.11 standard dictates several minimum requirements for the operation of a receiver. For

instance, the sensitivity for the minimum transmission mode should be −82 dBm for a 20 MHz channel

and the carrier sensing function should declare the medium busy for any signal 20 dBm above the

minimum sensitivity requirement (hence,−62 dBm for a 20 MHz channel). Note that the channel might

be busy due to transmission from other stations (i.e., station interference) or due to noise interference in

physical medium. Station interference is mainly seen as MAC-layer interference and noise interference

as PHY-layer interference.

Weak and Strong Signal Detection: A comprehensive summary about possible signal detection al-

gorithms, their performance and energy tradeoffs are given in [21]. In the context of wideband systems

they define the term carrier sensing (CS) to specifically indicate methods of coherent detection based

on suitable signal properties and distinguish it from non-coherent energy detection (ED). Non-coherent

ED is known to be a robust and universal mechanism that can be performed anywhere within the packet

without requiring any knowledge of the type of underlying signal structure at the physical layer [21].

However, 802.11abgn systems are wideband, where the signal power is much more spread around the

carrier frequency, which leads to signal power spectral density near the noise floor, and hence, ED is of-

ten not sufficient to detect the presence of a packet [123]. Wideband radio systems implement therefore

more reliable coherent detection methods such as preamble detection (PD) or decorrelation-based de-

tection. To this end, each packet is preceded with a known preamble, typically consisting of repetitions

of a sequence of symbols designed for a near-ideal autocorrelation property when the receiver varies the

time offsets during preamble detection. Both the 802.11abg and 802.11n support different length and

types of preamble sequences and need therefore specific detection capabilities in each radio.

A comprehensive source of information about Atheros methods to detect and demodulate packets

are patents [124, 125, 126, 127]. Based on these patents, we conclude that Atheros radio chipsets are

able to perform ED and PD signal detection concurrently [127], which are named as strong and weak

signal detection, respectively. The objective after packet detection is to maximize the received signal

size at the analog digital converter (ADC, shown in Figure3.3 to provide a good dynamic sampling

range. This is achieved by amplifying the received signal within the automatic gain control unit (AGC)

while providing headroom for adjacent channel interference and the peak-to-average-ratio of OFDM

symbols. A chart of possible state transitions and all background details about baseband detection and

gain operations can be found in [127] and references therein. Briefly, strong signal detection attempts to

detect incoming packets by monitoring sudden changes of the received raw signal power, especially the

saturation at the ADC. The start of a new packet is assumed when the measured signal power exceeds an

adjustable threshold above the current noise floor. The abrupt power increment triggers the Automatic

Gain Control (AGC) unit to reduce the amplifier gain so that the size of the received signal is forced to


fall between two predefined thresholds. When the signal strength drops down from the lower threshold,

the WiFi card assumes the end of the packet and the AGC unit increases the amplifier gain, hence, its

sensitivity to catch new packets. Our experiments with Atheros hardware reproduced findings in [111],

which showed that Atheros ED only starts detecting packets successfully if the reported SNR is above

14dB. Several thresholds that control the energy detection part can be specified via the proc filesystem

in Madwifi and ath5k, resulting in the same control register triggers described hereafter.

Besides energy detection, Atheros hardware uses preamble-based weak signal detection, that, in case

of 802.11a, measures the significance of auto-correlated power with a period of 0.8µs (short symbol du-

ration) and enables packet detection with signal power levels near the noise floor [126]. The detection

of packet boundaries is provided through a 2-round correlation process using multiple thresholds, which

are independently configured for OFDM and CCK preambles when 802.11b/802.11g modes are sup-

ported. It can be concluded that the Atheros relies on a complex orchestration of several values and

thresholds to adjust signal amplification, filtering, self-correlation significance and off-set timings in or-

der to adjust the parallel operation of energy (strong) and preamble-based (weak) packet detection. Both

Madwifi and ath5k drivers support five levels of so-called interference immunity specified within the

debugfs filesystem. These are empirically determined combinations of multiple gain and filter thresh-

olds in order to change the overall sensitivity of the radio receiver with respect to incoming signals and

interference [125]. Furthermore, both drivers support the ability to enable or disable preamble-based

(weak) packet detection, hence pure energy detection operation. Within standard specific mode of op-

eration, the lowest sensitivity corresponds to the highest interference immunity index (e.g., level 4) in

combination with disabling preamble-based (weak) packet detection and enabling only energy detection.

The highest possible sensitivity is achieved by enabling preamble-based (weak) detection and using the

lowest interference immunity index (e.g., level 0). In our work on adjusting and monitoring carrier sense

operations [95] we validate a Madwifi driver patch provided by [128] to disable carrier sensing hence

any signal detection.

Capture Effect: Atheros radios also implement capture, which allows aborting the reception of an

ongoing frame, if a new stronger signal is detected. If the in-band power is measured to be above the

strong signal detection, the receiver logic is reset and strong signal detection for the new packet is started.

This is often referred to as “capture effect” in the literature. Capture may have a profound impact on

communication performance, however, it is a significant challenge to dissect the existence of capture

during transmissions. This is the reason why we do not attempt this in out work.

Adaptive Noise Immunity (ANI): Madwifi and ath5k drivers have both implemented their version

of a so called Adaptive Noise Immunity (ANI) algorithm [125, 111]. Its objective is to adapt receiver

sensitivity parameters such that rate of false packet detections are minimized [125]. A false detection

occurs when interference triggers the signal detection unit to believe that a packet is present. In both ANI


implementations receiver sensitivity is dynamically adjusted by changing the aforementioned 5-level

interference immunity index as well as enabling or disabling preamble based (weak) signal detection.

Measurements in [111] showed that enabling ANI may cause high variations in packet detection rate and

reported SNR values. In most of our experiments we switch ANI off and specify a static carrier sense

setting in the driver configuration.

3.2.4 Noise Handling

The achievable receive sensitivity of any communication system is fundamentally limited by noise.

Signal quality is typically measured as the ratio of the power of the received signal and the noise (Signal

to Noise Ratio - SNR) [129]. A common definition of SNR for any modulation scheme can be found

in [130]:

SNR =average received signal energy per symbol time

noise energy per symbol time

Note that, SNR is a function of (1) the output power of the transmitter, (2) the antenna gains on both

the sender and receiver side, (3) the path loss of the wireless channel and (4) the receiver noise. The

receiver noise floor, shown in Figure 3.7, is a time varying process of measured noise energy, which

is the sum of all noise sources in a measurement system. The circuit itself generates internal noise

for instance, by the random motion of electrons in a conductor, which is positively correlated with

temperature (i.e., an increase in temperature leads to higher agitation of electrons and thus an increase

in thermal noise). Typical internal sources of noise are thermal noise, shot noise and flicker noise, while

external noise sources are atmospheric noise and man-made noise [131]. A large proportion of external

noise originates from sources such as televisions, radios, mobile phones or microwave ovens.

It is typically understood that a higher SNR means lower bit error rate, and therefore, it makes

it possible to increase the bit-rate, which consequently improves throughput. However, an important

issue of high density, multi-user networks such as current WiFi deployments, is that transmissions are

significantly affected by interference from neighboring transmissions. Although the underlying IEEE

802.11 MAC aims at scheduling one transmission per time slot to avoid concurrent transmissions (i.e.,

MAC-layer interference), outside the carrier sense range, PHY-layer interference will be created from

simultaneous transmissions. Thus, in low-density networks, transmission errors are typically due to

low SNR, which is referred to as noise-limited regime. On the other hand, in high density networks,

transmission errors are due to low signal to interference and noise ratio (SINR), also referred to as

interference limited regime [132]. As illustrated on the right part of the Figure 3.7, SINR is defined

as [130]:

SINR =received signal energy

noise energy +∑N

link=1 Interference(link)

In IEEE 802.11 networks, performance is well understood when transmissions are noise-limited, but in

the interference-limited case network performance is considerably less well understood.


10 20 30 40 50 60 70 80 90

-90

-85

-80

-75

-70

-65

-60

-55

-50

0

time t [s]

pow

er d

ensi

ty [d

B]

ReveiveSignalLevel

Noise floor

SNR(t)

Interference

SINR(t)

Figure 3.7: SNR and SINR

In order to detect and decode a desired signal, it is required that the receiver determines a signal

strength above the noise power level (i.e., the signal should have high SNR). To quantify this signal

strength as required by the IEEE 802.11 standard, the physical layer of all radio systems have to return a

Received Signal Strength Indicator (RSSI) to be used internally by the physical and data link layers [1].

The unit of RSSI is not specified in the standard and its implementation is vendor-specific. However,

generally, a lower RSSI value corresponds to a lower signal strength. In case of a fixed noise scenario,

this also indicates a lower SNR. The value range of RSSI may vary, where each vendor can define its

own maximum value ( up to 256 values). This way each vendor defines its own granularity based on the

mapping between a RSSI and corresponding signal strength [133].

RSSI measurement takes places during the preamble phase of an an 802.11 frame, or in other words

a RSSI measurement is taken within a 0.8 µs preamble duration. Considering a full frame can take up to

several milliseconds, this is clearly a limited estimate. On the other hand more accurate measurements

at the baseband may be done with the help of an analog circuit, which is not present in current wireless

802.11 hardware. Specifically, CMOS-based 802.11 hardware provides only an estimation of the power

of the thermal noise floor of the receiver, which is equal to the thermal noise floor at the antenna plus

the noise figure of the receiver’s analog front end [126]. In Atheros chipsets, RSSI is reported as the

offset from noise floor, which approximates the signal to noise ratio (SNR) of the signal. As stated in the

Atheros patent [126]: “For a given implementation at a constant temperature, the system gains will not

vary and the noise floor level is deterministic, so the absolute signal size of an incoming signal can be

Summary 45

computed directly from the relative computed RSSI value”. This is arguable, however, due to expected

temperature variability at different time scales (due to the effects from changes of seasons, night/day, cpu

load changing chip temperature). Furthermore, the true noise process is estimated by cyclic sampling,

which triggers an implementation-specific noise floor calibration. We present this process in more detail,

next.

Noise Floor Calibration: Noise calibration in the Atheros hardware is performed periodically by

measuring the minimum received in-band power, calculating a moving average and storing this value

in an Atheros hardware register. This value is used to calculate RSSI values per packet and therefore

affects all decisions that rely on the signal strength, noise level or both. Each time a noise calibration is

triggered, the hardware places the receive/transmit switch in an open position to ensure that any power

received at the antenna does not impact the calibration process. Hence, the noise calibration method

assumes that there exist inter-packet gaps between packet transmissions when no surrounding nodes send

packets. This assumption is necessary because during such a calibration, packet reception degrades and

weak signals may not be received nor processed. The whole noise floor calibration, which averages over

certain number of samples, takes less time than a SIFS duration. Since inter-packet gaps are unknown

in advance and may occur at unknown times, multiple noise floor measurements are taken within a time

window that is shorter than an inter-packet gap. However, it may not be possible to determine the true

noise floor when other continuous noise sources are present in the environment (i.e., no inter-packet

gaps). In this case, the calibration interval starts playing an important role and it becomes essential to

determine an interval which does not degrade packet reception and which provides reasonable noise

estimations.

3.3 Summary

In this section, we gave an overview of our testbed, and radio hardware, which play a significant role

in our tool development, experimentation, and performance evaluation. By combining multiple sources

of information with dedicated measurements we were able to understand the design, operation, and

limitations of our Atheros based WiFi hardware with respect to rate, power and carrier sense control.

For both of our WiFi cards deployed in BOWL, we analyzed the interaction between data rate and

transmit power. Our results validate that the maximum power level to send packets is a function of the

data rate. The next sections builds on the background information from chapter 3, and go into deeper

detail about how we monitor different radio functions. With this understanding, we develop a controller

for joint power and rate control.

Chapter 4

Wireless MAC and PHY LayerMonitoring

To design, analyze, evaluate and debug our controller, a deep and precise understanding of the radio

behavior under different conditions is required. In addition, it is crucial to be able to build correct

cause-and-effect chain. Therefore, measurement and monitoring systems play a vital role in our design.

In this section, we briefly discuss the state of the wireless measurement tools for monitoring wireless

MAC-layer parameters and their limitations. The main part of this section presents our new open-source

measurement tool RegMon, which significantly extends the PHY and MAC layer monitoring of Atheros-

based WiFi cards. We describe our implementation of RegMon for all tree major Linux device divers,

namely Madwifi [67], ath5k [134] and ath9k [135] and describe its monitoring capabilities and usage

instructions. We conclude this section with the validation and performance evaluation of RegMon.

4.1 Wireless Monitoring and its Limitations

In general, monitoring approaches can roughly be divided into active and passive solutions. Passive mon-

itoring approaches deploy monitoring nodes to complement main node deployment and, collect network

information, for example, packet traces. Passive monitoring is not intrusive and hence can be incremen-

tally deployed without interrupting ongoing data transmissions. While passive monitoring approaches

have been shown to be successful for troubleshooting [136, 137, 25, 138], they may lack precision due

to the following reasons: (1) hardware differences between the monitoring nodes and main nodes in

the deployed area (e.g., WiFi card, antenna specifications), (2) location of the monitor nodes not rep-

resenting the channel conditions experienced by the deployment nodes, (3) strict time synchronization

requirements to be able to correlate events (especially under heavy traffic conditions [139]). Addition-

ally, protocol information that can not be directly measured by the monitoring nodes, has to be inferred.

47

48 4. Wireless MAC and PHY Layer Monitoring

Such information includes vital statistics about noise floor, the radio busy times, or queue lengths. Thus,

the accuracy of passive monitoring is not typically sufficient to understand protocol behavior in detail.

In [140], we presented PaPMo, an active monitoring tool, which generates measurement packets and

captures snapshots of the protocol status as packets pass through the different layers and over distributed

nodes. PaPMo consists of 3 components: time synchronization via broadcast packets, in-kernel protocol

sniffers as part of Madwifi driver and TCP kernel module, and trace processing and merging in user

space. By merging and correlating the captured information, PaPMo is able to provide packet-level

network behavior accurately like in simulators. Specifically, PaPMo is able to correlate MAC-layer

events, such as packet loss due to queue overflow with TCP congestion control behavior at the accuracy

of microseconds. Nevertheless, being an active measurement tool, PaPMo is quite intrusive, affecting the

system under measurement and it requires a specific wired network set-up to guarantee the synchronized

time stamping of packets.

Dujovne et al [141] published a comprehensive taxonomy about measurable IEEE 802.11 wireless

parameters with available open source measurement tools, mostly for Linux. All of the 10 open source

measurement tools use information provided by APIs or libraries accessed from user-space. 9 out of 10

tools utilize packets or packet headers as information source, and only one tool, WaveMon, makes use of

the deprecated Linux Wireless Extensions (WEXt) and Wireless Tools (WT) to access aggregated driver

statistics. This implies that certain parameters, e.g., carrier sense, can only be estimated by combining

header information, which obviously requires packet reception. Lately, Rayanchu et al. developed two

monitor systems: Airshark [142] and WiFiNet [15]. Their objective is to detect, localize, and quantify

the interference from various non-WiFi interference sources using commodity Atheros 802.11n WiFi

hardware. To this end, they utilize the special spectral scan mode - which is a feature in Atheros chip

AR9280 and later, but is not yet documented or implemented in the open source Linux (ath9k) nor BSD

driver code base. This mode enables the reception and processing of raw FFT samples from the Atheros

PHY and could be of great use for understanding the benefits of having channel state information (CSI)

or at least for verifying certain PHY layer operations. Also Halperin et al. [119] use detailed PHY

layer measurements of CSI and effective SNR provided by a commodity 3x3 MiMo Intel 5300 802.11

abgn WiFi card. In contrast to Airshark and WiFiNet, this measurement tool, which enables the debug

mode of the Intel 5300 firmware, is made available to the public [143]. Nevertheless, open source

measurement tools that allow wireless MAC and PHY layer monitoring are rare and generally tailored

to specific hardware.

One of the well-known open source tools is Wprobe, released with OpenWrt Linux kernel package

in 2009 [144]. It provides a distributed way to monitor a set of PHY and MAC layer parameters from a

Madwifi-driven Atheros card and enables data collection via IPFIX [145] protocol. Wprobe monitors the

operation of Atheros Mac state-machine by periodic sampling of the relevant 32-bit hardware registers,

described in Section 3.2.1, and outputs the fraction of time the radio spent at each state (i.e., transmitting,

RegMon - Design, Implementation and Performance 49

receiving, busy or idle). It also provides SNR and noise statistics per wireless link. The maximum

sampling resolution of Wprobe is limited to 10 register samples per second (10Hz). In [95], we analyzed

and validated different carrier sense scenarios with our modified version of Wprobe, which provides

higher sampling rates up to 1000 Hz. However, as Wprobe monitoring worked only with Madwifi, we

decided to create a Atheros register monitoring tool that works on all drivers (i.e., Madwifi, ath5k, and

ath9k). In the next section, we present our Atheros-specific monitoring tool RegMon.

4.2 RegMon - Design, Implementation and Performance

RegMon is implemented as a single kernel driver patch for each of the supported three drivers, without

the need for additional modules, daemons or user-space applications. All main functions of RegMon

and their interactions are shown in Figure 4.1. These functions are explained in detail next.

4.2.1 In-Kernel MAC-Layer Monitoring

To perform the monitoring, we leverage the lightweight kernel-to-userspace debug file system called

debugfs (colored as the green line in Figure 4.1). This serves two purposes: (1) it enables a a simple

file-based configuration of RegMon for its in-kernel operations from the userspace and, (2) the actual

trace-file from the kernel can be accessed via standard file read (e.g., with tail, cat) from the userspace.

For the actual measurements, it is possible to access Atheros control and status registers stored in the

card memory through the PCI bus. Each of the Linux drivers (i.e., Madwifi, ath5k and ath9k) has

its own C functions or macros to access the memory-mapped 32-bit register content, as shown at the

bottom of Figure 4.1. The Linux kernel function readl() is called to read the current register value at

the memory address that was passed to it, respecting different host endianness and memory mapping

specifics [146]. For every register read, we store the current timestamp and the raw hexadecimal register

values. Each column, except the first one holding the current timestamp, represents a register address

specified through debugfs from the user-space. In our current implementation, we can monitor up to 11

registers in parallel. The main limiting factor for the number of registers is the memory footprint of the

data structure to hold these values in the kernel.

The in-kernel register sampling consists of three parts (in Figure 4.1, labeled as (1) in-kernel register

sampling):

i. Reading registers (read registers() ):

• The function getnstimeofday() is called to get current UNIX time in nanoseconds and store the

returned timestamp.

• Iterating through the register file list in debugfs, each register’s own memory address is used

to call the corresponding driver’s read register function and store the returned register content.


userspace

mac80211

ath5k

SoftMAC Linux drivers

ath5k_hw_reg_read( )

Atheros 802.11 b/g/a WiFi chips

ath9k

Atheros 802.11 nWiFi chips

non-mac802.11 FullMAC driver

RegMonRegMon RegMon

madwifi

OS_REG_READ( )REG_READ( )

debug filesystem per WiFi card

reg0 = 0x9321

reg9 = 0x8321 reg_interval = 10

cyclic readreg_trace file

specify register addresses

...

adjustsampling rate

...

time reg1 ... reg9

103 0x11 ... 0x44101 0x53 ... 0x79

105 0x61 ... 0x51

...

TCP/IP Stack kernelspace

packet traces

RegMon

WiFiinterface

(1) in-kernelregister

sampling

(2) user-spacedebugfssampling

PCI Bus

Figure 4.1: Kernel and User-Space Components of RegMon


• Reading sampling resolution via debugfs, a new timer to read registers is registered. The

reading of registers will be triggered via a kernel timer event. In the case jiffies event is used,

sampling rate is bounded by the kernel timer frequency (max 4000 Hz). In the case high

resolution timers are used, sampling rates of 20.000Hz and more are feasible.

ii. Assembling the userspace output is triggered when a read operation to debugfs file is requested

from the userspace. Then, all the new rows are written as formatted string into a debugfs log file.

iii. Initialization and de-initialization

• At device initialization, each WiFi interface creates its own debugfs RegMon folder and files.

• All data structures and initial timer event registrations are performed.

• At device de-initialization, all data structures are freed and all debugfs entries are removed.

Userspace debugfs sampling is shown as (2) in Figure 4.1. Here, by reading the debugfs log file, we

get access to the content of the desired registers. We store these values in a ring buffer between kernel

and user-space. This allows compensating for slower and possibly non-deterministic read cycles in the

user-space while the content of the array is constantly updated in-kernel. Our current implementation

uses 30000 rows, which was under all circumstances sufficiently large to support register reading rates

up to 30 kHz. The trace-file generated by RegMon is currently formatted as space separated list of

measurement values, which turned out to be a sufficient format to parse and process the trace file for

further analysis.

4.2.2 Calculating MAC states

Based on the statistics collected with RegMon, we are able to calculate the percentage of the time spent

in each MAC state during a given observation duration Tobs. Shown in Figure 4.2 is a simplified repre-

sentation of the three most important blocks associated with packet reception and carrier sensing. The

first two blocks address signal detection and are described in more details below. The third block is an

energy detection block parameterized by a threshold (thr62 on Figure 4.2). The output of these blocks

is a binary {0, 1} signal sampled at the specific clock rate of the system. There are four corresponding

32-bit hardware registers of profiling the MAC baseband interface:

• CYCLE counter reg(CLOCK) (cc) increases with the number of clock cycles at a given clock

speed.

• TX counter register reg(TX) counts the number of cycles the transmission unit is active.

• RX counter register reg(RX) is incremented only if any of the two signal detection block outputs

is positive.


„RegMon“in-kernelmonitorin

Figure 4.2: Simplified representation of the three most important blocks associated with packet receptionand carrier sensing. The first two blocks address signal detection and are described in more details in theAtheros patents. The third block is an energy detection block parameterized by a threshold. The outputof these blocks are periodically sampled to update three registers that allow to compute the distributionof the MAC state.

• BUSY counter reg(BUSY ) is the sum of the TX register value, the RX register value and the

sampled output of the energy detection block.

The clock speed of the WiFi card is a function of frequency band, channel bandwidth and the mode of

operation. At a typical 20MHz wide 802.11a channel (e.g., channel 165 - 5.528GHz) our Atheros chips

AR5212 and AR5413 use a system clock speed of 40MHz. On the other hand, the 20MHz wide 2.4GHZ

indoor channel has a clock speed of 44MHz. Depending on the monitoring and its sampling resolution,

the value of the four hardware registers can be sampled every Tobs seconds. Hence, we obtain the MAC

state distribution during an interval, which is Tobs seconds long, as follows:

SR =reg(R)[t]− reg(R)[t− Tobs]

reg(CLOCK)[t]− reg(CLOCK)[t− Tobs](4.1)

where t is an arbitrary sampling time, t − Tobs is the previous sampling time, reg(R)[t] is the value of

the register reg(R) at time t and R ∈ {RX,TX,BUSY }.In our work [95], we validated this state distribution calculation with dedicated experiments by

sending one 1470B packet from a sender to a receiver. Looking at the receiver’s MAC states showed the

expected increase in the register counters.

Limitations of periodic sampling: The maximal rate that the registers can be read through function

calls is determined by the timing limitations within the Linux kernel and the processing duration of the

function itself. Without going into all the details of the Linux timing capabilities and clock sources,

we briefly summarize the two approaches for triggering periodic register reading. Our first approach


is based on the mature Linux timer framework. Jiffies is the duration of one tick of the system timer

interrupt with a minimum duration defined by the frequency of the system ticks. The system frequency

can be specified in the Linux kernel build environment. Typical choices are 100 Hz, 250 Hz, or 1000

Hz, which lead to a maximal tick resolution of 10 ms, 4 ms, and 1 ms respectively. We were able to

successfully patch the kernel of our MIPS based Asus Router platform to a maximum of 4096Hz, which

represents the upper bound in sampling rate using jiffies.

In order to get higher sampling speed through more precise timer resolutions, we implemented a

second alternative based on the more recent high resolution timer subsystem (hr timers). High resolution

timers measure time at nanosecond-level resolution whereas standard Linux timers measure time at

millisecond-level resolution [146]. The usage of the hr timer subsystem depends on the hardware that

needs to provide sufficient precise clock sources, which our Asus WL-500gP router does. The changes

necessary to switch from using jiffies to hr timers were straightforward to implement, and did not include

any design changes. This way, we were able to increase the maximum sampling rate to 20.000 Hz.

Similar to any possible change to RegMon monitoring parameter, the sampling rate can also be changed

in an online fashion.

4.2.3 Validation and Performance

In this section, we validate basic functions of our RegMon implementation on different platforms and

drivers to ensure its correct operation and analyze its limitations. Specifically, we start with sampling

accuracy, the impact on cpu and network load, and execution time for register sampling.

Our validation experiments are performed on two different hardware platforms: (1) Asus WL-500gP

and (2) Ubiquity RouterStation pro (RSpro) both equipped with a Wistron CM9 Atheros 5212 WiFi

miniPCI card. Both platforms are driven by the same version of OpenWrt ‘Attitude Adjustment’ re-

vision 31101 using Linux kernel version 3.3. The Asus router platform is based on a Broadcom SoC

(BCM4704) MIPS with 264MHz, 32MB RAM, 1x miniPCI socket and Fast Ethernet. The RSpro is

more powerful compared to the Asus. It is based on an Atheros SoC (AR7161) MIPS 24K with 680MHz

CPU, 128MB RAM, 3x miniPCI sockets and Gigabit Ethernet. We use these two platforms to be able to

detect possible measurement limitations and errors within RegMon trace file generation and collection.

The performance of RegMon was evaluated by collecting trace files over Ethernet and not locally on

an USB stick. Note that the read/write performance of the ASUS USB interface would be much more

restricted compared to Ethernet.

In order to validate RegMon operation, we analyzed the following:

• Accuracy of sampling intervals: The distribution of error between specified sampling interval and

the measured interval

• CPU and network load: The impact of sampling interval to CPU and network load with and

without compression


• Register reading delay: The execution time of read registers()

• Packet reconstruction limitations: The limitations of reconstructing packet traces from Mac state

traces

Our validation is based on the following experiments. We connected Rspro directly to an IBM X200

Thinkpad laptop via an Ethernet cable and used it as a measurement sink. A customized bash script

running on the laptop triggered parameter changes on the router while we performed the following over

a duration of 60 seconds:

• RegMon trace file collection on the router and transfer via Ethernet to the laptop sink

• Cpusage [147] trace file collection on the router and transfer via Ethernet to the laptop sink

• Packet trace collection via tcpdump on the laptop

We repeated the same experiment with Asus.

Different sampling rates with and without on-line trace file compression were performed and ana-

lyzed. Based on the 22 Asus routers deployed across the BOWL network, the shortest possible interrupt

duration reported by the hr timer subsystem via dmesg output is 56 µs (equivalent to a sampling rate of

18 kHz). In case of the Ubiquity Routerstation PRO (RSpro), the hr timer subsystem reports a minimal

duration of 33 µs (equivalent to a sampling rate of 30 kHz). Based on these lower limits of the hr timer

subsystem, we choose sampling intervals starting from the lower bound of the given system up to 1000

µs in steps of 5 to 10 µs.

Accuracy of Sampling Intervals: To analyze the accuracy of specified sampling intervals, we used

our RegMon implementation based on the hr timer framework, which allows lower intervals to be set

compared to the jiffies implementation. In RegMon, we monitor two independent time sources: the

Linux system time and the TSF time based on the hardware clock within the Atheros WiFi card, both

with a granularity of 1 µs. In the optimal case, the measurement interval at which RegMon performs

periodic register readings should be of the same duration as the system time difference (or TSF time

difference) between two consecutive measurement records in RegMon trace file. As we described earlier

in 3.2.1, the TSF value is monitored through a register reading of the corresponding Atheros status

register and its value stored in the trace file along with the system time.

Figure 4.3 shows our first validation result based on RSpro router. The box whisker plot shows the

relation between the adjusted RegMon sampling interval in µs on the x-axis and the measured TSF time

difference (labeled as measured kernel interval) in µs between two successive register readings on the

y-axis. Each box-whisker summarizes the distribution of register readings, and in red points, we depict

the outliers that are more than 1.5 times the inter-quartile range away from the lower and upper quartiles.

The blue dashed line represents the optimal 1:1 linear relation between adjusted and measured interval.

Note that in our experiments, an interval of 200 µs between two measurements corresponds to a sampling

rate of 5000 Hz and therefore about 300000 samples are taken within those 60 seconds. Therefore, the


●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●●

●

●●●●●●●●●●●●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●●

●

●●●●●●●

●●●●●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●

●●●●●●●●●

●

●●●

●●●

●

●

●●●●●

●

●

●

●

●

●

●

●

●

●

●

●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●●●●●●●●

●●●●

●●●●●●

●●●●

●●●

●●

●

●●

●●

●

●

●

●

●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●●●●●●●●●●●●

●●●●●●●●●●●●●●●

●

●●

●

●

●

●

●

●

●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●●●●

●●●●

●●●●

●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●●●

●●●●

●

●

●●●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●●

●●●

●●●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●

●●●●

●●●●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●

●●●●

●

●●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●

●●●●

●

●●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●

●●●●●

●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●

●●

●

●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●

●●●●

●●●●●●●●●●●●●●●●

●●●●●●●●●●●●

●●●

●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●

●●●●

●●●●●●●●●●●

●●●●●●●●●●●●●●●●●

●●●●

●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●

●●●

●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●

●●

●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●●●

●●●

●●●●●●●●●●●●●●

●●●●●●●●●

●●

●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●

●●●

●●●●●●●●●●

●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●

●

●●●●●●●●●●

●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●●

●

●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●

●●●●●●●

●●

●●●●●●●●●●●

●●●●●●●●●●●●●●●●●

●●●

●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●●●

●●●

●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●●

●●●●●●●●

●

●●●●●●●●●●

●●●●●●●●●●●●●●●●●

●●●●

●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●

●●

●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●

●●●●●●●●●●

●●

●●●●●●●●●●●

●●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●●●●

●●●●●●●●●●

●

●●●●●●●●●

●●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●●●

●●●●●●●●●●

●

●●●●●●●●●●

●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●●●

●●●●●●●●

●●●●

●●●●●●●●●

●●●●●●●●●●●●●●

●

●●●●●●●●●●●●

●●●●●●●

●

●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●●●

●●●●●●●●●●

●

●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●

●●●●●●●●

●●

●●●●●●

●●●●●●●●●●●●

●

●●●●●●●●●

●●●●●●●

●

●●●●●●

●●●●●●●●●●●

●

●●●●●●●●●●

●●●●●●

●

●●●●●●●●●●

●●●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●

●●

●●●●●●●●●

●●●●●●●●●●●●

●

●●●●●●●●●●●

●●●●●●●

●

●●●●●●●●●●

●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●

●●●●●●●●●

●

●●●●●●●●

●●●●●●●●●●●●

●

●●●●●●●●

●●●●●●

●●

●●●●●●●

●●●●●●●●●●●●●●

●●●

●●●●●●●●●●●●

●●●●●●●

●●

●●●●●●●

●●●●●●●●●●●●

●●

●●●●●●●●●●●

●●●●●●●

●

●●●●●●●●●●

●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●●●

●●●●●●●●●

●

●●●●●

●●●●●●●●

●●

●●●●●●●●

●●●●●

●

●●●●●

●●●●●●●●●●●●

●

●●●●●●●●●●

●●●●●●●

●

●●●●●

●●●●●●●●

●

●●●●●●●●●●●

●●●●●

●

●●●●●●

●●●●●●●●●●●●●

●●

●●●●●●●

●●●●●●●●●●

●

●●●●●●●

●●●●

●

●●●●●●●●●●

●●●●

●

●●●●●●●

●●●●●●●●●●●●●●

●

●●●●●●●

●●●●

●

●●●●●●●●●

●●●●●●●●●●●●●

●

●●●●●●●●●●●

●●●●●●●●

●

●●●●●●●

●●●●●●●●

●

●●●●●●●●●●

●●●●●●●●●●●●●●

●

●●●●●●●●●●●

●●●●●●●●

●

●●●●●●●●

●●●●●●●

●

●●●●●

●●●●●●●●●

●

●●●●●●●●●●●●●

●●●●●●●

●

●●●●●●●●

●●●●●●●●●●●●●

●

●●●●●●●●●●

●●●●●

●

●●●●●

●●●●●●●●●●

●

●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●

●

●●●●●●●●

●●●●●●

●

●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

10

50

100

250

500

1000

2000

10 25 50 100 250 500 1000adjusted Interval [us]

mea

sued

ker

nel i

nter

val [

us]

Figure 4.3: Adjusted vs. measured interval duration based on TSF and 30,000 lines ring buffer size.

30

40

5060

80

100120

150

200

300

500

700

1000

30 40 50 60 80 100 120 150 200 300 500 700 1000adjusted Interval [us]

mea

sued

tsf i

nter

val [

us]

AsusRS-pro

Figure 4.4: Adjusted vs. measured interval duration based on TSF and 30.000 lines ring buffer size.

ring buffer which is filled in the kernel, and read by the user space need to be of appropriate size to

store all values, i.e., 30000 rows. Regarding the sampling accuracy, the results shows a high accuracy

between the adjusted measurement interval in RegMon compared to the measured interval between two

TSF timestamps from 1000 µs down to 50 µs (i.e., a sampling rate from 1000Hz up to 20 kHz). Intervals

below 45 µs lead to significant outliers, hence indicate decreasing accuracy below this duration on the

RSpro. Figure 4.3 displays regular outliers that are exactly twice the adjusted interval. Those measured

intervals appear with a relative frequency below 0.05 % out of all measurements and with a predictable

size of twice the interval, which makes it feasible to account for them.

Figure 4.4 compares the accuracy of Asus and RSpro hardware platforms in terms of of the measured

interval durations with respect to the adjusted intervals of both routers. To plot each line, we used

a smoothing method based on the standard estimator ‘generalized additive model’ (GAM). The grey

dotted line represents the perfect linear fitting between adjusted and measured intervals. As we saw


COMPRESSION=OFF COMPRESSION=ON

0.1

0.5

1.0

2.0

4.0

10.0

20.0

35.0

45 65 100 150 200 300 500 700 1000 45 65 100 150 200 300 500 700 1000adjusted Interval [us]

mea

sued

ban

dwid

th [M

Bit/s

]

Figure 4.5: Adjusted interval vs. measurement bandwidth with and without data compression.

in the the box-whisker plot, a good sampling accuracy using the RSpro router is achieved for sampling

intervals higher than 50 µs. In contrast to the RSpro, for the Asus router the lower limit is approximately

120 µs corresponding to a sampling rate of 8333 Hz. We expect the reason for lesser performance to be

the slower overall CPU and bus system of the Asus router.

Network and CPU Load: The monitoring of BOWL nodes is constrained by the available network

bandwidth through the university intranet, upper bounded by the Fast Ethernet ports of the nodes. Fur-

thermore, monitoring traffic may interfere with non-measurement related traffic. Therefore, it is useful to

analyze methods reducing the amount of measurement traffic. To this end, in addition to the collection of

raw measurements, we have run a second trial using Lempel-Ziv-Oberhumer compression (LZO) [148]

to compress the measurement data on the node before sending them over the Ethernet. LZO based com-

pression is known to be performant in terms of processing costs even on embedded router platforms

while producing moderate compression ratios compared to other algorithms (e.g., LZMA).

For these measurements, we used the ath5k implementation of RegMon, which performs 12 con-

secutive register readings and an additional 64 Bit system timestamp per sample step. Figure 4.5 shows

the required bandwidth as we increase the sampling interval using the RSpro router 1 with and without

LZO compression in MBit per second. The plot is in log-log scale. The left plot shows a peak band-

width requirement of approximately 35 MBit/s when RegMon sampling interval is 50 µs, respectively

20 kHz. The right plot shows the bandwidth reduction when the LZO compression is used with the

lowest compression level (i.e., utility ‘LZOP -1’ is used). At 20KHz, the bandwidth requirement drops

to 10 MBit/s, hence a reduction of more than 200% in bandwidth is achieved.

Figure 4.6 shows the CPU utilization of both RSpro and Asus with and without the lowest LZO

1The amount of required peak bandwidth is similar for RSpro and Asus.


0%

25%

50%

75%

100%

0%

25%

50%

75%

100%

CO

MPR

ESSION

=OFF

CO

MPR

ESSION

=ON

0 50 100 150 200 250 300 350 400 450 500adjusted Interval [us]

mea

sued

cpu

load

loadUserspaceSystemSoftIRQIDLE

0%

25%

50%

75%

100%

0%

25%

50%

75%

100%

CO

MPR

ESSION

=OFF

CO

MPR

ESSION

=ON

0 50 100 150 200 250 300 350 400 450 500adjusted Interval [us]

mea

sued

cpu

load

loadUserspaceSystemSoftIRQIDLE

RS-pro Asus

Figure 4.6: Comparison between Asus and RSpro routers in terms of adjusted vs. measured intervalbased accuracy on a log-log scale.

compression as a function of the adjusted sampling interval. In order to measure RegMon’s impact on

the overall system performance, we monitored the CPU usage with the Linux tool ‘cpusage’ [147] once

every second for all validation experiments. The measured load covers all the processing required by

RegMon sampling: the in-kernel sampling, debugfs read file operations in user-space and transferring

measurement data via netcat over Ethernet to the measurement sink. The load levels are divided in

the typical shares: user-space, system, SoftIRQ and IDLE. In the case that RegMon trace file is not

read from user-space, we are not able to observe any quantifiable change in system load with sampling

interval. On both platforms LZOP does not change the overall sum system load compared to the IDLE

states, but their mixture changes especially at small sampling intervals as LZO compression is done as a

user-space process.

From our validation plots of sampling accuracy, system and network loads, we conclude that the

maximum sampling rate that produces meaningful results depends on the router hardware. In case of

RSpro, for up to 20kHz sampling rates, the overall system load is at most 30%. On the other hand, the

Asus router maintains 30% total system load with sampling rates up to 150 µs, i.e., 6700 Hz. For both

hardware platforms, LZO compression leads to similar CPU load performance or acceptable increases

in load, whereas it helps reducing bandwidth requirements.

Register Reading Delay: As we described in Chapter 3, the MAC state registers change with the

clock speed of the Atheros WiFi card, and typically, with 40 MHz in 802.11a or 44 MHz at 802.11g

20MHz channels. As RegMon is one order of magnitude slower in terms of sampling these MAC state

registers, we investigate the processing delays added by register readings to quantify the measurement

error. Before the MAC state registers are read, a specific MIB (Management Information Base) register

write operation is required in order to freeze the MAC-state register content until the read operation

finished and the MIB is unlocked by a second write operation. This lock before read mechanism is

necessary for all Atheros drivers: Madwifi, ath5k and ath9k.

To quantify the duration of RegMon MAC-state register reading, we measure the execution duration


ACK receiver

sender

ACK

Data Data

preamble + signal24 µs

16 µs SIFS

16 µs SIFS20 µstime

shortest interval

Figure 4.7: 802.11a MAC frame and ack sequence in the case of packet bursts or fragmentation.

by comparing the TSF timestamp before and after the actual register reading takes place. A full cycle,

which includes freezing all MAC-state registers, reading each of the four registers and unfreezing them,

takes approximately 7 µs in all of our measurements and, across all drivers and also with both Asus and

RSpro hardware. As TSF is measured with an accuracy of 1 µs, the absolute error of a full read cycle

of all four MAC-state registers is 7 ± 1 µs. The impact of this error depends on the sampling interval

used, e.g., if MAC-state registers are sampled at 20kHz, which corresponds to a sampling interval of 50

µs, this translates to a relative error of 16%. However, most of our power control experiments need a

RegMon sampling speed of at most 1000Hz, which introduces a relative error of about 0.9 %.

Packet Reconstruction Limitations: Based on router capabilities, RegMon MAC-layer monitoring

can achieve a sampling rate of 20kHz, for instance in the case of our RSpro. Based on the Nyquist

sampling theorem [149] this resolution time is sufficient to perfectly reconstruct any packet process

with frequency lower than or equal to 10kHz, i.e., with duration shorter than or equal to 100 µs. The

minimum time between two frame transmissions in IEEE 802.11a occurs during a packet burst, when

fragmented packets are sent back to back. The Inter Frame Spacing (IFS) between these packets is a

SIFS duration, which is 16 µs (note that no back-off takes place during a packet burst). Such a packet

sequence is sketched in Figure 4.7 as an example. The shortest interval corresponds to the time between

two fragmented data packets plus the duration of the actual data part, determined by the packet length

in bytes (B) and the modulation. The minimum time interval between two frames is two SIFS intervals

plus ACK duration, which is 56µs. The smallest packet size defined in RFC 894 is 64 B, which will lead

to a transmission duration at the highest 802.11a modulation of 54 MBps of 16 µs (i.e., four symbols,

4 µs each, are needed to encode 64 B data + 36 B SNAT header). This frame is preceded by a 20µs

preamble. To sum, the worst case packet interval is as short as 92 µs (56+16+20) or about 10.9 kHz for

fragmented 802.11a packets. In order to allow a perfect packet process reconstruction, RegMon should

at least sample with about 21.7 kHz or 46 µs sampling interval. This is not feasible with the Asus router,

and in the case of the RSpro platform, such a high sampling rate can still be performed but the point of

operation is a bit below our 20kHz recommendation.


0%

25%

50%

75%

100%

0 1 2 3 4 5 6 7 8Time [ms]

rela

tive

dwel

l tim

e [%

]

MACstates

tx−busyrx−busyothersidle

tx−states of 1440 Byte UDP packets at 802.11a 6MBit datarate

0%

25%

50%

75%

100%

0 1 2 3 4 5 6 7 8Time [ms]

rela

tive

dwel

l tim

e [%

]

MACstates


tx−states of 180 Byte UDP packets at 802.11a 54MBit datarate

Figure 4.8: Zoomed MAC-states view of IEEE 802.11a broadcast packets at the sender.

0%

25%

50%

75%

100%

0 1 2 3 4 5 6 7 8Time [ms]

rela

tive

dwel

l tim

e [%

]

MACstates


rx−states of 1440 Byte UDP packets at 802.11a 6MBit datarate

0%

25%

50%

75%

100%

0 1 2 3 4 5 6 7 8Time [ms]

rela

tive

dwel

l tim

e [%

]

MACstates


rx−states of 180 Byte UDP packets at 802.11a 54MBit datarate

Figure 4.9: Zoomed MAC-states view of IEEE 802.11a broadcast packets at the receiver.

The Figures 4.8 and 4.9 show RegMon MAC-state monitoring at the sender and at the receiver side,

respectively, for two different broadcast scenarios in 802.11a using 20kHz resolution. While the left

graph in Figure 4.8 shows a 1440 Byte UDP packet sent at a data-rate of 6 MBps, the right graph shows

a 180 Byte UDP packet sent at a data-rate of 54Mbps. Our experiences from BOWL testbed show that

packet rates beyond 1400 packets per second lead to high packet loss while trying to capture them in

802.11 monitoring mode. In case of the scenario in Figure 4.9 where we send small 180Byte packets

back to back as 802.11a broadcast packets, the packet trace we took in parallel only received 10% out of

the 120.000 packets we sent. In contrast, sampling with RegMon with a rate of 20kHz, through a simple

estimation of packet boundaries by just counting inter packet gaps, we see from the figures that it is

possible to delineate the 120.000 packets. As expected the longer packets with slower rates put the card

in the transmission mode (respectively on the receiver side, in receive mode) longer and the packets and

intervals between packets are clearly visible. Nevertheless, for shorter packets that are sent and received

at faster rates, we can also identify when packets were sent. We therefore believe that RegMon, with its

monitoring capabilities, is of high interest and value to systems researchers 2.

Limitations of RegMon: As our results clearly show, the underlying hardware platform is the domi-

nant factor that impacts the maximum sampling rate of RegMon. Furthermore, the maximum sampling

2Usage instructions and source code of all RegMon variants are provided as Open Source at our departments webpage.


rate is limited by the number of wireless cards in a router that are monitored with RegMon. The 20kHz

sampling rate limit at the RSpro platform is an upper bound on the entire PCI bus meaning that the sum

of RegMon sampling rates for multiple WiFi cards can not exceed this sampling limit. Measurements

on newer WiFi cards that use PCI-express bus interfaces to connect to the host platform are left as future

work.

The presented RegMon tool does not perform any processing nor parsing of measurement data in

kernel. Its design is focused on fast register readings. But it might be feasible and also an interesting

path for future development to extend the online data processing that can, e.g., calculate statistics on mac

states. It should also be noted that the current RegMon design uses the same sampling rate for all register

readings. We expect it feasible to extend the current monitoring to individually assigned sampling rates

per register reading.

4.3 Summary

In this chapter, we presented the design, validation and performance of our Atheros specific monitoring

tool RegMon. RegMon enables sampling and analysis of hardware registers with high accuracy. It’s

sampling rate can be set up to 20 kHz depending on the measurement hardware. RegMon is implemented

and validated for all three major drivers of Atheros WiFi cards, namely Madwifi, ath5k and ath9k and

two alternative sampling methods based on Linux jiffies and hr timer. Our measurement tool enables

wireless researchers to access new information sources and is part of the default monitoring setup of the

BOWL network. It proved to be an accurate and reliable source for MAC and PHY layer measurements,

which were used in several research works [150, 151, 152, 153, 95]. In this thesis, RegMon is used

to carry out MAC layer measurements to develop, troubleshoot and analyse our joint rate and power

controller Minstrel-Blues, presented in the next chapter.

Chapter 5

Development of a Joint Power-RateController

In this chapter, we present the design of our power and rate controller, describe our implementation,

and discuss our validation and performance evaluation results. According to [43], a practical controller

should be:

• Distributed: To allow autonomous execution with minimal (if any) network communication re-

sources for control signals.

• Simple: To enable real time implementation with low computational overhead.

• Robust: To be able to adapt to diverse and uncertain inputs.

• Agile: For fast tracking of channel changes and node mobility.

• Scalable: To maintain high performance at networks of various sizes.

To support distributed operation, we propose a simple controller, which relies on local collection of

frame error statistics. This makes our controller scalable. To provide robust operation, the controller

does not react to random fluctuations, but to only the average trends reflecting the channel changes.

To this end, the controller updates power and rate at a timescale significantly larger than transmission

time (e.g., while periodic rate updates occur at each 100 ms, periodic power updates are performed at

slower or equal rates). To achieve agile operation, we check for conditions such as significant drops in

throughput during periodic rate updates and react with power adaptation. However, we do not consider

changes due to fast fading (e.g., mobility faster than walking speed).

Our controller builds on the new interface we introduce, which enables direct communication be-

tween IEEE 802.11 MAC and PHY layer to exchange information about transmit power levels. As

we want to implement a joint power and rate controller for current WiFi devices, we need the ability to

change and add new functionality to the operating system, more precisely, at the network stack and hard-

ware driver level. Given this constraint, Linux and BSD are our best choices. In this thesis our design and

61

62 5. Development of a Joint Power-Rate Controller

implementation will follow the Linux kernel. First we present the design of a cross-layer interface for

the Linux kernel, and propose our joint power and rate control algorithm, Minstrel-Blues, which takes

advantage of this new interface. We conclude with a performance evaluation to show Minstrel-Blues

operation under various settings, and environmental and network conditions.

5.1 Design and Implementation of a Cross-Layer Power-Rate ControlInterface

The implementation of IEEE 802.11 MAC layer typically uses a combination of dedicated hardware and

software [81]. Today, there exist two common designs for splitting the 802.11 MAC into two parts. On

the one hand, WiFi chip designers like Broadcom and Intel support on-chip micro-controllers, where part

of the time-critical code execution happens in firmware, and others are transferred to the host system.

On the other hand, Atheros 802.11 agn miniPCI and miniPCIe chips (besides the USB-based chips) do

not have a general firmware-driven micro-controller, but rather map certain functionalities directly onto

their hardware design. The exact architecture of the MAC layer, i.e., how much of its functionality is

implemented in hardware or in software, depends on the device itself, the device driver and the operating

system (OS) in use.

Historically IEEE 802.11 MAC implementations started as so-called FullMAC schemes, where con-

trol of MAC layer functions is mapped to the individual WiFi hardware or specific firmware or both.

FullMac designs can involve a firmware to be loaded into the chipset memory, e.g., Atheros 802.11n

USB WiFi sticks based on ath6kl [154]. However, due to the difficulty of developing and maintaining

the code for these FullMAC devices, in recent years, software implementations (i.e., SoftMAC) have

emerged. Now, a set of primitives such as authentication, association, beaconing, and functions such as

rate control are implemented at the OS level. For instance, SoftMAC design allows abstract rate control

algorithms to be used across multiple WiFi hardware from different vendors. In this section, we first give

an overview of Linux MAC 802.11 framework, which has SoftMAC capabilities, and next, describe the

extensions we have implemented to support per-packet transmit power and rate control.

5.1.1 Linux mac80211 framework

The Linux mac80211 subsystem provides different SoftMAC capabilities within the kernel [155]. The

main tasks of mac80211 are: (1) to translate between data frame protocols along the receiving (rx) path

(from the driver upwards) and along the transmitting (tx) path (from upper layers downwards), (2) to

control IEEE 802.11 management operations and (3) to provide an interface to perform per packet rate

adaptation. It supports different IEEE 802.11 standards (e.g., abgn), different interface modes (e.g.,

access point, station, ad hoc) and also certain QoS extensions such as 802.11e. An overview of the

current blocks of the Linux IEEE 802.11 part is depicted in Figure 5.1.

Design and Implementation of a Cross-Layer Power-Rate Control Interface 63

cfg80211

user space

mac80211

Atherosath5k

Atherosath9k

...

Protocoldriver

Hardwaredriver

Applications

netlink (nl80211)

cfg80211_ops

Broadcomb43

Inteliwlwifi

SoftMAC driversIEEE80211_ops

Atherosmadwifi

non-mac802.11driver

(old FullMAC )

cfg80211_

mac80211_config_ops

wext

wex

t_co

mpa

t

rate_control_opsRate

Control

legacy system

• MLME• Encryption• Rate Control• Radio Regulations

•AcessPoint-MLME•Encryption

IEEE80211_ops

IEEE80211_ops

ieee80211_ops ieee80211_

Figure 5.1: The relevant subsystems of Linux that enable joint control of rate and power starting fromthe MAC layer towards a specific driver


The figure also shows the deprecated interaction flow between FullMAC wireless drivers and the

Linux user space (see the area labeled as legacy system in Figure 5.1). This interaction was handled

by the Wireless Extensions, wext, which was a traditional configuration API (Application Programming

Interface) based on ioctl system calls. For detailed information about the design decisions and short-

comings of wext, we refer the reader to [156]. The Atheros-based madwifi driver is a very famous

representative of a FullMAC wireless driver using wext. Like every FullMAC driver, it comes with its

own 80211 stack and a limited set of specific MAC functionalities, e.g., encryption, rate control, access

point/station/ad hoc mode management.

The Linux 802.11 stack since the version 2.6.22 is shown on the left side of the Figure 5.1, where

wext gets replaced by its successors: cfg80211 and mac80211 as discrete kernel modules. In this new

design, starting from the top with user space, there are three functional blocks that are interconnected:

cfg80211 as control and configuration interface [157], mac80211 as Linux based SoftMAC realization

of a protocol driver and SoftMAC-enabled device drivers to drive 802.11 hardware from different ven-

dors. For instance, the SoftMAC-enabled driver for Atheros 802.11abg hardware is called ath5k. The

cfg80211 interacts with the mac80211 module by registering callbacks (i.e., function pointers), while

mac80211 exports cfg80211 functions to the cfg80211 module [154]. The main goal in this design is to

reuse certain 802.11 MAC layer functions across different drivers, including support for cryptography,

power saving schemes, frame aggregation through SoftMAC running on the host CPU. At the driver

and/or firmware level, this design allows using significantly reduced set of functions and therefore, re-

duced memory footprint [156] .

Most of the current mac80211 drivers do not implement their own rate controller but rather select

one of those provided by the framework. Current rate control implementations are MINSTREL, MIN-

STREL HT and PID, as we described in Chapter 2. The communication between the mac80211 module

and individual SoftMAC-enabled hardware drivers consists of driver methods (ieee80211 ops callbacks)

and, exported and mac80211 functions for reception (rx) and transmission (tx). On the tx path, a packet

is handed from the mac80211 to the driver, necessary buffers are initialized and the packet is mapped

to specified hardware queues. Transmit flags are assigned depending on the packet type, physical layer

parameters and control information (e.g., whether the frame is a data, beacon, rate control sampling

frame etc.). The packets are handed over to the hardware through Direct Memory Access (DMA) and

a transmit interrupt initiates the frame transfer and checks the status for reporting and retry tasks [157].

On the rx path, the hardware generates receive interrupts, which call the driver specific rx functions to

fetch the packet and transfer it top the mac80211 protocol stack with additional status information (i.e.

tx info about rate and retry status). In the next subsection, we describe the necessary restructuring of

mac80211 framework to extend these per-packet annotations to realize transmit power control.

Design and Implementation of a Cross-Layer Power-Rate Control Interface 65

5.1.2 Extending mac80211 for TPC

To control the per-packet rate levels, the Linux kernel uses a control structure (in addition to the packet

buffer), which carries the rate and retry annotations of a given data packet on its way to the driver for

transmission (tx-path). We extended this control structure to support power annotations at the MAC

layer. On receiving the control structure, the driver, in our case, the Atheros device driver, forms a tx-

descriptor that represents the rate and power settings to be used by the WiFi hardware. After a packet is

sent, this structure is overwritten with the status annotation (tx-info), which contains at which rate and

after how many retries the packet succeeded (if at all).

Our implementation can be logically divided into the following parts:

1) Restructuring in order to free up the necessary space and add tx info to support transmit power level

annotation.

This enables a per-packet annotation of one power level (dBm) per multi-rate-retry stage.

2) Introduction of TPC hardware capability flags.

Based on these flags, the driver specifies its different transmit power control capabilities.

• IEEE80211 TPC NONE: This is the default operation, where TPC is not supported and there

is a single fixed transmit power setting.

• IEEE80211 TPC PER DATA PACKET: In this case, power levels are set per-packet. Note that

in this case, the retries are also sent with the same power.

• IEEE80211 TPC PER DATA MRR: Multiple power levels per multi-rate-retry stage are sup-

ported. This works similar to the multi-rate retry.

• IEEE80211 TPC ACK POWER GLOBAL: In this case, a single power level for ACK packets

is set.

3) Add support to change power-level of acknowledgement packets.

A global power level to be used in ACK packets extends the hardware configuration structure. When-

ever a change in ACK power occurs (i.e., through a user space configuration call), MAC sets the new

configuration flag IEEE80211 CONF CHANGE ACK POWER to signal a change to the driver. For

the ACK power to take effect, the driver registers a callback function with this flag, which reads the

new ACK power from the hardware configuration flags.

4) Adapt the source code in the sending path (tx-path) of all effected drivers.

TPC support is added to mac80211 by restructuring of struct ieee80211 tx info. Therefore the tx-

path of all effected drivers is modified to respect the new tx info structure. Linux wireless drivers that

we needed to modify were: ath9k, ath5k, iwl3954, iwl4965, iwl-agn, mwl8k, carl9170, ath9k-htc,

p54, rt2x00, rtl8180, rtl8087, hwsim, b43, b43legacy, brcmsmac and zd1211rw.

As a side effect of our implementation efforts, we also fixed several driver bugs, including race condi-

tions and pointer referencing issues. This mac80211 restructuring implementation is already accepted

in Linux kernel tree (since 31.07.2012). In the next sub-section we leverage our mac80211 extension to


modulation rate (IEEE 802.11 a)

throughput[MBit/sec]

success probability

number of attempts

number of successes

6 4 99 % 0 0

9 5,5 90 % 0 0

12 6 70 % 0 0

18 11 80 % 1 1

24 12 65 % 4 4

36 4 20 % 1 1

48 1,5 5 % 1 0

54 0 0 % 0 0

∑

Minstrel component: update statistics

36MBit

90%unicast

broad- & m

ulticast

10%

24MBit

24MBit

18MBit

24MBit

48MBit

24MBit

ACKACK ACK ACK ACKACK

∑

Calculate exponential weighted moving average (EWMA) ofsuccess probability.

ACK

compute

senderdata

receiver

Figure 5.2: The statistics update is part of Minstrels rate control. To calculate per-rate success proba-bilities, Minstrel collects statistics from all packet transmission attempts. It also uses 10% of the datapackets as sampling packets to try random rates.

implement a joint power and rate controller.

5.2 Joint Power and Rate Control Algorithm: MINSTREL-BLUES

In this section, we present our controller solution that brings together the Minstrel rate control algorithm

and our power control algorithm. To control the transmission rate per-packet, the data-rate and retry an-

notations on the tx-path are performed by Minstrel. This algorithm is explained in detail in Section 5.2.2

and its operation is illustrated in Fig 5.2 summarizing the operation of Minstrel. In addition, we propose

the Blues algorithm to perform per-packet power control. In this section, we first present our validation

of power-rate relationship, which forms the foundation of our algorithms. Next, we present the Blues

algorithm, which enables a trade-off between achievable throughput and spatial reuse. Specifically, this

trade-off allows us to select lower transmission powers, which improves spatial-reuse but may degrade

throughput, which is controlled by using a throughput utility function. For performance evaluation, we

first present detailed validation and performance results on a specific case of Blues, which maintains

throughput equal to the one achieved at maximum power level. This version of Minstrel-Blues is called

Minstrel-Piano. We conclude with results of Minstrel-Blues in our indoor network at 5GHz, and in a

home network with two laptops and one access-point at 2.4GHz.

Joint Power and Rate Control Algorithm: MINSTREL-BLUES 67

(a) Measured SNR at the receiver for different tx powerlevels and two carrier sense settings: (1) Energy andpreamble detector (2) only energy detector.

(b) Measured throughput per rate for different tx powerlevels and two carrier sense settings: with (1) energy andpreamble detector and (2) only energy detector.

Figure 5.3: Measurement results of the relationsship between adjusted tx-power and (a) received SNRand (b) throughput per rate

5.2.1 Validating Power-Rate and Throughput Relationships

We first try to understand the relationship between the Atheros power settings and the set of rates sup-

ported by the IEEE 802.11 standard through measurements. To serve as a baseline, we ran experiments

on a single link (i.e., with one sender and one receiver). Figure 5.3(a) presents the SNR at the receiver

for different transmit power settings for rates 6 − 24 Mbps from one link in our 5 GHz outdoor WiFi

network [109]. Figure 5.3(b) shows the throughput measurement results. For this example, we used 2

different carrier sense settings: (1) with energy and preamble detection and (2) only with energy detec-

tion [1]. Figure 5.3(a) shows that SNR at the receiver increases linearly with increasing power. Note

that the higher SNR does not necessarily mean higher throughput. In Figure 5.3(b) , when the rates

6 − 18 Mbps are chosen, the transmission power can be reduced to 1 dBm with (1), and to ≈ 16 dBm

with (2) without affecting the throughput. For 24 Mbps, these power levels are 3 dBm and 16 dBm, re-

spectively. The figure also shows that this link cannot support rates higher than 24 Mbps. These results

confirm that throughput is a non-decreasing function of transmission power, and that it is possible to

maintain the same throughput at lower power levels. We design our controller based on these principles.

The objective of Blues is to reduce the power level of each packet close to the power level where the

throughput starts to decrease as shown in Figure 5.3(b).

5.2.2 Design Properties and Functionality

Figure 5.4 presents the sending and receiving path of Minstrel-Blues from Linux mac80211 subsystem

through the ath5k driver and finally the Atheros hardware. The joint rate and power decision of Minstrel-

Blues is annotated at the MAC layer and translated to the Atheros specific power annotation through its

tx-descriptor format within the ath5k driver. Our implementation allows also a user to manually adjust


Minstrel-Blues

mac80211

SoftMACdrivers (ath5k)

txpath

ieee80211_ops.tx

statistics

look-upupdate

rxpath

compose tx-controldescriptor

processrx-status

descriptor

Atheros WiFi chip

hardware

PCI/PCIe via dma access

tx

rxack

per neighbor

data

data

sk_buff

sk_buff->cb48-Byte

data

fill sk_buff->cb withieee80211_tx_info->tx-status

•rates[4]• vif• hw_keys

fill sk_buff->cb withieee80211_tx_info->control

rxdata

failed

failedfailed

ok

Beacons

fail

failfail o

•rate•retry•power

Figure 5.4: Minstrel-Blues’s tx- and rx-path between mac80211 subsystem, ath5k driver and Atheroshardware.

a static power level and or a static data-rate via Linux debug file system (debugfs). This enables flexible

experimentation with different constants and variables.

To decide at which power level to operate, Blues uses 3 types of packets:

• Reference packets, which are sent at a reference power (typically a high power level).

• Sample packets, which are sent for power-level exploration of different power levels.

• Data packets, which are sent at a power level equal to sample power level plus a constant, ∆

(∆ = 2 dB in our experiments).

By sending packets at different power levels, Blues aims to understand the impact of transmission power

changes on packet success probability. Using these three different types of packets, the algorithm oper-

ates in two parts: (1) It records number of successes and attempts obtained from the transmission feed-

back (see COLLECT STATS in Minstrel-Blues pseudocode depicted in Fig. 5.5), and (2) if enough packets

are sampled for a given rate (determined by the min update parameter), an update mechanism adjusts


the power levels for each type of packet (i.e., P ref [R], P sample[R] and P data[R] in Fig. 5.5) based

on this history of attempts and successes (see BLUES UPDATE STATS in Fig. 5.5).

To make these adjustments, similar to Minstrel, Blues also maintains an EWMA of reference, sam-

ple, and data success probabilities, which are denoted as prefsuccess[R], psamplesuccess[R], pdatasuccess[R], respec-

tively. At initialization, Blues starts from the maximum power level. As time goes, Blues determines

a power-level in dBm for each data-rate, that complies with the specified success probabilities. The

main idea of the update mechanism is to keep the sample and reference success probabilities close (see

BLUES UPDATE STATS, comment (1) in Fig. 5.5). Therefore, the sample power is incremented if psamplesuccess[R]

is below prefsuccess[R] by a δinc threshold. The power increment is given as ∆inc and the maximum power

level that can be set is Pmax. On the other hand, Blues reduces the sample power, if pdatasuccess[R] is higher

than prefsuccess[R] minus a δdec threshold. The power decrement is denoted as ∆dec and the minimum

power level that can be set is Pmin. Note that, here, the comparison is made between data and reference

success probability, as the power of data packets are determined based on sample packets. Essentially,

P data[R] = P sample[R] + ∆ (BLUES UPDATE STATS, comment (3) in Fig. 5.5), where ∆ is the power

separation between data and sample packets. Blues updates the reference power similarly, but uses 1 as

the comparison success probability (BLUES UPDATE STATS, comment (2) in Fig. 5.5). For each sent packet,

Blues uses the tx-feedback to collect the success statistics.

The pseudo-code of Minstrel and Blues interactions is presented in Fig. 5.6. When sampling different

power levels, Blues does not interfere with Minstrel sampling. Hence, only when the packet is not a

Minstrel sampling packet, Blues decides whether to send this packet as a reference, sample or a data

packet. Based on this decision, the power level of the packet, Send P , is set respectively as reference

power (P ref [R]), sample power (P sample[R]) or data power (P data[R]). Since the power level

used for sampling depends on the rate, in Blues, we alternate between a set of sampling rates (set as

4 by default). The set of rates that Blues considers for its own sampling consists of the four highest

throughput rates determined by Minstrels statistics. With this approach, we reduce the rates that Blues

uses for sampling to the data-rates that support potentially high throughput. If any data-rate below the

maximum throughput rate is selected for power sampling, the rate order in the multi-rate-retry (mrr)

chain is also changed accordingly, for consistency. Note that with varying wireless channel conditions,

the sampling rate set is expected to change. Hence, Blues maintains a validity timer for the power

statistics at each sampled rate (set to 1 second by default). Power levels of such rates that Blues does

not actively sample, or rates where the statistic validity timer expired are set as follows: (1) all higher

data-rates above the highest throughput rate are assigned the maximum power level and (2) the power

level of the fourth highest throughput rate is used to set the power level of the lower data-rates.


Algorithm 5.2.1: BLUES()

global min update,min P,max P,∆inc,∆dec,∆, δinc, δdec, δemergency

procedure INIT()∀R :ref pwr[R], P data[R], P ack ← max P ;P sample[R]← P ref [R]−∆INIT STATS()

procedure COLLECT STATS(tx-feedback)for each R ∈ tx-feedback.retry chain

do

success← tx-feedback.got ACK(R) == trueif tx-feedback.power == ref power[R]

then attempt ref [R] + +; success ref [R]+ = success;else if tx-feedback.power == data power[R]then attempt data[R] + +; success data[R]+ = success;else if tx-feedback power == sample power[R]then attempt sample[R] + +; success sample[R]+ = success;

comment: After sufficient samples, update Blues statistics

if attempts[sample pwr[R]] > update thresh and attempt ref [R] > update threshthen BLUES UPDATE STATS(R)

if attempts[data pwr[R]] > update thresh

then EWMA(α, psamplesuccess[R], success sample[R]

attempt sample[R])

sorted rate list← SORT BY THROUGHPUT(full rate set)sampling rate set← subset[sorted rate set]

procedure BLUES UPDATE STATS(R)

EWMA(α, prefsuccess[R], success ref [R/attempt ref [R])EWMA(α, pdatasuccess[R], success data[R]/attempt data[R])

EWMA(α, psamplesuccess[R], success sample[R]/attempt sample[R])

comment: If throughput collapse, reset to initial settings

if pdatasuccess[R] < δemergency or current Thr[R] == 0then INIT()

comment: (1) Update sample power, ref power and data power

INC POWER(P sample[R], psamplesuccess[R], prefsuccess[R])

DEC POWER(P sample[R], pdatasuccess[R], prefsuccess[R])

INC POWER(P ref [R], prefsuccess[R], 1)

DEC POWER(P ref [R], prefsuccess[R], 1)P data[R] = P sample[R] + ∆

procedure INC POWER(P, p1, p2)if p1 < p2− δinc

then P = min(max P, P + ∆inc)

procedure DEC POWER(P, p1, p2)

if p1 > p2− δdecthen P = max(min P, P −∆dec)

Figure 5.5: Blues control algorithm


Algorithm 5.2.2: MINSTREL-BLUES()

main

if sending Pkt

then

comment: Update Minstrel statistics periodically

if DO GET TIME(now) > last updated+ update intervalthen

{MINSTREL UPDATE STATS(full rate set)

comment: Determine wether to use packet for sampling

if Pkt == Minstrel sample pkt

then

comment: Setup Rate Sampling Packet

R← RANDOMLY SELECT(R[full rate set])P ← P ref [R]SET PACKET ANNOTATION(R,P )

else

if Blues Counter > 0

then

comment: Setup data packet

Blues counter ← Blues counter − 1for each R ∈ sampling rate set

do U [R]← CALCULATE UTILITY(Thr[R] · weight, P data[R])R← FIND RATE WHERE(U [R]→ max)P ← P data[R]SET PACKET ANNOTATION(R,P )

else

comment: Setup power sampling packet

Blues counter ← 100/SAMPLE RATIOR← SELECT ROUND ROBIN(sampling rate set)P ← ALTERNATE BETWEEN(P sample[R], P ref [R])SET PACKET ANNOTATION(R,P )

else if receive RX feedback

then{

COLLECT STATS(tx-feedback)

Figure 5.6: Minstrel-Blues.


5.2.3 Utility Function for Joint Decisions

Based on several experiments with Blues running on a single link, we often observed in the statistics

collected by Minstrel and Blues that the throughput difference between the highest and the second high-

est data-rate is below 10% while the power-level difference can be more than 6dB (a reduction of more

then 75%). A reduction in transmission power leads to less effected radiated power and therefore, less

interference to potential surrounding transceivers. To expose the trade-off between the throughput and

interference to other transmissions, we introduced a linear utility function, U(w, ratei), where w de-

notes the weight that is given to throughput achieved at a ratei. For instance, if the goal is maximizing

throughput, than the weightw = 10. We call this case, which finds the necessary power level to maintain

the throughout at maximum power, as Minstrel-Piano.

To decide which rate and power level should be assigned to data packets, Minstrel-Blues periodically

calculates the utility function for each combination of the four highest data-rates and their power levels,

and uses the combination with the highest utility value for all data packets. The utility function uses two

attributes: benefit of a rate, benefit(ratei) and costs of a rate cost(ratei). We define benefit(ratei)

based on its estimated throughput and the maximal throughput:

benefit(ratei) =throughput(ratei)

throughput(ratemax thr)× 100 (5.1)

We scale the ratio of two throughput values with 100 to ease the kernel-level computations.

The cost factor is used to represent the interference costs of achieving a certain throughput at a given

rate, and hence, a power level. The interference cost is essentially a function of the area affected by the

interference and duration of the interference. The area is determined by the transmit power level, which,

in our case, is chosen as power(ratei) and path loss based on environmental and network settings.

However, as modelling such affects are quite complex, we approximate the interference area with only

power(ratei). Similarly, the duration can be approximated as 1/throughput(ratei). Based on these

approximations, we define the cost of a ratei, cost(ratei), with respect to maximal throughput and the

corresponding power:

cost(ratei) =power(ratei)

throughput(ratei)× throughput(ratemax thr)

power(ratemax thr)× 100 (5.2)

Note that, power levels are maintained in dB in Blues, therefore, we convert them first into Watts (i.e.,

power(Watt) = 10power(dB)/10). To avoid the anti-log calculation each time, we build a look-up table,

and use this table for the necessary conversion (i.e., all dBm values from 0 to 30 dBm are precalculated

in mW).

Based on the benefit(ratei) and cost(ratei), utility of rate i, U(ratei) is defined as:


Table 5.1: Impact of different weighting factors w to the joint power and rate decision

Data Thr.1 Power Power Benefit CostUtility

Rate [MBits] [dBm] [mW] [%] [%] w = 1 w = 2 w = 4 w = 10

6 6.0 1 1.3 39.2 20.3 19.0 29.1 34.1 37.2

9 8.8 1 1.3 57.5 13.8 43.7 50.6 54.1 55.1

12 11.7 1 1.3 76.5 10.4 66.12 71.32 73.9 75.4

18 15.3 12 15.9 100.0 100.0 0.0 50.0 75.02 90.02

24 4.7 19 79.4 30.7 1631.5 -1600.0 -758.0 -377.2 -132.4

36 2.1 19 79.4 13.7 3651.5 -3600.0 -1812.0 -899.2 -351.4

48 0.0 19 79.4 0.0 0.0 0.0 0.0 0.0 0.0

54 0.0 19 79.4 0.0 0.0 0.0 0.0 0.0 0.01 Throughput: Minstrel periodically estimates the achievable throughput per data rate based on measured success

probabilities.2 Maximum utility at a given weighting factor w is shown in bold.

U(ratei) = w ∗ benefit(ratei)− cost(ratei) (5.3)

Using different values for w, we can adjust Minstrel-Blues operation. We export the throughput weight

factor w from mac80211 subsystem to user space via debugfs to enable convenient control.

Table 5.1 provides a detailed example of benefit, cost, and utility calculations based on a snapshot of

Minstrel-Blues throughput and power level statistics. In the table, the throughput benefit of the data-rate

18 MBits, which provides the maximal throughput, is set to 100%, while the benefits of the remaining

rates are calculated as relative ratio to the maximum. In addition, the cost, which represents the relative

power per throughput, is set to 100% for 18Mbits. The remaining costs are again calculated relatively to

the maximum. The utility column is divided into different weight factors w. A weight factor of w = 1

indicates that both benefit and cost are treated equally, which may lead to a decrease in throughput if

the savings in power are considered as important. Increasing the weight w shifts the preference towards

higher throughput. The utility values in bold numbers indicate the maximum utility for a given weight.

Hence, this data rate should be chosen to achieve the maximum utility. Negative utility values are not

considered in our actual implementation but for completeness shown in Table 5.1. Finally, while this

utility function is chosen as one example that allows adjusting different power and throughput trade-offs,

our implementation can be easily extended to other utility functions.


5.3 Performance Evaluation

In this section, we describe the performance of Minstrel-Blues in different scenarios, ranging from single

link to two or more links that operate in parallel. We run these experiments in our BOWL network

using the 5GHz frequency band and a residential location using the 2.4GHz frequency band. For traffic

generation, we used Iperf version 2.0.5, running single-threaded to generate UDP or TCP traffic. In

addition, the senders continuously ping their respective receivers every 2s to maintain connectivity. The

Iperf client and server ran either on dedicated BOWL servers that are connected to each wireless router

via Ethernet, or on the access-point and the client itself. Our experiments in this section are based on

our Minstrel-Blues implementation that runs on two different router platforms Asus wl-500gP and PC-

Engines Alix 3d2. Our evaluations take three different carrier-sense settings into account: (1) energy

and preamble detection, (2) only energy detection, and (3) automatic carrier sense control through ANI

(for details of these settings, see Section 3.2). To evaluate the performance with common metrics, we

monitor different sources across network layers: As shown in Figure 5.7 we use tree different monitoring

sources: (1) RegMon in order to monitor the MAC-layer states and consequently the interference, (2)

tcpdump to determine throughput and received SNR from packet traces and (3) statistics via debugfs to

monitor Minstrel-Blues control behavior in terms of chosen data-rates and power levels. All trace files

are stored while the experiment is running, and analyzed afterwards. Minstrel-Blues monitoring sources

5.3.1 Piano Power Control in a Single Link Scenario

In the initial design of our algorithm, we only considered supporting the same rate, and hence, the

throughput that Minstrel achieves, with the lowest power possible. In our current design, Minstrel-

Piano is a special configuration of Minstrel-Blues, where the weight factor, w, is set to 10, so that only

throughput influences the utility calculation, and the power level is negligible. This approach has a clear

two-step decision sequence: first the rate decision is made by Minstrel based on the estimated throughput

and second, Piano decides the power level based on the loss ratio with the rate set composed of the four

highest throughput rates of Minstrel.

The goal of the following measurement results is to show the ability of Minstrel-Piano to reduce

transmission power while maintaining the same throughput [153]. The traffic is UDP traffic with a

constant datagram size of 1420 B and a rate of 32 Mbps to make sure that all lower layers, including

the wireless MAC layer, are always saturated. We first validate the Piano operation using fixed rates.

Then, we validate the Minstrel-Piano operation, with the goal of showing that Piano is able to work with

Minstrel well.

Performance Evaluation 75

userspace

mac80211

ath5kSoftMACLinux drivers

Atheros 802.11 b/g/a WiFi chips

RegMon

debug filesystem per WiFi card

cyclic readMAC-state trace

time reg1 ... reg9

103 0x11 ... 0x44101 0x53 ... 0x79

105 0x61 ... 0x51

...

Minstrel-Blues statistics

time rate ... prob

101 9 ... 68%101 6 ... 95%

...

101 12 ... 56%

cyclic readMinstrel-Blues trace

TCP/IP Stack kernelspace

debug filesystem perWiFi card & connection

packet traces

RegMon rc/tpc-stats

802.11interface

per neighbor

tcpdump

CarrierSense

TransmitReceive

MAC-states

libpcap capturePacket trace

Throughput and SNR per neighbor

Figure 5.7: The three monitoring sources we trace during each experiment.

Piano with Fixed Rates

To confirm that Piano reduces the transmission power as long as there is no penalty in throughput,

we switched the sender to use different transmissions rates while Piano is running. Figure 5.8(a) and

Figure 5.8(b) show the SNR and throughput at the receiver over time. We observe that with both carrier

sense settings, Piano is indeed able to reduce the power while maintaining the same throughput. For the

case with energy and preamble detector, the reduction is more significant (as expected from Fig. 5.3(a)).

For the rates 6−24 Mbps, the saturation throughput is achieved when the SNR values are≈ 16−22 dB.

This can be seen from looking up the power level from Fig. 5.3(b) and checking the SNR value for this

power level in Fig. 5.3(a). We see that Piano successfully reduces the power level to attain these SNR

levels at the receiver (see Fig. 5.8(a)). On the other hand, with only energy detection, the power reduction

opportunities are limited. Here, Piano maintains the SNR values around 26− 28 dB, which corresponds

to the point where the receiver can attain higher throughput (see again Figs. 5.3(a) and 5.3(b)).

Minstrel-Piano with Joint Rate and Power Control

Next, we validate the joint operation of Piano and Minstrel. To this end, we first start Minstrel with

maximum transmission power using only energy detection. The SNR and the throughput at the receiver


(a) SNR at the receiver

Time [s]

Th

rou

gh

pu

t [M

Bit

/s]

0

4

8

0

4

8

0

4

8

0

4

8

0

4

8

Energy & preamble detector

5 10 15 20

Energy detector

5 10 15 20

6

9

12

18

24

(b) Throughput at the receiver

Figure 5.8: (1) Piano with energy and preamble detection (2) Piano with energy detection.

(a) SNR at the receiver (b) Throughput at the receiver

Figure 5.9: (1) Minstrel at max. power with energy detection (0-120s) (2) Minstrel-Piano with en-ergy detection (120-240s), (3) Minstrel-Piano with energy and preamble detection (240-360s) and (4)Minstrel-Piano back to only using energy detection (360-480s).

during this time are shown in Figures 5.9(a) and 5.9(b). We observe that Minstrel throughput is quite

stable. In our experiment after 120 s, Piano is started. We see that with Piano, the SNR values at the

receiver reduce to≈ 30 dB, which is the expected operation level with only energy detector for 24 Mbps

without negatively impacting the throughput. Again, after 120 s, the preamble detector is activated. In

this setting, the SNR further reduces to ≈ 21 dB, while the same throughput is maintained. SNR values

increase back to ≈ 30 dB, when the preamble detector is disabled at around 360 s. We see that this

causes a short glitch and leads to high variation in power levels as well as a throughput drop. However,

Minstrel-Piano recovers fast and Piano bumps up the transmit power to maintain the same throughput

as before. Finally, Fig. 5.10 depicts the number of times the data packets were received at different

rates at different intervals. Note that in all intervals 24 Mbps is the dominant data rate (Fig. 5.10 is

in log-scale). It must be noted that Minstrel also tries the higher rate 36 Mbps at times, which leads to


Figure 5.10: Rate distribution across data packets received. (1) 0-120s: Minstrel at max. power withenergy detection, (2) 120-240: Minstrel-Piano with energy detection, (3) 240-360: Minstrel-Piano withenergy and preamble detection, and (4) 360-480: Minstrel-Piano back to only using energy detection.The y-axis is in log-scale.

consequent throughput degradation (e.g., around 90 s). These results confirm that Piano is able to reduce

the transmission power without affecting the rate selection in Minstrel, and throughput performance.

5.3.2 Piano Power Control in a Multi-Link Scenario

While the former experiments show that Piano significantly decreases transmission power while main-

taining similar throughput compared to a static maximal power assignment, these experiments only

show performance of a single wireless link. To gain insight about the spatial reuse performance, in this

section, we consider a multi-link scenario. More specifically, we performed the following experiments

on multiple wireless links in our BOWL indoor network set-up, depicted in Figure 5.11. Our set-up

includes eight Asus routers that establish four wireless links, operating at the same frequency of 5.825

GHz (channel 165). This channel is part of the ISM outdoor upper band and is not used in the BOWL

indoor network for other communication. Consequently, we run our experiments free from interference

from other devices and networks. To ensure that we were the only users of this frequency band and

that no foreign WiFi emitter was in range, Asus node 163 was used as a monitor node at the highest

sensitivity. In its pcap traces we could not find any other transmission sources than our routers. Also the

RegMon Mac-state traces did not show any noticeable problems with other external interference.

In the rest of the network, nodes 16−2, 16−4, 17−2 and 17−3 are configured to run as access-points

while nodes 16− 1, 16− 5, 17− 1 and 17− 4 are configured in client mode as their corresponding re-


17. floor

16. floor

16-5

16-4 16-316-2

16-1

17-4

17-117-3 17-2

sinksource

link-2link-1

link-3

link-4

Figure 5.11: Nodes and links in the BOWL indoor network setup for spatial reuse evaluation.

ceivers. Hence, we enable a maximum of 4 independent communication links as depicted in Figure 5.11.

The distance between each sender-receiver pair varies from 15 to 25 meters. A line-of-sight condition is

only provided in the case of link 2. Two servers are used to generate and receive UDP and TCP traffic

via Iperf (marked as source and sink, respectively, in Figure 5.11). The sink server also managed all

remote experiments and trace file collection via a dedicated Bash script. For network traffic, we used a

fixed datagram size if 1420 Byte for all measurement trials. In case of UDP traffic, 32 Mbps data rate

was used to ensure that all lower layers, including the wireless MAC layer, are always saturated. In case

of TCP traffic, the default settings of Iperf were used. Our traffic generation is not meant to represent

realistic user traffic. Rather, we focus on the extreme case of having always backlogged traffic with

reasonably long durations to observe its impact on link and network throughput. To this end, we chose

120 seconds for each UDP session. In case of TCP traffic, we did not use equal transmission durations.

Instead, we sent a fixed amount of data (50 MByte) from a sender to its receiver. All UDP sessions and

TCP file transfers start at the same time for the selected transmitters of a given scenario.

In order to compare the impact of different carrier sense settings, we decided to use a subset of

three different CS adjustments: (1) fixed carrier sense parameters at the highest receiver sensitivity

possible, (2) fixed carrier sense parameters at the lowest receiver sensitivity possible and (3) automatic

carrier sense control by ath5k ANI, as it is the default setting. Our experiments involve all possible link

combinations for 1, 2, 3 and 4 links, using 2 types of traffic, and 3 different carrier sense settings. In all

the experiments, we compared the performance Minstrel-Blues to Minstrel at a static power of 17dBm

power (i.e., maximum power for all rates). Hence, our experiments span 14 different link combinations

with 12 factor combinations, which sums to 168 different runs of 85 to 170 seconds each. The whole


experiment lasts about 8 hours, and was performed between 22:00 to 6:00.

To evaluate the spatial reuse potential, we evaluate the total and per-link throughput. Any signifi-

cant increase in sum throughput confirms Minstrel-Blues’ ability to increase spatial reuse, and per-link

throughput results help us to understand how each link shares the medium. For the TCP experiments, we

also observe the duration of file transfers to decide about spatial reuse. For example, if the file transfers

with Minstrel-Blues finishes significantly earlier than with fixed transmission power, and we observe the

same data rate distribution, we can decide the improvement is due to spatial reuse. In addition, to be

able to monitor the power and rate selection in the Minstrel-Blues algorithm, we dumped the rate and

power state for each link every 50 ms on the measurement sink. We also monitored the MAC-states

of each node via RegMon at a sampling rate of 1000 Hz. The transmission power used serves as an

indicator to the level of overall interference created to potentially nearby communications. Data rates

determine how long the spectrum was occupied due to transmissions. The MAC states differentiate the

activities of each WiFi radio and serves as a useful indicator for spatial reuse. For example, an increase

of IDLE ratio points to a potential for spatial reuse, while the increase in TX and RX states shows a

better medium utilization. In an ideal case, when all links operate in parallel with no interference from

and to each other, the sum of TX state durations would be equal to the sum of RX states at the respective

receivers. However, we do not operate in the ideal case. Therefore, the difference between durations of

TX and RX states is caused by MAC-layer interference from other ongoing transmissions.

For validation and to serve as a baseline, we ran single link experiments to understand the achievable

throughput at each traffic type and carrier sense setting. All measured throughputs, which are not shown

for the sake of brevity, are similar for links 1, 2, 3 and 4 regardless of the carrier sense settings. In

case of TCP, each link supports 20 MBit/s and in the case of UDP, 24 MBit/s, which corresponds to

the maximum achievable throughput. Minstrel-Blues provides the same throughput performance as the

maximum power case but is able to reduce the power to 2dBm (with sample power 0dBm). Next, we

present the results from multiple links in communication - more specifically, we present the following

scenarios: (1) two active links: links 1 and 2, (2) three active links: links 1, 2 and 3 and (3) four active

links: links 1, 2, 3, and 4.

Measurement Results with two active links: As shown in Figure 5.11, the four Asus nodes for links

1 and 2 are located on the same floor in our office building. In Figure 5.12, the upper plot shows the

throughput results for different carrier-sense settings and, UDP and TCP traffic. In all cases, Minstrel-

Blues is able to increase the overall throughput as well as the per-link throughput for both UDP and

TCP traffic. Significant throughput gains are achieved when carrier sense settings are at low sensitivity

and ani on. As the individual per-link throughput values also increase, we are convinced that reducing

the power allows each link to operate independently, i.e., not carrier sense each other. If the two links

run concurrently, we expect the total throughput to be around 38 Mbps in the case of TCP (2 × 19


aniBlues: off

aniBlues: on

highBlues: off

highBlues: on

lowBlues: off

lowBlues: on

0

10

20

30

40

0

10

20

30

40

tcpudp

0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120

Time [s]

Thro

ughp

ut [M

Bit/s

]

link12total

active links: 12

TCP UDP

0

3

6

9

12

15

18

0

3

6

9

12

15

18

TX−L1TX−L2

0 20 40 60 80 100 120 0 20 40 60 80 100 120Time [s]

tx−P

ower

Lev

el [d

Bm]

powerlevel

datareference

tx−power level used at each sender active links: 12 rx−sensitivity: low

BLUES=OFF BLUES=ON

0%

50%

100%

0%

50%

100%

0%

50%

100%

0%

50%

100%

TX1−link

RX

1−linkTX

2−linkR

X2−link

0 20 40 60 80 100 0 20 40 60 80 100Time [s]

rela

tive

dwel

l tim

e [%

]

MACstates

tx−busyrx−busyidleothers

active links: 12 protocol: tcp CS−sensitivity: low

Time [s]

Throughput with active Links: 1, 2

TX-Power Data-Rate

MAC-states

TX1-link

TX2-link

TX link−1BLUES=OFF

TX link−1BLUES=ON


TX link−2BLUES=ON

5448

36

241812

6

5448

36

241812

6

5448

36

241812

6

1st−best2nd−best

high−pr

0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120Time [s]

802.

11a

data

rate

Minstrel−Blues data rates of each sender active links: 12 proto: TCP rx−sensitivity: lowTX-Data-rate

Figure 5.12: Both links 1 and 2 are active.


Mbps achieved at a single link) and 46 Mbps for UDP (2 × 23 Mpbs achieved at a single link). Both

ani and low sensitivity scenarios show sum throughput values around 36 Mbps for TCP and around 43

Mbps for UDP. This indicates that both links almost transmit at their potential maximum transmission

rate concurrently. Minstrel-Blues needs 20 to 35 seconds across all scenarios to reach to this state

of operation. While in the case of highest sensitivity, shown in the middle, Minstrel-Blues is able to

slightly increase sum throughput. Hence even at the lowest power level both links do still carrier sense

each other.

Next, we take a deeper look at the TCP scenario with low sensitivity (see Figure 5.12 ). To this end,

the lower part of Figure 5.12 shows additional measurement results about the evolution of MAC-states,

transmission power and data-rate. The tx-power plot shows that Minstrel-Blues continuously reduces

the power levels of both senders of TX link-1 and TX link-2 from 19 dBm to 2 dBm during the first

17 seconds. This indicates that the Blues part of our algorithm decreases power levels every second,

the shortest time period at which statistic updates are calculated and new power levels are assigned (17

consecutive power changes within 17 seconds). TX-Data-Rate plot shows that the first-best and second-

best data rates do not change significantly between Minstrel and Minstel-Blues. In contrast, the data

rate with the highest success probability (labeled high pr) spans a wider range of rates in the ase of

Minstrel-Blues but without influencing the throughput. The Mac-states plot shows that when Blues is

active, between the 10th and 15th second, there is a significant reduction in others, which annotates all

busy states that correspond to energy detection without triggering packet reception. This shows that

the senders stop carrier sensing each other and the interference on the receiver of the 2nd link is also

reduced. In other words, both links are able to operate independently without interfering each other

at power levels below ≈ 9 dBm. Consequently, their TX-state utilization rises from 27 % to 40 %

and RX-states from 30 % to 45 %. Looking at MAC states, we also confirm that total time spent for

communication (i.e., transmission and reception) went down from 110 seconds to 75 seconds by turning

Blues on, which confirms the increase in spatial reuse, and better utilisation of the medium, and hence

higher throughputs. Our results from the remaining two link scenarios are similar. In all cases of two

links, Minstel-Blues, by decreasing transmission power, enables simultaneous transmissions that exploit

spatial reuse potential and hence, increases total network throughput.

Finally, we show entire the MAC states of all 8 nodes in Figure 5.13. We see that energy detection

ratio for all nodes is significantly reduced. This holds also for the nodes that are in communication -

they receive less and detect less energy, resulting an increase in idle state. It shows that these nodes may

also have potential for spatial reuse, which we confirm next with our 3-links and 4-links experiments.

Measurement results with three active links: In this section, we investigate the performance with

three active links. In particular, we consider the links 1, 2, and 3, where the link 3 is located one floor

below links 1 and 2, as shown in Figure 5.11. In Figure 5.14, the upper plot shows the throughput


TX1−link

RX1−link

TX2−link

RX2−link

TX3−link

RX3−link

TX4−link

RX4−link

0

50

100

0

50

100

BLU

ES

=O

FF

BLU

ES

=O

N

0 100 0 100 0 100 0 100 0 100 0 100 0 100 0 100

Time [s]

dwel

l tim

e [s

] MACstates

tx−busy

rx−busy

idle

others

MAC−states of all 8 Nodes active links: 12 protocol: tcp CS−sensitivity: low

Figure 5.13:

results for different carrier-sense settings and, UDP and TCP traffic. Again in all cases, Minstrel-Blues

is able to increase the overall throughput for both UDP and TCP traffic. When we look at different

traffic and carrier sense configurations, we observe that, with 3 links, Minstrel-Blues needs up to 50

seconds to start improving throughput. We also notice that, for some links, throughput does not always

increase with Blues, but there is also no significant drop. In the case of TCP, the throughput gains are

more remarkable compared to UDP across all carrier sense settings. However, in contrast to the two-

link scenario, we are not able to completely remove carrier sensing and isolate the 3 links. Both ani

and low sensitivity scenarios show total TCP throughput values are around 50 Mbps and not 57 MBps

(3× 19 MBps achieved at a single link). UDP traffic at low sensitivity reaches the highest value of total

throughput (58 Mbps) after 50 seconds while each individual link achieves almost equal performance of

about 18 to 21 Mbps.

Next, we look more closely at the highest sensitivity case with TCP traffic, shown in the middle red

marked box. In this case, Minstrel-Blues is able to increase sum throughput from about 27 Mbps to 40

Mbps. In this set-up, all three links still carrier sense each other. From our single link measurements,

we observe that at lowest power level and highest sensitivity link-3 and link-2 do not carrier sense each

other while link-3 and link-1 do partly interfere witch each other. Comparing the actual node locations,

this interaction seems logical because the sender and the receiver of link-1 are located right above link-

3. In contrast, link-2 and link-3 are located at the opposite ends of the 17th and 16th floor as shown

in Figure 5.11. The MAC-state results in the lower part of Figure 5.14 show that, with Minstrel-Blues

nodes are able to finish transmitting 50 MB in about 125 s, while with Minstrel and static maximum


aniBlues: off

aniBlues: on

highBlues: off

highBlues: on

lowBlues: off

lowBlues: on

0

10

20

30

40

50

60

0

10

20

30

40

50

60

tcpudp

0 40 80 120 160 0 40 80 120 160 0 40 80 120 160 0 40 80 120 160 0 40 80 120 160 0 40 80 120 160

Time [s]

Thro

ughp

ut [M

Bit/s

]

link123total

active links: 123Throughput with active links:1, 2, 3

BLUES=OFF BLUES=ON

0%

50%

100%

0%

50%

100%

0%

50%

100%

0%

50%

100%

0%

50%

100%

0%

50%

100%

TX1−link

RX

1−linkTX

2−linkR

X2−link

TX3−link

RX

3−link

0 20 40 60 80 100 120 140 160 0 20 40 60 80 100 120 140 160Time [s]

rela

tive

dwel

l tim

e [%

]

MACstates


active links: 123 protocol: tcp CS−sensitivity: highMAC-states

Figure 5.14: Throughput and mac-states when links 1, 2 and 3 are active.



TX link−1BLUES=ON


TX link−2BLUES=ON


TX link−3BLUES=ON

5448

36

241812

6

5448

36

241812

6

5448

36

241812

6


high−pr

0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120Time [s]

802.

11a

data

rate

Minstrel−Blues data rates of each sender active links: 123 proto: TCP rx−sensitivity: high

TCP UDP

0369

121518

0369

121518

0369

121518

TX−L1TX−L2

TX−L3

0 20 40 60 80 100 120 0 20 40 60 80 100 120Time [s]

tx−P

ower

Lev

el [d

Bm]

powerlevel

datareference

tx−power level used at each sender active links: 123 rx−sensitivity: high

Figure 5.15: TX Data-rate and Tx Power-level distribution when Link 1, 2 and 3 are active.

power assignment, this takes around 158 s to complete. Especially, the transmitters of link-2 and link-

3 are able to increase the time they spend in transmission and reception, and hence, their throughput.

They complete sending 50 MByte in about 90 s. After that point, transmitter of link-1 is able to send its

remaining data without being interfered at an increased throughput of about 18 Mbps.

Figure 5.15 shows Minstrel-Blues data rate decisions (on the left) and power level decisions over

time (on the right). It takes about 30 seconds until the lowest power level for reference and data is used

by all three senders. While both transmitters of link-1 and link-2 decrease their power continuously to

the lowest level, the transmitter of link-3 is not immediately able to reduce its power in the TCP case. It

jumps back to max power after initially decreasing its power and then takes a second attempt to lower its

power level down to 2 dBm. Also for the UDP case, it converges to a higher transmit power compared to

the other two transmitters. Finally, the data rate evolution, shown in the left part of Figure 5.15, shows

little difference between Minstrel-Blues and Minstrel in terms of the highest and second highest data

rate assignments.

Measurement results with four active links: Our last measurement includes all four wireless links

transmitting at the same time across both floors as shown in Figure 5.11. The upper plot of Figure 5.16

contains all throughput results. Also in this scenario Minstrel-Blues is able to increase the overall

throughput for both UDP and TCP traffic across all sensitivity levels. However, in contrast to our for-

mer results, some links experience significant throughput decrease compared to the case with maximum

power level. For instance, link-4 (blue line) shows significant throughput drops when carrier sensing is

controlled by ani (both UDP and TCP) and also, in the case of low sensitivity with UDP traffic. This

scenario is the most challenging, as there is no possibility to operate all four links independently. The

maximal total throughput using Minstrel-Blues is about 55 Mbps for both TCP and UDP in the case of

low sensitivity. The maximum throughput achieved by Minstel with maximum power is around 40-45

Mbps.

We depict the case of TCP traffic when sensitivity is controlled by ani in more detail. The MAC-state

plot in the lower part of Figure 5.16 shows that all nodes are able to finish the 50MB data transfer in


BLUES=OFF BLUES=ON

0%

50%

100%

0%

50%

100%

0%

50%

100%

0%

50%

100%

0%

50%

100%

0%

50%

100%

0%

50%

100%

0%

50%

100%

TX1−link

RX

1−linkTX

2−linkR

X2−link

TX3−link

RX

3−linkTX

4−linkR

X4−link

0 20 40 60 80 100 120 140 160 0 20 40 60 80 100 120 140 160Time [s]

rela

tive

MAC

−sta

tes

MACstates


active links: 1234 protocol: tcp CS−sensitivity: ani

aniBlues: off

aniBlues: on

highBlues: off

highBlues: on

lowBlues: off

lowBlues: on

0

10

20

30

40

50

60

0

10

20

30

40

50

60

tcpudp

0 40 80 120 160 0 40 80 120 160 0 40 80 120 160 0 40 80 120 160 0 40 80 120 160 0 40 80 120 160

Time [s]

Thro

ughp

ut [M

Bit/s

]

link1234total

active links: 1234Throughput with active links:1, 2, 3, 4

MAC-states

Figure 5.16: Throughput and Mac-states when Link 1, 2, 3 and 4 are active.


≈ 150 s with Minstrel-Blues compared to ≈ 160 s in the case of maximum power. The different MAC-

state distributions allow a clear distinction between the finishing order between all links. In addition,

from these graphs, the reasons behind poor performance of link 4 becomes more clear. So long as the

other transmitters carrier sense each other less, and hence, attempt more transmissions, the transmitter

of the link 4 senses these transmissions (and hence, has higher energy detection compared to others),

and is expected to back off more. While the increased transmissions do also affect the receiver of link 3,

the throughput of link 3 is still able to increase with Minstrel-Blues.


TX link−1BLUES=ON


TX link−2BLUES=ON


TX link−3BLUES=ON


TX link−4BLUES=ON

5448

36

241812

6

5448

36

241812

6

5448

36

241812

6


high−pr

0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120 0 40 80 120Time [s]

802.

11a

data

rate

Minstrel−Blues data rates of each sender active links: 1234 proto: TCP rx−sensitivity: ani

TCP UDP

0369

121518

0369

121518

0369

121518

0369

121518

TX−L1TX−L2

TX−L3TX−L4

0 20 40 60 80 100 120 140 160 0 20 40 60 80 100 120 140 160Time [s]

tx−P

ower

Lev

el [d

Bm]

powerlevel

datareference

tx−power level used at each sender active links: 1234 rx−sensitivity: ani

Figure 5.17: TX Data-rate and Tx Power-level distribution when Link 1, 2, 3 and 4 are active.

Figure 5.17 shows Minstrel-Blues rate decisions (left plot) and power level decisions (right plot) over

time. The power level evolution shows that after 25 seconds both transmitters of link-1 and link-2 use

the lowest power level (2 dBm) for reference and data packets. In contrast, link-3 reduces its power level

in two phases. Between the 60th and 80th seconds when all senders transmit in parallel the transmitter

of link-3 assigns about 6 dBm for both data and reference power. Once the transmitter of link-1 finishes

its transmission after 85 seconds, the transmitter of link-3 further decreases its power to 2 dBm. On the

other hand, the power level of link-4’s transmitter alternates between 2 to 3 dBm. Note that even though

link 4 experiences throughput drops, it does not ramp up its power, as the loss of throughput is not a result

of packet loss but increase in contention and carrier sensing other transmitters. Monitoring the increase

in contention to tune power levels to avoid throughput drops is left as future work. Finally, the data rate

evolution, shown in the left part of Figure 5.17, indicates little difference between Minstrel-Blues and

Minstrel in terms of the highest and the second highest data rate assignments.

5.3.3 Compatibility Experiment with Minstrel-Blues

Up to now, we have mainly evaluated Minstrel-Piano at 5 GHz band. In this section, we validate

Minstrel-Blues with different utility weight factors, w. In addition we switch from 5 GHz frequency

band to 2.4 GHz. This provides also a test whether our Linux kernel implementation is able to per-

form under IEEE 802.11g settings and conditions. We confirm our controller’s capability of using the

increased number of available data rates (from eight 802.11a rates to twelve 802.11g rates).


Lenovo Thinkpad T520OS = Ubuntu 12.04WiFi = Intel Ultimate-N 6300

802.11 a/g/n 450MBitdriver = iwlwifi

ASUS Eee PC 1005HAOS = Windows 7 homeWiFi = Atheros AR2427

802.11 b/gdriver = Windows specific

monitorinterface

accessinterface

-- ca. 5m --

-- ca. 3m --

PC-Engines Alix 3d2OS = OpenWrt rev. 33027WiFi = 2x Wistron CM9

802.11 a/b/gdriver = Ath5k + Minstrel-Blues

channel = 1 (2,412 GHz)date = 11.07.2012time = 22:00location = residence in Berlin

Figure 5.18: Node and Link Setup of Minstrel-Blues Compatibility Scenario.

For these experiments, we use a different measurement setup that consists of two client devices (a

laptop and a netbook) connected to one Minstrel-Blues enabled access-point in a residential house in

Berlin (see Figure 5.18). The WiFi card of the laptop is based on an Intel IEEE 802.11n chip powered

by a recent Ubuntu version. The netbook is equipped with an IEEE 802.11n Atheros chip and a recent

Windows version as its operating system. In contrast to the formerly used Asus MIPS hardware, the

access point is a x86 based PC-Engines Alix 3d2 router running a current version of OpenWrt. It

includes two Atheros based Wistron CM9 WiFi cards that are driven by the ath5k driver including our

Minstrel-Blues implementation. And a common 5 dBi indoor omni-directional antenna is attached to

each wireless interface. One WiFi cards serves as an access point on channel 1 (2.412 GHz) and the

other WiFi card is used as the monitoring interface to capture packets. Both clients and the access

point are located in one living room with direct line of sight to each other. The approximate distance of

communication links is annotated in Figure 5.18 and are rather short.

We generate traffic with Iperf, where the access point starts sending: (1) two UDP flows and (2) two

TCP flows to each client at the same time. To ensure that both flows start at the same time, the actual

measurement script is executed on the Alix router. The packet size is set to 1420 Byte. We collect MAC-

state traces at 1000Hz via RegMon, tcpdump traces from the monitoring interface, and Minstrel-Blues

data rate and power level assignments periodically via proc filesystem. The 8 GB CF card on the router

is sufficiently large to store all the monitoring data.

The whole experiment consists of six measurement runs (three weight factors of 10, 4 and 2, and

two traffic types of UDP and TCP) and lasts about 70 minutes. The impact of these weight factors were

shown and explained earlier in Table 5.1. Each experiment lasts for 10 minutes while we change from

Minstrel-Blues to Minstrel with maximum power (and vice versa) every 150 seconds. We start with


Minstrel with static maximum power (at 19 dBm, in all plots marked with a red dotted line). After

150 seconds, Minstrel-Blues with its specific weight factor is activated (in all plots marked with a blue

line). At 300 seconds Minstrel-Blues is deactivated and we switch back to plain Minstrel with maximum

power. At the fourth and last interval, starting right after 450 seconds, we again change back to Minstrel-

Blues.

Measurement Results: Since, for these experiments, we were operating at 2.4 GHz at channel 1, we

first checked the amount of external traffic that may potentially affect our experiments. By analyzing

beacon packets across all packet traces, we identified four additional wireless networks with individual

service set identifiers (SSID). During our experiments, the total amount of external wireless traffic stayed

always below 74 kbps. Out of our six measurements, we choose two cases to present hereafter: TCP

traffic with the highest weight (w = 10) and the lowest weight (w = 2). All other measurements show

similar results. Note that w = 10 is Piano, and is evaluated to compare with earlier measurements.

Figure 5.19 shows the results with w = 2 and Figure 5.20 with w = 10. At the top of both

Figures 5.19 and 5.20, the first two plots present the per-link throughput averaged over one second.

The throughput variation ranges from 0 to 12 Mbps. The summary throughput plot aggregates the

throughput of both links with a moving average shown as blue and red lines, respectively. In addition,

the total throughput is shown as a bar plot with a bin size of 50s. Our results from multi-link experiments

suggest that this bin size is reasonable to cover Minstrel-Blues transition phase within 50 seconds, which

corresponds to the first 50s of each 150s interval. Even though we observe high throughput variations per

link, there is no significant drop or increase in total throughput while alternating between the Minstrel-

Blues and Minstrel with maximum power. Across all measurements, our Minstrel-Blues implementation

performs well in the IEEE 802.11g mode and no significant disruption is observable.

We also plot the MAC state distribution of the access point over one second time interval. With

w = 2 (depicted in Figure 5.19) and w = 10 in Figure 5.20, the MAC-state distribution does not

significantly change with or without Blues. The validation of Minstrel-Blues is able to reduce the actual

transmission power in received signal strength and adjusted tx power level plots in Figures 5.19 and 5.20.

The results are presented as aggregated bar plots with bin size of 50s. Both the reduction of tx-power

levels and the measured decrease in received signal strength show that Minstrel-Blues is able to perform

well for IEEE 802.11g too. In Chapter 3, we have explained that with higher data rates the maximal

power level decreases (see Section 3.2.2). This is clearly observed in our measurements. In case of the

laptop link, tx-power levels adjusted by Minstrel-Blues are shown in Figure 5.20 and stay at a tx-power

of around 9 dBm. This equals a reduction of 10 dB as 19 dBm is the maximum power level. On the

other hand, the plot showing the actual measured receive signal strength indicates only a reduction of 7

dB on average. This is due to the fact that around 90 % of the packets used data rates 48 and 54 Mbps.

And based on our Eeprom measurements (see Fig 3.6), the Wistron CM9 at channel 1 supports up to 15


0.0

0.2

0.4

0.6

0.8

1.0

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

rel.

coun

t

datarate

125.56911121824364854

0

2

4

6

8

10

12

14

16

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

Thro

ughp

ut [M

Bit/s

]

throughput weighting factor = 2

0.0

0.2

0.4

0.6

0.8

1.0

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

rel.

coun

t

datarate

125.56911121824364854

●

●

●

●

●

●●

●

●

●

●

●

0

2

4

6

8

10

12

14

16

18

20

22

24

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

Thro

ughp

ut [M

Bit/s

]

0

2

4

6

8

10

12

14

16

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

Thro

ughp

ut [M

Bit/s

]

laptop netbook

summary throughput

throughputper link

receivedsignal

strengh

adjustedtx-power

level

datarate

MACstates

0.0

0.2

0.4

0.6

0.8

1.0

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

rela

tive

MAC

−sta

tes

MACstates


●

●

●

●

●

●

●●●

●●●

●

●

●●

●●

●●

●

●●

●

●

●

●

●

●●

●

●

●●

●●●

●

●

●●●●●●●●

●

●

●●●●

●●●●

●

●

●

●●

●

●

●●

●

●

●●●

●

●

●

●●

●

●

●

●●●

●

●

●●●●

●●

●●●

●

●●

●

●●

●

●

●

●

●●

●●

●●●

●●●

●

●

●●

●

●●●●●●●

●●

●

● ●

●

●

●

●●●●●●●

●

●

●

●

●●●

●

●

●

●

●

●●●●●

●

●●●

●

●

●

●

●

●

●●

●

●●●

●

●

●

●

●

●

●

●●

●

●

●●

●

●●

●

●

●

●

●

●●

●

●

●

●

●●●●

●

●

●●

●

●

●

●

●

●●●●●

●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●

●

●●

●

●●●●●●●●●●

●

●

●

●●●

●

●●●

●

●●●

●

●●

●

●

●

●

●

●●

●

●

●

●●●

●

●●●●●●

●

●●●●

●

●●●●●●●●

●

●

●

●

●

●

●

●●

●

●●

●

●●

●

●

●

●●

●●

●

●

●

●●●●

●

●●

●

●

●

●●

●

●●

●

●

●

●

●●●

●●●

●

●

●●

●

●

●

●●

●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●

●

●●●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●●●

●

●

●●●

●

●

●

●

●

●

●●●●

●●

●

●●

●●●●●●●

●

●

●

●●●

●

●

●

●

●●

●●●●

●

●

●

●●●

●

●

●●●●●●●●

●

●

●●

●

●

●

●●●●

●●●

●

●●

●

●

●●

●●

●

●

●

●

●

●●

●

●●●

●

●

●●

●●●●

●

●

●

●●

●

●

●

●

●

●●●●●●

●

●●

●

●●

●

●

●

●●●●●●●

●

●

●

●

●●●●●

●

●

●

●

●●●●

●●●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●●●●●

●

●●

●

●

●

●●●●●●

●

●

●

●

●●

●●

●●●

●

●

●

●

●

●

●●

●

●●

●

●●

●●

●

●

●

●

●

●●●●

●

●

●●●

●

●

●

●

●

●

●

●

●

●●●●

●

●

●

●●●●

●●

●

●

●●

●●●

●●●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●●●

●●

●

●

●●●

●

●

●●●

●

●

●

●●●●●

●●

●●

●

●

●

●

●

●

●●●●

●

●

●

●●●

●●

●●

●

●●●●

●

●●●●

●●●

●

●●●

●

●

●●

●●●●

●

●

●

●●●●●

●

●

●

●

●●

●

●

●

●

●

●●

●

●●●

●

●●●●

●●●●●

●

●●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●

●

●●●

●

●●●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●●●

●●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●

●

●

●●●●●

●●

●

●

●

●

●

●

●

●●

●

●●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●●●●●

●

●

●

●

●●

●●●●●●

●

●●

●

●

●

●

●●●●

●

●●●

●

●●●

●

●

●●

●

●

●●●●

●

●

●

●●

●

●●●●

●

●●

●

●

●●●

●

●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●

●●●●●

●

●

●●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●

●●●

●●●

●

●

●

●●●

●●

●

●●

●●

●●

●

●●

●

●

●

●

●

●

●●

●●

●●●●

●

●●●

●●

●

●●

●

●●●●

●

●

●

●●●

●

●

●●

●●●

●

●

●

●

●

●

●

●

●●●●●

●●●

●

●●

●

●

●

●

●

●

●●●

●

●

●●

●●●●●

●

●●

●

●

●

●●●

●

●●

●●●

●●●

●●●●●

●●●

●

●

●●●●

●

●●

●

●●●

●

●●●●●●●

●

●●●●

●

●●

●●

●●

●●

●●●

●●●

●●

●●●●●

●

●

●

●●●

●

●

●●●

●●

●

●

●

●●

●

●●

●

●

●

●

●

●

●●●●

●

●●●

●●●

●

●●

●●

●●

●

●●

●●

●

●

●

●●

●●

●

●

●

●

●

●●

●●

●

●

●●●

●●

●

●

●

●

●●

●

●●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●●

●

●

●●

●●●

●●

●

●

●

●

●

●

●●

●●●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●●●●

●

●

●

●

●●

●●●

●●●●●

●

●●●●●

●

●●●●

●

●

●●

●

●

●

●

●

●

●

●●

●●

●

●

●●

●

●●●●

●

●

●

●●●●

●

●

●●

●

●

●

●

●

●●

●

●●●

●●●●●

●

●

●●

●

●●●

●●●●●

●

●●●●●

●●●

●●

●

●

●

●

●

●

●●

●●●

●●

●

●●

●

●

●

●

●

●●

●

●

●●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●

●

●●

●●●

●●

●●●●●●

●

●●●

●

●●●●

●

●●●●●●

●●

●●●

●●

●

●●

●

●●●●●●●●●

●

●

●●●●●●

●

●●●●●●●

●

●●●●●●●●●●

●●

●

●

●●●●●●●●●

●

●

●

●●●●●

●

●●●●

●

●

●

●

●●

●

●

●

●●

●●

●●●●●●●

●

●●●●●●●●

●

●●●●●●

●●

●●●●

●

●●●●●

●

●

●●

●

●●●●●●●●●●●●●●●●

●

●

●

●

●●●●

●

●

●●

●●●●●●

●●

●●●●

●●

●

●

●

●

●

●

●●

●

●●

●●●

●

●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●●●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●●●

●

●●

●

●

●

●

●●

●

●

●

●●●●●

●

●

●

●

●

●●

●

●

●

●●●

●●

●

●

●●●●

●

●

●●●

●

●●

●

●

●

●●●

●

●

●●

●●●●

●

●

●

●●

●●

●

●●●

●●●

●

●

●●

●●

●

●●●●●●

●●

●●●●

●

●●●●

●

●

●●

●

●

●

●

●

●

●

●●●●

●●●

●●●●●●●

●

●

●

●

●

●

●

●●

●

●●●●

●

●

●

●

●

●

●

●●

●

●

●●●

●

●●●

●

●

●●●●

●●

●

●●

●

●●●

●●

●

●

●

●

●

●

●

●●

●

●●

●

●

●●

●●

●

●●

●

●

●

●●●

●●

●●

●

●●

●

●

●●●●

●●●●●

●

●

●●

●

●

●

●●●

●●

●●●

●

●

●●

●

●

●

●●

●

●●●●●

●●

●●●

●

●●●●

●

●

●●

●

●

●

●

●

●

●

●●

●

●

●

●●

●

●●●●●

●

●

●

●

●

●●

●

●

●

●

●●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●●●●

●●

●

●●

●

●

●

●●

●

●

●●●●●

●

●

●

●

●●

●●

●

●

●

●

●

●

●●●●

●

●

●

●

●

●●●●●●●●

●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●

●●

●

●

●

●

●

●

●

●●●●

●●

●●

●

●●

●

●

●

●

●

●

●●

●●

●●

●●

●

●●

●

●●

●

●

●●

●

●●

●●

●

●

●●●

●

●

●

●

●●

●

●●

●

●

●●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●●

●●

●

●

●

●●

●

●●

●

●●

●

●

●

●●●●●

●

●●●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●

●

●●

●

●

●

●

●●●

●●●●●

●

●

●

●●

●●

●

●●●●

●●

●

●

●

●

●

●●

●

●

●

●

●

●●●

●●

●

●

●●

●

●●

●

●

●●

●

●

●●

●●

●

●

●

●

●

●●

●●

●

●

●

●

●

●●

●

●

●

●

●

●●●

●

●

●

●

●

●

●●

●

●

●●

●●

●●●●

●●

●

●

●

●●●

●

●●

●

●●●

●●●

●●●●●

●

●

●●

●

●

●●●

●●

●

●●●

●

●●●●●●

●

●

●●●

●●

●

●●●

●

●●●●

●

●●●●●

●

●

●

●

●●

●●

●●

●

●

●●●

●

●●●

●

●

●●●

●

●●●

●

●

●●●

●

●

●●●●●●

●

●●

●

●

●

●●●

●●

●●

●●

●

●●

●

●

●●

●●●●●

●●

●

●●

●●●●

●●

●

●

●

●

●

●

●

●●

●●

●

●

●

●●

●

●

●

●●

●●

●

●

●●

●

●●●

●

●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●●●●

●

●

●

●

●

●

●

●●●●●●

●●

●

●

●

●●

●

●

●●

●●

●

●

●

●●●●●●

●●●●●

●

●●

●

●

●●

●●●

●●●

●

●●●●●●●●●

●

●

●

●●●

●

●

●

●●

●●

●

●●●

●

●

●

●●

●●●

●

●

●

●

●

●

●

●

●●●

●●

●●

●●

●

●

●

●●

●

●

●●●

●

●

●●●●

●

●●

●

●●

●

●

●●

●●

●

●

●●●

●

●

●

●●

●●●

●

●

●

●

●●●●

●

●

●●

●

●●●

●

●●

●

●

●

●●

●

●●

●

●

●●●

●●

●●

●●●●●

●

●

●

●

●●●●●●●●

●●

●●

●●●

●

●

●●

●

●●

●

●●

●

●●

●●●

●

●

●

●

●●●●

●

●

●

●

●

●

●●

●

●

●●

●

●

●●

●●●

●

●●

●

●

●

●

●●

●

●●●

●

●●

●

●

●

●

●

●●

●

●

●●

●●

●

●

●

●

●●

●

●

●●

●●

●

●

●

●

●●●

●

●

●

●●

●

●

●●

●

●●

●●

●

●●

●

●●

●●●

●●

●

●

●

●

●●●

●

●

●

●●

●●

●●●●

●●

●●

●

●●

●

●

●

●

●

●

●●

●

●

●

●●

●

●

●

●

●●

●

●

●

●

●

●●

●

●●

●

●

●

●

●●

●

●

●

●●

●

●

●

●●●●

●●

●

●

●

●

●

●

●

●●●

●

●

●

●

●●

●

●●●●

●

●

●

●

●

●

●●

●●

●

●●

●

●

●

●

●●

●

●

●●●

●●

●●

●

●

●

●

●

●

●

●●●●

●

●

●

●●

●

●●●

●●

●

●

●

●

●

●●●●

●

●●

●

●●

●

●

●

●

●

●

●●

●

●

●

●●

●

●●

●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●●

●

●

●

●●

●

●●

●

●●●

●

●

●

●

●

●●●

●

●

●

●

●

●●

●

●

●

●●●●

●

●●

●

●●

●

●●●

●

●

●●

●

●●●

●

●

●

●●●

●

●●●

●●

●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●●

●●●●●

●

●

●

●

●●●●●

●

●

●●

●

●●

●

●

●●●

●

●

●

●●●

●

●

●●

●

●

●●●●●

●

●●●●

●●

●

●

●●●●

●

●

●●

●

●●●●

●

●

●

●

●●●

●●

●●

●

●

●

●●●

●

●●

●

●●

●●

●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●●

●

●

●

●●●

●●●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●●●

●

●

●●●

●

●●●

●

●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●

●●

●●

●

●

●

●

●●

●

●●●●

●●●

●

●

●

●●

●

●

●●●

●●

●

●●●

●

●●

●

●●

●

●●

●

●

●

●●

●●●

●

●●

●

●

●

●●●

●●

●●

●

●●

●

●

●

●●

●●●●●●●●●

●

●

●

●●●●●

●

●

●●●

●

●●

●●●

●●

●

●●

●●

●●

●

●

●

●

●

●●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●●●

●

●●

●●●●

●

●●

●●●●

●

●

●●

●●

●

●

●●●

●

●●●

●

●●●●

●

●

●

●

●

●

●●

●●●

●

●

●

●●●

●●●

●●

●

●

●●

●●

●

●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●●

●●

●

●●

●●

●

●

●

●

●

●

●

●●●●

●

●

●

●

●

●●

●●●

●

●

●●

●

●●

●●

●

●

●

●

●●●

●

●●

●

●

●

●

●●

●

●

●●●

●●

●

●●

●

●

●

●

●

●

●●

●●●

●

●

●●

●

●●

●

●

●

●

●

●

●●●●●

●

●

●

●

●

●●

●

●

●

●●

●

●

●●

●●●

●

●

●●●

●●●

●

●

●

●

●●

●●

●

●

●

●●●

●

●

●

●●

●

●

●●

●

●

●

●

●

●

●●●

●●

●

●

●

●●●

●●●

●●

●

●

●

●

●

●●

●

●●●

●●

●●●

●●

●

●●●

●●●

●

●

●

●

●

●

●

●

●

●●

●●●

●●

●

●●●

●●●●●●●

●

●

●

●

●

●

●

●

●

●

●●

●●

●●●●

●

●

●

●

●

●

●

●●

●●●

●

●

●●●

●

●●●

●●

●

●

●●●

●

●●●

●●●●

●

●●●

●

●

●●

●

●

●●●

●●●●●

●

●

●●●●●●●

●●

●●●●

●

●

●

●●●●●●●

●●

●

●

●

●●●●●

●

●●●

●●●

●

●●●●

●

●●●●●

●

●●

●●

●

●●●●●●●●●

●

●

●

●

●●●●●

●●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●●

●●●●●

●●

●●

●

●

●●●

●

●

●

●●

●

●

●

●●

●

●

●

●

●

●

●●

●

●

●●

●●●●

●

●

●

●●

●

●●

●

●

●●

●●

●

●

●

●●●●

●●●

●

●

●

●

●●●●●●

●

●

●

●●●

●

●

●●●

●●●●●●●●

●

●●●

●

●●

●●●

●

●●●

●●●●●●●●●●

●

●●

●●●●●

●

●

●

●

●

●

●●●●●●●●●●●

●●

●

●●●

●●

●●●

●●

●

●

●●●●●

●

●●●●

●

●

●●●●●●●

●

●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●

●

●

●

●

●

●●

●●●●●

●

●●●●●●●●●

●

●

●

●●●●●●

●

●●●●●●●●●●

●●●

●

●

●●●●

●

●●●●●●●

●

●●●●●●●●

●

●●●●

●

●

●●

●

●●●●●●●●●

●

●●●●●●●●●●●

●

●●●●●●●●

●

●

●

●

●

●●●

●

●●

●

●●

●

●

●●

●

●●●●●●●●●●●●●●

●

●

●

●

●●

●●●●●●●●●●●●

●

●●●●●

●

●

●●●

●

●

●●●●●●●

●

●●●●●

●

●

●●●●●

●

●●●●●

●

●●●●●●●

●

●●●

●

●●●

●●●●●

●

●●

●

●

●●

●

●●●●●●●●

●

●●●●●●●●

●●

●●●●●●●●●●

●

●●

●

●

●

●●●●●

●●

●●●●●●●

●

●●●●

●●●●●●●●

●

●●

●

●

●

●

●●●●●

●

●●

●●

●

●

●

●●●●●●●●●●●●●●●●●●●●

●

●●●●●

●

●

●

●●●●●●●●

●

●

●

●

●●●

●

●

●

●

●

●

●

●●

●

●●●●●

●

●

●●

●

●

●

●

●

●●

●

●●

●

●

●

●●

●

●

●

●●●●

●

●

●●

●

●

●

●●●

●●●●

●

●●●

●

●●●●

●

●●●●●●

●

●

●

●

●

●●●

●

●

●

●

●●

●●

●

●

●

●

●

●

●●●●●

●●

●●

●

●

●●

●

●

●●●

●

●

●

●●

●

●

●

●

●

●●●●●●

●

●●

●

●

●

●●

●

●●

●

●●●●

●

●

●

●

●●

●

●●

●

●●●●

●●●●

●

●●

●●

●

●

●

●●

●

●●

●●

●●●

●

●

●

●

●●

●

●●●●

●

●

●●

●●

●

●●●●

●

●

●

●●●●

●●●

●

●●

●●

●●●●●

●

●

●

●●

●●

●

●●

●

●●●

●●●

●●●●

●

●●●●●

●●●●●

●

●

●●●●●●

●●●●●●

●

●

●

●

●●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●●●●●

●●●

●●

●●●

●●●

●●●●●●

●

●

●

●●

●●●●●

●●

●

●●

●●

●

●

●

●

●●

●

●

●

●●

●

●

●

●

●●●●●

●●●●

●●●●

●●

●

●

●

●

●●●●●●

●●

●

●●●●●●●●●

●●

●●

●●●●

●

●

●●●

●●

●●

●

●●●●

●

●●

●

●

●

●●

●●

●●●

●

●

●

●●●●

●

●

●●●

●

●●●

●●●●

●●

●

●

●

●

●

●●●

●●

●

●

●●●●●●

●

●●

●●

●

●●●

●

●

●

●●

●

●

●●●●●●

●

●

●

●

●

●

●●

●

●●

●●

●●●

●●

●●●●●●

●

●●●●●

●

●

●

●

●●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●●

●

●●

●●

●●

●●

●

●

●

●●●

●●

●

●●●●●●●

●

●●●

●

●●

●

●

●

●●

●

●●

●

●●●●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●●●

●

●●●●●

●●

●

●●●

●

●●

●●●

●

●●●●

●

●●

●

●●

●●

●

●

●

●

●●

●●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●●

●●●●●●●●●●

●

●

●

●

●●●

●

●

●●●●

●

●

●

●●

●

●●●●●●●●●●●●●●

●

●

●●●●●●

●

●●●●●●●●●●●●

●

●●●

●

●●●

●

●●●

●

●●●●●●●●●●

●

●●●●●

●

●●●●●●●●●●●●●●●●

●

●●

●●●●●●●●●●●●●●

●

●

●

●●

●

●

●

●●●●●●●●●●

●

●●

●

●●●●●

●

●

●●●●●●●

●

●

●

●

●●●●●●

●

●●●●●●●●●●●

●

●

●

●

●

●

●●●

●●●

●

●

●

●●●●

●●

●●●

●●●

●●

●

●

●

●●

●●

●●

●

●●●●●●●●

●

●

●

●

●●●●●

●

●●

●

●

●

●

●

●●●●●●

●

●

●●●

●

●●●

●

●●●

●

●●●●●●●●

●

●●●●●●●●

●●

●

●

●●●●

●●

●●●●●●●●●

●

●

●

●●●●●

●

●●●●●●

●

●

●●●●●

●

●●●

●

●

●

●●●●●●

●●●●

●●

●

●

●

●●●

●●

●

●●●●

●

●

●

●

●

●

●

●

●●

●●●

●●

●●●●

●

●

●●●

●●●●●●●●●●●●

●●

●

●

●●●●●

●

●●●●●●●●●●●●

●●

●

●●●●●

●

●●●

●●

●

●●

●

●

●●●

●

●●

●

●

●

●●●●

●

●●●

●

●

●

●●●●

●

●●●●●●

●●

●

●●●●●

●●●●

●●●●●●●

●●●●

●

●

●

●

●●●●

●

●●●●●●●

●

●

●●

●●●●●

●

●●●●

●

●

●●

●

●

●

●

●●●

●

●●●●

●

●●●●

●

●●●●●

●

●

●

●●

●

●●●●●●

●

●●

●

●●●●

●

●●

●

●●●●

●

●●●

●

●

●

●●●●●●●●●●●

●

●

●

●

●

●●●●

●

●●●●●●●●●●●●

●●

●

●●●●●●●●

●

●●●●●●●●●●●●

●

●

●

●●●●●●●●●

●

●●●●

●

●●●●●●●●●●●

●

●

●

●

●●●●●

●

●●

●●●●

●

●●●●

●

●●●●●

●

●

●

●

●

●●●●●

●

●●●●●●●

●

●

●

●●●●●

●

●●●●●●●

●●

●

●

●

●●●●●●●●●●●●●

●

●●●●●●

●

●●●

●

●

●

●●●●●●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●●

●

●

●

●

●●

●

●●

●

●●●●●●●

●

●●●●●●●●●●●

●

●

●

●

●

●

●

●

●

●●●●

●

●●●●●●●●●

●

●●●●●●●●●●●

●

●●●●● ●●●●●●●●

●

●●●●

●

●●●●●●●

●

●

●●

●

●●●●

●

●●

●

●

●

●

●●●

●

●●●●●

●

●●●●●

●

●●

●

●●●●

●

●

●

●

●●

●

●●●●●●●●●●●

●

●

●●●

●

●●

●

●

●

●

●

●

●●●●●

●●●

●

●●●

●

●

●●

●

●

●

●

●

●●

●

●●●●

●

●●●

●

●●●

●

●

●

●

●

●●

●

●

●●●

●●

●

●●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●

●●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●

●

●●●

●

●●●

●

●●●

●

●

●

●

●

●

●●

●

●●

●

●●●

●

●

●●

●

●

●●

●●●●

●

●

●

●

●

●●●

●●

●

●

●

●●

●●●●

●

●●

●●

●

●●●●●

●●

●

●●

●

●

●

●

●●

●

●

●●

●●

●

●

●

●

●●●

●

●●

●●

●●●●

●●●

●

●

●

●●

●

●●

●

●●●●●

●●

●

●

●

●

●●●

●●

●

●●●●●

●

●

●●

●●

●

●

●

●●

●

●●

●

●

●

●●

●●●

●

●●

●●●

●

●

●●

●

●

●●●

●

●

●●

●

●●●●●

●

●●●●●

●

●

●

●●●●●●●●●●

●●

●●●●

●

●

●

●

●●

●

●

●●

●●

●●

●

●

●●

●●

●●

●

●

●

●

●

●●●

●●

●

●

●●●●●

●

●

●

●

●●

●

●

●

●

●

●●

●●

●●

●

●

●●●

●

●

●

●●

●●●●●●

●

●

●●●

●

●●

●●

●

●

●

●●

●

●

●

●

●●●●

●●

●

●●●

●●

●

●●●

●

●

●

●

●●

●

●

●

●

●●

●

●●

●

●●

●●●

●●

●

●●●

●

●

●

●●●●●

●

●●●●

●

●

●

●●

●●●

●

●

●

●●

●

●

●●

●●

●●

●

●●

●

●

●

●

●

●●

●

●●●

●

●

●●

●●

●●

●●

●●●●

●●

●

●

●

●

●

●●●

●

●

●

●

●

●●

●

●

●

●

●

●●●

●

●

●

●●

●

●

●

●

●

●●●

●●●●●●●●

●●●

●

●

●

●●●●

●

●●

●

●

●

●●

●

●●●●●

●

●●●

●

●

●●●●

●

●●●

●

●●●

●

●●●

●

●

●

●

●

●

●●

●●●●

●●

●●

●

●

●

●

●

●

●

●●

●●

●

●

●●●

●

●

●

●

●

●●●●

●●

●●●

●

●

●

●

●●

●

●

●●●●●●

●●

●

●

●●●

●●

●

●

●

●

●●

●●●

●

●

●●●

●

●●●●

●

●●

●

●

●

●●

●●

●

●

●●

●

●

●

●

●

●

●●●

●

●●

●

●

●●●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●●

●

●

●

●●

●

●

●

●

●

●

●

●●●

●●●●

●

●

●

●●

●

●

●

●

●

●

●

●●●●●●

●●

●

●

●●

●

●

●

●●●

●

●

●●●●●●●●

●●

●

●

●

●●

●●●●

●

●

●

●●

●●●●●

●

●●

●

●●●●●

●

●

●

●●●

●●

●●

●●

●

●●

●●

●●

●

●●●

●

●●●●

●

●●

●

●

●

●●

●

●

●

●

●●

●

●

●●●

●●

●

●●●●

●●●

●●

●

●

●●

●

●●●

●

●●

●●●

●

●

●

●●

●

●●

●

●

●

●

●

●

●●

●

●

●

●●

●

●●●●

●

●

●

●

●

●

●

●●●

●

●●●

●

●

●●●

●

●

●

●

●●

●

●

●

●

●●

●●●

●

●

●●●●

●●

●●

●

●

●●

●

●

●

●

●

●●

●●

●

●●●●

●

●

●

●●●●

●

●●●

●●

●

●

●

●

●●

●

●

●

●

●

●

●

●●

●●

●

●

●●

●

●

●

●

●

●●●●●

●

●

●

●

●

●

●

●●

●

●

●

●●

●●●

●

●

●●●

●

●●

●

●●

●

●●●●●●●

●●

●●●●●●●

●

●

●●●●●

●

●

●

●

●

●●

●

●

●

●

●●●

●

●

●

●

●●●

●

●

●

●

●

●●●

●

●

●

●

●●●

●

●

●●

●

●

●

●

●

●

●

●●

●

●

●

●●

●

●

●●●

●

●

●

●

●●

●

●

●

●

●●

●●●●

●

●

●

●●

●●●

●

●●

●●

●

●●

●●●

●

●

●

●●●

●●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●●●

●●

●

●

●

●

●

●●●●●

●●●

●●

●

●●

●

●

●●●●

●

●

●

●

●●

●

●●

●●

●

●

●

●

●

●

●

●●

●●

●●

●●

●

●●

●

●

●

●●

●●

●

●

●●●●

●●●●●

●

●

●

●●●●

●●

●●●●

●

●

●

●

●

●

●

●

●●

●

●

●●●●●

●

●

●

●

●●●

●●

●●●

●

●

●●●●

●

●

●

●●●

●●

●

●●●

●

●●●●

●

●

●●

●

●

●

●

●

●●

●

●

●

●

●●

●

●●●

●

●

●●●

●

●

●

●●●

●

●●

●●●

●

●

●●●

●

●

●●●●

●

●

●●

●●●

●

●●●

●

●

●

●●

●●●

●

●

●●

●

●

●●

●●●

●

●●●●●

●

●

●

●

●●

●

●

●

●●●●

●

●●●●

●

●

●

●

●●●●

●

●●●

●

●

●

●

●

●

●

●●●●●

●

●●

●●●

●

●

●

●●●●

●

●

●

●●

●

●

●

●●●●

●

●

●●●

●●●●

●

●

●●

●

●●●

●●

●

●●●●●●●

●●●●

●●

●

●

●

●

●

●●

●

●●

●●

●●●

●

●●

●

●●

●●

●●

●

●

●●

●

●

●

●●

●

●●●●

●●

●●●

●●

●

●

●

●

●

●

●

●

●●●

●

●

●●

●

●

●

●●●●

●

●

●

●●

●●

●●●

●

●●

●

●●●●

●●

●

●●●

●

●●●●

●

●

●

●

●

●●●

●

●

●●●●●●

●

●

●

●

●●●●

●●

●

●

●

●●

●

●

●●

●

●

●●

●

●

●●

●

●●●●

●

●

●

●

●●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●

●

●●

●●●●

●

●●

●

●

●

●

●

●●●●●

●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●●●

●

●●●

●

●

●●●

●

●●

●

●

●●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●●●●●●●●●●●

●

●

●

●

●

●●

●

●

●●

●●●

●●●●

●●●

●

●

●

●

●

●

●

●●

●

●

●●●●●

●

●

●

●●●

●●

●

●

●●●

●●

●●

●

●●

●●●●●

●●

●

●●●

●●

●

●●

●●●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●●

●

●

●

●

●

●

●●

●

●●●●●

●●

●

●

●

●●

●

●

●

●

●●●

●

●●

●

●

●

●

●●

●

●

●

●

●●●●●●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●

●

●●

●●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●●●

●

●

●

●

●●

●●

●

●

●

●

●●

●

●●●

●

●

●

●●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●●

●

●

●

●

●

●●

●

●

●

●●

●

●●●

●●●●●

●●

●

●

●

●

●

●

●●

●

●●

●

●●●

●

●

●

●

●

●

●●

●

●●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●●●

●

●●●

●

●●

●

●

●

●

●

●

●●●●

●●

●●

●

●

●●

●

●

●

●

●

●●

●●

●●

●

●

●

●●

●

●

●

●

●

●●●●●●●●●●

●●●●

●

●●

●

●●●●●

●

●

●

●

●

●●

●

●

●●

●●●

●

●●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●

●

●●●●

●●●

●

●

●

●

●●

●●

●

●

●

●●●

●

●

●●●●●

●

●

●

●

●

●

●●●

●

●

●

●●●

●●

●

●●●

●

●

●

●●●

●

●●●●●●

●

●●

●●●

●

●

●

●

●

●

●

●●

●

●●●

●●

●

●

●●

●●

●

●

●

●●

●●●●

●●

●

●●

●

●

●

●●

●

●

●

●●

●

●

●

●●

●

●

●

●●

●

●

●

●

●

●●●●

●

●●

●

●

●

●●●

●●

●

●●

●

●

●

●

●

●●●●●

●

●

●●●●

●

●

●

●

●

●

●

●

●

●

●●●●●

●

●●

●

●

●

●

●●

●●

●●

●●

●●●●●

●

●

●

●●●

●

●

●

●

●

●

●

●●

●●●

●●●

●

●

●●●●●

●

●

●

●●

●

●

●●●

●●●●

●

●●●

●

●●●

●●

●

●

●

●●●●●●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●●●●

●●

●●

●

●

●●●●

●●

●

●

●●●

●●●

●

●

●

●

●●

●

●

●●

●

●

●●

●

●

●

●●●

●

●

●

●

●

●●●●●●●●●

●

●

●

●●●●

●●●

●●●

●

●

●

●●●●

●

●

●●●●●●●

●

●

●

●

●●●

●

●●●●

●

●

●

●

●

●●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●●●

●

●

●

●

●

●●●●●

●

●●

●●●●

●●

●●●●●●

●●

●

●●

●

●

●

●

●

●●●

●

●

●

●

●

●

●●●●

●

●

●

●●●●

●

●●●●●

●

●

●●

●

●●●●

●●

●

●●

●

●

●●

●

●

●●

●

●●●

●

●

●

●

●●●

●●

●

●

●●●●●

●

●

●

●

●

●●

●

●●●●

●

●

●

●●●

●

●

●●●

●●

●●●

●

●●

●

●

●●●

●

●●●●

●●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●●●●

●

●

●

●

●●

●●

●●

●

●

●

●

●

●●

●

●●

●

●

●

●●●●●

●

●

●

●●●●

●●

●

●●

●

●

●

●●●

●

●

●

●

●

●

●●●

●

●●

●●

●

●

●

●●

●

●

●

●●

●●●

●

●

●●

●

●●

●●●●

●

●●●

●

●

●●

●

●●

●●●

●●●●

●●

●●●

●●

●

●

●

●

●

●●●

●

●

●

●

●●

●●●●●●●

●

●●●

●

●

●●●●

●

●

●●

●●

●

●

●●●

●

●●

●

●

●●

●

●●

●●

●●

●

●

●

●●

●

●

●

●●

●

●

●

●

●●●

●

●

●

●●

●

●●

●

●

●

●

●

●●●

●

●

●

●●

●

●

●

●

●●●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●●

●

●

●●

●●

●

●

●

●●●●●

●

●●●●●●

●●

●

●●

●

●●●●

●●●

●●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●●●

●

●

●●●●●

●●●●●●●

●

●●

●●●●

●

●

●

●●●●●

●

●●●

●

●

●●●●●

●

●

●

●

●●

●

●

●

●●●●

●●●

●

●●

●

●

●

●

●●

●

●

●●●●●

●●●

●

●●●

●●●●●●

●●

●

●●

●

●●

●

●

●●

●

●●

●

●

●

●

●

●●

●●

●

●●●

●

●

●●●●

●

●●

●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●●●

●

●

●

●

●

●●●

●●

●

●●

●●

●

●●

●●

●

●●

●

●

●●

●

●●●●●

●

●●●

●●●●

●●●●

●

●●

●

●●

●

●

●

●

●●

●

●●

●

●

●

●●●

●●

●●

●●

●●

●

●

●

●●

●●

●●

●

●

●●●●●

●●●

●

●●

●●

●●●●

●●●

●●

●●

●

●●

●●●

●

●●●●

●

●●●●

●

●

●●●●●●●●●●●●

●●●●●●

●

●

●●

●●

●●●●●

●

●●

●●

●

●

●

●

●

●●

●

●

●

●

●

●●

●●●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●●

●●●

●

●

●

●

●

●●

●

●●

●

●●●●●

●

●●

●

●

●

●●●

●

●

●

●

●

●

●●●●●●

●

●

●

●●

●

●●

●

●●●●●●

●●

●

●

●

●

●●●●●

●

●

●

●●

●

●●

●

●

●

●●●●●●●●●

●

●

●

●

●●

●

●

●

●●

●

●●

●

●

●●

●

●●

●

●

●

●

●●

●

●

●●

●●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●

●●

●

●

●

●●●●●●●●●●●●

●

●

●●

●

●

●

●

●●

●

●

●

●

●

●●●●●

●

●

●

●

●

●

●●

●

●

●●●●●

●

●●●●

●

●

●●●●●●●●●●●

●

●●

●

●●

●

●●

●

●●

●

●●

●

●

●

●●●●

●

●

●●●

●

●

●

●

●●●●●●

●

●

●

●

●●

●

●

●●

●●

●

●

●

●

●

●●

●

●

●

●●

●●

●●●

●

●●●●●●●●

●

●●●

●●

●

●●●●●●●

●

●

●

●

●●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●

●

●

●●●●●

●

●

●

●

●●●●●

●●●

●

●●●●

●●

●

●

●●

●●

●●●●

●

●●

●

●●

●●●

●

●

●●

●

●

●

●

●

●

●●

●●●●●●

●●●●

●

●

●

●

●

●

●●●

●●●

●

●●●●●●●●

●

●

●

●

●

●

●●

●●●

●

●

●

●●

●●

●

●●●

●

●

●●●

●

●

●●

●●●●●●

●

●●

●

●

●●

●

●

●●●

●●●●●

●

●●

●●●

●

●●●

●

●

●●●●●●●

●

●

●●

●

●

●

●

●

●

●

●●

●

●●

●●●●●●●●

●●

●

●●

●●

●●●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●●●●

●

●

●●

●

●●●

●●

●

●

●

●

●

●

●

●

●

●●

●

●●●●

●

●

●●●

●

●●●●

●

●

●

●●●●●

●

●

●

●

●●●●

●

●●

●

●●●●●

●

●●

●

●

●●

●

●

●

●

●●●●●

●

●

●

●●●●●●

●

●

●

●

●●●●●●

●

●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●●●

●●●

●

●

●

●

●

●●●●

●

●●

●

●●●●●●●

●

●

●

●

●

●

●●●●●●

●

●

●●●●

●

●●

●●●

●

●

●●

●

●●●●●

●

●

●

●

●

●●●

●

●

●●●

●

●

●

●●

●●●●●●●●●●●●●●●●

●

●●

●

●●

●

●●

●

●

●

●●

●

●

●

●●

●

●

●●●

●●

●

●

●●

●

●

●

●

●

●

●●●

●

●

●●●

●

●

●

●

●

●

●●

●

●●●●●●

●

●●●

●

●●●●●●●●●●●●●●

●●●

●

●

●●

●

●●●●●

●

●

●

●

●

●

●

●

●●

●●

●

●

●●●●●

●●●

●●●●

●●●

●

●●●

●●

●

●

●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●●

●

●●

●

●

●●●

●●

●

●

●

●

●

●

●

●●●●●

●

●

●

●●

●

●

●

●

●

●

●●●

●●●

●

●●●●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●

●●●

●

●

●

●●●●●●●●●●

●

●●

●

●●●●●

●●

●

●

●

●●

●

●

●

●

●●

●●

●●●●

●●

●

●

●

●

●

●●

●●

●

●●

●

●●●●

●●

●●●●

●

●

●

●

●●

●

●

●

●●●●

●

●

●

●●●

●

●

●

●●●

●●

●

●●

●●

●●

●●●

●

●●●●●●●●●

●

●●●●●

●●●●●●●

●●

●

●

●●

●

●

●

●●

●

●●

●

●●

●

●●●

●

●

●

●

●●●●●

●●●●

●●

●

●●●●●

●●

●●●●●

●

●

●

●●●

●

●

●●

●

●

●

●●

●●

●●●

●

●

●●

●

●●●●●●

●

●

●●

●●

●

●

●

●●●●●●

●●●●

●●

●

●

●

●

●

●●●

●

●●

●●

●

●

●

●●

●

●●

●●

●

●

●

●

●

●

●

●

●●●●●

●

●

●●

●

●●●●●●●●

●

●●●●●●●●●●●●

●

●●●●

●

●●●●●●●●●

●●

●●●●●

●

●

●

●●●●●●●●●

●

●●●●●

●

●

●●

●●●●●●●

●

●

●●

●

●●

●●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●●

●

●

●●

●

●

●

●

●●

●

●

●●

●

●

●

●

●●

●

●●

●

●

●●

●

●

●●●

●

●

●

●

●

●

●

●

●

●●

●

●●●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●●●

●●

●

●●

●

●

●

●●●

●●●●●

●●

●

●●

●

●

●

●●●●

●

●

●

●●●●●

●●●●

●

●

●

●

●●●●●●●

●

●●●●●●●

●

●

●

●

●

●

●●

●

●●●●●

●●

●

●●●

●●

●

●

●

●●

●●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●●

●●

●

●

●●●●

●

●

●

●

●

●

●

●●●●●●●●

●●

●

●

●

●

●

●

●●

●

●

●

●

●●

●●

●

●●●

●

●

●

●

●

●

●

●

●

●●●●●●

●

●

●

●

●

●

●●●●

●

●

●●

●

●

●

●

●

●●●●●●●

●

●●

●●●

●

●

●

●

●

●

●●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●

●

●●

●

●●

●

●

●●●

●●

●●

●

●

●

●●●●●

●●

●

●●●

●●●

●

●●●●

●

●

●●

●●

●

●

●

●●●

●●

●●

●●

●●

●

●

●

●

●●●●

●●●

●●●●●●

●

●

●●

●●●●●

●

●●●●

●

●●●●●●●

●

●

●

●

●●●●●●●●●●●

●●

●●

●

●

●

●

●

●●

●●

●

●

●

●●

●●

●

●●

●

●●●●

●●●●

●●

●

●●●●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●●

●●

●●●

●

●

●

●

●●●

●

●

●●

●

●●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●

●

●

●●●

●

●

●

●

●●●

●

●

●

●●●

●

●

●

●

●●●

●

●

●

●

●●

●

●

●●●

●

●

●●●●●

●

●

●●

●

●●

●

●

●

●

●●●●●

●

●●●●

●

●●●●●●●●

●

●●

●●●●

●●

●●

●

●●

●

●●●●●

●

●

●●

●●●●

●

●●

●

●●●●

●

●●●●●●●●●●

●

●●●

●

●

●●●●●●●●●●●

●

●●●

●

●●

●

●●●

●●●

●

●

●●●●

●

●

●●

●

●●●●●●●●●

●

●●●●●●●●

●

●

●

●

●●●●●●●●●●●●●●●●●●●●●●

●

●●

●

●●●●●●●

●

●

●●●

●●●●

●

●

●

●

●●

●

●●

●

●●●

●

●

●

●

●●●●

●

●●●●●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●●●●●●

●

●

●

●

●●

●

●

●●

●

●

●●●●

●

●●

●

●

●

●

●

●●

●●

●●

●●●●●●

●

●

●●●●●

●

●

●

●●

●

●●●

●●

●

●

●●●●●●

●●●

●

●●

●

●●●●●●●

●

●

●●●

●●

●

●●●

●

●●

●

●●●●●

●

●

●●

●

●

●

●●●●●

●●

●

●●

●●

●

●●●●●●●

●

●●●

●

●

●

●

●●●●●●●

●

●●

●

●●

●●

●●

●●●●●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●

●●●●●●●●●●●●●

●

●

●

●●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●●●●●●●●●

●

●●

●

●

●●●●

●

●●●●

●●

●●●●●●

●

●●●

●

●●

●●●

●

●

●●

●

●●●●●

●●

●●

●

●●

●●

●●●●●

●

●

●●●●●

●

●

●●

●

●●

●●●●●

●

●

●●●●

●●●●

●

●

●●●●●●

●

●

●

●●

●●●●

●

●

●

●●●●●●

●●

●

●●●

●

●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●

●●

●●●●●●●●●●●

●

●●

●

●

●●●●●●●●●●●●

●

●●●●●●●●●●●●

●

●●●●●●●●●●●●●

●●

●

●●

●

●

●

●●

●●●●●●●●

●

●

●●●●●●●●●●●●●●●

●

●

●

●

●

●●

●

●●●

●

●●●●

●●

●

●●●

●

●●●●

●

●

●

●

●●

●

●●●

●

●●●

●

●●●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●●

●

●

●

●●●

●●

●●●

●●●

●●●

●

●●

●

●

●●

●

●

●●

●●

●

●

●

●●●●

●

●

●

●●●●

●

●●

●●

●

●

●

●●●●

●

●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●

●●

●●●●●●●●●●●

●●

●●●

●

●●

●

●

●

●

●

●

●

●●●●

●

●●●●●●●●●

●

●●

●

●

●

●

●

●●

●

●●

●

●●

●●

●●●

●●

●●

●●●

●●

●

●

●●●

●

●●●

●

●●

●

●

●

●●●●●●

●

●

●

●●

●

●●●●●●

●

●

●

●

●●

●

●●

●

●●

●●

●●●●

●

●

●

●

●●

●●●

●●

●●●

●

●

●

●

●●

●

●●

●●●

●

●●●

●●

●●

●

●●

●

●

●

●

●

●●●●●

●

●●●

●●

●●

●●

●

●●

●●●●●

●●

●

●●

●●

●

●

●●

●

●●●●●●●

●

●

●●●●

●●●

●●

●

●●●

●

●

●●●●●●

●●

●

●

●

●●

●

●●

●●

●●

●

●●

●●

●

●●●

●●●●

●●●

●●●

●

●●●

●●●●

●

●

●●

●●

●

●●●

●●●●●

●

●

●

●

●●

●●

●●

●

●●●●

●

●●

●

●

●●

●

●●

●●

●

●●●●

●

●

●●

●●●

●

●

●

●

●

●

●

●●

●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●

●

●

●●●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●

●●

●

●

●●●

●

●

●●●

●

●●

●

●

●

●●●

●

●●

●

●

●

●●

●

●

●●

●

●

●

●

●

●●●●●

●

●●●

●

●●

●

●

●

●

●

●

●

●

●●

●

●●●●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●●●●

●●

●

●

●●●

●●

●●●●

●

●●●●●

●

●

●

●

●

●

●

●●●●●●●

●●●●●

●

●●

●

●●●

●●●

●

●

●

●

●

●●●●●

●●●●●

●

●

●

●●

●

●

●

●

●●●●●●

●●

●●

●

●

●

●●●●●

●

●

●

●●

●

●

●

●

●

●●

●

●●●●●●

●

●

●

●

●

●

●●

●●●●●

●

●●

●

●

●

●

●

●

●

●●●●

●

●●●

●

●●

●●●

●

●

●

●●●

●

●●●●

●

●●

●

●●●

●●●

●●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●

●

●

●●

●●

●

●

●

●●●●

●●●●

●●

●●

●

●

●

●●●●

●

●

●●

●

●

●●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●●

●●

●

●

●

●●

●

●

●

●●●

●

●

●●

●

●

●●●●

●

●

●●●●●

●

●

●

●

●●

●

●

●

●●●

●

●●

●

●

●

●●●●

●

●●

●●

●

●

●

●

●

●●●

●●

●

●●●●●

●

●

●

●

●●

●

●●●

●

●

●

●

●

●●

●●

●●

●●

●

●●

●

●

●●●

●

●

●

●●●●

●

●●

●●

●

●●●

●

●

●

●●●

●

●●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●●●

●

●

●

●

●●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●●●

●

●●

●

●

●●●●●●

●

●

●

●

●●

●

●

●

●

●●●●

●

●●

●●

●

●

●●

●

●●

●●

●

●●

●

●●●

●

●

●●●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●

●

●●

●

●●

●

●●

●

●

●

●●

●

●●●

●

●

●

●

●●

●

●

●

●

●

●●

●

●

●

●

●●

●

●●

●

●●

●

●●●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●

●

●

●●

●

●

●

●●●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●●●●●

●

●●●●●●

●●●●

●●

●

●

●

●

●●●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●●

●●●●

●

●

●

●

●

●

●

●

●

●●●●●●

●

●●●

●

●

●●

●●

●

●

●●●

●

●

●●●●

●●

●

●

●

●

●

●

●●●●

●

●●●

●

●

●●

●

●●●

●

●

●

●

●●

●

●

●●●

●

●●●●●●●●

●●●●

●●●●

●

●●

●

●

●

●●

●

●

●

●●●●●●

●

●●●

●

●

●●●

●●

●

●

●

●

●

●●●●

●

●

●

●

●

●

●●●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●●●

●●

●●

●●

●

●

●●

●

●●

●●●●

●

●

●●

●

●

●

●

●

●

●

●●●●

●

●

●●●

●

●●

●●●●

●

●●●●●●●

●

●●●●

●

●●

●

●●●●●●●●

●

●●●●●●●

●●

●●●

●

●●●●●

●●

●

●

●●

●

●

●●

●

●

●

●●●

●

●●

●

●

●

●●

●

●●●●●

●

●

●●●●●●

●

●

●●●

●

●●●●●●●

●

●●

●

●

●●

●

●●●●

●●

●●

●

●

●

●

●

●●●●●●

●

●●●●●

●●

●

●

●

●●

●

●

●

●●●

●

●

●●

●

●

●

●●

●●

●●

●

●●

●

●

●

●

●

●

●

●●●

●

●●●

●

●●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●

●●

●

●

●●●

●●

●

●

●

●

●●●●●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●●●

●●

●●

●

●●

●

●

●

●

●●

●

●●

●

●

●

●●

●

●●●●

●

●●●●●●●●●●●●

●

●

●

●●●●●

●

●

●●

●

●●●●●

●

●●●

●

●

●

●●

●

●

●

●●●●●●

●

●●●

●●●●●●●●

●

●●●●●

●●●●●●●

●

●●●●

●●●

●

●●●●●●●●●●●●

●

●●

●

●

●●●●●●

●

●

●

●

●●●●

●

●●●●●●●●●●●●●●●●●

●●

●●●●●

●

●

●

●●●●

●

●●

●●●●●●●●●●●●●●●●●

●●

●

●

●

●●●●●

●

●

●●●●●●●●

●

●●●●●●

●

●●●

●●●●●

●

●●●●●

●

●

●

●

●●●

●

●

●●

●●

●●●

●

●●●●●

●

●

●

●

●

●●●●●●

●

●●●●●

●

●●●●

●

●●

●●

●

●●●●●●●●●●

●●

●

●●●●●●●●

●●●

●

●●●●

●●●

●

●●●●●●

●

●

●●

●

●●●●●●●

●

●●●●●●●

●

●

●●

●

●●

●

●●●

●

●

●

●

●●●●●●●●●●●●●●●●●

●

●

●

●●●●

●

●

●

●●●

●

●●●●●●●●●●●●●●●●●●●●

●●

●

●●●●●

●

●

●●●

●

●

●

●

●

●

●●

●

●

●●

●●●●●

●

●●

●

●●●●●

●

●●

●●

●●

●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●●

●

●

●

●●

●

●

●●

●

●

●

●●●●

●●●

●

●●

●

●

●

●

●●●

●

●

●

●

●

●●

●●

●

●

●

●●●

●

●

●

●

●●●●●●

●●

●●●

●

●

●●

●

●

●

●

●●●

●●●

●

●

●●●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●

●

●●

●●

●

●●

●

●

●

●

●

●●

●●●

●●●

●

●●

●●●

●

●

●●●●●

●

●

●

●●

●

●●

●

●●●

●●

●

●

●●●●

●

●

●●

●●

●

●

●

●

●

●

●

●●●●●

●

●

●

●●●●●

●

●

●●

●

●

●

●

●

●

●●●●●●●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●

●

●

●

●●●●●

●

●●●

●●

●

●

●●●●●●●●

●●●

●●

●

●●●●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●●●●●●●●●

●

●●

●

●

●

●●●

●●

●

●●

●

●

●●

●

●

●●

●

●

●

●●●●●●●●

●

●

●

●●

●

●●

●●●●●●

●

●

●

●

●●●●●●●●●●●●●

●

●

●

●

●●●

●●

●●

●

●

●

●●

●

●

●

●

●

●●●

●

●●

●

●

●●●●

●

●

●

●

●

●●

●●●

●

●●●

●●

●●●

●

●

●

●

●●●●

●

●●

●

●

●●●

●●●

●

●

●●

●

●●

●●●

●

●

●●

●

●●

●

●

●

●●

●

●●●●

●●

●●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●●

●●

●

●

●●

●

●●

●●

●●

●●

●

●

●●●●

●

●●

●

●●

●

●●

●

●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●●●●

●

●

●

●

●●

●

●

●

●●●

●●

●●●

●

●

●

●

●

●

●●

●

●

●●●●

●

●

●

●●

●

●

●

●

●●

●

●

●●●

●

●

●●●

●

●

●

●●

●●●

●

●

●●

●●

●●

●●●●●

●●

●

●

●

●●●

●

●

●●●●

●

●

●

●

●

●

●

●●

●

●

●

●●

●

●

●●

●

●

●

●

●

●●

●●●●●

●

●●

●

●●●●

●

●●

●●

●

●

●●

●

●●●

●

●●

●

●

●●

●●●

●

●

●

●●●

●

●

●●●

●

●●●

●

●

●●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●

●●

●●●●

●●

●

●

●

●

●

●

●

●

●●

●

●●

●●●

●

●

●●●

●●

●

●

●

●

●

●●●●●

●●

●

●

●●

●

●

●

●●

●

●

●

●●●●●

●

●●

●

●

●●

●

●

●

●

●

●●●

●

●●●●

●

●

●

●

●

●

●●●

●

●

●●●●●●●

●

●

●

●●

●

●

●

●

●●

●

●

●●

●

●

●

●

●●

●●

●●●

●

●●

●

●

●

●●●●

●●●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●

●●●

●●●●●●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●●

●

●●

●

●●

●

●

●

●●

●

●●

●

●

●●

●

●

●●

●

●

●

●

●

●●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●

●

●

●

●

●●●●●

●

●●●●●

●

●

●●●●●

●

●

●●●

●

●

●

●

●●●●●●

●

●●

●

●

●●

●●

●

●●●●

●●●

●●●●●

●●

●●

●●

●●

●

●

●

●●

●

●●

●

●●

●

●●

●●●●

●

●

●

●●●

●

●

●●●●●●●●●●●

●

●

●●●●

●

●

●●

●●

●●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●●●

●

●

●

●

●●

●●●●

●

●●

●

●

●

●●●

●

●

●

●●●●

●

●

●

●●

●

●

●●●●

●

●●●●

●●

●

●

●●

●

●●●●

●

●

●●●●

●

●●●●

●

●●●

●

●●

●

●

●●

●

●●

●

●

●

●●●

●

●

●●

●●

●

●●●

●

●●●●

●

●●●●●

●

●

●●

●●

●●●

●

●●●●●●●●●●●●●

●●

●

●

●●

●

●

●●

●

●

●●

●●●

●

●

●

●

●

●●

●●

●

●●●

●

●

●

●●

●

●●

●●●

●

●

●●●●

●

●

●

●

●

●●●●

●

●

●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●●

●

●

●●

●●

●

●

●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●●●●

●●●

●

●

●●●●

●●

●

●●

●

●●

●●

●

●

●

●●●●

●●

●●●●

●●

●●

●

●

●

●●●

●

●

●

●●●

●●

●●●●

●●

●●

●●●

●

●

●

●●

●●

●

●●

●

●●

●

●

●●

●

●

●●●●●

●

●

●●●

●

●

●●●

●●

●

●

●

●●

●

●

●

●

●●

●

●

●

●

●

●

●

●●●

●

●●●●●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●●●●●

●

●●

●

●●

●

●

●

●●

●

●●●

●

●●●●

●

●●●

●

●●

●

●

●●

●●●●

●

●

●

●●

●

●

●

●

●●

●●●●

●

●●●●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●

●●●●●

●

●●●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●

●

●

●●

●

●●●

●●●

●

●

●●

●

●

●

●

●●

●

●

●

●●

●

●●

●●●●●

●

●●●

●

●

●●

●

●●

●

●

●

●●

●

●

●

●

●

●●●

●●

●

●

●●●●

●●●●●●●

●

●●●●●

●

●●●●●●●●

●

●●●●●●●●●

●

●

●

●●●●●●●

●

●●●●●●●●●●●

●●

●●●●●●●

●

●●●●●●●

●

●

●

●

●●●

●

●

●●

●

●

●

●

●●●

●●●

●●

●●

●●

●●

●

●

●●●●

●

●

●

●

●

●●●

●

●●

●

●

●

●●●●●●●

●

●●

●

●

●

●

●●●●●●●●

●

●

●●●●●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●●

●

●●●●

●

●

●●●

●

●

●●●●

●

●

●

●●

●●

●●●

●●●●

●

●

●

●

●●●

●

●

●

●

●

●●●●●●

●

●

●●

●●

●

●

●

●

●●●●●●●

●

●

●

●

●●

●●

●●

●●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●●

●

●

●

●●

●

●●●

●

●●●●

●●

●

●

●

●

●●

●●

●●

●●●●●●●●●●

●●

●●●●●

●

●

●

●

●●●●●●●●●

●

●

●

●●

●

●●●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●●

●●

●●●●

●

●●

●

●●

●

●

●●●●

●●

●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●●●

●

●

●

●

●

●

●●●

●●●●

●

●

●●●●●

●●

●●●●

●

●●●●●●●●●

●

●

●

●

●●●●●●

●

●

●

●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●

●

●●

●●

●●●

●

●●

●

●●

●●

●

●

●

●●

●

●

●●●

●

●

●

●

●●●

●●

●

●●

●

●

●●●

●

●

●●●●

●

●●●●●●

●

●●●●●●●●●●●●●

●

●●●●

●

●●●●●●●●

●

●●●●●

●

●●●●●●●

●

●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●●●●

●

●●

●

●

●

●●●●●●●●

●

●●●

●

●

●

●

●

●

●

●

●

●●●●●●

●

●●●

●

●●

●

●

●

●●●●

●●●●●

●

●●

●

●

●

●●●●●●

●

●●

●

●

●

●

●●

●

●

●

●

●●●●●

●●●

●

●●●

●●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●

●

●

●●●

●

●●●●

●

●

●●

●●

●

●

●●

●

●

●●●●

●●●

●

●●

●●

●

●

●

●

●

●

●●

●●●●●

●

●

●

●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●

●●●●●

●

●●

●

●●●●

●

●

●●●●●●●●●

●

●

●

●

●●●

●

●●●

●

●

●

●●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●●●●●

●

●

●

●●

●

●

●

●●

●●●●●

●

●●●●●●●●

●

●

●

●

●●

●

●●

●

●●●●

●●

●

●

●

●

●

●●●

●

●●

●

●●●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●●

●●

●●

●

●●

●

●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●●●

●

●●

●●

●

●

●

●●

●

●

●●●

●

●

●

●

●●

●

●

●●●

●

●

●

●●

●

●

●

●●●

●●

●●●●●●●

●

●●●●

●●

●

●●

●

●

●

●

●

●

●

●

●●

●●

●

●

●●

●

●

●●●●

●

●

●

●●

●

●

●

●

●●●●

●

●●●●●

●

●

●●●

●

●●

●

●

●●●

●

●

●

●

●●

●

●●●

●

●●

●

●

●●

●

●●

●

●

●

●●

●

●●

●

●

●

●

●

●

●●

●●

●

●●

●●

●

●●

●

●●

●

●

●

●●●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●●

●●

●

●

●

●

●●

●●

●

●

●

●●●●

●

●

●

●●

●

●●●

●

●●

●

●

●

●●●●

●

●●●

●

●●

●

●●

●●

●

●

●

●●●

●●●

●●

●

●

●●

●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●●●

●

●

●

●

●●

●●

●

●

●●

●

●

●●

●

●

●

●

●●

●

●

●

●

●

●

●●●●●

●

●

●

●

●

●

●

●

●●●

●●●

●

●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●

●●●●●

●

●

●

●●●●●

●●

●●

●●

●

●

●●●

●

●●●●●●●●●

●●

●●●●●●

●●●●●

●

●

●

●●●●●

●

●●●●

●

●

●●

●

●

●●●●

●

●●●●●●●

●

●

●

●

●●●

●

●

●●●●●

●●

●

●●

●

●●●

●

●●

●

●●●●●●

●

●●●●

●●●

●

●●●●

●

●●●

●

●●●●●●●●●●

●

●●●●●

●●

●●

●

●●●●●

●●

●

●

●●●●●●●●

●

●●●●●

●

●●●●●●●

●●

●

●●●●●

●

●●●●●●●●●●●●●

●

●

●

●

●

●●●●

●

●●

●

●●●●

●

●●●●●

●

●

●●●●●●●●●●●●●●●●●●

●●●●

●

●●●

●

●●●●

●

●●●

●●

●

●●●●●●●●●

●

●●●

●

●●

●

●

●

●●●●●●●●●●●●●

●

●

●●

●

●●

●

●●

●

●●

●

●●●

●

●●●

●●

●●●●●

●

●●●●

●

●●●●●●

●

●

●●●●●●

●

●

●●●●

●

●

●●●●●●●

●

●●●●

●

●●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●●●●

●

●●●●●●●●●●

●

●●

●

●●●

●

●

●●●●

●

●

●

●

●●

●

●

●

●

●●

●

●

●●●●

●

●

●●

●

●

●

●●

●

●●●

●

●

●

●

●●●●

●

●●●

●●●●●●

●

●●●●●●

●

●

●

●●

●

●

●

●

●

●●●

●

●●●●●

●

●

●

●●

●

●

●

●●●●●●●●●●●●●●●●●●●

●

●●●●●

●●

●●●●

●

●●

●

●

●

●●●●

●

●●●●

●

●

●

●●●

●

●

●●●●●●

●

●●●●●●●●●●●●

●

●

●●●●

●

●

●

●●●●●

●●

●

●

●●●●●●

●

●●

●●

●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●●●●

●

●●●

●

●●

●●

●

●

●

●

●

●●

●

●

●●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●●

●

●

●

●

●

●

●

●●●

●●

●●●

●

●●

●●●

●●

●

●●●

●

●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●●●●

●

●

●

●●

●

●●●●

●

●●

●●●

●

●

●

●

●

●●●●

●

●●●

●

●●

●

●

●

●

●

●●●

●

●

●●

●●

●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●

●

●

●●●

●●●●

●●

●

●

●

●●

●

●

●

●

●●●●●

●

●

●

●

●

●

●●●

●

●

●●

●

●●●●

●●●

●●

●

●

●●

●●●●

●

●

●●●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●●

●

●

●

●

●●

●

●

●●

●

●●●

●

●

●

●●

●●●

●

●

●

●

●

●●

●●

●●

●

●●

●●

●●●●●●

●

●

●

●

●●

●

●

●

●●●

●●

●●

●●●

●

●●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●

●●●

●

●

●

●

●●

●

●●

●

●

●●

●

●

●●

●●●

●

●●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●

●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●●●

●

●●

●

●

●

●

●

●●●●●●

●

●●●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●●●●●

●

●●

●

●

●●●●

●

●●

●

●

●

●

●

●●

●●

●●●

●●

●

●

●

●

●●

●

●

●●

●

●

●

●

●●

●●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●●●●

●

●●

●

●

●●

●

●

●

●●

●

●

0

3

6

9

12

15

18

21

24

27

30

33

36

39

42

45

48

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

SNR

[dB]

netbook

●

●●●

●

●●●●●●●●●●●●●●●

●

●●

●

●

●

●

●●

●

●●●

●

●

●●●●●●● ●

●

●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●

●

●

●

●●●●●●●●●●

●

●●●

●

●●●●

●

●

●

●

●

●●●

●

●●●●●●

●

●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●● ●●

●

●●●

●

●●

●

●

●

●

●

●

●●●●●●

●

●●●●●

●

●

●●

●

●

●

●●●●●●●

●

●

●

●

●

●

●

●

●●

●

●●●

●

●●●

●

●

●●●●●●

●

●

●

●

●●●

●

●

●

●●

●●

●

●●●●

●

●

●

●

●●

●

●

●

●●●

●●

●●●●●

●●

●

●

●

●●

●●●

●

●

●

●

●

●●

●

●

●

●●

●

●●

●

●●

●●●●●

●

●

●

●●●●

●

●

●

●●●●●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●

●

●

●●

●●

●●

●●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●●●●

●

●●

●

●●

●

●●●●

●

●

●

●●

●

●●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●●

●●●

●●●●

●

●●●●

●

●

●

●●●●●●

●

●●

●

●●●

●

●

●

●

●

●

●●

●●●●●●●

●

●●

●

●●

●●●●●

●

●

●

●●●●●●

●●

●●●

●●

●

●

●

●●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●●

●

●●●●●

●

●

●●●

●●●

●

●

●

●●

●●

●●●

●●●●

●

●●

●●●●

●

●

●

●

●

●●●●

●

●●

●●

●

●●

●

●

●

●

●●●

●●

●

●

●●●

●

●●

●

●

●●

●

●

●

●

●

●

●

●●

●●●●●

●

●

●

●●

●

●

●

●●

●

●

●●

●●

●

●●

●●

●●

●●

●●

●

●

●

●

●●●●

●●

●●●●

●

●

●

●

●

●●

●●●●●

●●

●●●

●

●

●●

●

●

●

●●

●●●●●

●

●

●●●

●

●

●●

●

●●

●

●

●

●

●

●●●

●

●

●●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●●

●

●

●●

●

●

●

●●

●

●

●●

●●

●●

●

●

●●

●

●

●●●

●

●

●●

●

●●

●●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●●●

●

●●●●●●●

●

●

●●●●●●

●

●

●

●

●

●

●

●

●

●●

●●●●●

●

●●

●●

●

●●

●

●●●●

●

●

●

●●

●

●

●●●

●

●

●

●●●●

●

●●●

●

●

●

●

●●

●

●●●●

●

●●●●

●

●●

●●

●●●

●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●●

●

●

●●●

●

●

●

●

●●●

●●●●

●

●

●

●

●

●●●

●

●●●

●

●●

●

●●●

●

●

●

●●●

●

●

●

●

●●●●

●

●●●

●

●

●

●●●

●

●

●

●

●

●●

●

●●●

●

●

●●

●●●●●●●

●

●

●●●●

●

●

●●●●●

●●●

●

●

●

●

●

●

●●

●●●

●

●

●●●

●

●●

●●●

●

●

●

●

●●●

●

●

●

●

●●●

●●

●

●

●●

●●●●

●

●

●

●

●

●

●

●●

●●●●●

●

●

●●●

●

●●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●●

●

●●

●

●

●●●

●●

●

●

●●

●

●

●

●

●

●

●●

●●●

●

●

●

●

●●●

●

●●

●●

●●●●

●

●●

●

●

●

●

●●

●●●

●

●●●

●

●●

●

●

●

●

●

●●●

●

●●●●●

●

●

●

●

●

●

●●●●●

●

●

●

●

●

●

●

●

●

●●●●

●

●●●

●●

●●●●

●

●

●

●

●

●●

●

●●

●

●

●

●●●●●

●●

●●

●●

●

●

●

●●

●●

●

●

●

●

●●

●●●

●

●

●●●●

●●●

●

●

●●

●

●

●

●●●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●●

●

●

●●

●

●

●●●●●

●●●

●

●

●●

●

●●●●●●●●

●

●

●

●●●

●

●

●

●●

●

●

●

●

●●●●●●

●

●

●●

●

●

●

●

●

●●●

●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●●●

●●●

●

●

●

●

●

●

●●●●●●●●

●●●●●

●●●●●●●●●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●●

●

●●

●

●

●

●●●●

●

●

●●

●

●

●

●●●

●

●

●

●

●●

●●

●●

●

●

●

●

●

●●

●

●

●●●●

●●

●●●●●

●

●

●●●

●

●●●●

●

●

●

●

●

●●●●●

●

●

●●●

●●●●

●

●●

●

●●

●

●●●●●●●●

●●

●●

●

●

●●●●●●●●

●

●●

●●

●

●

●

●

●●●

●

●

●

●●●

●

●

●●

●

●

●

●●

●

●

●

●●●

●

●

●

●●●

●

●●●●

●●

●

●

●●●

●●

●●●

●

●●

●●

●

●

●

●

●●

●

●●

●

●

●

●

●●●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●

●●●

●

●

●

●

●●

●

●

●●●●

●

●

●

●●●

●

●

●

●●

●

●

●

●

●●●

●

●

●

●●●●●

●

●

●

●

●

●●●●

●

●

●

●

●

●●

●●

●

●●

●●

●●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●

●

●

●●

●

●

●

●

●●●●●

●

●

●

●

●

●

●

●●

●

●

●●

●

●●●

●

●

●

●

●

●

●

●

●●

●●●

●

●●

●

●

●

●

●●

●

●●●●●●

●●●●

●

●●

●●

●●

●

●

●

●●

●

●●●

●

●●●●●

●

●●●●●●

●

●

●●●

●

●●

●

●

●●

●●●●●●

●●●

●●●●●●

●●

●

●

●●●●

●

●

●

●

●

●

●●●●●

●

●●●●●

●

●●

●●

●●

●

●

●●

●

●●●●●●●●

●

●

●

●●●●

●●●●

●●●

●

●

●

●

●●●●●●

●●

●●

●●●

●

●

●●

●●●●●

●

●●

●

●

●

●

●

●●●●

●

●

●

●●

●

●

●●

●

●

●

●●●●

●

●●

●●

●

●

●

●●●

●

●●●

●

●●●●●●●●●

●

●

●●●●●

●

●●

●

●●●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●

●

●

●●●

●

●●●●

●

●●

●

●

●●●●

●

●●

●

●

●

●

●

●

●●

●●

●

●●●

●

●

●

●

●

●●●

●●

●●●●

●●

●

●

●

●●

●●●

●●

●

●

●

●

●

●●●●

●

●

●●●●●

●

●●

●

●●●●

●

●●

●●

●●●

●

●●●●

●

●

●●●

●●

●●

●

●●

●

●

●

●●

●

●●●

●

●●

●

●●

●

●●●●●

●●●

●

●

●

●●

●

●●

●

●●●●

●

●

●●

●●●

●

●●

●●

●

●

●●

●

●

●●●●

●

●

●●

●

●

●

●

●●

●

●●●

●

●

●●

●●

●●

●

●●

●

●

●●

●

●●●●

●

●●●

●

●

●●●●

●

●●●●●●●

●

●

●

●

●●

●

●

●●

●●

●

●

●

●●

●

●

●●

●

●

●

●

●●

●

●●

●

●

●

●

●

●●

●●

●

●●●

●●

●

●●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●●●●●●●

●

●●●

●

●

●

●●●

●

●●●

●●

●

●●

●●●

●●●

●

●●●●●

●

●●●

●

●

●

●

●

●

●●

●

●●●●●●●

●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●

●●

●●

●●●●

●●●

●

●●●●●●●

●

●

●

●●●

●

●●●

●

●●

●

●●

●

●

●

●

●●●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●

●●

●●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●●

●

●

●

●

●

●

●

●

●

●●●●

●

●

●

●●

●●●

●●●

●●

●

●

●●●

●

●●

●

●

●

●

●

●●

●

●

●●●●●

●

●●●●

●

●

●

●●●

●

●

●

●●●●●●●

●●●●

●●●

●

●●●●●●●●●●

●

●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●●●

●

●

●●

●

●

●●●

●

●●

●

●

●●●

●●

●●●

●

●●

●●

●

●●

●

●

●

●

●

●

●●

●●●

●

●

●●●●●●●●

●

●●●●

●

●●

●●

●

●

●

●●●

●

●●●●●●●●●●

●

●

●●●●●

●●●

●

●●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●●

●

●

●

●

●

●

●●●

●

●

●

●

●●●●●●

●

●

●●●

●●

●

●

●

●

●●

●

●●

●

●

●

●●

●

●

●●

●

●

●●●

●●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●

●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●●

●

●

●

●●

●

●

●

●●

●

●

●

●

●●●

●

●

●

●●

●

●

●

●●●

●

●

●●

●●

●●

●

●●●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●●●●●●●●

●

●●●

●

●●●●●

●

●●

●

●●

●

● ●●●

●

●●●●●●●●●●

●

●●●●●●●●●

●

●●●●

●

●●●●●

●

●●●●●●●●●●●●●●●●

●

●●●●●●●●

●

● ●●

●

●●

●

●

●

●

●

●●●●●

●

●●●●

●

●●●

●

●

●

●●●●●●●●●●

●

●●●●●

●

●●●●●●●●

●

●●

●

●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●

●

●●●●●●●

●

●●

●

●●

●

●●●●●●●

●

●

●●●

●

●●

●

●●●●●●

●

●●●●●●●●●

●

●●●●●●●

●

●

●●

●●

●

●

●

●

●

●

●●

●●●

●●

●

●

●●

●

●

●

●

●

●●

●●●

●

●

●

●

●

●●●

●

●●●●

●●

●●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●●

●

●

●●●

●

●●

●

●

●

●●

●

●

●

●

●

●●●●●

●

●

●

●

●

●●●

●

●●●

●●●

●

●

●●

●●●

●●

●

●●●●●

●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●●●●

●

●

●

●●●●

●

●

●

●

●●

●●

●

●●

●

●

●

●

●●

●

●

●

●

●

●

●

●●

●●

●

●

●

●

●

●

●●

●

●

●●●

●

●

●

●

●

●●

●●●●●●

●●

●●●

●

●●●

●●

●●

●●

●

●

●

●

●●

●

●

●

●

●

●

●●●

●

●

●

●●●

●

●

●●

●

●●

●

●●

●

●

●

●

●●

●

●●

●●●●●

●

●●

●

●

●●

●

●

●

●

●

●

●

●●

●

●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●

●

●●

●●●

●

●

●

●

●●

●●

●

●

●●

●

●

●

●

●●●●

●

●

●●

●

●●●

●

●

●●

●

●●

●●

●●

●

●●●●

●

●●●●

●

●

●

●●●

●

●●

●●

●

●

●●

●

●

●

●

●

●●

●●

●

●

●

●

●

●●

●●●●

●

●●

●

●●●●

●

●

●

●●

●

●●

●●

●

●

●

●

●

●●●

●

●

●

●●●

●

●●

●

●

●

●

●

●●

●

●

●

●●

●

●●●

●

●

●●●●

●

●●

●●

●●●●●

●

●●

●

●

●●●●

●

●

●●

●

●

●

●

●

●●●

●

●●

●●●●●

●

●●

●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●

●

●●●●

●

●●

●

●●●●●●

●

●●

●

●●

●

●●

●●

●●●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●●

●

●

●

●●

●

●

●

●

●●

●●●

●

●

●

●

●

●

●●

●●●●

●●

●●●●

●

●

●

●

●●

●

●

●

●

●●

●

●

●●

●

●

●

●

●●

●

●●

●●

●

●

●

●

●

●●

●●●●●

●●

●●●●

●

●

●●

●

●

●●●●

●

●●●●

●

●

●●

●

●●

●

●

●●●●●

●●

●●●●●

●

●

●

●●

●

●●

●

●●

●

●

●

●

●

●

●●●

●

●

●

●●

●

●●●

●

●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●●●

●

●●

●●

●

●

●●

●

●

●●●●

●

●

●

●

●●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●●●●

●

●●

●

●●

●

●

●

●●

●●

●

●

●

●

●

●

● ●

●●●●●

●●

●

●

●

●●

●

●

●

●●●

●

●

●

●●●●●

●

●

●

●●●●●

●

●●

●

●●●

●●

●●

●

●●●●●●●

●

●

●

●

●●

●

●

●

●

●●

●

●●●●●

●●

●

●●●

●

●

●

●●●

●

●●●

●

●

●●●

●

●●

●

●●

●

●

●●●●●

●

●

●

●●

●●●●●

●

●

●●●●●

●

●

●

●

●●

●

●●●●

●

●●●

●

●

●

●

●

●

●

●

●●

●

●

●●

●●

●

●●●●

●●

●

●●●

●

●●

●

●

●

●●●●●●

●

●

●●

●●

●

●

●●●

●

●●●●●●●●●●●●●●●

●

●●●

●

●●

●

●

●

●●●●●●

●

●●●

●●

●●

●

●

●

●

●●●●●●●

●

●●

●

●

●

●

●

●

●

●●●●

●

●●

●

●●●●

●

●

●●●●

●

●●●

●

●

●

●

●●●●●●●●

●

●●●●

●

●●●

●●

●●●●●●

●

●

●

●●●●●

●

●●

●

●

●

●●●●●●●●●

●●

●

●

●●

●

●●●●

●

●●

●

●●

●

●●●●●

●

●

●

●●●

●

●●●●●●●

●●

●

●

●●●

●

●

●

●●●

●

●

●

●●

●

●

●

●

●

●●●●

●●

●

●●●●●●

●

●

●

●

●

●

●

●

●

●●●

●

●●

●●

●●

●

●●●●●

●

●●●●●●●

●

●

●

●

●

●

●

●

●●●●●●●●●●●●●

●

●

●●

●

●

●

●●●●●●●

●

●●

●

●

●

●

●

●●●●●●●●●●●●●

●

●●●●

●

●

●

●

●

●

●●●

●

●

●●

●

●●●●

●

●

●●●●●

●

●●●

●●

●●

●

●

●

●

●

●●●●

●

●

●

●

●●●

●●●●●●●

●

●●●●●●

●

●

●

●

●

●

●

●●●●

●●●

●

●●

●

●●●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●

●●

●●

●

●●

●

●

●●

●

●●

●●●

●●●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●●●●

●

●●●

●

●

●

●

●

●

●

●

●

●●

●●●

●

●

●●

●●

●●

●

●

●●

●

●

●●●

●●●

●

●

●

●

●●

●

●

●

●●●

●●●●●

●

●

●●

●

●

●●

●

●

●●

●●●●

●

●

●●●●●

●

●

●

●

●●●●●●●●●●●●

●

●●●

●

●●

●

●●

●

●●●

●

●●●

●

●●

●

●

●

●●

●

●

●●

●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●

●●●

●

●

●●●

●

●●

●

●

●●

●●●

●

●●●●

●

●

●●

●●

●●

●

●

●

●●

●

●

●

●

●●●●

●●

●

●

●

●●●

●

●

●

●

●●

●

●●

●

●●●●

●

●

●●

●

●●●

●

●●●

●●

●●●●●●

●

●

●

●

●●●●

●

●●

●●

●●●●

●

●

●●

●

●

●

●

●●

●

●●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●●

●

●

●

●●●

●

●●

●

●●

●

●●

●

●

●

●●●

●●●

●

●

●●●●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●

●

●

●

●●●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●

●●

●●

●●

●

●

●

●●●●

●

●●●

●

●●

●

●●●

●●

●

●

●

●●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●●

●●●

●

●

●●

●

●●●

●●

●●

●

●

●●

●

●

●●

●

●

●

●

●

●

●●

●

●

●

●●

●

●●●●

●

●

●●

●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●

●●●●

●

●

●

●

●●

●●●

●●●●

●

●

●

●●●●

●●

●●●●

●

●●●

●

●●

●●

●●●

●

●

●

●●●●●●

●

●

●

●

●

●

●●

●

●●

●

●

●●●

●●●●●●●●●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●

●●

●

●

●

●

●●●●●●

●

●●●●

●

●

●●●

●

●●

●

●

●●

●

●

●

●●●

●

●●

●

●●●

●

●●

●●●

●

●

●●●●

●

●

●

●

●

●●

●

●

●

●●

●●

●

●●●●

●

●●●

●

●●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●●●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●●

●●

●

●

●

●

●●

●●

●●●●●●

●

●●●

●

●●●●●●●●●●●●●●

●

●

●

●

●●

●

●●

●

●

●●●

●

●

●

●

●

●●●

●

●●

●●

●

●●

●

●●●

●

●

●

●

●

●●●

●

●●●

●

●

●

●●

●

●

●

●●●

●

●●●●●●

●

●

●

●

●

●●

●

●

●

●

●●

●

●●

●

●

●

●●

●●●

●

●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●●

●

●

●●

●

●●

●●

●

●

●

●●

●●

●●

●●●

●

●●●●

●●

●

●

●

0

3

6

9

12

15

18

21

24

27

30

33

36

39

42

45

48

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

SNR

[dB]

laptop

●●●●●●●●

●●●●

●●●●

●●

●●●

●

●

●●●●

●●●●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

0123456789

101112131415161718192021

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

Powe

r−le

vel(d

ata)

[dBm

]

●● ●●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●●●●●●●●●●●●●●●●●

●●●●●●●●●

●●

0123456789

101112131415161718192021

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

Powe

r−le

vel(d

ata)

[dBm

]

Figure 5.19: Performance results of 2-Links with TCP traffic and w = 2.


0

2

4

6

8

10

12

14

16

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

Thro

ughp

ut [M

Bit/s

]

●

●●

●

●

●

●

●

●

0

2

4

6

8

10

12

14

16

18

20

22

24

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

Thro

ughp

ut [M

Bit/s

]

0.0

0.2

0.4

0.6

0.8

1.0

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

rela

tive

MAC

−sta

tes

MACstates


throughput weighting factor = 10

0.0

0.2

0.4

0.6

0.8

1.0

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

rel.

coun

t

datarate

125.56911121824364854

0.0

0.2

0.4

0.6

0.8

1.0

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

rel.

coun

t

datarate

125.56911121824364854

0

2

4

6

8

10

12

14

16

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

Thro

ughp

ut [M

Bit/s

]

laptop netbook

summary throughput

throughputper link

receivedsignal

strengh

adjustedtx-power

level

datarate

MACstates

●●●●●●

●

●

●

●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●

●

●●

●

●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●

●●

●●

●●

●●●●●●●●●●●●●●●●

●

●●●

●

●●●●●

●

●●●●●●●●●●●●●●●●●●●● ●●●●●

●

●●●●●●●●●●

●

●●●●

●

●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●

●●

●

●

●●●

●

●

●●●

●●

●

●●●●●

●●●

●●●●●●

●

●

●

●●●

●

●

●

●●●

●

●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●●●

●

●●●

●●

●

●●●

●●

●

●

●●●

●

●●

●

●

●

●

●

●●●

●●

●

●

●

●

●

●

●●●●

●

●

●●

●

●

●●

●●●

●●

●

●

●●●●●●●●●●●●●●

●●

●

●●●●●●●●●●●

●

●●

●●●●

●●●●

●●

●●●●●●

●

●●

●

●●●●

●

●

●●●●

●

●●●

●●

●●

●●●●

●●

●

●

●

●

●●●

●

●

●

●●●

●●

●

●

●●

●●

●●●●

●

●

●

●

●●●●

●●●

●

●

●

●

●●●

●●

●

●●

●

●●

●●●

●

●●

●●

●●●●●●●●●●●●

●●

●●

●●

●●

●●

●

●●●●

●

●

●

●●

●

●●

●●●●●

●●●

●●

●●

●

●

●●●

●●

●●●●●●●

●

●●●●●

●

●●●●●●

●

●

●●

●●

●

●

●●

●

●

●

●

●●●

●

●

●

●●●●●●●●●●

●

●●●

●

●●

●

●

●

●●●

●

●

●●

●●

●

●

●●

●

●●●

●

●●

●●

●

●●●●●●●●●●

●

●●●●●●●●●●●●

●●

●●●●●●●●●●●●●●●●●●●●

●

●

●

●●●●●●●●●

●

●●●●●●●●●

●

●●●●●●●●●●●●●●●● ●●●

●

●●

●

●●●●●●●●●●●●●●●●●●●●

●

●

●

●

●●●●●●●●●●●

●

●

●

●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●

●

●

●●●●●●●●●●●●●

●

●●●●●

●

●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●

●

●●●●●●●●

●●●●●●●●●●

●

●●●●

●

●●●●●●

●

●●●●●●●

●

●

●

●

●

●●●●

●

●●●

●

●●

●

●●●●

●

●●●●●●●●

●

●●●

●

●●●

●●

●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●

●

●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●●●●●●●●

●

●●●●

●

●

●

●●●●●

●

●●

●

●●●

●●

●

●●●●●●●●●●

●

●●●●●

●

●●●

●

●●●●

●

●

●●●●

●

●

●

●●●

●

●

●●●●●●●

●

●

●

●

●

●

●

●●●●●

●

●●●

●

●●●●●●●●●●

●

●●

●

●

●

●●

●

●●●

●

●●

●●●●●

●

●

●●●●●●●

●●●●●●●●●

●

●

●●

●●●

●

●●●●●●●●●●●●●●●●●●●●●

●

●●●

●

●●●●●●●●●●●

●

●

●●●●●●●●

●

●●●●●●

●●

●●●●

●

●●●●●

●

●●●●●

●●

●●●●●●●●●

●

●

●

●

●

●●●●●

●●

●●●●

●

●

●

●

●●●●

●

●●●●●●●●●●●

●

●

●

●

●

●

●●●●

●●

●

●

●

●

●

●

●

●

●●●●●●●●●

●

●●●●●●●●

●

●●●●●

●

●●●●●●●

●

●●●●

●

●●●●●●●

●

●●●●●●●

●

●

●

●●●●

●

●

●

●●●●●●●●●●●●●●●●●●

●

●

●

●●●

●

●●●●●●●●●

●

●●●●

●

●

●

●

●

●●●

●●●

●

●●●●●●

●

●●●

●

●●●

●

●●●●●●●●●●●●●●

●

●

●

●

●●●●●●●

●

●

●

●

●●●●

●

●

●

●●

●

●

●●●●●●●●

●

●●●

●

●

●

●

●●●●●●●●●●●●●●●

●

●●●●●●●

●

●●●●●

●

●●●

●

●●●●●●●●

●

●●●●●●

●

●●●●

●

●

●●●●●

●

●●

●

●●

●

●●

●

●●●●●●●

●●●

●

●

●

●

●●●●●

●

●●●

●

●●●●●

●

●

●●●●

●

●

●

●●

●

●●

●

●●●●●

●

●●●●●●●

●

●●●●●●●●

●

●

●●●

●

●●●●●●●●●●

●

●

●

●

●

●●●

●

●●●●●●●●●

●

●●●●

●

●

●●●

●

●●

●

●●●●●

●

●●●●●●●●●●●●●●●

●

●●●●●●●●

●

●

●●●●

●●

●

●●

●●

●●●●●●●

●

●●●●●●●●●●

●●●

●●●●

●

●●

●

●●

●●

●●●

●

●●●●●●

●●

●●●

●

●●

●

●●

●

●

●

●●●●●●

●

●●●

●

●●●●●●●●●

●

●●●

●

●

●

●●●●●

●

●●●●●●●

●

●●●●●●●●●●

●

●●●●●●●●●●●

●

●

●

●

●

●●●●●

●

●

●

●●●●

●

●

●

●

●

●

●

●●●●●●●

●

●

●

●

●●●●●

●

●

●

●●

●

●●●●●●

●

●●●●●●

●

●

●●●●●●●●

●

●●

●●

●

●

●●●●●●●●●●

●

●●●●●●●●

●

●●●●●●●●

●

●●●●●

●

●

●

●

●

●●●

●

●●●●

●

●

●

●●●●●

●●

●●●●●●

●

●●●●●●●

●

●●●

●

●●

●

●

●

●

●

●

●

●●●●●●●●●●●

●

●

●

●●●●●●

●●

●●●●●

●

●●●●●●●●

●

●●●●●●●●●●●●●●●

●

●

●

●●●●

●

●●●●●●●●●

●

●●●●●

●

●●

●

●●●

●●

●●

●

●●●●●●

●

●●●●●●●●●●●●●●●●●●

●

●

●●●●●●●●●

●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●●●●●●

●

●●●●●●

●

●

●

●●

●

●

●

●●●●●

●

●●

●●

●●

●

●●●●●●●

●

●●●●

●

●

●

●

●●●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●●

●

●

●

●

●●●

●

●

●

●

●●

●

●

●

●

●

●●●●●●●●●●●●●●

●●

●●●●●●●●●

●

●●●●●●●●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●●●●●●●●●●●●

●

●●

●

●●

●

●●●●●●●●●●

●

●●●●●●●●

●

●●●

●●

●●●●●●●●●●

●

●

●●

●●

●●●●

●

●●●●

●

●●●●

●

●●●●●●●

●

●●

●

●●

●

●

●

●●●

●

●

●●●

●

●

●

●

●●●●

●

●

●

●●●●

●

●●●●●

●

●●●●●●●●●●

●

●●●

●

●●●●

●

●●●●●●●●

●●

●●●●

●

●●●●●

●

●

●●●●●●●

●

●●

●

●●●

●

●

●●●●●●●●●

●

●

●●

●●●●

●

●●●●

●

●●

●

●●

●

●●●

●

●●●●●

●

●●●●

●

●

●

●●●●●●●●●●

●

●●●●●●

●

●●●●

●●

●

●

●●

●

●●

●

●●●●●●●

●

●●●●●●

●

●

●●●●●●●●●●●

●

●●●●●●●●

●

●●●●●●●●●●●●●●●●

●●

●

●

●●

●●

●

●

●

●

●

●

●●

●●

●●

●●●

●

●

●

●

●

●●●

●

●●

●

●●●●●●●●●

●

●

●

●●●●●●●●

●

●●●●●●

●

●●●

●

●●●●●

●

●●●●●●●●●●

●

●●●●

●

●

●

●●●●●●●●

●

●●●●●●●

●

●●●●●●●●●

●

●●●●●●

●

●

●

●●

●

●●●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●

●●

●●●

●

●

●●

●

●

●

●

●

●●●●●●●●●●●●

●

●●

●

●●●●●●

●

●●●●●

●

●●

●

●●●●●

●

●●●●●●●

●●

●●

●

●●●

●

●●●●●●●●

●

●●●●●●

●

●●

●●

●●●●●●●●●●●●●●

●●

●●●●

●

●●●●●●●●●

●

●●●●●●●●●●●●●

●

●

●

●

●●●

●

●●●●●●

●

●●●●●●●●●●●●●

●

●

●

●●●●●●●●●●

●●

●●

●

●●●●●●●

●

●

●●●

●

●●●●●

●

●●●●●●●●●●●●

●

●

●

●

●●

●

●●●●●●●

●

●●●●●●●●●●●●●

●●

●●●

●

●●

●

●

●

●

●

●

●●●

●

●

●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●●●●●●

●

●●●●●●●●●●●●●

●

●●●●●●●

●●

●

●●

●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●

●

●●

●

●●

●

●●●●●●●●●●●●●●

●●

●●●●●●●●●●●

●

●●●●●●●●

●

●●●●●

●

●

●

●

●

●

●

●●●●

●

●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●

●●●

●●●●

●

●

●

●●●●●●●●●●●●●●●

●

●●●●●●●

●

●●●●●●●

●

●●●●●●●●●●

●

●●●

●

●●

●

●●●●●●●●●

●

●●

●

●●●●●●●●●

●

●●●●●●●

●

●●●●●●●

●

●●

●

●●

●●

●●●●●

●

●●

●

●●

●

●●●●

●

●●●●●●

●

●

●

●

●

●

●●

●

●●

●

●

●●●

●

●

●

●

●●●●●

●

●

●●●●●

●

●●

●●●

●

●

●●●●●●●

●

●

●

●●

●●●●●

●

●●●

●●

●

●

●

●

●●●●

●

●●●●●●

●●

●

●

●●●●●

●

●

●

●

●●

●

●●●●●

●

●

●

●●●

●

●

●●

●

●

●●

●

●●

●

●

●

●●

●●●●

●

●●

●

●

●

●

●

●●●●

●

●●

●

●

●

●●●●

●

●●●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●●●

●

●●●

●

●●●●

●

●●

●

●

●

●

●●●

●

●●●

●

●●●●

●

●

●

●

●●●●

●

●

●●●●

●●●

●

●

●●

●●

●●

●

●

●

●

●

●

●●●●

●

●

●

●●

●

●●●

●

●●●

●

●●

●

●

●●

●

●●●●●●

●

●●●●

●

●●

●

●●

●

●

●●●●

●

●

●●

●●●

●

●●●●●●

●

●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●●

●●●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●●

●

●●

●

●●●●●

●

●●●

●

●

●

●

●

●●●●●●

●

●●●

●●

●●

●●

●●●

●

●●●●

●

●

●●

●

●

●

●

●

●

●

●●

●

●●

●

●

●●●●●●●●●

●

●

●●●

●●●

●●

●●

●

●

●

●

●

●

●

●●

●

●●●●●●●●●

●

●●●

●

●

●

●●

●

●●●

●

●●

●

●

●●●●●●●●●●●●●

●

●●●

●

●●

●

●

●

●●●●

●●

●

●

●

●

●●●●●●●●●●●●

●

●

●

●

●●●●●●●

●

●

●

●

●

●●●●●

●

●●●●

●●

●●●●

●

●●●●●●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●●●●

●

●

●●

●

●

●●

●

●●●●

●

●●

●●●●

●●

●

●

●

●●

●

●●●

●●

●

●

●

●

●●

●●

●

●

●

●●

●

●

●

●●

●

●

●

●●●●

●●

●

●●●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●●

●

●●

●

●●

●●

●●●●

●

●

●

●

●●●

●

●

●●

●●●●

●

●

●●●

●

●●●

●

●

●●●

●●

●

●

●●

●

●●

●

●

●

●●●

●●

●

●

●

●

●

●●

●

●●

●

●●●

●

●●

●

●

●●●●●

●

●●

●●●

●●●●●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●

●●●

●

●●

●●●●

●●●●

●

●●●●

●●●●

●●●●●●

●

●●●

●

●●

●●

●●

●

●

●●

●

●

●

●

●●●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●

●●●●●

●

●

●

●●

●●●

●●●●

●●●

●●●

●●●●●

●

●

●●●●●●●●●●●

●●

●

●

●

●●

●

●

●

●●

●●

●

●

●

●

●

●

●

0

3

6

9

12

15

18

21

24

27

30

33

36

39

42

45

48

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

SNR

[dB]

●

●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●

●

●●●●●●

●

●●●●●●●

●

●●●●●

●

●●●●●●●●●

●

●●● ●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●

●

●●●●●●●●●●

●

●●●●●●

●

●●●●●●●●●

●

●●●●

●●

●●●●

●

●●●●

●

●●●●●●●● ●●

●

●

●

●●●●

●

●●●●

●

●

●●●●●●●●

●

●

●

●

●

●

●

●●●●●●●

●

●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●

●

●●●●●

●

●●●●●

●

●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●

●

●

●●

●

●

●●●●

●●●

●

●

●●

●●

●●

●

●

●

●●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●●●

●●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●

●

●●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●●

●●

●

●●●●

●

●

●

●

●

●

●

●●

●●●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●●●●

●●●

●

●

●

●

●

●●

●

●●

●

●

●●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●

●

●

●

●

●●●

●●●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●●●●

●

●

●●

●

●

●

●●

●

●●

●●

●

●

●

●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●

●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●●

●

●●

●

●

●●

●

●

●●●

●

●

●

●●

●

●

●●

●●

●

●●

●

●

●

●

●

●

●

●●●

●

●

●●

●

●●

●

●

●●

●

●

●

●

●

●

●●

●

●●

●

●●

●

●

●

●

●

●

●●●●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●

●

●●

●

●

●

●

●

●●

●

●

●●●

●●●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●●

●

●

●●

●

●●●

●

●

●●●

●●●

●●●

●

●●

●

●

●

●

●

●●●

●

●

●

●●

●

●

●

●

●●

●

●●●

●

●

●

●

●

●●

●

●●●●●

●

●

●

●

●

●●

●

●

●

●●

●

●●●

●

●●●

●●

●●

●

●●●●

●

●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●●

●●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●●

●●

●

●

●

●●

●

●●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●

●

●●

●●●●

●●●●

●

●

●

●

●●

●

●●

●

●●●●

●

●

●

●

●

●●

●

●●●●●

●

●

●

●

●●

●

●●●●

●

●●

●●

●

●

●

●

●●

●

●

●

●

●

●

●●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●●

●●

●

●

●

●

●

●

●

●

●●●●

●

●

●

●

●●

●

●●

●

●

●

●●

●

●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●

●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●●

●●●●●●

●

●

●

●●

●

●

●●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●

●

●●●●●

●

●

●

●

●●

●

●

●

●

●

●

●●●

●

●●●●●●

●

●

●

●

●●

●

●

●

●

●●

●●

●●●

●

●

●

●●●●●

●

●

●

●●●●

●●●●

●

●●●

●●●●●●

●

●●

●

●

●

●

●●

●●

●●

●●●

●

●

●

●

●

●

●

●●

●●●

●

●

●

●

●●

●

●

●

●

●

●●●●

●

●

●

●

●

●●●

●

●

●●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●●●●●

●

●

●●

●

●

●●

●

●●●

●

●●

●

●

●

●

●

●●

●

●●●●●

●

●

●●●●●

●

●

●

●

●●

●

●

●

●●●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●●

●

●●

●

●●●●

●

●●

●

●

●

●●

●●

●●

●●●

●

●

●

●

●

●

●●●●

●

●

●

●

●

●

●●●

●

●

●●

●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●●●●●

●

●

●●

●

●

●

●

●●

●

●

●

●

●●

●

●●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●●

●●

●●

●

●

●

●●●●●●●●●

●

●

●

●

●

●

●●●●●●●●●

●

●●●●●●●

●

●●●●●●

●

●●

●

●●

●

●

●●

●

●●

●

●

●●

●

●●●●●●●●●●

●

●●●●●●●●●●●●

●

●

●●

●

●●●●

●

●●

●

●

●

●●

●

●●●●●●

●

●

●●●●

●●●●●

●●

●

●●

●●

●

●

●●●

●

●

●

●●

●

●

●

●●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●●●●

●●●

●●●●●

●

●

●

●

●

●●

●

●

●

●

●●

●

●●●●

●

●●

●●

●

●●

●●

●

●

●

●●

●

●●●●●

●

●●●

●

●●

●●

●

●

●●●●●●●

●

●●●

●

●

●

●●

●

●●

●

●●

●●

●

●

●

●●

●

●●●●●●

●

●

●

●

●●

●●●●●●●●●

●

●

●

●

●

●●

●

●●●●●●●●●●●

●

●●●●●●

●

●●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●●

●

●

●

●●●

●

●●●

●

●

●●

●

●

●●●

●

●

●

●

●

●

●

●●

●

●●●

●

●●

●

●

●

●

●

●●

●●

●

●

●

●●●●

●

●

●

●●

●●

●

●

●●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●

●●

●

●

●●●

●●●●●

●●

●

●

●

●

●

●●●

●●●

●

●

●●●

●●●

●

●

●

●

●

●

●●

●●

●●

●

●

●●●

●

●●●

●

●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●

●

●

●

●

●

●

●●

●

●

●

●●●●●

●

●

●●

●●

●

●

●

●

●

●●

●

●

●

●

●●●●●●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●●●●

●●●

●

●

●

●

●●●

●●●●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●●

●

●

●

●

●●

●

●

●

●

●●

●

●●

●

●●

●

●

●

●

●

●

●●●●

●●●

●

●

●

●●

●●

●●

●

●

●

●●●

●

●●

●

●

●

●

●

●●

●

●

●●●

●

●

●●●●●

●●●

●

●

●

●

●●

●●

●

●

●

●●

●

●

●

●

●●

●●●

●

●

●

●●

●●●

●

●

●

●

●●●

●

●●●●●●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●●

●

●

●

●●●●

●

●

●

●

●●

●

●

●

●●

●●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●●

●

●

●

●

●

●

●

●●●

●

●

●●

●

●●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●

●●●●

●

●●

●

●●

●

●●●●

●●

●●

●

●

●●●●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●

●

●●

●●●

●

●

●

●●

●●●

●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●●

●

●

●

●

●

●●

●●

●

●

●●●

●

●

●●

●●

●●●

●

●

●

●

●●

●

●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●●

●

●

●●

●

●

●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●●

●

●●●●

●

●

●

●

●●

●

●●

●●

●●

●●

●

●

●

●

●●●●

●

●●

●

●

●

●●●

●●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●●

●●●

●

●

●

●

●

●●●

●●

●●

●

●

●●●

●

●

●●

●●

●

●

●●●●

●

●●

●

●●

●●

●

●●●

●

●

●

●●●●

●

●

●

●

●

●

●

●●●●

●●●●●

●●

●

●

●

●

●●

●

●

●

●

●

●●●●

●●●

●

●

●

●

●

●●

●

●

●●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●●●

●●●

●

●

●

●●

●

●

●

●

●●●

●●

●

●

●●●

●

●●

●

●

●

●

●

●

●●

●

●

●

●

●●●●●

●

●

●

●●●●

●

●●

●

●●

●

●

●●●

●

●

●●

●

●●

●●●

●●

●

●●●

●●●●

●

●●

●●

●●

●

●

●

●●●

●

●

●●

●

●●●

●●●

●

●

●

●●●

●

●

●

●●

●

●

●

●

●

●●

●

●

●

●●

●

●

●

●●

●

●

●●

●

●

●

●●

●

●

●●

●

●

●●●

●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●●

●

●

●●●

●

●

●●

●●

●

●●●●●●●●

●

●

●

●●●

●

●

●

●●●

●

●●

●

●●●

●

●●

●

●

●

●

●

●

●●●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●●●●

●

●

●

●●

●

●

●

●●

●●●●

●

●

●

●

●●●●●

●

●●

●

●●●●●●●

●●

●●

●

●●●

●

●

●

●

●

●●

●

●●●●●

●

●●●

●

●

●

●

●

●●

●

●●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●●●●●●●

●

●

●●

●

●

●

●●

●

●

●

●●

●

●

●

●

●●●●

●

●

●

●●●●

●

●●●

●

●

●

●

●●●

●

●●

●●●●●

●●

●●

●●

●

●

●●●●●

●

●●●

●●

●

●●

●

●●●●●●

●●

●

●●●●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●

●●●

●

●●

●

●●●

●●

●●

●

●

●

●●

●●

●

●

●●

●

●

●

●

●●

●

●

●

●

●

●

●

●●●

●●

●

●

●

●

●●

●

●

●

●●

●●

●

●●

●

●

●

●

●

●

●

●●●

●

●●●

●

●

●

●●●

●

●●●●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●●●

●

●

●

●

●

●●●

●

●●

●

●●

●

●

●

●

●●●●

●●

●●

●

●

●

●●

●●

●●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●●

●

●

●

●●

●

●●

●

●●

●●

●

●

●

●●

●

●●

●

●●

●

●

●

●●

●

●

●

●●

●

●●●

●

●●●

●

●●

●

●

●

●

●●

●

●●

●

●

●

●●●●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●●●

●

●

●

●

●

●

●

●

●

●●

●●

●●

●●

●●

●

●

●●●●●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●●●●

●

●●●

●

●

●

●●●●

●

●

●

●

●●●●

●

●●●●●●

●

●●

●

●

●

●

●

●●●●

●

●

●

●

●●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●●●

●

●

●●●

●

●

●

●●●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●

●●●

●

●●●

●

●

●

●

●

●●●●●●

●

●

●

●

●●

●

●

●

●

●

●

●●●●

●●

●●

●

●

●

●

●

●●

●

●

●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●

●●

●●

●

●

●

●●

●

●

●

●●●●

●

●●

●

●●●

●●

●

●

●

●

●

●●●●●●

●

●

●

●

●●●●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●

●●

●

●

●

●●●

●

●●●●

●

●●

●

●

●

●●

●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●

●

●

●

●●

●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●●

●

●●

●●

●●●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●

●●●●

●

●

●●

●

●

●

●●

●

●

●●●●●●

●

●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●●●●

●

●

●

●

●●

●●

●

●

●

●●

●

●

●●

●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●

●

●

●●●●

●

●●●

●

●

●

●●●

●

●●

●

●

●

●●

●

●

●●●

●●

●

●

●●●●●

●

●●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●●

●

●

●●●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●●●

●

●

●

●●

●●

●

●

●

●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●●

●●

●●●●

●●●

●●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●●●●●

●

●●

●

●

●

●

●

●

●

●

●●●

●

●●

●

●

●

●

●

●●●

●

●

●

●

●●●●

●

●

●

●●●

●

●

●●

●

●

●

●

●

●

●●

●●

●●●●●

●●●

●

●●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●●

●●

●●●

●

●

●

●●●

●

●

●

●●

●

●

●

●●●●

●

●●

●●

●

●●

●

●

●

●●

●

●●

●

●●

●

●

●

●●●

●

●

●●

●

●

●

●

●

●●●●

●

●

●

●●●

●

●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●

●

●●●●

●

●●

●●

●

●

●

●

●●

●

●

●●

●

●

●●●

●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●

●

●●

●

●

●

●●

●

●

●●

●

●●

●

●

●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●●●

●

●●●●●

●●

●

●●

●

●

●

●●

●

●

●

●

●

●

●

●●●●

●

●

●●

●

●

●

●●

●

●●

●

●

●

●

●●

●

●

●●

●

●

●

●

●●●

●

●

●●●

●

●

●●●

●

●

●

●

●●

●

●

●

●

●

●

●●

●

●

●●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●●

●●●

●●

●●

●

●

●●

●●

●

●

●●

●

●●●●●

●

●

●

●●

●●

●

●●●●

●

●

●●

●

●

●

●

●

●●●●●

●

●●●●

●

●

●●●

●

●

●

●

●

●

●

●

●

●

●●●●●

●●●

●

●

●●

●

●

●

●

●

●●●●

●

●

●

●

●

●●

●

●

●●

●

●

●

●

●

●

●●●●

●●●

●●

●●●●

●

●

●

●●

●

●

●●

●●

●

●

●●●

●

●●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●●

●

●

●

●

●●●●

●

●●

●●

●

●

●●●●●●●

●

●

●

●

●●●●

●

●

●●●●●●●●●●●

●

●●●●●●

●

●●

●

●

●

●

●

●

●●●●

●

●

●●●●●

●●●●●

●

●●●●●●

●

●

●●●

●

●●●●●●●

●

●

●

●

●●●●●

●

●

●

●●●●

●

●

●

●

●

●●

●●

●

●

●●

●●

●

●

●●

●●●●●●

●

●●●●

●

●

●

●●

●

●

●●

●

●●

●

●

●●●

●

●

●

●●●●●

●

●●

●

●●

●

●

●

●

●

●●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●●

●●

●

●

●●

●

●●

●

●●●

●

●

●

●

●

●

●

●

●●

●●●

●

●

●

●●●●●●●●

●

●

●

●●●●●●●●●●●●●●●●●

●●●●

●●

●

●●●●●●●●●●●●●

●

●●●

●

●

●

●●

●

●●

●

●

●

●

●●

●●●●●●●●

●

●●●●

●

●●●●●●●

●

●

●●●

●●●●●●

●

●

●

●●●●●●●●●●

●

●

●●●

●●

●●

●

●●●●

●

●

●

●●

●●

●●●● ●

●

●●

●

●●●

●

●

●●

●●●●●

●

●●●

●

●●

●

●

●

●●●●

●

●●●●●●●●●●

●●

●

●

●

●●

●

●

●

●

●●●●

●

●●●●

●

●

●

●

●●

●●●●●

●

●

●

●

●

●●●

●

●

●

●●

●●●●

●●●●

●

●●

●

●●

●●

●

●●

●

●

●

●

●●

●●●

●

●

●

●

●

●

●

●●

●●●●●

●

●●

●

●●

●

●

●

●

●

●

●

●

●●

●●●●●

●●●

●

●●

●

●●●●

●●●

●

●

●

●●●●●●●●

●

●

●●

●

●●

●

●

●

●●●

●

●●

●

●

●

●

●

●

●●

●●●●●●

●●

●

●

●

●●

●

●

●

●

●●●●

●

●

●

●●●

●

●

●●

●

●

●

●●

●●

●

●●●●●●●

●

●

●●

●

●●●

●

●●●●

●●

●●

●

●

●

●●●

●

●●

●

●

●

●

●●

●●

●●●

●

●

●●

●●●

●

●●

●●●

●

●

●

●

●

●

●●

●●

●●

●●●●●

●●

●

●

●●●

●

●

●

●

●●

●●●

●

●●●●

●

●

●●●●●

●

●

●

●

●

●●●●

●

●

●

●●

●

●

●●●

●

●●

●

●

●

●

●●

●●●●

●

●

●

●●

●●

●●

●

●

●

●●

●

●●●●

●●●●

●●

●

●●

●

●●

●●

●

●●●●

●●●

●

●●●●

●

●

●

●●●●

●

●

●●

●

●●

●

●

●

●

●

●

●●●

●

●●

●

●●●●●

●

●●●●●●

●

●●

●

●

●

●●●

●

●●

●●●

●●●

●●●●

●

●

●

●

●

●

●●

●●

●●

●●

●

●●●●

●

●●

●

●●

●●

●●●●●●

●

●●●●

●

●●

●●

●●

●

●

●

●●●●●

●

●●●●

●

●●

●

●

●●

●

●

●

●

●●

●

●

●

●

●●●

●

●●●

●

●

●

●

●●

●●

●

●●●

●

●

●

●

●●

●

●●

●

●●●●●

●

●

●

●●

●●●●●

●

●

●

●

●

●

●

●●●●

●

●●●

●●

●

●

●

●●

●

●

●●●●

●

●

●

●●

●

●

●

●●

●●

●

●

●

●●

●

●

●

●●●●●

●

●

●●

●●●●●●

●

●

●●

●●●

●●●

●●

●●●

●

●●

●

●●●●

●●●●●

●

●●●●●●●●

●●

●●

●●●●

●

●●●●●

●

●●

●

●●●

●

●●●

●

●

●●

●

●●

●●

●●

●●●●

●

●

●

●●

●

●

●

●

●

●●

●●●●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●●

●

●●

●●●●●●●

●●●●●

●

●

●

●

●

●

●

●●●

●

●

●

●●●

●

●●●

●

●

●●

●

●●

●

●

●●

●●●

●●

●

●●

●

●●

●

●●●

●

●●●●

●

●

●

●

●

●

●●

●

●●

●●

●●●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●●

●

●●

●

●●

●

●●

●

●●●●●●●●●●

●●●

●●

●●●●●●●●●

●

●

●

●

●

●●●

●

●●

●●●●●

●

●

●

●●●

●

●●

●

●●

●●●●●●●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●●●

●

●

●

●

●●●

●●

●

●

●

●

●●

●

●

●●●

●

●●●

●●

●●

●

●●●

●

●

●

●

●

●●

●

●

●

●●●●●

●

●●

●

●●●

●●●

●

●

●●

●●

●●

●

●

●●●

●

●●●

●

●

●●●●

●

●

●

●

●●●●●●●

●

●

●●●

●●

●

●

●●

●●

●

●●

●●●

●●

●●●●●

●

●

●

●

●

●

●

●

●●

●

●

●●●●●

●●

●●●

●●●

●●●●●

●●●●

●

●

●

●

●●●

●

●●

●

●

●●

●

●●

●

●

●

●●●●●

●

●●

●●●●●

●●

●●

●●

●●

●

●●●

●●

●

●

●

●●●

●

●

●

●

●

●

●●

●

●●●●●●●●●●●●●

●

●●●●●●●

●

●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●

0

3

6

9

12

15

18

21

24

27

30

33

36

39

42

45

48

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

SNR

[dB]

laptop netbook

●● ●

0123456789

101112131415161718192021

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

Powe

r−le

vel(d

ata)

[dBm

]

●

●

●●●

●●●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●

●●●●●●●●

●

●

●

●●●●●●●●●●●●●●●●

●

●●●●●●●●

●●●●●●●●

0123456789

101112131415161718192021

0 50 100 150 200 250 300 350 400 450 500 550 600Time [s]

Powe

r−le

vel(d

ata)

[dBm

]

Figure 5.20: Performance results of 2-Links with TCP Traffic and w = 10.

Summary 91

dBm at 54 Mbps and 16 dBm at 48 Mbps. This explains the difference of 3 dB between the adjusted and

measured reduction in power.

The data rate plots in Figures 5.19 and 5.20 show the relative count of all 12 IEEE 802.11g data-rates

that Minstrel-Blues actually used to send data packets for each interval of 150 seconds. By comparing

rate distributions per interval it can be seen that when w = 2, Minstrel-Blues prefers lower data rates,

while with w = 10, Minstrel-Blues uses the same data rates with Minstrel with maximum power level.

In case of the netbook and w = 2, the dominant date rate changes from 48 Mbps to 36 Mbps as shown

in Figure 5.19. The same observation holds for the laptop. It is to be noted that the actual power level

reduction with the laptop link and w = 10 is slightly higher compared to w = 2. We assume this is due

to the fact that the wireless channel conditions changed, as there was a 30 minute time gap between the

experiments.

From our results, we conclude that Minstrel-Blues operates as expected at 2.4 GHz with IEEE

802.11g hardware. It does significantly reduce actual transmission power while achieving similar per-

formance in throughput for both the netbook and laptop clients. The ability to adjust Minstrel-Blues’

utility function and therefore, influence data-rate and power selection by different weighting factors has

also been validated.

5.4 Summary

In this chapter, we presented the design, implementation, and performance evaluation of our joint rate

and power controller, Minstrel-Blues. In the first part, we explained our modifications to the Linux

mac80211 subsystem to annotate transmission power levels per packet. Building upon this, we described

our heuristic approach to minimize transmission power by sampling different, discrete power levels and

use the resulting success ratios for control decisions. Additionally, we enabled the TPC capabilities of

Atheros WiFi chips by extending the Linux ath5k driver. We motivated and introduced a utility function

to realize different preferences for combinations of achievable throughput per data rate and its necessary

transmission power. The special configuration of Minstrel-Blues, where only throughput influences the

utility calculation, is called Minstrel-Piano.

Several validation experiments confirmed Minstrel-BLUES is able to adapt data rates and power lev-

els, while operating with different IEEE 802.11a and 802.11g devices. The design and implementation

of our controller within the Linux kernel shows good performance. It allows to fully utilize the trans-

mission capacity at the highest data rate. Furthermore, our algorithm is able to reduce the transmission

power according to statistics of packet success probabilities, while maintaining the same throughput.

Hence, it reduces the amount of overall interference in the network.

In our performance evaluation in the BOWL testbed we showed that Minstrel-Piano significantly

increases the total network throughput through spatial reuse. Our measurements cover three different


receiver sensitivities with UDP and TCP traffic at 5 GHz.

Limitations: In this chapter, we analyzed our joint rate and power controller with its ability to increase

spatial reuse, and thus total network throughput. Our current experimentation setup does not cover

mixed traffic, different packet sizes, or multiple packet flows and distributions. Therefore, additional

measurements would be necessary to explore the effects of realistic user traffic in terms of spatial reuse

potentials.

Any sampling based rate and power control algorithm needs sufficient sample attempts to realize

reasonable control decisions based on up-to-date statistics. Both, Minstrel as well as Minstrel-Blues,

currently use a fixed share of common data packets from the IP-layer and above to sample success

ratios of different data rates and power levels. The trade-off between accuracy and overhead of different

sampling methods in WiFi networks is unexplored.

As Minstrel-Blues operation depends on different thresholds to control power adjustments, different

intervals to periodically update success statistics, and other implementation specific parameters, the set

of default values to be chosen needs further study. In terms of agility, our power control settings are

conservative. Minstrel-Blues decreases power levels using smaller steps (currently 1 dB) and increases

power using larger steps (currently 2 dB). In other words, if the channel conditions get worse, we in-

crease power levels faster as compared to the case of good channel conditions, where we decrease the

power.

Finally, it must be stated that our current implementation of Minstrel-Blues is able to perform on

the latest Atheros 802.11n hardware but does not yet take advantage of its enhanced power control

capabilities at per pmulti-rate-retry stage.

Chapter 6

Conclusion and Outlook

6.1 Summary

We started by asking three questions: (1) What are the necessary prerequisites in order to achieve ef-

ficient rate and power control in real WiFi networks? (2) How do we design and implement transmit

power control in addition to existing rate control? (3) What are the conditions that allow joint rate and

power control to increase total throughput in WiFi networks?.

Chapter 3 and 4 answer the first question based on Atheros WiFi hardware. In this chapter we

present, in detail, the practical operation and limitations of Atheros WiFi cards and the specific interac-

tions between data rate and maximal power level. Our results validate that the maximum power level to

send packets is a function of the data rate and actual WiFi hardware. Both of the tested WiFi cards show

a nearly linear relation between the adjusted and measured power level up to a certain data rate specific

limit. This study allowed us to understand the necessary details of the Atheros hardware, essential for

our controller design.

In order to achieve efficient rate and power control in IEEE 802.11 wireless networks, an impor-

tant requirement is to understand their impact on channel utilization and network throughput. Improper

power, rate, and carrier sensing adjustments can lead to under-utilizing or attempting to over-utilize

medium, which can stall communication, or in the worst case result in network breakdowns. As packet

level traces are insufficient to directly monitor medium utilization at the MAC-layer, we created a new

wireless monitoring tool for Linux. In Chapter 4, we present the in-kernel design, validation and per-

formance of our Atheros specific monitoring tool RegMon. RegMon enables sampling, and analysis of

hardware registers with a high accuracy through a sampling rate up to 20 kHz depending on the mea-

surement hardware. It is implemented and validated for all three major drivers of Atheros WiFi cards,

namely Madwifi, ath5k and ath9k as well as two alternative sampling methods to support a wide range of

IEEE 802.11abgn hardware. Our measurement tool enables wireless researchers to access new informa-

93

94 6. Conclusion and Outlook

tion sources and is part of the default monitoring setup in our BOWL network. textitRegMon essentially

provides us with MAC layer measurements that help develop, troubleshoot and analyze our joint rate

and power controller.

Chapter 5 aims at answering the remaining two questions on the design and implement of a joint

rate and power controller. In the first part, we explained our modifications to the Linux mac80211

subsystem to annotate transmission power levels per packet. To enable a power-level setting per packet

in the MAC layer, we restructured the mac80211 Linux subsystem to provide the necessary space in

the control data structure to allow a power level setting for each of the four rates per packet. With this

extension, we enable a general abstraction to annotate the transmission power at the Linux MAC layer.

More specifically, we modified the Linux drivers from Atheros: ath5k and ath9k in their transmission

path to support TPC. To the best of our knowledge, we are the first to implement such an interface, which

enables realizing different power control approaches using today’s WiFi hardware. Building upon this,

we described our heuristic approach to minimize transmission power by sampling different, discrete

power levels and use the resulting success ratios for control decisions.

Using our implementation, it becomes possible to annotate per-packet power levels based on hard-

ware capabilities: one power-level for all retries in IEEE 802.11abg, and four power levels corresponding

to the four retries in IEEE 802.11n. Our implementation takes into account different hardware capabili-

ties, e.g., data and MAC acknowledgment (ack) packets differ in terms of controllability of power levels.

The PHY layer part of our implementation covers several Atheros-based WiFi chips but it can easily be

extended to other hardware drivers.

Finally, based on our cross-layer interface, we designed, implemented, and validated a joint power

and rate controller: Minstrel-Blues. Our controller respects the trade-off between packet delivery suc-

cess and interference to other ongoing transmissions. It uses cross-layer information from both PHY

and MAC layers (power and rate) and operates at the PHY layer. It is a decentralized sampling-based

controller that does not require additional control messages between a WiFi transmitter and a receiver,

e.g., to obtain received signal strength information.

Several validation experiments confirmed Minstrel-Blues capability of adapting data rate and power

levels, while operating with different IEEE 802.11a and 802.11g devices. The design and in-kernel im-

plementation of our controller provides sufficient performance to fully utilize the transmission capacity

at the highest data rate. Furthermore, our algorithm is able to reduce the transmission power according

to statistics of packet success probabilities, while maintaining the same throughput. Hence, it reduces

the amount of overall interference in the network. By evaluating the performance within the BOWL

testbed, we showed that Minstrel-Blues is able to significantly increase the total network throughput

through spatial reuse.

Future Directions 95

6.2 Future Directions

In our performance evaluation, we analyzed our joint rate and power controller in terms of its ability to

increase spatial reuse, and thus, total network throughput. While we have shown significant throughput

gains using Minstrel-Blues, our experiment setup is limited and does not cover mixed traffic, differ-

ent packet sizes, or multiple packet flows and distributions. Therefore, additional measurements are

necessary to explore the effects of realistic user traffic on spatial reuse potential.

At the time of writing this thesis both standards, IEEE 802.11a and 802.11g, are somehow out-of-

date and IEEE 802.11n as well as 802.11 ac are their successors. Hende, we plan to extend Minstrel-

Blues capabilities to support multiple input multiple output (MIMO) WiFi devices. Furthermore, current

Atheros 802.11n cards promise enhanced power control abilities. They support individual power levels

per multi rate retry stage, which could be incorporated into our current sampling approaches. As there

exists already a follow-up of Minstrel rate control, called Minstrel HT, we are confident that the power

controller Blues can be merged with this new 802.11n rate control algorithm.

With IEEE 802.11n comes also an increase in available data rates (up to 32 MCS rates with two

different guard intervals and channel width). The overall search space of possible power and rate com-

binations grows significantly and hence, efficient sampling of these rates and power levels becomes the

challenge.

Any sampling based rate and power control algorithm needs sufficient sample attempts to realize

reasonable control decisions based on up to date statistics. Both, Minstrel as well as Minstrel-Blues use

currently a fixed share of common data packets coming from the IP-layer and above to sample success

ratios of different data rates and power levels. The trade-off between accuracy and overhead of different

sampling approaches in current WiFi networks should be explored.

Another venue that requires investigation is our utility implementation in Blues, which provides

different mappings of user preferences for the joint decision process. A performance analysis in mixed

and also multi-hop scenarios when using different weight factors is also on our future work list.

Finally, one of the interesting paths that we plan to explore in the near future are the necessary steps

to ensure Minstrel-Blues operation together with non power-controlled WiFi routers. Therefore, we are

going put the necessary effort to get Minstrel-Blues committed into the mainline Linux kernel. Our

experiences when pushing our new data structure into the mac80211 subsystem convinced us that this

is not only nice-to-have but also a must to ensure comparability and repeatability of WiFi experiments.

This needs constant effort and probably an ”attitude adjustment” to realize that pros outweigh the cons.

96 Bibliography

Bibliography

[1] IEEE, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications

(ANSI/IEEE Std 802.11, 1999 Edition (R2007)), Institute of Electrical and Electronics Engineers,

Inc., June 2007.

[2] A. Goldsmith and S. Wicker, “Design challenges for energy-constrained ad hoc wireless net-

works,” Wireless Communications, IEEE, vol. 9, no. 4, pp. 8 – 27, Aug. 2002.

[3] S. Stanczak, M. Wiczanowski, and H. Boche, Fundamentals of Resource Allocation in Wireless

Networks: Theory and Algorithms, 2nd ed. Springer Publishing Company, Incorporated, 2009.

[4] F. B. Abdesslem, L. Iannone, M. D. D. Amorim, K. Kabassanov, and S. Fdida, “On the feasibility

of power control in current ieee 802.11 devices,” in in PERCOMW ’06: Proceedings of the 4th

annual IEEE international conference on Pervasive Computing and Communications Workshops.

IEEE Computer Society, 2006, p. 468.

[5] V. Shrivastava, D. Agrawal, A. Mishra, S. Banerjee, and T. Nadeem, “On the (in)feasibility of fine

grained power control,” SIGMOBILE Mob. Comput. Commun. Rev., vol. 11, no. 2, pp. 65–66, Apr.

2007.

[6] V. Shrivastava, D. Agrawal, A. Mishra, S. Banerjee, and T. Nadeem, “Understanding the limi-

tations of transmit power control for indoor wlans,” in Proceedings of the 7th ACM SIGCOMM

conference on Internet measurement, ser. IMC ’07. New York, NY, USA: ACM, 2007, pp.

351–364.

[7] IEEE, Wireless LAN Medium Access Control (MAC)and Physical Layer (PHY) Specifications

Amendment 5: Enhancements for Higher Throughput (IEEE Std 802.11n-2009), Institute of Elec-

trical and Electronics Engineers, Inc., 2009.

[8] A. Botta, I. Matyasovszki, A. Pescape, and R. Karrer, “Performance evaluation of the magnets

backbone,” Deutsche Telekom Laboratories and University of Napoli ”Federico II”, Tech. Rep.,

Jul. 2006, http://www.grid.unina.it/Traffic/pub/TR-DTLab-UoN-2006.pdf.

97

98 Bibliography

[9] R. Karrer, A. Pescape, and T. Huhn, “Challenges in second-generation wireless mesh networks,”

EURASIP Journal on Wireless Communications and Networking, vol. 2008, August 2008, article

ID 274790, 10 pages.

[10] K. Thota, “Broadband and wi-fi households global forecast 2012,” Strategy Analytics, Tech. Rep.,

Marz 2012.

[11] M. Mueck and D. Noguet, “TV white space standardization and regulation in europe,” in Wireless

Communication, Vehicular Technology, Information Theory and Aerospace Electronic Systems

Technology (Wireless VITAE), 2011 2nd International Conference on, Mar. 2011, pp. 1 –5.

[12] X. Liu, D. Anderson, and K. Papagiannaki, “Maximizing spatial reuse in indoor environments,”

Ph.D. dissertation, School of Computer Science Carnegie Mellon University, 2011.

[13] X. Guo, S. Roy, and W. Conner, “Spatial reuse in wireless ad-hoc networks,” in Vehicular Tech-

nology Conference, 2003. VTC 2003-Fall. 2003 IEEE 58th, vol. 3, Oct. 2003, pp. 1437 – 1442

Vol.3.

[14] S. Lakshmanan, K. Sundaresan, S. Rangarajan, and R. Sivakumar, “Practical beamforming based

on RSSI measurements using off-the-shelf wireless clients,” in Proceedings of the 9th ACM SIG-

COMM conference on Internet measurement conference, ser. IMC ’09. New York, NY, USA:

ACM, 2009, pp. 410–416.

[15] S. B. Shravan Rayanchu, Ashish Patro, “Catching whales and minnows using wifinet: Decon-

structing non-wifi interference using wifi hardware,” in USENIX NSDI. ACM, 2012.

[16] M. A. Ergin, K. Ramachandran, and M. Gruteser, “Understanding the effect of access point den-

sity on wireless LAN performance,” in Proceedings of the 13th annual ACM international con-

ference on Mobile computing and networking, ser. MobiCom ’07. New York, NY, USA: ACM,

2007, pp. 350–353.

[17] I. Tinnirello and G. Bianchi, “Interference estimation in IEEE 802.11 networks,” Control Systems,

IEEE, vol. 30, no. 2, pp. 30 –43, Apr. 2010.

[18] IEEE, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications,

Amendment 5: Spectrum and Transmit Power Management Extensions in the 5 GHz band in

Europe (IEEE Std 802.11h-2003), Institute of Electrical and Electronics Engineers, Inc., 2003.

[19] IEEE, Wireless Medium Access Control (MAC) and physical layer (PHY) specifications, Amend-

ment: High Speed Physical Layer in the 5 GHz band, (IEEE Std 802.11a-1999), Institute of

Electrical and Electronics Engineers, Inc., 1999.

Bibliography 99

[20] ETSI, Broadband Radio Access Networks (BRAN); 5 GHz high performance RLAN; Harmonized

EN covering the essential requirements of article 3.2 of the R&TTE Directive (ETSI EN 301 893

V1.7.0), European Telecommunications Standards Institute, Januar 2012.

[21] I. Ramachandran and S. Roy, “Clear channel assessment in energyconstrained wideband wireless

networks,” IEEE Wireless Communications, vol. 14, no. 3, pp. 70 –78, Jun. 2007.

[22] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang, “MACAW: a media access protocol for

wireless LAN’s,” SIGCOMM Comput. Commun. Rev., vol. 24, no. 4, pp. 212–225, Oct. 1994.

[23] K. Jamieson, B. Hull, A. Miu, and H. Balakrishnan, “Understanding the real-world performance

of carrier sense,” in Proceedings of the 2005 ACM SIGCOMM workshop on Experimental ap-

proaches to wireless network design and analysis. Philadelphia, Pennsylvania, USA: ACM,

2005, pp. 52–57.

[24] M. Vutukuru, K. Jamieson, and H. Balakrishnan, “Harnessing exposed terminals in wireless net-

works,” in Proceedings of the 5th USENIX Symposium on Networked Systems Design and Imple-

mentation, ser. NSDI’08. Berkeley, CA, USA: USENIX Association, 2008, pp. 59–72.

[25] Y.-C. Cheng, J. Bellardo, P. Benko, A. C. Snoeren, G. M. Voelker, and S. Savage, “Jigsaw: solving

the puzzle of enterprise 802.11 analysis,” SIGCOMM Comput. Commun. Rev., vol. 36, no. 4, pp.

39–50, Aug. 2006.

[26] L. Scalia, I. Tinnirello, and D. Giustiniano, “Side effects of ambient noise immunity techniques

on outdoor IEEE 802.11 deployments,” in Global Telecommunications Conference, 2008. IEEE

GLOBECOM 2008. IEEE, Dec. 2008, pp. 1 –6.

[27] A. Muqattash and M. Krunz, “A single-channel solution for transmission power control in wire-

less ad hoc networks,” in Proceedings of the 5th ACM international symposium on Mobile ad hoc

networking and computing, ser. MobiHoc ’04. New York, NY, USA: ACM, 2004, pp. 210–221.

[28] D. Son, B. Krishnamachari, and J. Heidemann, “Experimental study of the effects of transmission

power control and blacklisting in wireless sensor networks,” in Sensor and Ad Hoc Communica-

tions and Networks, 2004. IEEE SECON 2004. 2004 First Annual IEEE Communications Society

Conference on, Oct. 2004, pp. 289 – 298.

[29] M. Sha, G. Xing, G. Zhou, S. Liu, and X. Wang, “C-MAC: Model-Driven concurrent medium

access control for wireless sensor networks,” in INFOCOM 2009, IEEE, Apr. 2009, pp. 1845

–1853.

100 Bibliography

[30] N. Ahmed and S. Keshav, “SMARTA: a self-managing architecture for thin access points,” in

Proceedings of the 2006 ACM CoNEXT conference, ser. CoNEXT ’06. New York, NY, USA:

ACM, 2006, pp. 9:1–9:12.

[31] J. Bicket, “Bit-rate selection in wireless networks,” Master’s thesis, Massachusetts Institute of

Technology, 2005.

[32] M. Lacage, M. Manshaei, and T. Turletti, “IEEE 802.11 rate adaptation: A practical approach,”

in Proceedings of the 7th ACM international symposium on Modeling, analysis and simulation of

wireless and mobile systems, ser. MSWiM ’04. ACM, 2004.

[33] W. Yin, P. Hu, J. Indulska, and K. Bialkowski, “Performance of mac80211 rate control mech-

anisms,” in MSWiM ’11: Proceedings of the 14th ACM international conference on Modeling,

analysis and simulation of wireless and mobile systems. ACM Request Permissions, Oct. 2011.

[34] W. Yin, K. Bialkowski, J. Indulska, and P. Hu, “Evaluations of MadWifi MAC layer rate control

mechanisms,” in Quality of Service (IWQoS), 2010 18th International Workshop on, Jun. 2010,

pp. 1 –9.

[35] M. Vutukuru, H. Balakrishnan, and K. Jamieson, “Cross-layer wireless bit rate adaptation,” SIG-

COMM Comput. Commun. Rev., vol. 39, no. 4, pp. 3–14, Aug. 2009.

[36] K. L. K. L. LaCurts, “Measurement and analysis of real-world 802.11 mesh networks,” Thesis,

Massachusetts Institute of Technology, 2010, thesis (S.M.)–Massachusetts Institute of Technol-

ogy, Dept. of Electrical Engineering and Computer Science, 2010.

[37] J. Zhu, B. Metzler, X. Guo, and Y. Liu, “Adaptive CSMA for scalable network capacity in High-

Density WLAN: a hardware prototyping approach,” in INFOCOM 2006. 25th IEEE International

Conference on Computer Communications. Proceedings, Apr. 2006, pp. 1 –10.

[38] X. Yang and N. Vaidya, “On physical carrier sensing in wireless ad hoc networks,” in INFO-

COM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies.

Proceedings IEEE, vol. 4, Mar. 2005, pp. 2525 – 2535 vol. 4.

[39] J. Zhu, X. Guo, L. Yang, and W. Conner, “Leveraging spatial reuse in 802.11 mesh networks with

enhanced physical carrier sensing,” in Communications, 2004 IEEE International Conference on,

vol. 7, Jun. 2004, pp. 4004 – 4011 Vol.7.

[40] K. Park, J. Hou, T. Basar, and H. Kim, “Noncooperative carrier sense game in wireless networks,”

Wireless Communications, IEEE Transactions on, vol. 8, no. 10, pp. 5280 –5289, Oct. 2009.

Bibliography 101

[41] H. Ma, R. Vijayakumar, S. Roy, and J. Zhu, “Optimizing 802.11 wireless mesh networks based

on physical carrier sensing,” IEEE/ACM Trans. Netw., vol. 17, no. 5, pp. 1550–1563, 2009.

[42] F. Dressler, “A study of self-organization mechanisms in ad hoc and sensor networks,” Computer

Communications, vol. 31, no. 13, pp. 3018 – 3029, 2008.

[43] N. Bambos, “Toward power-sensitive network architectures in wireless communications: con-

cepts, issues, and design aspects,” Personal Communications, IEEE, vol. 5, no. 3, pp. 50 –59,

Jun. 1998.

[44] V. Kawadia and P. Kumar, “Principles and protocols for power control in wireless ad hoc net-

works,” Selected Areas in Communications, IEEE Journal on, vol. 23, no. 1, pp. 76 – 88, Jan.

2005.

[45] G. Foschini and Z. Miljanic, “A simple distributed autonomous power control algorithm and its

convergence,” Vehicular Technology, IEEE Transactions on, vol. 42, no. 4, pp. 641 –646, Nov.

1993.

[46] Y. Wang, J. C. S. Lui, and D. Chiu, “Understanding the paradoxical effects of power control on

the capacity of wireless networks,” Trans. Wireless. Comm., vol. 8, no. 1, pp. 406–413, Jan. 2009.

[47] M. Krunz, A. Muqattash, and S. Lee, “Transmission power control in wireless ad hoc networks:

challenges, solutions and open issues,” Network, IEEE, vol. 18, no. 5, pp. 8 – 14, Oct. 2004.

[48] A. Muqattash and M. Krunz, “POWMAC: a single-channel power-control protocol for throughput

enhancement in wireless ad hoc networks,” Selected Areas in Communications, IEEE Journal on,

vol. 23, no. 5, pp. 1067 – 1084, May 2005.

[49] J. Gomez, A. T. Campbell, M. Naghshineh, and C. Bisdikian, “PARO: supporting dynamic power

controlled routing in wireless ad hoc networks,” Wirel. Netw., vol. 9, no. 5, pp. 443–460, Sep.

2003.

[50] S. Narayanaswamy, V. Kawadia, R. S. Sreenivas, and P. R. Kumar, “Power control in Ad-Hoc

networks: Theory, architecture, algorithm and implementation of the COMPOW protocol,” in in

European Wireless Conference, 2002, pp. 156–162.

[51] V. Kawadia and P. R. Kumar, “Power control and clustering in ad hoc networks,” in In Proc. IEEE

INFOCOM 2003, 2003.

[52] J. Monks, V. Bharghavan, and W. Hwu, “A power controlled multiple access protocol for wireless

packet networks,” in INFOCOM 2001. Twentieth Annual Joint Conference of the IEEE Computer

and Communications Societies. Proceedings. IEEE, vol. 1, 2001, pp. 219 –228 vol.1.

102 Bibliography

[53] V. Navda, R. Kokku, S. Ganguly, and S. Das, “Slotted symmetric power control in managed

wireless lans,” Technical report, State University of New York at Stony Brook, 2008, Tech. Rep.,

2009.

[54] E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F. Kaashoek, “The click modular router,” ACM

Transactions on Computer Systems, vol. 18, pp. 263–297, 2000.

[55] A. Amiri Sani, L. Zhong, and A. Sabharwal, “Directional antenna diversity for mobile devices:

characterizations and solutions,” in Proceedings of the sixteenth annual international conference

on Mobile computing and networking, ser. MobiCom ’10. New York, NY, USA: ACM, 2010,

pp. 221–232.

[56] X. Liu, A. Sheth, M. Kaminsky, K. Papagiannaki, S. Seshan, and P. Steenkiste, “DIRC: increasing

indoor wireless capacity using directional antennas,” in Proceedings of the ACM SIGCOMM 2009

conference on Data communication, ser. SIGCOMM ’09. New York, NY, USA: ACM, 2009,

pp. 171–182.

[57] X. Liu, A. Sheth, M. Kaminsky, K. Papagiannaki, S. Seshan, and P. Steenkiste, “Pushing the

envelope of indoor wireless spatial reuse using directional access points and clients,” in Proceed-

ings of the sixteenth annual international conference on Mobile computing and networking, ser.

MobiCom ’10. New York, NY, USA: ACM, 2010, pp. 209–220.

[58] E. Jung and N. H. Vaidya, “A power control MAC protocol for ad hoc networks,” in Proceedings

of the 8th annual international conference on Mobile computing and networking, ser. MobiCom

’02. New York, NY, USA: ACM, 2002, pp. 36–47.

[59] A. Spyropoulos and C. Raghavendra, “Energy efficient communications in ad hoc networks using

directional antennas,” in INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE

Computer and Communications Societies. Proceedings. IEEE, vol. 1, 2002, pp. 220 – 228 vol.1.

[60] F. I. Piazza, S. Mangione, and I. Tinnirello, “On the effects of transmit power control on the

energy consumption of WiFi network cards,” in Quality of Service in Heterogeneous Networks,

ser. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommuni-

cations Engineering, N. Bartolini, S. Nikoletseas, P. Sinha, V. Cardellini, A. Mahanti, O. Akan,

P. Bellavista, J. Cao, F. Dressler, D. Ferrari, M. Gerla, H. Kobayashi, S. Palazzo, S. Sahni, X. S.

Shen, M. Stan, J. Xiaohua, A. Zomaya, and G. Coulson, Eds. Springer Berlin Heidelberg, 2009,

vol. 22, pp. 463–475.

[61] D. Halperin, B. Greenstein, A. Sheth, and D. Wetherall, “Demystifying 802.11n power consump-

tion,” in HotPower’10: Proceedings of the 2010 international conference on Power aware com-

puting and systems. USENIX Association, Oct. 2010.

Bibliography 103

[62] V. Rodoplu and T. Meng, “Minimum energy mobile wireless networks,” Selected Areas in Com-

munications, IEEE Journal on, vol. 17, no. 8, pp. 1333 –1344, Aug. 1999.

[63] R. Wattenhofer, L. Li, P. Bahl, and Y. Wang, “Distributed topology control for power efficient

operation in multihop wireless ad hoc networks,” in INFOCOM 2001. Twentieth Annual Joint

Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 3,

2001, pp. 1388 –1397 vol.3.

[64] S. Khan, “Design of rate-adaptive MAC and medium aware routing protocols for multi-rate,

multi-hop wireless networks,” Thesis, Brunel University School of Engineering and Design PhD

Theses, 2010.

[65] S. Biaz and S. Wu, “Rate adaptation algorithms for IEEE 802.11 networks: A survey and com-

parison,” in Computers and Communications, 2008. ISCC 2008. IEEE Symposium on, Jul. 2008,

pp. 130 –136.

[66] A. Kamerman and L. Monteban, “WaveLAN R©-II: a high-performance wireless LAN for the

unlicensed band,” Bell Labs Technical Journal, vol. 2, no. 3, pp. 118–133, 1997.

[67] Madwifi - wireless driver documentation. [Online]. Available: http://madwifi-project.org/wiki/

DevDocs/Branches

[68] S. Brivio. PID - rate control. http://linuxwireless.org/en/developers/Documentation. [Online].

Available: http://wireless.kernel.org/en/developers/Documentation/mac80211/RateControl/PID

[69] (2012, Juli) /madwifi/trunk/ath rate/minstrel/minstrel.txt - madwifi-project.org - trac.

http://madwifi-project.org/browser/madwifi/trunk/ath rate/minstrel/minstrel.txt.

[70] J. Kim, S. Kim, S. Choi, and D. Qiao, “CARA: collision-aware rate adaptation for IEEE 802.11

WLANs,” in INFOCOM 2006. 25th IEEE International Conference on Computer Communica-

tions. Proceedings, Apr. 2006, pp. 1 –11.

[71] S. H. Y. Wong, H. Yang, S. Lu, and V. Bharghavan, “Robust rate adaptation for 802.11 wireless

networks,” in Proceedings of the 12th annual international conference on Mobile computing and

networking, ser. MobiCom ’06. New York, NY, USA: ACM, 2006, pp. 146–157.

[72] P. Acharya, A. Sharma, E. Belding, K. Almeroth, and K. Papagiannaki, “Rate adaptation in con-

gested wireless networks through Real-Time measurements,” Mobile Computing, IEEE Transac-

tions on, vol. 9, no. 11, pp. 1535 –1550, Nov. 2010.

[73] G. Holland, N. Vaidya, and P. Bahl, “A rate-adaptive MAC protocol for multi-Hop wireless net-

works,” in Proceedings of the 7th annual international conference on Mobile computing and


http://madwifi-project.org/wiki/DevDocs/Branches

http://madwifi-project.org/wiki/DevDocs/Branches

http://wireless.kernel.org/en/developers/Documentation/mac80211/RateControl/PID

104 Bibliography

[74] Z. Li, A. Das, A. Gupta, and S. Nandi, “Full auto rate MAC protocol for wireless ad hoc net-

works,” Communications, IEE Proceedings-, vol. 152, no. 3, pp. 311 – 319, Jun. 2005.

[75] B. Sadeghi, V. Kanodia, A. Sabharwal, and E. Knightly, “Opportunistic media access for multirate

ad hoc networks,” in Proceedings of the 8th annual international conference on Mobile computing

and networking, ser. MobiCom ’02. New York, NY, USA: ACM, 2002, pp. 24–35.

[76] D. Qiao, S. Choi, and K. Shin, “Goodput analysis and link adaptation for IEEE 802.11a wireless

LANs,” Mobile Computing, IEEE Transactions on, vol. 1, no. 4, pp. 278 – 292, Dec. 2002.

[77] About the history of the madwifi driver. [Online]. Available: http://madwifi-project.org/wiki/

About/History

[78] S. Choudhury and J. Gibson, “Payload length and rate adaptation for throughput optimization in

wireless LANs,” in Vehicular Technology Conference, 2006. VTC 2006-Spring. IEEE 63rd, vol. 5,

May 2006, pp. 2444 –2448.

[79] K. Huang, D. Malone, and K. Duffy, “The 802.11g 11 mb/s rate is more robust than 6 mb/s,”

Wireless Communications, IEEE Transactions on, vol. 10, no. 4, pp. 1015 –1020, Apr. 2011.

[80] W. Yin, P. Hu, J. Indulska, and K. Bialkowski, “A method to improve adaptability of the minstrel

MAC rate control algorithm,” in Proceedings of the 7th international conference on Ubiquitous

intelligence and computing, ser. UIC’10. Berlin, Heidelberg: Springer-Verlag, 2010, pp. 504–

518.

[81] E. D. Stic, S. Informatique, M. H. Manshaei, E. Planete, I. S. Antipolis, T. Walid, D. T. Turletti,

M. H. Manshaei, and M. H. Manshaei, “Cross layer interactions for adaptive communications in

ieee 802.11 wireless lans,” Ph.D. dissertation, INRIA Sophia Antipolis, France, 2005.

[82] Z. Li, A. Das, A. Gupta, and S. Nandi, “Full auto rate mac protocol for wireless ad hoc networks,”

Communications, IEEE, vol. 152, no. 3, pp. 311 – 319, june 2005.

[83] J. Camp and E. Knightly, “Modulation rate adaptation in urban and vehicular environments: cross-

layer implementation and experimental evaluation,” in Proceedings of the 14th ACM international

conference on Mobile computing and networking, ser. MobiCom ’08. New York, NY, USA:

ACM, 2008, pp. 315–326.

[84] B. Han, A. Schulman, F. Gringoli, N. Spring, B. Bhattacharjee, L. Nava, L. Ji, S. Lee, and

R. Miller, “Maranello: practical partial packet recovery for 802.11,” in Proceedings of the 7th

USENIX conference on Networked systems design and implementation, ser. NSDI’10. Berkeley,

CA, USA: USENIX Association, 2010, pp. 14–14.

http://madwifi-project.org/wiki/About/History

http://madwifi-project.org/wiki/About/History

Bibliography 105

[85] M. Z. Brodsky and R. T. Morris, “In defense of wireless carrier sense,” SIGCOMM Comput.

Commun. Rev., vol. 39, no. 4, pp. 147–158, Aug. 2009.

[86] R. K. Schmidt, A. Brakemeier, T. Leinmuller, F. Kargl, and G. Schafer, “Advanced carrier sensing

to resolve local channel congestion,” in Proceedings of the Eighth ACM international workshop

on Vehicular inter-networking, ser. VANET ’11. New York, NY, USA: ACM, 2011, pp. 11–20.

[87] T. Kim, H. Lim, and J. C. Hou, “Improving spatial reuse through tuning transmit power, carrier

sense threshold, and data rate in multihop wireless networks,” in Proceedings of the 12th annual

international conference on Mobile computing and networking, ser. MobiCom ’06. New York,

NY, USA: ACM, 2006, pp. 366–377.

[88] M. Kurth and J.-P. Redlich, “Carrier sensing and receiver performance in indoor IEEE 802.11b

mesh networks,” in Proceedings of the 2009 International Conference on Wireless Communica-

tions and Mobile Computing: Connecting the World Wirelessly, ser. IWCMC ’09. New York,

NY, USA: ACM, 2009, pp. 726–732.

[89] W. Kim, J. Lee, T. Kwon, S.-J. Lee, and Y. Choi, “Quantifying the interference gray zone in wire-

less networks: A measurement study,” in IEEE International Conference on Communications,

2007. ICC ’07, Jun. 2007, pp. 3758 –3763.

[90] A. Rao and I. Stoica, “An overlay MAC layer for 802.11 networks,” in Proceedings of the 3rd

international conference on Mobile systems, applications, and services, ser. MobiSys ’05. New

York, NY, USA: ACM, 2005, pp. 135–148.

[91] F. Foukalas, V. Gazis, and N. Alonistioti, “Cross-layer design proposals for wireless mobile net-

works: a survey and taxonomy,” Communications Surveys Tutorials, IEEE, vol. 10, no. 1, pp. 70

–85, 2008.

[92] V. Srivastava and M. Motani, “Cross-layer design: a survey and the road ahead,” Communications

Magazine, IEEE, vol. 43, no. 12, pp. 112 – 119, Dec. 2005.

[93] Y. Zhang, J. Luo, and H. Hu, Wireless Mesh Networking: Architectures, Protocols and Standards.

Auerbach Pubn, Dec. 2006.

[94] V. Mhatre, K. Papagiannaki, and F. Baccelli, “Interference mitigation through power control in

high density 802.11 WLANs,” in INFOCOM 2007. 26th IEEE International Conference on Com-

puter Communications. IEEE, May 2007, pp. 535 –543.

[95] T. Huehn, R. Merz, and C. Sengul, “Joint transmission rate, power, and carrier sense settings:

An initial measurement study,” in Wireless Mesh Networks (WIMESH 2010), 2010 Fifth IEEE

Workshop on, 2010, pp. 1–6.

106 Bibliography

[96] D. Qiao, S. Choi, A. Jain, and K. G. Shin, “MiSer: an optimal low-energy transmission strat-

egy for IEEE 802.11a/h,” in Proceedings of the 9th annual international conference on Mobile

computing and networking, ser. MobiCom ’03. New York, NY, USA: ACM, 2003, pp. 161–175.

[97] “Report: NSF workshop on future wireless communication research| whitepapers | TechRepub-

lic,” 2009.

[98] T. Nadeem, L. Ji, A. Agrawala, and J. Agre, “Location enhancement to IEEE 802.11 DCF,” in

Proceedings IEEE INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and

Communications Societies, vol. 1, Mar. 2005, pp. 651 – 663 vol. 1.

[99] P. Chevillat, J. Jelitto, and H. L. Truong, “Dynamic data rate and transmit power adjustment in

IEEE 802.11 wireless LANs,” International Journal of Wireless Information Networks, vol. 12,

no. 3, pp. 123–145, 2005.

[100] A. Akella, G. Judd, S. Seshan, and P. Steenkiste, “Self-management in chaotic wireless deploy-

ments,” in Proceedings of the 11th annual international conference on Mobile computing and


[101] X. Yang and N. Vaidya, “A spatial backoff algorithm using the joint control of carrier sense

threshold and transmission rate,” in Sensor, Mesh and Ad Hoc Communications and Networks,

2007. SECON ’07. 4th Annual IEEE Communications Society Conference on, Jun. 2007, pp. 501

–511.

[102] H. Ma, J. Zhu, S. Roy, and S. Y. Shin, “Joint transmit power and physical carrier sensing adapta-

tion based on loss differentiation for high density IEEE 802.11 WLAN,” Comput. Netw., vol. 52,

no. 9, pp. 1703–1720, Jun. 2008.

[103] F. A. Tobagi and M. M. Hira, “Joint optimization of physical layer parameters and routing in

wireless mesh networks,” in Ad Hoc Networking Workshop (Med-Hoc-Net), 2010 The 9th IFIP

Annual Mediterranean, Jun. 2010, pp. 1 –8.

[104] K. Ramachandran, R. Kokku, H. Zhang, and M. Gruteser, “Symphony: synchronous two-phase

rate and power control in 802.11 WLANs,” IEEE/ACM Trans. Netw., vol. 18, no. 4, pp. 1289–

1302, Aug. 2010.

[105] B. Alawieh, Y. Zhang, C. Assi, and H. Mouftah, “Improving spatial reuse in multihop wireless

networks - a survey,” IEEE Communications Surveys Tutorials, vol. 11, no. 3, pp. 71 –91, 2009.

[106] R. Merz, H. Schioberg, and C. Sengul, “Design of a configurable wireless network testbed with

live traffic,” in Testbeds and Research Infrastructures. Development of Networks and Communi-

ties - 6th International ICST Conference, TridentCom 2010, Berlin, Germany, May 18-20, 2010,

Bibliography 107

Revised Selected Papers, ser. Lecture Notes of the Institute for Computer Sciences, Social Infor-

matics and Telecommunications Engineering, T. Magedanz, A. Gavras, H.-T. Nguyen, and J. S.

Chase, Eds., vol. 46. Springer, 2010, pp. 189–198.

[107] R. Karrer, I. Matyasovszki, A. Botta, and A. Pescape, “MagNets - experiences from deploying a

joint research-operational next-generation wireless access network testbed,” in 3rd International

Conference on Testbeds and Research Infrastructure for the Development of Networks and Com-

munities, 2007. TridentCom 2007, May 2007, pp. 1 –10.

[108] H. Schioberg, “Interactions of legacy internet traffic with multihop wireless networks,” Ph.D.

dissertation, Technical University Berlin, 2012.

[109] T. Fischer, T. Huhn, R. Kuck, R. Merz, J. Schulz-Zander, and C. Sengul, “Experiences with

bowl: Managing an outdoor wifi network (or how to keep both internet users and researchers

happy?),” in Proceedings of the 25th Large Installation System Administration Conference (LISA

’11). Usenix, December 2011, pp. 287–292.

[110] Openwrt project homepage. [Online]. Available: www.openwrt.org

[111] I. Tinnirello, D. Giustiniano, L. Scalia, and G. Bianchi, “On the side-effects of proprietary so-

lutions for fading and interference mitigation in IEEE 802.11b/g outdoor links,” Comput. Netw.,

vol. 53, no. 2, pp. 141–152, Feb. 2009.

[112] J. Thomson, B. Baas, E. Cooper, J. Gilbert, G. Hsieh, P. Husted, A. Lokanathan, J. Kuskin, D. Mc-

Cracken, B. McFarland, T. Meng, D. Nakahira, S. Ng, M. Rattehalli, J. Smith, R. Subramanian,

L. Thon, Y.-H. Wang, R. Yu, and X. Zhang, “An integrated 802.11a baseband and MAC proces-

sor,” in Solid-State Circuits Conference, 2002. Digest of Technical Papers. ISSCC. 2002 IEEE

International, vol. 1, 2002, pp. 126 –451 vol.1.

[113] D. Su, M. Zargari, P. Yue, S. Rabii, D. Weber, B. Kaczynski, S. Mehta, K. Singh, S. Mendis, and

B. Wooley, “A 5 GHz CMOS transceiver for IEEE 802.11a wireless LAN,” in Solid-State Circuits

Conference, 2002. Digest of Technical Papers. ISSCC. 2002 IEEE International, vol. 1, 2002, pp.

92 –449 vol.1.

[114] W. McFARLAND and J. THOMSON, “Method and system for detecting false packets in wireless

communication systems,” U.S. Patent WO 2003 028 272 A3R4, Apr., 2003.

[115] J. S. U. THOMSON and W. J. U. MCFARLAND, “Method and system for testing and optimizing

the performance of a radio communication device,” U.S. Patent 7 447 163, Nov., 2008.

[116] Ath5k hardware registers. [Online]. Available: http://lxr.free-electrons.com/source/drivers/net/

wireless/ath/ath5k/reg.h

www.openwrt.org

http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath5k/reg.h


108 Bibliography

[117] Ath9k registers documentation. [Online]. Available: http://lxr.free-electrons.com/source/drivers/

net/wireless/ath/ath9k/reg.h

[118] K. Kowalik, M. Bykowski, B. Keegan, and M. Davis, “Practical issues of power control in IEEE

802.11 wireless devices,” in Telecommunications, 2008. ICT 2008. International Conference on,

Jun. 2008, pp. 1 –5.

[119] D. Halperin, W. Hu, A. Sheth, and D. Wetherall, “Predictable 802.11 packet delivery from wire-

less channel measurements,” SIGCOMM Comput. Commun. Rev., vol. 40, no. 4, pp. 159–170,

Aug. 2010.

[120] R&S R©FSP spectrum analyzer (Rohde & schwarz international - products - test & measurement

- signal & spectrum analyzers). [Online]. Available: http://www.rohde-schwarz.com/en/product/

fsp-productstartpage 63493-8043.html

[121] M. Briggs, J. Martinez, and D. Bare, “Power measurements of OFDM signals,” in Electromag-

netic Compatibility, 2004. EMC 2004. 2004 InternationalSymposium on, vol. 2, Aug. 2004, pp.

485 – 488 vol.2.

[122] V. Shah and S. Krishnamurthy, “Handling asymmetry in power heterogeneous ad hoc networks: A

cross layer approach,” in Proceedings of the 25th IEEE International Conference on Distributed

Computing Systems, ser. ICDCS ’05. Washington, DC, USA: IEEE Computer Society, 2005,

pp. 749–759.

[123] I. Ramachandran and S. Roy, “On the impact of clear channel assessment on MAC performance,”

in Global Telecommunications Conference, 2006. GLOBECOM ’06. IEEE, Dec. 2006, pp. 1 –5.

[124] W.-J. U. CHOI, J. M. U. GILBERT, Y.-H. U. WANG, and X. U. ZHANG, “Spur mitigation

techniques,” U.S. Patent 7 321 631, Jan., 2008.

[125] P. J. U. HUSTED, H. U. YE, and A. U. SINGLA, “Adaptive interference immunity control,” U.S.

Patent 7 349 503, Mar., 2008.

[126] P. J. Husted and W. J. McFarland, “Method and system for noise floor calibration and receive

signal strength ...” U.S. Patent 7 643 810, Jan., 2010, U.S. Classification: 455/226.1.

[127] P. J. U. HUSTED and W. J. U. MCFARLAND, “Method and apparatus for selective disregard of

co-channel transmissions on a medium,” U.S. Patent 7 522 669, Apr., 2009.

[128] E. Anderson, G. Yee, C. Phillips, D. Sicker, and D. Grunwald, “Commodity AR52XX-Based

wireless adapters as a research platform,” Colorado Computer Systems Research Group, Tech.

Rep., Apr. 2008.



http://www.rohde-schwarz.com/en/product/fsp-productstartpage_63493-8043.html

http://www.rohde-schwarz.com/en/product/fsp-productstartpage_63493-8043.html

Bibliography 109

[129] T. H. Lee, The Design of CMOS Radio-Frequency Integrated Circuits, Second Edition, 2nd ed.

Cambridge University Press, Dec. 2003.

[130] D. Tse and P. Viswanath, Fundamentals of Wireless Communication. Cambridge University

Press, Jul. 2005.

[131] G. Fritzsche, Theoretische Grundlagen der Nachrichtentechnik 1. UTB fur Wissenschaft, Nov.

1984.

[132] V. Sridhara, H. Shin, and S. Bohacek, “Performance of 802.11b/g in the interference limited

regime,” Comput. Commun., vol. 31, no. 8, pp. 1579–1587, May 2008.

[133] J. Bardwell, “You believe you understand what you think i said,” Connect802 Corporation, Tech.

Rep., 2004.

[134] ath5k - linux wireless driver. [Online]. Available: http://wireless.kernel.org/en/users/Drivers/

ath5k

[135] ath9k - linux wireless driver. [Online]. Available: http://wireless.kernel.org/en/users/Drivers/

ath9k

[136] P. Bahl, J. Padhy, L. Ravindranath, M. Singh, A. Wolman, and B. Zill, “Dair: a framework for

managing enterprise wireless networks using desktop infrastructure,” in Proc. HotNets, College

Park, MD, Nov. 2005.

[137] Y.-C. Cheng, M. Afanasyev, P. Verkaik, P. Benko, J. Chiang, A. C. Snoeren, S. Savage, and G. M.

Voelker, “Automating cross-layer diagnosis of enterprise wireless networks,” in Proc. SIGCOMM,

Kyoto, Japan, Aug. 2007.

[138] R. Mahajan, M. Rodrig, D. Wetherall, and J. Zahorjan, “Analyzing the mac-level behavior of

wireless networks in the wild,” in Proc. SIGCOMM, Pisa, Italy, Aug. 2006.

[139] A. Schulman, D. Levin, and N. Spring, “On the fidelity of 802.11 packet traces,” in Proc. PAM,

Cleveland, OH, Apr. 2008.

[140] A. Aziz, T. Huhn, R. Karrer, and P. Thiran, “Model validation through experimental testbed: the

fluid flow behavior example,” in Proceedings of 4th International Conference on Testbeds and Re-

search Infrastructures for the Development of Networks and Communities (TRIDENTCOM ’08).

Brussels, Belgium: ICST (Institute for Computer Sciences, Social-Informatics and Telecommu-

nications Engineering), March 2008, pp. 1–6.

http://wireless.kernel.org/en/users/Drivers/ath5k




110 Bibliography

[141] D. Dujovne, T. Turletti, and F. Filali, “A taxonomy of IEEE 802.11 wireless parameters and open

source measurement tools,” Communications Surveys Tutorials, IEEE, vol. 12, no. 2, pp. 249

–262, 2010.

[142] S. Rayanchu, A. Patro, and S. Banerjee, “Airshark: detecting non-WiFi RF devices using com-

modity WiFi hardware,” in Proceedings of the 2011 ACM SIGCOMM conference on Internet

measurement conference, ser. IMC ’11. New York, NY, USA: ACM, 2011, pp. 137–154.

[143] D. Halperin, W. Hu, A. Sheth, and D. Wetherall, “Tool release: gathering 802.11n traces with

channel state information,” SIGCOMM Comput. Commun. Rev., vol. 41, no. 1, pp. 53–53, 2011.

[144] S. L. Felix Fietkau and S. Pirwitz, “Wireless probe, distributed measurement of link status in-

formation using ipfix and openimp,” Fraunhofer Institude for Open Communication Systems,

Technical Report TR-2009-0216-Wireless Probe Link Status Measurement, 2009.

[145] Ip flow information export: charter-ietf-ipfix-07. [Online]. Available: http://datatracker.ietf.org/

doc/charter-ietf-ipfix/

[146] J. Corbet, A. Rubini, and G. Kroah-Hartman, Linux Device Drivers, 3rd Edition. O’Reilly

Media, Inc., 2005.

[147] F. Schneider. Linuxtool: Cpusage. [Online]. Available: http://www.net.t-labs.tu-berlin.de/∼fabian/software de

[148] M. F. Oberhumer. LZO real-time data compression library. [Online]. Available: http:

//www.oberhumer.com/opensource/lzo/

[149] H. Nyquist, “Certain topics in telegraph transmission theory,” American Institute of Electrical

Engineers, Transactions of the, vol. 47, no. 2, pp. 617 –644, Apr. 1928.

[150] J. Schulz-Zander, “Quantitative analysis of physical layer and link layer measurements in wifi

networks,” Diplomarbeit, Technische Universitat Berlin, Berlin, Germany, September 2011.

[151] T. Juhre, “Wireless noise analysis and modeling for bowl network,” Diplomarbeit, Technische

Universitat Berlin, Berlin, Germany, March 2012.

[152] B. Vahl, F. Luque, T. Huehn, and C. Sengul, “Bowlmap: Network monitoring and debugging

through measurement visualization,” in The 4th IEEE Workshop on Hot Topics in Mesh Network-

ing (IEEE HotMESH 2012), San Francisco, USA, Jun. 2012.

[153] T. Huehn and C. Sengul, “Practical power and rate control for WiFi,” in 21st International Confer-

ence on Computer Communications and Networks (ICCCN 2012), Munich, Germany, Jul. 2012.

http://datatracker.ietf.org/doc/charter-ietf-ipfix/

http://datatracker.ietf.org/doc/charter-ietf-ipfix/

http://www.net.t-labs.tu-berlin.de/~fabian/software_de

http://www.net.t-labs.tu-berlin.de/~fabian/software_de

http://www.oberhumer.com/opensource/lzo/

http://www.oberhumer.com/opensource/lzo/

Bibliography 111

[154] P. Salvador, S. Paris, C. Pisa, P. Patras, Y. Grunenberger, X. Perez-Costa, and J. Gozdecki, “A

modular, flexible and virtualizable framework for IEEE 802.11,” in Future Network and Mobile-

Summit 2012 Conference Proceedings. Berlin: IIMC International Information Management

Corporation, Jul. 2012.

[155] (2012, May) mac80211 - linux wireless subsystem. [Online]. Available: http://linuxwireless.org/

en/developers/Documentation/mac80211

[156] J. W. Linville, “Tux on the air: The state of linux wireless networking,” in Ottawa Linux Sympo-

sium, Ottawa, Jul. 2008.

[157] M. Vipin and S. Srikanth, “Analysis of open source drivers for IEEE 802.11 WLANs,” in Inter-

national Conference on Wireless Communication and Sensor Computing, 2010. ICWCSC 2010,

Jan. 2010, pp. 1 –5.

http://linuxwireless.org/en/developers/Documentation/mac80211

http://linuxwireless.org/en/developers/Documentation/mac80211

112 Bibliography

List of Figures

2.1 IEEE 802.11 MAC and PHY layer interactions. . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Transmission, carrier sense and interference ranges in IEEE 802.11. [source: Figure 5

in [42]] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Possible transmission rates in IEEE 802.11abg . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Effective throughput per SNR for IEEE 802.11a at different channel models [78] . . . . 18

2.5 Diagram of the Multi-Rate-Retry chain (MRR) setup per packet as part of Minstrels rate

control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 outdoor indoor map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 BOWL dual-router boxes in indoor and outdoor. . . . . . . . . . . . . . . . . . . . . . . 31

3.3 Design and interconnections between host and Atheros 802.11 interface with MAC and

PHY layer functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4 Measurement setup: Rohde & Schwarz FSP spectrum analyzer connected via pigtail to

a Wistron DCMA-82 WiFi card powered by an Asus wl-500gP . . . . . . . . . . . . . . 37

3.5 Measured output power vs. adjusted power level for 802.11a data-rates at channel 165

(8.525 GHz) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.6 Output Power Limits stored in EEPROM . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.7 SNR and SINR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1 Kernel and User-Space Components of RegMon . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Simplified representation of the three most important blocks associated with packet re-

ception and carrier sensing. The first two blocks address signal detection and are de-

scribed in more details in the Atheros patents. The third block is an energy detection

block parameterized by a threshold. The output of these blocks are periodically sampled

to update three registers that allow to compute the distribution of the MAC state. . . . . 52

4.3 Adjusted vs. measured interval duration based on TSF and 30,000 lines ring buffer size. 55

4.4 Adjusted vs. measured interval duration based on TSF and 30.000 lines ring buffer size. 55

4.5 Adjusted interval vs. measurement bandwidth with and without data compression. . . . 56

113

114 Bibliography

4.6 Comparison between Asus and RSpro routers in terms of adjusted vs. measured interval

based accuracy on a log-log scale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.7 802.11a MAC frame and ack sequence in the case of packet bursts or fragmentation. . . 58

4.8 Zoomed MAC-states view of IEEE 802.11a broadcast packets at the sender. . . . . . . . 59

4.9 Zoomed MAC-states view of IEEE 802.11a broadcast packets at the receiver. . . . . . . 59

5.1 The relevant subsystems of Linux that enable joint control of rate and power starting

from the MAC layer towards a specific driver . . . . . . . . . . . . . . . . . . . . . . . 63

5.2 The statistics update is part of Minstrels rate control. To calculate per-rate success prob-

abilities, Minstrel collects statistics from all packet transmission attempts. It also uses

10% of the data packets as sampling packets to try random rates. . . . . . . . . . . . . . 66

5.3 Measurement results of the relationsship between adjusted tx-power and (a) received

SNR and (b) throughput per rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.4 Minstrel-Blues’s tx- and rx-path between mac80211 subsystem, ath5k driver and Atheros

hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.5 Blues control algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.6 Minstrel-Blues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.7 The three monitoring sources we trace during each experiment. . . . . . . . . . . . . . . 75

5.8 (1) Piano with energy and preamble detection (2) Piano with energy detection. . . . . . . 76

5.9 (1) Minstrel at max. power with energy detection (0-120s) (2) Minstrel-Piano with en-

ergy detection (120-240s), (3) Minstrel-Piano with energy and preamble detection (240-

360s) and (4) Minstrel-Piano back to only using energy detection (360-480s). . . . . . . 76

5.10 Rate distribution across data packets received. (1) 0-120s: Minstrel at max. power

with energy detection, (2) 120-240: Minstrel-Piano with energy detection, (3) 240-360:

Minstrel-Piano with energy and preamble detection, and (4) 360-480: Minstrel-Piano

back to only using energy detection. The y-axis is in log-scale. . . . . . . . . . . . . . . 77

5.11 Nodes and links in the BOWL indoor network setup for spatial reuse evaluation. . . . . . 78

5.12 Both links 1 and 2 are active. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.14 Throughput and mac-states when links 1, 2 and 3 are active. . . . . . . . . . . . . . . . 83

5.15 TX Data-rate and Tx Power-level distribution when Link 1, 2 and 3 are active. . . . . . . 84

5.16 Throughput and Mac-states when Link 1, 2, 3 and 4 are active. . . . . . . . . . . . . . . 85

5.17 TX Data-rate and Tx Power-level distribution when Link 1, 2, 3 and 4 are active. . . . . 86

5.18 Node and Link Setup of Minstrel-Blues Compatibility Scenario. . . . . . . . . . . . . . 87

5.19 Performance results of 2-Links with TCP traffic and w = 2. . . . . . . . . . . . . . . . . 89

5.20 Performance results of 2-Links with TCP Traffic and w = 10. . . . . . . . . . . . . . . 90

List of Tables

2.1 Summary of Transmit Power Control (TPC) Algorithms . . . . . . . . . . . . . . . . . . 13

2.2 Summary of Rate Adaptation Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 How does Minstrel fill the retry chain? . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1 Impact of different weight factors w on the joint power and rate decision . . . . . . . . . 73

115

116 Bibliography