Cross-Layer Design in Wireless Mesh Networksassets.disi.unitn.it/uploads/doctoral_school/... · Figure 1.2: A two-tier architecture for WMNs. mesh routers form and maintain the wireless

PhD Dissertation

International Doctorate School in Information andCommunication Technologies

DISI - University of Trento

Cross-Layer Design in Wireless Mesh

Networks

Roberto Riggio

Advisor:

Prof. Imrich Chlamtac

Universita degli Studi di Trento

March 2008

Acknowledgments

As researchers, and human beings before that, we are not self-sufficient

islands, but part and initiators of communities. Therefore, I own a great

deal of gratitude to colleagues, friends, and members of my family from

whose work and unconditioned support I did enormously benefit.

I would like to express my utmost gratitude to my advisor Prof. Imrich

Chlamtac. His mentoring enriched me both as person as well as a member

of the academic community.

I am thankful to Prof. Yuguang Fang for inviting and hosting me in

the Wireless Networks Laboratory at the University of Florida where I had

the opportunity of sharing his commitment and enthusiasm for scientific

research.

Finally, or, as they say, last but not least, I am grateful to Daniele Mio-

randi and Francesco De Pellegrini for the care with which they revised my

manuscripts and for the conversation that helped me developing a personal

critical thinking. Their friendship and professional collaboration means a

great deal to me.

Abstract

Wireless Mesh Networks (WMNs) have recently emerged as a major conver-

gence research area, drawing concepts and tools from ad-hoc networking, IP

networks and Wireless LANs. Typical application scenarios include broad-

band home networking, community networks and wireless metropolitan area

networks. Furthermore, WMNs can serve as a standalone communication

system for emergency response or public safety.

A WMN consists of several nodes interconnected via wireless links (pos-

sibly employing multiple radio interfaces) and exploiting multi-hop commu-

nications in order to deliver data services to the end-users. With respect to

conventional star-shaped networks, WMNs offer advantages in terms of en-

hanced robustness (in that no single points of failure are present and redun-

dant links are encompassed) and flexibility (without the need for deploying

cables, connectivity may be provided only where and when needed/econom-

ically attractive). Likewise, WMNs differ from the ad hoc paradigm since

the network is not anymore made of an homogeneous set of devices, on the

opposite, nodes involved in the communication can play two different logical

roles, i.e., mesh clients or mesh routers. Mesh clients are the end-users’

devices that dynamically join/leave the network, while mesh routers are in

charge of forwarding packets to and from the wired infrastructure the WMN

gives access to.

Notwithstanding the fact that the decentralized nature of WMNs pro-

vides the network designers with a higher level of flexibility, i.e. a wireless

interconnection of hot-spots is able to provide enhanced coverage without

the need of wiring each AP to the Internet, considerable challenges arise at

v

vi ABSTRACT

each layer of the networking stack. The most evident is the way packets are

routed, where open issues concern the protocol architecture (i.e., at which

level routing should be performed), the routing metric (from standard hop-

count to more complex parameters based on link quality) and the ability to

deliver QoS guarantees to multimedia applications.

In order to turn WMNs into a commodity it is mandatory to develop

techniques capable of enhancing the perceived end-user’s experience. As

matter of fact, it is widely acknowledged that the next-generation Inter-

net will be characterized by an extreme variety of multimedia broadband

services. Unlike traditional “pure data” applications like FTP or HTTP,

multimedia services impose strict requirements in terms of packet loss, la-

tency, delay and jitter.

This thesis exploits cross-layer methods and tools in order to both im-

prove scalability and enable effective autonomic network management. Par-

ticular ephasis has been given to the validation of the proposed solutions

over a real-world WMN test-bed based on the IEEE 802.11 standard. It

is the candidate’s standpoint that such an approach allow rigorous, trans-

parent and replicable experimentation, while also supporting evaluation of

novel protocols and applications in real-world settings. Finally, all the

developed code has been released under the BSD License making it fully

available to the research community. The outcomes of this thesis are the

following:

• A lightweight architecture combining service differentiation with an

adaptive traffic aggregation scheme capable of reducing the service time

at the MAC layer by compounding several frames into a single burst.

Results show that the proposed technique is able to effectively differ-

entiate services and improve the network scalability. With respect to

the specific case of VoIP traffic, in fact, a factor of 5 increase in the

number of simultaneous VoIP sessions is reported.

• A Knowledge Plane tailored for the WMNs scenario and capable of en-

abling consistent sharing of service ontologies among the entities par-

ticipating the WMN. Such Knowledge Plane can be can be exploited for

both monitoring purposes and to adapt the behavior of the node depend-

ing on the particular operating conditions (e.g., traffic type, channel

perturbations, network status, node selfishness and/or maliciousness,

among the others). Moreover, JANUS, a freely available monitoring

framework has been developed in order to verify the suitability of the

proposed Knowledge Plane to a realistic networking scenario, namely

the wireless mesh networking paradigm.

Keywords: wireless mesh networks, IEEE 802.11, traffic aggregation, au-

tonomic computing, service differentiation, testbed, roofnet.

Contents

1 Introduction 1

1.1 Background & Motivation . . . . . . . . . . . . . . . . . . 1

1.2 Innovative Aspects . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . 6

2 State of the Art 9

2.1 Wireless Mesh Networks . . . . . . . . . . . . . . . . . . . 9

2.2 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2 IEEE 802.16 . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Routing metrics . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.1 Expected Transmission Count (ETX) . . . . . . . . 14

2.4.2 Expected Transmission Time (ETT) . . . . . . . . 15

2.4.3 Weighted Cumulative ETT (WCETT) . . . . . . . 16

2.5 Research challenges . . . . . . . . . . . . . . . . . . . . . . 16

2.5.1 QoS Provisioning . . . . . . . . . . . . . . . . . . . 16

2.5.2 Network management . . . . . . . . . . . . . . . . . 18

2.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Methodological approach 23

3.1 Designing a wireless testbed . . . . . . . . . . . . . . . . . 23

3.2 Hardware platforms . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Wireless AP/Routers . . . . . . . . . . . . . . . . . 25

ix

x CONTENTS

3.2.2 Personal Computers . . . . . . . . . . . . . . . . . 25

3.2.3 Embedded PCs . . . . . . . . . . . . . . . . . . . . 26

3.2.4 Time-shared testbed facilities . . . . . . . . . . . . 27

3.3 Layer 3 Solutions . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.1 Ad hoc On-demand Distance Vector (AODV) . . . 27

3.3.2 Dynamic Source Routing (DSR) . . . . . . . . . . . 28

3.3.3 Hazy Sighted Link State (HSLS) . . . . . . . . . . 29

3.3.4 Optimized Link State Routing (OLSR) . . . . . . . 29

3.4 Layer 2.5 Solutions . . . . . . . . . . . . . . . . . . . . . . 29

3.4.1 Roofnet . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4.2 MCL . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5 Multi-channels solutions . . . . . . . . . . . . . . . . . . . 30

3.5.1 Single-radio MAC . . . . . . . . . . . . . . . . . . . 31

3.5.2 Multi-radio MAC . . . . . . . . . . . . . . . . . . . 31

3.6 Final considerations and remarks . . . . . . . . . . . . . . 32

3.6.1 Hardware platform . . . . . . . . . . . . . . . . . . 32

3.6.2 Routing framework . . . . . . . . . . . . . . . . . . 34

3.6.3 Routing protocols . . . . . . . . . . . . . . . . . . . 35

3.6.4 Protocol Architecture . . . . . . . . . . . . . . . . . 36

3.6.5 Licensing . . . . . . . . . . . . . . . . . . . . . . . 36

4 Adaptive traffic aggregation 39

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 Architectural Overview . . . . . . . . . . . . . . . . . . . . 42

4.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4.1 Encapsulation overhead . . . . . . . . . . . . . . . 43

4.4.2 Contention overhead . . . . . . . . . . . . . . . . . 45

4.5 Aggregation in Error-prone Channels . . . . . . . . . . . . 48

4.5.1 Runtime measurements and adaptation . . . . . . . 50

4.5.2 Hop-by-hop packet aggregation . . . . . . . . . . . 52

4.6 Evaluation Methodology . . . . . . . . . . . . . . . . . . . 53

CONTENTS xi

4.6.1 Testbed configuration . . . . . . . . . . . . . . . . . 53

4.6.2 Traffic Generation . . . . . . . . . . . . . . . . . . . 54

4.6.3 E-Model . . . . . . . . . . . . . . . . . . . . . . . . 55

4.7 Performance Measurements . . . . . . . . . . . . . . . . . 56

4.7.1 Channel aware traffic aggregation . . . . . . . . . . 57

4.7.2 Impact of background traffic . . . . . . . . . . . . . 60

4.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5 A DiffServ architecture for Wireless Mesh Networks 65

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Providing intra-cell airtime fairness . . . . . . . . . . . . . 66

5.2.1 Deficit Round Robin (DRR) Scheduling . . . . . . 67

5.2.2 Airtime DRR (A-DRR) Scheduling . . . . . . . . . 68

5.3 Architectural Overview . . . . . . . . . . . . . . . . . . . . 70

5.4 Evaluation Methodology . . . . . . . . . . . . . . . . . . . 71

5.5 Performance Measurements . . . . . . . . . . . . . . . . . 75

5.5.1 Data-set A . . . . . . . . . . . . . . . . . . . . . . . 75

5.5.2 Data-set B . . . . . . . . . . . . . . . . . . . . . . . 75

5.5.3 Data-set C . . . . . . . . . . . . . . . . . . . . . . . 76

5.5.4 Data-set D . . . . . . . . . . . . . . . . . . . . . . . 78

5.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6 Holistic network monitoring 83

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.3 Autonomic Network Management . . . . . . . . . . . . . . 88

6.4 Overview of the Proposed Approach . . . . . . . . . . . . . 90

6.5 System Architecture . . . . . . . . . . . . . . . . . . . . . 95

6.5.1 Managed Resource . . . . . . . . . . . . . . . . . . 96

6.5.2 Agent . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.5.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.5.4 Mesh Knowledge Base . . . . . . . . . . . . . . . . 100

xii CONTENTS

6.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7 Conclusions and future work 103

Bibliography 113

The greatest challenge to any thinker

is stating the problem in a way that

will allow a solution.

Bertrand Russell

Chapter 1

Introduction

1.1 Background & Motivation

The need for telecommunications1 dates back to the ancient Greeks. Hy-

draulic telegraphs are known to have been used during the Punic wars

(264 to 241 BC) in order to send messages between Sicily and Carthage.

Such devices consisted in two identical containers placed on top of sepa-

rate hills. Each container would be filled with water, and a vertical rod

floated within. The rods were inscribed with various predetermined codes.

To send a message, the sender operator would raise a torch to signal the

receiving operator; once the two were synchronized, they would simultane-

ously open the tap at the bottom of their containers. Water would drain

out until the border of the container was aligned with the desired code, at

which point the sender would lower his torch, and both operators would

simultaneously close their taps. The receiving operator could then read

the code of the signal on the rod.

The development of unwired communication technologies proved to be

a constant historical trend also in the networking scenario. As a matter

of fact, albeit capable of delivering data-rate up to hundreds of gigabytes

per second, current optical technology is failing to impose itself as standard

network access solution. The reason for such a situation is twofold. First,

the advantages of fiber are not so appealing when cost is factored into

1“tele” is Greek work that means “far away”.

1

2 Chapter 1. Introduction

Figure 1.1: A star-shaped architecture for IEEE 802.11-based WLANs.

the equation. Second, even in highly populated areas where the number

of customers could make optical technology a viable choice, the increas-

ing demand for ubiquitous internet access is again tipping the balance

toward wireless solutions mostly in the form of IEEE 802.11 “hot-spots”

(see Fig. 1.1) and cellular technologies.

Nonetheless, one major obstacle to the deployment of massive wireless

networks, especially in metro areas, is the cost related to the placement

of APs, which typically are wired and cannot be replaced or moved easily.

Network planning is thus a quite irreversible operation: once deployed,

APs can be added but hardly moved to new positions. In such a scenario,

Wireless Mesh Networks (WMNs) have recently appeared as a major con-

vergence research area for academic institutions and companies. As op-

posed to WLANs, WMNs exploit a multi-hop wireless back-haul in order

to deliver Internet connectivity to the end-users. Compared to other, more

conventional network architectures, WMNs offer considerable advantages

in terms of improved fault tolerance, extended network coverage and en-

hanced protocol efficiency, while presenting much lower deployment costs.

Figure 1.2 shows a two-tier architecture for WMNs. In such a scenario

1.1. Background & Motivation 3

Figure 1.2: A two-tier architecture for WMNs.

mesh routers form and maintain the wireless back-haul realizing the in-

frastructure exploited by the mesh clients. Some mesh routers can also

act as gateway providing the WMN with Internet access. Community and

neighborhood networks can be built using such an architecture with mesh

routers placed on top of the roof, serving as access points for users in the

neighborhood (e.g. MIT Roofnet).

However, the distributed and decentralized nature of WMNs arises many

challenges when facing the increasing demand for multimedia applications.

As proved in recent studies [1], ensuring the required QoS parameters ap-

pears a challenging task even for a small number of hops (2-3). On the

other hand, from a wireless internet service provider perspective, the eco-

nomic convenience of a WMN is measured by the number of customers

that can be supported by a given network deployment. The two metric are

strictly correlated: the larger the network diameter, the larger the number

of customers that can be served without incurring the expenses related to

the wiring of additional APs.

As a matter of fact, the current Internet lacks a widely deployed frame-

work for supporting QoS. Such mechanisms are in fact mostly needed when


network resources are scarce and real world experience has proved that is

often cheaper to upgrade to higher capacity links or equipments than to

deploy Internet-wide QoS solutions. Such an approach, known as over-

provisioning, cannot easily be applied with wireless networks especially

in the case of “last-mile” solutions based on the IEEE 802.11 family of

standards. In the latter case in fact, interference caused by the increased

number of wireless devices operating over unlicensed frequency is bound to

produce higher error rates and service interruptions than equivalent wired

or licensed wireless networks.

Notwithstanding the fact that WMNs can already be deployed using

off-the-shelf components and protocols developed for ad hoc networks, sig-

nificant research challenges must still be addressed in order to fully benefit

of the mesh networking paradigm. Indeed, mobile ad hoc and wireless

sensor networks constraints on power consumptions and mobility lead to a

protocol design that is too cumbersome for the WMNs scenario. Likewise,

the increasing demand for multimedia services mandates a set of require-

ments that is significantly different from a general ad hoc network.

1.2 Innovative Aspects

This research activity involved from the beginning the design and realiza-

tion of a wireless mesh testbed based on the IEEE 802.11 family of stan-

dards and using off-the-shelf components. Measurements run over such a

testbed have been exploited in order to evaluate the performance of current

protocols in a wireless mesh environment, providing precious guidelines for

the design of the proposed solutions. Here follows the major milestone

achieved:

• An adaptive traffic aggregation scheme for WMNs, where service time

reduction at the MAC layer is obtained by compounding several pack-

ets into a unique burst frame. The scheme receives as input some

measurable link metrics, and each node can compute the optimal

1.2. Innovative Aspects 5

burst length using a closed formula derived under saturation assump-

tions. The proposed solution proved to enhance the scalability of

IEEE 802.11-based WMNs. In fact, with respect to the specific case

of VoIP traffic, we experienced a factor 5 increase in the number of

simultaneous VoIP flows supported by the network. A service differen-

tiation scheme combining traffic prioritization and packet aggregation

has been implemented in order to assess the suitability of the proposed

approach to a realistic network deployment. The resulting architec-

ture does not require any modification to the IEEE 802.11 MAC and

can be readily implemented over existing hardware.

• A Knowledge Plane tailored for the WMNs scenario and capable of

enabling consistent sharing of service ontologies among the entities

participating the WMNs. The Knowledge Plane is here intended as a

network construct additional to both the Data and the Control Plane.

Such a scenario requires the Knowledge Plane to encompass consistent

syntax and semantic in order to allow its exploitation for monitoring

purposes as well as to adapt the behavior of the node depending on

the particular operating conditions (e.g., traffic type, channel pertur-

bations, network status, node selfishness and/or maliciousness, among

the others). In our approach, such a feature is obtained by exploiting

both a meta-model, general enough to support the different aspects

of existing mesh networking paradigms and a common meta-data ex-

change facility. These elements have been identified respectively in

the Meta Object Facility (MOF) and the XML Metadata Interchange

(XMI). As it will be clear in the following, the exploitation of these

two standards allows uniformity among heterogeneous WMNs imple-

mentations to be easily gained.

The complexity of the above mentioned tasks requires knowledge to be

shared across the whole networking stack. In order to achieve such a goal

this thesis abandoned a strictly layered architecture in favor of a cross-layer

protocol design. This approach already proved its effectiveness in the multi-


hop wireless networks domain where both performances and scalability can

be greatly improved by taking into account interactions between layers. As

for example in [2], multiuser diversity can substantially improve wireless

network throughput in IEEE 802.11-based WLANs. In such an approach

each user reports to the base station its “instantaneous” channel capacity.

This information can be exploited by the scheduling algorithm in order

to take advantage of channel variations by giving priority to users with

instantaneously better channels. In a similar way, link quality information

are exploited in [3] in order to minimize the expected total number of

retransmission required to successfully deliver a packet to the ultimate

destination in a multi-hop wireless network.

1.3 Structure of the Thesis

The rest of this thesis is structured as follows. Chapter 2 introduces the

wireless mesh networking paradigm, discussing performance and manage-

ment challenges that arise from the distributed and decentralized nature

that characterizes this kind of networks.

Chapter 3 provides a survey on the most relevant hardware and software

platforms that can be used to build a WMN testbed. Trade-offs involved

in the design of a WMN testbed are carefully discussed motivating the

design choices that eventually led to the testbed design exploited during

this thesis.

Chapter 4 addresses the voice capacity issue by proposing an adaptive

traffic aggregation scheme. VoIP applications have been chose as reference

application scenario due to: (i) their widespread use (e.g. Skype) and (ii)

their strong requirements in terms of Quality-of-Service support.

Chapter 5 introduces an architecture for achieving service differentiation

and performance isolation (at layer 2.5) in IEEE 802.11-based WMNs.

While not providing strict QoS performance bounds, the proposed scheme

aims at enhancing the perceived quality of experience by combining traffic

prioritization and packet aggregation in IEEE 802.11-based WMNs.

1.3. Structure of the Thesis 7

Chapter 6 proposes a Knowledge Plane tailored for the WMNs scenario

and capable of enabling consistent sharing of services ontology among the

entities participating the WMNs. Moreover, it illustrates JANUS, a novel

monitoring framework developed in order to verify the feasibility of the

proposed approach.

Finally, Chapter 7 draws the conclusions pointing out future research

directions.

The secret to creativity is knowing

how to hide your sources.

Albert Einstein

Chapter 2

State of the Art

2.1 Wireless Mesh Networks

A WMN [4, 5] consists in a set of communication nodes, interconnected

via wireless links using possibly multi-channel multi-radio technologies/in-

terfaces. It allows for continuous connections and reconfiguration around

broken or blocked paths by “hopping” from node to node until the destina-

tion is reached. WMNs share many features with the conventional ad hoc

networking paradigm, namely, the self-healing and self-configuring capabil-

ities. Although WMNs can serve as a standalone communication systems

for disaster recovery or public safety, this thesis focuses on access network

applications. In this scenario, a distinction exists in terms of logical roles

supported by the physical devices:

• Relay : building the multi-hop wireless backhaul by establishing links

between a selected set of nodes.

• Gateway : interfacing the WMN with another network, typically the

Internet.

• Access point : providing wireless connectivity to clients.

• Client : gaining network access for end users.

Nodes providing relaying/access functionality are generally computa-

tionally powerful devices with no constraints on power consumption and

9

10 Chapter 2. State of the Art

possibly equipped with multi-channel and multi-radio interfaces/technolo-

gies. Those nodes are generally called “mesh routers” as opposed to the

end-user devices generally referred to as “mesh clients”. Mesh routers can

also act as gateways providing the WMN with Internet connectivity.

The remainder of this chapter is organized as follows. Section 2.2 de-

scribes the current standardization efforts in WMNs. Protocol architec-

tures and alternatives routing paradigms are discusses in Sec. 2.3. Sec-

tion 2.4 surveys the routing metrics developed specifically for the WMN

scenario. The most relevant architecture for QoS provisioning and network

management for WMNs are described in Sec. 2.5. Finally, Sec. 2.6 draws

the conclusions highlighting the major contribution of this thesis.

2.2 Technologies

In principle, WMNs could interface, through suitable gateway nodes, with

networks based on different radio technologies (3G, WiFi, Bluetooth, WiMAX,

etc.). However, most actual solutions, in both academic and business en-

vironments, heavily rely on the IEEE 802.11 family of standards. This is,

to a large extent, because of both the availability of low-cost equipment on

the market and the “ad hoc” features already present in such protocols,

which makes possible to obtain a mesh configuration with some rather sim-

ple modifications. This section describes the most relevant standardization

efforts by IEEE in order to support the wireless mesh networking paradigm

in its 802 family of protocols.

2.2.1 IEEE 802.11

IEEE 802.11s Task Group (TG) plans to integrate mesh networking ser-

vices and protocols within 802.11 MAC layer. The resulting systems will be

compatible with the IEEE 802.11 Infrastructure Mode. In this standard,

peer-to-peer L2 links among multiple IEEE 802.11s Mesh Points can be es-

tablished to enable direct or multi-hop data delivery for higher throughput

2.3. Routing 11

and range extension.

2.2.2 IEEE 802.16

WiMAX is the commercial name of products compliant with the IEEE

802.16 [6] standard. The IEEE 802.16 first release accounts for a scenario

with no mobility and with operations in licensed frequency bands ranging

from 10 to 66 GHz. Later amendments (IEEE 802.16-2004) extends the

standard to non-line-of-sight applications in the 2-11 GHz band. Addi-

tional releases encompass mobility (IEEE 802.16e) and improved Quality

of Service (QoS) (IEEE 802.16g). Multihop relaying will be provided by

IEEE 802.16j.

2.3 Routing

WMNs share a number of features with ad hoc networks [7]. In particular,

WMNs are characterized by self-organization and self-healing capabilities

and exploit multi-hopping to build a wireless backhaul for delivering In-

ternet connectivity to end-users. As a result, many routing protocols de-

veloped for Mobile Ad hoc Networks (MANETs) have been adapted to fit

the mesh environments. Particular attention has been devoted to the intro-

duction of novel routing metrics capable of achieving better performance in

outdoor deployments by considering the wireless channel characteristics [8].

Routing can be either provided at level three of the ISO/OSI networking

stack as modification of the standard IP protocol (see Fig. 2.1(a)) or by

adding an interposition layer between the Data Link Layer and the Network

layer (Fig. 2.1(b)). In the latter solution (usually referred to as Layer 2.5

routing), the multi-hop backhaul is transparent to the upper networking

stack making the WMN appear like a LAN. On the other hand, such

an approach introduces additional encapsulation and processing overhead

as a result respectively of the header and the checksum required by the

interposition level. This implies a slight reduction in overall performance,


(a) L3 Routing (b) L2.5 Routing

Figure 2.1: Alternative protocol stacks for WMNs.

in terms of both throughput and latency.

Routing protocols developed for MANETs are generally classified as

proactive, reactive, and hybrid. This section summarizes the main features

of each category. For a comprehensive survey, readers are referred to [7].

Proactive routing

Proactive protocols attempt to continuously evaluate all the routes within a

network, so that when a packet needs to be forwarded, the route is already

known and ready to use. Early applications of proactive routing schemes

were based on Distance Vector Routing (DVR) protocols exploiting the Dis-

tributed Bellman-Ford (DBF) algorithm for computing the shortest path in

a weighted graph representing the network. Modifications to the basic DBF

algorithm [9] were proposed to address the inherent problems of slow con-

vergence and excessive traffic (both can be quite severe in MANETs, where

the bandwidth is scarce and the topology is often dynamic). Destination-

Sequenced Distance-Vector Routing (DSDV) [10] is a routing protocol for

ad hoc networks based on the Bellman-Ford algorithm.

As opposed to DVR protocols, Link State Routing (LSR) protocols re-

act more quickly to connectivity changes. Network traffic is also lower

2.3. Routing 13

because only the information about a node’s immediate neighbors is trans-

mitted, instead of the node’s entire routing table. The main disadvantage

of link-state routing is that it requires more storage and more computing

resources than distance vector routing. The need to improve convergence

performance and to reduce control traffic led to the development of im-

proved path finding algorithms which combine the features of DVR and

LSR protocols. The Optimized Link State Routing (OLSR) [7] is an ex-

ample of such a protocol. OLSR is an optimized version of traditional

link-state routing protocol such as OSPF. It uses the concept of Multi-

point Relays (MPRs) to efficiently disseminate link state updates across

the network. Only the nodes selected as MPRs are allowed to generate

link-state updates.

Reactive routing

Reactive routing protocols invoke a route discovery procedure on an on-

demand basis. The reactive route discovery is usually based on a query/re-

ply exchange, where a flood-based process is used to reach the desired des-

tination. The main disadvantages of such an approach are (i) the initial

delay for route discovery; (ii) the potential scalability problems related to

the use of flooding. The Dynamic Source Routing (DSR) [11] and Ad hoc

On-Demand Distance Vector (AODV) [12] protocols can be used to uni-

cast the route reply back to the querying source along a path constructed

during the route query phase. In the case of DSR, the routing information

is accumulated in the query packet and the complete sequence of nodes

on a path to the destination is recorded and returned to the source to be

used for source routing of the actual user data. AODV, on the other hand,

distributes the discovered route in the form of next-hop information stored

at each node in the route.


Hybrid

Protocols that belong to this class leverage both proactive and reactive

techniques in order to determine the best path between any pair of nodes.

The Hazy Sighted Link State Routing Protocol (HSLS) [13] was designed

to scale in networks with over thousands of nodes, where it outperforms

most of other best-known routing algorithms. The protocol exploits both

proactive and reactive link state routing to limit network updates in space

and time. Unlike traditional methods, HSLS does not flood the network

with link-state information and attempts to cope with moving nodes that

change connections with the rest of the network.

2.4 Routing metrics

The highly time-varying nature of the wireless medium led to the consider-

ation that, even under light load conditions, routing metrics that minimize

the hop count do not result in good performances [8]: a two hop path over

reliable and fast links can lead to better performances than a single hop

route over a lossy and/or slow link. As a result, novel performance metrics

have been developed in order to take into account link quality. This section

surveys the most relevant routing metric with a particular focus on solu-

tions implemented over real-world testbeds. In [8], a detailed evaluation of

the performance of different routing metrics is reported.

2.4.1 Expected Transmission Count (ETX)

The ETX metric [3] of a link is the expected number of transmission re-

quired to send an unicast packet over that link, including retransmission.

Being dfwd and drev respectively the forward and the reverse link delivery

ratio of the link, it stands:

ETX =1

dfwddrev

(2.1)

2.4. Routing metrics 15

In order to compute the delivery ratios dfwd and drev each node periodically

broadcast probes of fixed size at an average period τ . It is worth remem-

bering that broadcast frame are not acknowledged nor retransmitted by

the IEEE 802.11 devices. Each node keeps track of the number of probes

received during an observation window W . At any time, the link delivery

ratio r is then given by:

r(t) =count(t − W, t)

w/τ(2.2)

Note that count(t − W, t) is the number of probes received during the

observation window W and w/τ is the number of probes that should have

been received. Finally each probe sent by a node contains the number of

probes packets received by the same node from all its neighbors. This allow

each node to properly compute both dfwd and drev.

One major drawback of the ETX metric is that it considers only loss

rate and not link bandwidth. As a result it cannot distinguish among the

links that are loss-free at the lowest data-rates, only some of which will

work well also at higher rates. As a result, selected routes will not take

much advantage of high bit-rate links.

2.4.2 Expected Transmission Time (ETT)

The ETT metric [14] aims at estimating the amount of time required to

transmit a packet over a wireless link. let S denote the size of the probe

and B the data rate at which the probe has been sent, then the ETT metric

of the link is given by:

ETT =S

BETX (2.3)

As a result, ETT will favors paths with higher bit-rate. The main

disadvantage of the ETT metric is its inability to select channel-diverse

paths in multi-radio environments.


2.4.3 Weighted Cumulative ETT (WCETT)

WCETT [14] extends the ETT metric in order to take into account the

interference among links which use the same channel. WCETT always

assumes that two hops on a path always interfere if they use the same

channel. As pointed out by the authors in [14], this assumption is true for

short paths but is pessimistic on longer paths. Let us consider an n-hops

path and a k-channels WMN. Let Xj be the sum of the transmission times

of hops exploiting the same channel j:

Xj =∑

hop i on channel j

ETTi 1 ≤ j ≤ k (2.4)

According with such definition the bottleneck channel is the one with

the largest Xj. Thus for a path consisting of n-hops it stands:

WCETT = (1 − β)n

∑

i=1

ETTi + β max1≤j≤k

Xj (2.5)

The first term in 2.5 is the sum of transmission times along the full path,

while the second term takes into account the hops that will most affect the

route throughput. The relative weight of the two terms can be specified

by means of the tunable parameter β (0 ≤ β ≤ 1).

2.5 Research challenges

2.5.1 QoS Provisioning

The distributed and decentralized nature of WMNs presents many chal-

lenges when facing the increasing demand for multimedia applications,

which require a tight control over the system’s available resources. Fur-

thermore, as proved in recent studies [1], WMNs scalability problems pose

additional constraints so that ensuring the required QoS parameters ap-

pears a challenging task even for a small number of hops (2-3). But, despite

this is considered a strategic goal to achieve, little efforts have been dedi-

cated to investigate efficient techniques for supporting QoS in WMNs. The

2.5. Research challenges 17

vendors which have been selling wireless mesh solutions of course do im-

plement some form of QoS policies, but they are obviously very reluctant

to release those informations. Hence the research in this field lacks from a

comprehensive QoS perspective. This is mainly due to the fact that wire-

less mesh technology has begun to attract interests only recently, while

both the WiMAX and the WiFi technologies have been around from quite

a long time.

Internet-wide solutions

The Asynchronous Transfer Mode technology (ATM), defined in the ATM

Forum specifications ([15, 16] and subsequent), is a cell relay, network and

data link layer set of protocols which carries data into small (53 bytes;

48 bytes of data and 5 bytes of header information) fixed-sized cells. This

aims at replacing the variable size packets which are typical of IP networks.

ATM is a connection-oriented technology, in which a connection is estab-

lished between the two endpoints before the actual data exchange begins.

ATM provided very advanced QoS management features like multiple traf-

fic classes, tunable performance parameters and suitable mechanism for

ensuring QoS (e.g. Call Admission Control, Traffic Shaping). ATM has

proved very successful in the WAN scenario and numerous ISPs have im-

plemented ATM in their wide-area network cores. However, it failed to

gain wide use as a LAN technology, and its complexity has held back its

full deployment as the single integrating network technology in the way

that its inventors originally intended.

Network layer solutions

At the network level, IETF answered the ever growing demand for QoS

provisioning by proposing the Integrated Services (IntServ) [17, 18] and

the Differentiated Services (DiffServ) [19] models. The IntServ model pro-

vides per-flow differentiation. This in turn requires flow-specific state in-

formation in each router. Applications with QoS requirements have to


set up connections before transmitting their data requesting for a certain

amount of resources. An admission control routine will determine if the

requested resources are available or not, accepting or rejecting the connec-

tion. The IntServ approach showed several scalability limitations [20] as

the amount of state information increases with the number of flows travers-

ing an IntServ network. DiffServ was introduced because of the limitations

of IntServ. DiffServ is an architecture which provides a per-hop aggregated

service differentiation and is suitable for ISPs which may want to have dif-

ferent Service Level Agreements (SLAs) with their customers. To this end,

the ISP leaf routers may mark the customers datagrams according to their

SLA in order to provide different levels of QoS.

Link layer layer solutions

The need for service differentiation in WLANs drove the 802.11 Work-

ing Group to ratify an amendment dedicated to QoS provisioning. IEEE

802.11e introduces a new coordination function called the Hybrid Coor-

dination Function (HCF). Within the HCF there are two access mech-

anisms: a non-contended polling channel access scheme called HCF Con-

trolled Channel Access (HCCA) and a prioritized contention scheme called

Enhanced Distributed Channel Access (EDCA). Both EDCA and HCCA

define Traffic Classes (TC). For example, best effort TCP traffic could be

assigned to a low priority class, while VoIP traffic could be assigned to a

high priority class. With EDCA, high priority TCs have, on average, an

higher chance of being sent than low priority TCs. The HCCA way of

working resembles IEEE 802.11’s PCF, however since HCCA support is

not mandatory currently available APs do not support it.

2.5.2 Network management

Albeit research of WMNs has been up to a large extent confined to the

study of efficient routing protocols, there is a clear need to envision new

network management tools, able to sufficiently exploit the peculiarities of

2.5. Research challenges 19

WMNs. Nowadays, in network management, a set of tools, applications

and devices are used in order to monitor and maintain networks. This

includes performing functions such as initial network planning, frequency

allocation, predetermined traffic routing to support load balancing, fault

management, security management, performance management, bandwidth

management, and accounting. Current management functionalities are

developed using a strongly centralized approach. However, the distributed

and self-organizing nature of WMNs suggest a transition from network

management (in terms of manual tweaking) to network sensing (in terms of

distributed and automated fault detection and/or performance analysis).

The advantages provided by such an approach are twofold: (i) network

operators can gain an increased insight into network behavior and resource

utilization, (ii) the research community is provided with a powerful tool

for the rapid prototyping of innovative solutions.

Simple Network Management Protocol (SNMP)

SNMP is an application layer protocol developed in order to standardize

the exchange of management information between network devices enabling

effective network management. An SNMP-managed network consists of

four key components:

• Managed devices. A managed device is a network node that contains

an SNMP agent and that resides on a managed network. Managed

devices collect and store management information and make this in-

formation available to NMSs using SNMP. Managed devices can be

routers, switches, hosts, etc.

• Agents. An agent is a network-management software module that

resides in a managed device. An agent has local knowledge of man-

agement information and translates that information into a form com-

patible with SNMP.


• Network Management Systems (NMSs). A NMS is in charge for mon-

itoring and controlling managed devices. In a SNMP deployment, the

NMS is responsible for polling and receiving traps from the Agents

as well as for changing the values of variables stored within managed

devices.

• Management Information Base (MIB). A Management Information

Base (MIB) is a collection of information that is organized hierarchi-

cally. MIBs are accessed using a the SNMP protocol.

Control and Provisioning of Wireless Access Points (CAPWAP)

CAPWAP is centralized architecture designed to manage multiple IEEE

802.11 wireless access point reducing the amount of time spent configuring,

monitoring and troubleshooting a large network. There exist two basic en-

tities in CAPWAP-managed wireless network: the Wireless Termination

Point (WTP), which roughly correspond to the AP, and the Access Con-

troller (AC). A single AC manages multiples WTPs allowing fast deploy-

ments of network-wide configurations. CAPWAP proposes two different

network architectures:

• Split MAC, both data and management frames are encapsulated via

the CAPWAP protocol and exchanged between the AC and the WTP;

• Local MAC, frames are processed locally by the WTP, and then tun-

neled to the AC.

It is worth pointing out that services characterized by strict timing

requirements (e.g. transmission of beacons and probes) are always handled

by the WTP.

2.6 Conclusions

WMNs are emerging as novel networking paradigm capable of support-

ing application scenarios where ease of deployment and reconfiguration are

2.6. Conclusions 21

major requirements. However, notwithstanding the considerable interest

raised in the research community in the last couple of years and the grow-

ing number of companies currently active in this field, WMNs still pose

significant challenges at each layer of the networking stack. In this chapter

state-of-the-art solutions for QoS provisioning and network management

have been discussed highlighting the limitation of current approaches.

As matter of fact, the scope of the issues addressed during this research

activity spans across all layers in the networking hierarchy motivating the

cross-layer approach exploited in this thesis. However, it is worth noting

that a layered architecture enables protocols designers to concentrate their

efforts at a particular level without worrying about the rest of the protocol

stack. On the other hand, once the layering is broken such an approach

is no more viable, and the effects of any single design choice on the whole

system needs to be carefully considered. In [21] it is shown that that

unintended cross layer interactions can have undesirable consequences on

overall system performance and a few general principles for cross-layer

design are given.

An expert is a man who has made all

the mistakes, which can be made, in

a very narrow field.

Niels Bohr

Chapter 3

Methodological approach

3.1 Designing a wireless testbed

WMNs [4, 5] are currently receiving considerable interest in both industrial

and academic environments. Many companies are active in this field devel-

oping solutions mostly based on the IEEE 802.11 family of standards [22].

However, while commercial deployments are characterized by proprietary

approaches, there are significant efforts from the academic world to provide

real-world prototypes and testbeds based on open-source software and off-

the-shelf technologies. In parallel, as described in Sec. 2.2, relevant efforts

are coming from the IEEE 802 working group in order to support the wire-

less mesh networking paradigm within the well-known and diffused IEEE

802.11 and IEEE 802.16 standards.

This research activity involved from the beginning the design and real-

ization of a wireless mesh testbed using off-the-shelf components. Being

shielded by the hazards of a live or production environment, testbeds pro-

vide rigorous, transparent and replicable testing conditions. Measurements

run over testbeds can be exploited in order to evaluate the performance of

newly developed protocols, providing important guidelines for the design

of innovative solutions. Moreover, all the solutions proposed in this thesis

have been implemented and and validated through experiments conducted

over a real-world testbed based on the IEEE 802.11 standard.

This chapter provides a survey on the most relevant hardware and soft-

23

24 Chapter 3. Methodological approach

ware platforms that can be used to build a WMN testbed. It is not the

candidate’s intention to provide an exhaustive survey on all platforms that

are suitable for a WMN deployment, instead this chapter concentrate on

open-source software and off-the-shelf hardware components. Unlike [4, 5],

where the authors aim at providing a survey of existing technologies and

research challenges in the WMNs scenario, this chapter’s goal is to discuss

the design guidelines and trade-offs faced for engineering a WMN testbed.

The remainder of this chapter is organized as follows. Section 3.2 surveys

hardware platforms and operating systems suitable for WMN deployments.

Software solutions implementing a WMN with layer 3 and layer 2.5 routing

are reported in Sec. 3.3 and Sec. 3.4, respectively. Particular emphasis will

be given to the implementations based on open-source code. Muti-radio

solutions are surveyed in Sec. 3.5. Finally, Sec. 3.6 concludes the chapter

giving some remarks on WMN testbed engineering.

3.2 Hardware platforms

From the hardware viewpoint, a wireless mesh router consists of a com-

puter (e.g., laptop), one or multiple wireless Network Interface Controllers

(NICs), an enclosure, an antenna, and all the necessary cable and mount-

ing equipments. A more detailed checklist heavily depends on research

directions and reference deployment scenario in terms of network type and

size, expected users and services features, budget and time availability. Fi-

nally, a suitable Operating System (OS), which manages the hardware and

software resources of a mesh node, must be chosen. It is worth pointing

out that the choice of OS should not be the driving factor in the testbed

development. Instead, it must act as the “glue” between the hardware and

software requirements.

Companies like Tropos, BelAir, Firetide, MeshNetwork and Strix pro-

vide network engineers with vertical solutions for wireless mesh networking,

from network planning to network management. However, such solutions

are based on proprietary technologies and adopt radically different ap-

3.2. Hardware platforms 25

proaches and protocols, making interoperability a key issue.

This Section reviews the most relevant hardware platforms for WMN

developments. It is not the candidate intention to provide an exhaustive

comparisons of all the available solutions, instead, the section focuses on

platforms based on the well recognized standards supporting preferably

open-source OSes. The latter requirement provides the testbed designed

with an higher level of control over the network parameters.

3.2.1 Wireless AP/Routers

Although limited by the radio capability due to their small antenna and

low powered WiFi cards, many home wireless routers can be successfully

exploited as wireless mesh routers. Being characterized by low costs (80-

100e at the time of this writing), those devices provide the cheapest solu-

tion for wireless mesh networking. However, due to their limited resources,

embedded devices cannot generally run a compiler or a development envi-

ronment. In such a scenario, cross compilation is the only possible way to

build programs. Cross compilation is a process by which a compiler gen-

erates binary program files that are not meant to be executed on the local

system (an x86-compatible PC typically), but rather on a different platform

(the embedded device). For example, OpenWRT is a GNU/Linux based

distribution for embedded devices, which provides an integrated frame-

work for cross compiling software packages, allowing users to generate a

customized firmware image to be loaded into the wireless router.

3.2.2 Personal Computers

Personal Computers based on the Intel x86 architecture provide high flexi-

bility in the components such as main memory, mass storage and even the

motherboard and the central processing unit, which are widely available

and may be selected according to the specific needs. However, being de-

signed primarily as general purpose computers, those platforms could be

expensive to install and manage and are not suitable for a 24/7 service.


For example, many PCs have moving parts (hard disk and fans) and their

outdoor deployment could be challenging due to both the lack of suitable

(water-proof) enclosures and the power consumption requirements. On

the other hand, they are easier to program and offer greater flexibility. A

wide range of operating systems is available for such platforms, like all Lin-

ux/Unix variants, the various children of BSD and the Microsoft operating

systems. LocustWorld provides mesh routers, called MeshBoxes, consisting

of a PC, an 802.11b card, and an omni-directional antenna. A MeshBox is

based on open-source software components and runs a customized Linux

kernel, with mesh routing and interactive functions provided as Linux ap-

plications.

3.2.3 Embedded PCs

Being based on the x86 architecture, embedded PCs combine the advan-

tages of Wireless routers and PC. Custom and off-the-shelf hardware (PCI,

MiniPCI, etc) is available and final systems are characterized by a wide

performance range. No cross compilation is required and standard devel-

opment tools and operating systems can be used. Finally, outdoor de-

ployment is made easier by tailored water-proof enclosure, Power Over

Ethernet support and the absence of any moving part. Soekris Engineer-

ing provides a line of x86-based embedded computers. For example, the

Soekris net4826-50 board is equipped with a 266 MHz AMD Geode CPU,

128 MB of RAM, one 100 Mbit Ethernet port, and two Mini PCI type

III sockets. Power can be provided through an external power supply or

with Power Over Ethernet according to the 802.3af standard. Such a sys-

tem can be equipped with one/two wireless NICs, providing a cheap yet

powerful Wireless Router Application Platform. Many operating systems

are available for these platforms, ranging from open-source systems based

on the various Linux/BSD distributions to commercial real-time solutions.

Similar solutions are provided by other companies (e.g., PCEngines). Em-

bedded platforms based on non-x86 CPUs (e.g. RouterBoard) provide a

3.3. Layer 3 Solutions 27

better price/performance ratio with the drawback of requiring cross com-

pilation.

3.2.4 Time-shared testbed facilities

An interesting initiative is the Orbit project1, which aims at building a lab-

oratory testbed designed to achieve reproducibility of experimentation and

fostering the development of novel protocols and applications. Orbit ex-

ploits a large two-dimensional grid of 400 nodes, each of which is equipped

with two IEEE 802.11 radios. Nodes can be interconnected into user-

defined topologies with reproducible wireless channel conditions. Users

are allowed to load a custom operating system together with any modified

system software and application needed to run their experiments. An ex-

tensive library of measurement tools and experimental setups is available.

3.3 Layer 3 Solutions

This section surveys the main implementations of layer 3 routing protocols

for multi-hop wireless networks. Implementations are grouped by proto-

col’s type and have been selected using code maturity, license, and ex-

ploitation in real-world testbeds as classification criteria.

3.3.1 Ad hoc On-demand Distance Vector (AODV)

The AODV-UIUC project developed a library (ASL, Ad hoc Support Li-

brary) that can be exploited to implement on-demand or reactive ad hoc

routing protocols. The library works in user-space on GNU/Linux systems,

and is provided together with a small loadable kernel module. In order to

show the capabilities of the framework, the AODV protocol has been imple-

mented using both Netfilter and the ASL. A similar design has been used

by the AODV-UCSB and the AODV-UU implementations. Both exploits

1http://www.orbit-lab.org/


the same kernel interaction part differing only in the logic implementation

of the AODV protocol, which is done in user-space.

Unlike the previous implementations, Kernel-AODV, developed by the

US National Institute of Standards and Technology, uses Netfilter and

moves all the routing logic in kernel-space; therefore, no user-space daemon

is needed. Such an approach improves the performance in terms of packet

handling, because no packets are required to traverse from kernel to user-

space. This implementation is also known to support multiple interfaces

and has basic multicast capabilities.

A Java implementation of the AODV protocol, called JAdhoc, is pro-

vided by the ComNets Department of the University of Bremen. It uses the

Java packet capture library to monitor the interfaces in user-space. Cur-

rent code is known to work in GNU/Linux, Zaurus and Windows. Security

extensions have been added in a recent release.

3.3.2 Dynamic Source Routing (DSR)

A kernel level implementation of the DSR protocol is provided by Rice

University with Monarch project. Routing logic is implemented through

extensive modifications of the IP stack. At the time of this writing, the

project is in a pre-alpha release and is made available for the information

and use of other network researchers.

DSR-UU, developed by the Uppsala University, provides a DSR imple-

mentation for both GNU/Linux and the ns-2 network simulator. DSR-UU

implements a virtual network interface that enables the DSR network to

coexist with the regular single-hop ad hoc network at the same time. DSR-

UU supports multiple routing cache implementations, where the routing

cache is loaded as a separate module in Linux, so that different implemen-

tations of a routing cache can be tested without recompilation. DSR-UU

implements a link cache that supports multiple routing metrics. However,

at the time of this writing, only minimum-hop-count routing is used.

The MIT Roofnet and the Microsoft MCL (both discussed in Sec. 3.4)

3.4. Layer 2.5 Solutions 29

utilize a DSR-like protocol optimized to take link-quality into considera-

tion. The Microsoft implementation also supports multi-radio interfaces.

3.3.3 Hazy Sighted Link State (HSLS)

HSLS has been implemented by the Champaign-Urbana Community Wire-

less Network (CUWiN) for the NetBSD platform. The CUWiN foundation

aims at fostering the development of community-owned networks exploit-

ing open-source technologies. In order to enhance the portability to other

operating systems, the routing logic has been implemented as a daemon

running in the user-space. ETX is used as routing metric.

3.3.4 Optimized Link State Routing (OLSR)

A cross platform implementation of the OLSR protocol supporting GNU/Linux,

MacOS and the various children of BSD is provided by the University of

Oslo as a part of the OLSR daemon (Olsrd) project. Olsrd supports a plug-

in interface based on dynamically linked libraries (DLLs) for extending the

OLSR functionality.

QOLSR is a QoS extension introduced to the OLSR protocol by LRI

Laboratory at the University of Paris. Link state information generated

by MPRs are exploited in order to provide optimal paths based on the

applications’ QoS requirements. QOLSR does not require any change to

the format of IP packets, thus any existing IP stack can be used and the

protocol only interacts with kernel routing table management. QOLSR

is written in the C++ programming language and its goal is to achieve

modularity, efficiency and conformance to the standard [23].

3.4 Layer 2.5 Solutions

This section reviews the software platforms implementing a WMN with

routing performed at layer 2.5.


3.4.1 Roofnet

Roofnet is an experimental IEEE 802.11b-based WMN consisting of about

50 nodes located in Cambridge, Massachusetts, installed and operated by

the Massachusetts Institute of Technology. The network participants are

volunteers who accept hosting in their apartments the equipments required

to implement a mesh node. Each node is equipped with a single 802.11b

wireless card. Roofnet routes packets using SrcRR [1], a protocol inspired

by DSR. The original protocol has been modified extensively, mainly for

supporting additional link-quality metrics. SrRR uses ETT as routing

metric [14].

3.4.2 MCL

The Mesh Connectivity Layer (MCL) is a loadable Microsoft Windows

driver, which implements an interposition layer between the link layer and

network layer of the standard ISO/OSI model. MCL routes packets using a

modified version of DSR called Link Quality Source Routing (LQSR) [14].

It uses WCETT to choose the best route between any pair of nodes [8].

An indoor testbed based on the MCL software is introduced in [14].

3.5 Multi-channels solutions

Besides enhancing existing MAC protocols or proposing new medium ac-

cess scheme, scalability issues in WMNs can be addressed by allowing each

node to exploits multiple channel for transmitting data. Such an approach

has already been exploited by several testbed designs. As for example,

the Hyacinth [24] project aims at developing a joint channel assignment

and routing strategy for multi-radio WMNs. Each node participating the

network is equipped with two IEEE 802.11 radios. Performance studies

carried out using both simulations as well as a system prototype shows

that even with just 2 radios on each node, it is possible to improve the net-

work throughput by a factor of 6 to 7 when compared with a conventional

3.5. Multi-channels solutions 31

single-channel architecture. Similarly, the Heraklion [25] project aims at

investigating the performances and the management issues of a multi-radio

WMN in an actual metropolitan deployment. The testbed is built using

off-the-shelf components and covers an area of approximately 60 Km2 in

the city of Heraklion, Crete. This section discusses alternatives design

choices for multi-channels WMNs based on the IEEE 802.11 MAC.

3.5.1 Single-radio MAC

In a single radio scenario, only a channel at time can be used for trans-

mitting. In fact, current IEEE 802.11 devices are equipped with a single

half-duplex transceiver. Such transceiver is capable of switching channels

dynamically, but it can only transmit or listen on one channel at a time.

Thus, when a host is listening on a particular channel, it cannot hear

communication taking place on a different channel. In [26] a novel MAC

protocol for multi-hop networks is proposed. This protocol exploit multiple

channels dynamically in order to improve performance. The proposed ap-

proach enables hosts to utilize multiple channels by switching channels dy-

namically. The protocol requires only one transceiver per host, but solves

the multi-channel hidden terminal problem using temporal synchroniza-

tion. Simulations show that the protocol achieve higher throughput than

IEEE 802.11. In [27] a distributed MAC protocol exploiting frequency di-

versity is presented. This protocol, called Slotted Seeded Channel Hopping

(SSCH), is a virtual MAC protocol operating on top of the standard IEEE

802.11 MAC and using a single transceiver. Channel hopping is handled

by the SSCH layer which defines the hopping schedule and then transmits

it to the neighboring nodes.

3.5.2 Multi-radio MAC

In a multi-radio scenarios a network node has multiple radios each with its

own MAC and physical layer. Since communications in these radios are

totally independent, an additional layer coordinating the different radios


is needed. In [28] a new MAC layer protocol, called the Multi-radio Uni-

fication Protocol (MUP) is proposed. This protocol coordinates multiple

IEEE 802.11 radios operating over multiple channels with the objective of

exploiting the available spectrum more efficiently.

3.6 Final considerations and remarks

As a promising technology for ubiquitous wireless network access, WMNs

are required to support a wide range of benchmarks and application scenar-

ios. Being a testbed, the ideal play-field to develop and validate innovative

solutions, its design should be driven by both research trends and require-

ments imposed by the applications scenarios. This section complements

the previously discussed issues by analyzing the most relevant trade-offs

involved in WMN research testbeds. Table 3.1 summarizes the trade-offs to

be considered by both academia and industries in building a WMN testbed.

However, it is worth remembering that, none of the following issues should

be considered “closed”, and instead, open topics for further investigation.

3.6.1 Hardware platform

A testbed designer need to consider issues ranging from node deployment,

to the selection of a suitable software framework for an efficient and useful

testbed operation. Section 3.2 surveyed the most relevant platforms for

WMN development. However, additional study is required for more proper

choice of both wireless interfaces and antennas.

Wireless Interfaces

Different IEEE 802.11 chipsets are available on the market. While, for in-

door deployments, NICs characterized by a low transmission power should

be the preferred ones in order to minimize the interference, outdoor de-

ployments require higher transmit power and receiver sensitivity. Com-

mon IEEE 802.11 NICs are characterized by an output power of 30mW

3.6. Final considerations and remarks 33

Industrial testbed Academic Testbed

Target Prototype/Final product Proof-of-concept

Software framework Focus on code maturity

and stability (e.g., OLSRD,

AODV-UCSB, AODV-UU).

Kernel-space implementation

(e.g., Kernel AODV) preferred

when performances are a major

requirement.

Focus on easy development and

software flexibility. User-space

implementation preferred due

to their shorter development

cycle (e.g., OLSRD, AODV-

UCSB, AODV-UU). Single

platform solutions (e.g., MCL)

should be avoided if code

portability is a major concern.

Hardware platform Focus on ease of deployment

and management features. Em-

bedded platforms (e.g., Soekris,

RouterBoard) provide better

price/performance ratio.

Focus on ease of development

and hardware accessibility. x86

platforms provide a flexible yet

cost effective solution.

License Permissive licenses (e.g., BSD,

MIT) preferred in order to facil-

itate commercial exploitation.

Both permissive and copyleft

(e.g., GPL) licenses are suit-

able. The latter facilitate

building communities working

on the same platform.

Table 3.1: Design Trade-offs for a WMN testbed.

(15dBm), while Access Point (AP) can reach 100mW (20dBm). By oper-

ating in the ISM bands, the WMNs based on the IEEE 802.11 technology

can exploit frequency bands located around 2.4 and 5 GHz. However, each

range has different characteristics. While the lower frequencies typically

exhibit better range, the higher frequencies have shorter range and are sub-

ject to greater attenuation from solid objects, but usually present a lower

level of background noise.

Wireless NICs that allow to control low level (physical) parameters

should be preferred. As an example, NICs based on the Prism 2.5 chipset

allow to control parameters such as bit rate, carrier sense thresholds and

provide transmission feedback for unicast frames which are not successfully


delivered. Atheros-based NICs provide IEEE 802.11a/g OFDM modes and

expose raw 802.11 frames to the driver, allowing to control most of the

node’s functionality at the application level; for example, it is possible to

get per-packet signal and noise readings and to send broadcast frames at

arbitrary rates. Such features are exploited, for example, in Roofnet in

order to estimate the forward and reverse link delivery ratios required to

compute the ETX metric. It is worth noting that most bundled solution

(e.g., the Intel Centrino platform) usually does not support such advanced

features. An extensive comparison of open source drivers and supported

chip-sets is available at [29].

Antennas

In order to maximize the overall performance of a WMN, a careful selec-

tion of antennas and node placement is needed. Omnidirectional antennas,

like dipoles, are used when coverage in all directions is required. On the

other hand, directional antennas focus more energy in one direction and

expend less energy in all other directions. As the gain of a directional

antenna increases, the angle of radiation usually decreases, providing a

greater communication distance, but with a reduced coverage angle. Di-

rectional antennas can increase the network throughput by both reducing

the exposed terminal problem and by enabling sectoral coverage. However,

they raise considerable challenges at the MAC layer such as more hidden

nodes. Routing protocols also need to take into account the selection of

directional antenna sectors.

3.6.2 Routing framework

The most relevant implementations of routing protocols for WMNs are

summarized in Table 3.2. The implementation of multi-hopping requires

considerable modifications to the networking stack, often involving kernel-

space programming. Moving the networking stack into user-space libraries

offers considerable advantages over kernel-space development in terms of

3.6. Final considerations and remarks 35

both faster development cycle and easier debugging at the expense of per-

formance reduction.

Due to such considerations, many academic research testbeds exploit

routing protocol implementations running in the user-space. A hybrid ap-

proach is the the Click modular router [30] on which the MIT Roofnet

testbed is based. A Click router is built by assembling several packet pro-

cessing modules, called elements, forming a directed graph. Each element

is in charge of a specific function such as packet classification, queuing, and

interfacing with networking devices. Click comes with an extensive library

of elements supporting various types of packet manipulations. Such a li-

brary enables easy router configuration by simply choosing the elements

used and the connections among them. Finally, a router configuration can

be easily extended by writing new elements. The Click modular router

is available as both Linux Kernel Module and user-space driver, allowing

straightforward porting of an user-space implementation to kernel-space.

3.6.3 Routing protocols

Section 2.3 classified the routing protocols for WMNs as either proactive or

reactive, with proactive routing maintaining a list of all destinations and

routes and reactive routing finding routes on-demand when a packet needs

to be forwarded. Such a behavior makes proactive routing less suitable for

WMNs or in general for networks characterized by low churn rates2.

Proactive routing protocols (e.g., OLSR) aim at computing routes be-

tween any pair of nodes participating the networking3. On the other hand,

many reference scenarios for WMNs (e.g., access network) are character-

ized by a low percentage of intra-mesh traffic and a high percentage of

outgoing traffic.

As a result, on-demand route discovery protocols can result in much

less traffic than the standard proactive approach, especially when innova-

2Number of nodes that leave the network during a specified time period divided by the average total

number of nodes over that same time period.3Albeit in OLSR only nodes selected as MPRs are responsible for forwarding control traffic.


tive route maintenance schemes are employed. However, the reliance on

flooding that characterizes reactive protocols may still lead to consider-

ably high control traffic in mobile networking environments. Moreover,

the route discovery process may be subject to significant delays due to the

large volume of control traffic generated.

3.6.4 Protocol Architecture

Routing can be either provided at level three of the ISO/OSI networking

stack as modification of the standard IP protocol or by adding an interposi-

tion layer between the Data Link Layer and the Network layer. In the latter

solution (usually referred to as Layer 2.5 routing), the multi-hop backhaul

is transparent to the upper networking stack, making the WMN appears

just as another Ethernet link. On the other hand, such an approach in-

troduces additional encapsulation and processing overhead as a result of,

respectively, the header and checksum required by the interposition level.

This implies a slight degradation in overall performance, in terms of both

throughput and latency. Cross-layer design can also be considered as an

interesting research direction in the design of WMNs.

3.6.5 Licensing

No currently available routing framework may be considered as the final

answer to deploy a WMN testbed. A license which makes available the

source code under terms that allows modification and redistribution, may

therefore speed up the research activity. In this scenario permissive li-

censes (e.g., BSD and MIT) have fewer restrictions compared to other free

software licenses, such as the GNU GPL, which require the copies and

derivatives of the source code to be made available on the same terms of

the original code. While for an academic research testbed, this may not be

a major problem, for an industrial testbed, a routing framework released

under a permissive license may be preferable in that it allows a higher

degree of freedom in the distribution of the final product [31].

Nam

eP

roto

col

Pla

tform

Imple

menta

tion

Routi

ng

AO

DV

-UC

SB

AO

DV

GN

U/L

inux

Ker

nel

module

w/

L3

use

r-sp

ace

routi

ng

logi

c

AO

DV

-UIU

CA

OD

VG

NU

/Lin

ux

Use

r-sp

ace

L3

AO

DV

-UU

AO

DV

GN

U/L

inux

Ker

nel

module

w/

L3

N/A

use

r-sp

ace

routi

ng

logi

c

CU

WiN

HSLS

Net

BSD

Ker

nel

-spac

eL3

DSR

-UU

DSR

GN

U/L

inux

Use

r-sp

ace

L3

JA

dhoc

AO

DV

GN

U/L

inux,W

indow

s,U

ser-

spac

eL3

Zau

rus

Use

r-sp

ace

L3

Ker

nel

-AO

DV

AO

DV

GN

U/L

inux

Ker

nel

-spac

eL3

MC

LLQ

SR

(DSR

-lik

e)W

indow

sLoa

dab

lew

indow

sdri

ver

L2.

5

Mon

arch

Pro

ject

DSR

Fre

eBSD

Ker

nel

-spac

eL3

OLSR

DO

LSR

GN

U/L

inux,W

indow

s,U

ser-

spac

eL3

Mac

OS

X,*B

SD

Use

r-sp

ace

L3

QO

LSR

OLSR

GN

U/L

inux

Use

r-sp

ace

L3

Roof

net

Src

RR

(DSR

-lik

e)G

NU

/Lin

ux,*B

SD

Use

r-sp

ace

L2.

5

Tab

le3.

2:C

ompar

ison

bet

wee

nro

uti

ng

pla

tfor

ms

for

WM

Ns.

All truths are easy to understand

once they are discovered; the point is

to discover them.

Galileo Galilei

Chapter 4

Adaptive traffic aggregation

4.1 Introduction

WMNs exploit multi-hopping in order to wirelessy interconnect multi-

ple communication nodes, possibly using different technologies/interfaces.

WMNs share several features with the traditional ad hoc paradigm (namely

the self-organizing, self-healing capabilities), even though research on WMNs

shifted the focus from the support of mobility to network scalability issues.

In fact, since WMNs are decentralized, at present, they fit badly the re-

quirements of multimedia applications with respect to the required packet

loss and transmission delays [1, 32]. In turn, this translates into a strong

limitation in the maximum number of hops that WMNs can support [33].

This chapter proposes a novel packet aggregation technique which in-

creases the scalability of IEEE 802.11-based WMNs. Such an aggregation

is performed on top of the MAC layer, allowing us to reduce the overhead

due to both protocol headers and the contention mechanism regulating the

IEEE 802.11 standard. The novelty of the proposed approach lies on the

adaptive aggregation scheme that leverages the channel probing function-

alities of mesh routers: such information are exploited in order to compute

the optimal saturation burst length. A linear scaling is then applied in

order to re-modulate the burst length to the unsaturated operation point.

The proposed scheme is tested over an IEEE 802.11-based WMN testbed

in the specific case of VoIP traffic, and showed a very large gain in the

39

40 Chapter 4. Adaptive traffic aggregation

voice capacity attained, even in presence of background traffic.

The chapter is organized as follows. Section 4.2 is dedicated to related

work. The system architecture is sketched in Sec. 4.3. Section 4.4, asses

the impact of both encapsulation and contention overhead on network per-

formances. In Sec. 4.5 the analytical model matching link layer param-

eters with traffic aggregation is introduces and a closed formula allowing

run-time computation of the optimal burst length is derived. Section 4.6

introduces the testbed setup e describes the evaluation methodology. The

outcomes of the measurement campaign are reported in Sec. 4.7. Finally,

Sec. 4.8 concludes the paper pointing out directions for future research.

4.2 Related work

The literature on the capacity of multi-hop wireless networks is extensive.

In [34] the authors show how network scalability is preserved in static ad

hoc networks only when the average distance between source and desti-

nation remains small as the network grows. Vice-versa non-local traffic

severely impair per-node network capacity. Several techniques have been

developed in order to boost network performances. In [28] multiple radio

are exploited, while in [3, 14] novel routing metrics capable of selecting

the best route are introduced. This thesis addresses the above mentioned

issues in IEEE 802.11-based WMNs by proposing a novel adaptive traffic

aggregation scheme capable of reducing MAC service time by compounding

several frame into a single burst.

There exist a vast literature on the modeling and analysis of the IEEE

802.11 CSMA/CA protocol. The fundamental model, i.e. the Bianchi

model, is presented in [35]; there, a two-dimensional Markov chain is

exploited in order to model the exponential back-off algorithm of the

IEEE 802.11 Distributed Coordination Function (DCF) under saturation

assumption. Among several works elaborating on the initial model, such

analysis is extended to error-prone channels in [36]. There, the authors

conclude that, for any given bit error rate, an optimal packet size exists

4.2. Related work 41

that maximize the goodput.

Related works on VoIP over WLANs [37, 38, 39] and UWB networks [40]

proposed the introduction of a packet aggregation scheme. The technique

trades off service time for packet length: the increase of CSMA/CA service

time is mitigated by assembling multiple upper layer packets into a single

MAC burst. Performance measures proved that the proposed MAC can sig-

nificantly improve both throughput and delay performance in CSMA/CA

based networks. In [32] the authors propose several performance optimiza-

tions aimed at improving the VoIP support in WMNs. Voice packet aggre-

gation and header compression are then exploited to improve the network

capacity in terms of number of voice calls supported. Extensive simulation

and experiments run over a real testbed are used in order to validate the

proposed approach.

In [41] an analytical model is developed in order to study the impact

of packet aggregation on delay. Results show that packet aggregation can

significantly improve the performance of the CSMA/CA protocol. Such

a result is exploited by the authors in order to provide a novel packet

aggregation policy capable of optimizing both the network throughput and

delay.

This thesis extends both [35] and [40, 41] by introducing a novel adaptive

traffic aggregation policy capable of matching the parameters available

in a real-world WMNs, namely link status and channel utilization ratio,

with the requirements of an adaptive packet aggregation scheme. A closed

formula allowing run-time computation of the optimal burst length based

on measurable routing metrics and the number of stations in radio range is

also proposed. The proposed technique does not require any modification

to the IEEE 802.11 MAC and can be readily implemented over existing

hardware. Finally, the performances of our scheme are evaluated by means

of a testbed deployed at UFL premises.


Figure 4.1: Aggregated MSDU (A-MSDU) frame format.

4.3 Architectural Overview

Our aggregation scheme concatenates several MAC Service Data Units

(MSDUs) to form the data payload of a large MAC Protocol Data Unit

(MPDU). The PHY header and the MAC header together with the Frame

Check Sequence (FCS) are then appended in order to build the Physical

Service Data Unit (PSDU). The frame format for an Aggregated MSDU

(A-MSDU) is sketched in Fig. 4.1.

The building blocks of the Aggregation Buffer and their relationships are

sketched in Fig. 4.2. Incoming MAC frames are first classified according

to their destination address and then fed to a different queue. Each Aggre-

gation Buffer maintains a pool of unused queues and an hash table that

associates the MAC destination addresses with the corresponding queue.

Unused queues are moved from the hash table to the pool, this is done in

order to alleviate the need for repeated memory allocation as neighbors

come and go. For each queue, an A-MSDU is generated when either an

aggregation timer is expired or a burst of optimal length can be generated.

4.4. Motivation 43

Figure 4.2: Block diagram for the packet aggregator.

4.4 Motivation

The overhead associated with IP packets transmitted over an IEEE 802.11

is due both to both the additional headers and to the exponential back-

off algorithm required by the contention procedure defined in the stan-

dard [22]. Both types of overhead are particularly relevant in the case of

small sized packets, such those used in VoIP. This section describes the

impact of such effects on the network performance.

4.4.1 Encapsulation overhead

The IEEE 802.11 standard [22] currently defines six modulation techniques,

with data rate ranging from 1 to 54 Mbps, while the upcoming IEEE

802.11n amendment introduces an advanced physical layer based on MIMO

techniques that is supposed to deliver data rates up to 540 Mbps. In order

to allow the IEEE 802.11 MAC to operate with minimum dependence on

the physical sublayer, the Physical Layer Convergence Procedure (PLCP)

is introduced (see Fig. 4.3). The PLCP maps MAC sublayer Protocol Data

Units (MPDU) into a framing format suitable for the Physical Medium

Dependent (PMD) layer. The PLCP protocol data unit (PPDU) is unique


Figure 4.3: IEEE 802.11 Protocol Stack.

Figure 4.4: IEEE 802.11 PPDU Format.

to the specific PHY layer. The PPDU (See Fig. 4.4) frame consists of a

PLCP preamble, PLCP header, and MAC protocol data unit (MPDU).

The PLCP preamble and PLCP header are always transmitted at 1 Mbps,

while the MPDU can be sent at higher rates.

Additional overhead is introduced by the MAC and the LLC/SNAP

headers. The Subnetwork Access Protocol (SNAP) is an extension to the

IEEE 802.2 LLC. It provides a mechanism for multiplexing different pro-

tocols exploiting the 8-bit 802.2 Service Access Point (SAP) fields. SNAP

identifies protocols using EtherType1 field values; it also supports vendor-

private protocol identifier spaces. SNAP is used for example with IEEE

802.3, IEEE 802.5, IEEE 802.11 and other IEEE 802 networks, as well as

with non-IEEE 802 technologies such as FDDI that use the 802.2 LLC.

SNAP headers are introduced since the IEEE 802.11 MAC header does

1The EtherType is a field used in the Ethernet frame to indicate which protocol is being transported,

e.g. value 0x800 is associated with the IPv4 protocol.

4.4. Motivation 45

Figure 4.5: IEEE 802.11 Frame Format.

not has an EtherType field to indicate which protocol is being trans-

ported. The frame structure for a SNAP-encapsulated IEEE 802.11 frame

is sketched in Fig. 4.5. Furthermore, SNAP circumvents the limited ad-

dress space provided by IEEE 802.2 LLC. In fact, in the LLC frame, layers

using the data link service, usually the network layer protocols, are dis-

tinguished by the 8-bit 802.2 Service Access Point (SAP) fields. However,

since the first two bits of each SAP field are reserved, there is room for

only 64 globally assigned SAP numbers. SNAP allows EtherType values

to be used to specify the protocol being transported atop of IEEE 802.2. A

packet with an LLC header with both Source and Destination SAP set to

0xAA and the control field set to 03 (Unnumbered Information PDUs) is a

SNAP packet. The SNAP header follows the 802.2 header; it has a 5-octet

protocol identification field, consisting of a 3-octet IEEE Organizationally

Unique Identifier (OUI) followed by a 2-octet protocol ID. If the OUI is

0x000000, the protocol ID is the EtherType.

Finally, it is worth pointing that some IEEE 802.11 NICs transform

802.11 data packets into fake Ethernet packets before supplying them to

the host, and, even if they don’t, the drivers for the adapters often do so

before supplying the packets to the operating system’s networking stack

and packet capture mechanism. Figure 4.6 shows how Ethernet frames are

SNAP-encapsulated in IEEE 802.11 frames.

4.4.2 Contention overhead

In the IEEE 802.11 protocol the mechanism used to access the wireless

medium is called Distributed Coordination Function (DCF). According

to the DCF scheme, a station that wants to transmit a packet monitors


Figu

re4.6:

Eth

ernet

frame

SN

AP

-encap

sulated

inIE

EE

802.11fram

e

4.4. Motivation 47

Figure 4.7: IEEE 802.11 access scheme based on the DCF.

the channel until an idle period equal to the Distributed Inter-Frame Space

(DIFS) is detected. Then, the station generates a random back-off counter.

The back-off counter is decremented as long as the channel is idle, frozen

when a transmission is detected, and reactivated when the channel is sensed

free for a DIFS interval. The station transmits when the back-off counter

time reaches zero. Initially, the back-off timer is drawn uniformly in the

back-off window [0, CWmin]: at each retransmission (due to collisions or

errors), the back-off window is doubled until it reaches the maximal size

2mCWmin. Thus, due to the back-off procedure, the concurrent transmis-

sion of alien stations affects the service time of IEEE802.11: the higher the

number of transmitting stations, the larger the overhead [37]. It is worth

remembering that half-duplex IEEE 802.11 stations cannot hear their own

transmission. An acknowledgment (ACK) is then transmitted by the des-

tination station to the source station if a packet transmission is successful.

An ACK is always transmitted after a Short Inter-Frame Space (SIFS).

If the transmitting station does not receive the ACK within an Extended

Inter-Frame Space (EIFS) it reschedules the transmission like if a collision

occurred. The whole process is sketched in Fig. 4.7. The DCF scheme

can be optionally enforced by a four-way handshaking technique, i.e. the

Request-to-Send/Clear-to-Send (RTS/CTS) handshake. The RTS/CTS

scheme, being optional, is not implemented in most commercial cards, and

what follows will then focus on the basic access scheme only.


4.5 Aggregation in Error-prone Channels

Aggregating multiple frames into a single burst at the MAC level allows to

both reduce encapsulation and backoff overhead and increase the system

throughput. The last claim is supported by the analytical model introduced

in [35]. The author provides an accurate estimation of the IEEE 802.11

saturation throughput for both the basic and the RTS/CTS access scheme

for an error-free channel. However, channel conditions in WMNs are not

ideal and packets are lost due to both collisions and transmission errors.

As result, we decided to exploits the ETX metric as a cross-layer technique

able to match link layer parameters with our adaptive traffic aggregation

policy.

As described in Sec. 2.4, ETX estimates the average number of retrans-

missions needed by each node to successfully deliver a packet over a given

link. In order to compute the metric, each node periodically broadcast

probes at different data rates. Each probe contains the overall number of

probes received from each of the neighbors during a specific observation

window. Each station then computes the loss rate over a specific link (the

IEEE 802.11 MAC does not retransmit the broadcast packets). Consider-

ing that a successful unicast transmission in IEEE 802.11 requires sending

the data packet and receiving the corresponding ACK, the ETX metric

between nodes A and B, can be computed as

ETX =1

dfwddrev

=1

PUni

, (4.1)

where dfwd and drev are, respectively, the forward and the reverse delivery

ratio of the link and PUni is the overall probability of a successful unicast

transmission. Being Pe the Frame Error Rate (FER) and p the collision

probability, it follows

PUni = (1 − p)(1 − Pe). (4.2)

Assuming also that errors after decoding are i.i.d. over the frame bits, and

4.5. Aggregation in Error-prone Channels 49

being Pb the Bit Error Rate (BER), is stands:

Pe = 1 − (1 − Pb)L. (4.3)

By combining (4.1), (4.2) and (4.3), we obtain

Pb = 1 − e−log[ETX(1−p)]

LProbe , (4.4)

where LProbe is the length of the probe packet used for computing ETX. The

network throughput computed according to the Bianchi’s model presented

in [35] can then be extended to account for error prone channels

S =Ps(1 − Pe)E[P ]

σPi + PsPeTe + Ps(1 − Pe)Ts + (1 − Pc)Tc

=Ps(1 − Pe)E[P ]

σPi + PsTs + PcTc

=ABLL

C + DL, (4.5)

where for the ease of reading we put

A =Ps

R, B = 1 − Pb, (4.6)

C = σPi + PsTs0+ PcTc0

, D =Ps + Pc

R. (4.7)

Also, we denoted

Ts0= H + SIFS + δ + ACK + DIFS + δ (4.8)

Tc0= H + DIFS + δ (4.9)

Ts = Ts0+ E[P ], Tc = Tc0

+ E[P ∗], (4.10)

being and Te the time the channel is sensed busy for a failed transmission

due to a channel error. Notice that in (4.5) we assumed that Ts = Te, which

is due to the particular timeout settings in IEEE 802.11, namely the EIFS.

Figure 4.8 plots the system saturation throughput versus an increasing

length of the payload for different values of the routing metric ETX. As we

can see, the argument that is the basis for the packet aggregation technique

described in the following is that if we increase the payload length, we


0 500 1000 15000

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Payload length [bytes]

Sat

urat

ion

thro

ughp

ut

Pb=0Pb=6E−5Pb=2E−4

Figure 4.8: IEEE 802.11 Saturation throughput versus an increasing length of the payload

for different BERs.

decrease system overhead. But, there exist a trade off, since frame errors

become more likely with the packet length, i.e., the number of aggregated

packets. Assuming as a first approximation constant length packets, the

saturated optimal packet length LOpt writes as

LSat = −C

2D

1 −

√

√

√

√1 +4DLProbe

C log ETX(1 − p)

. (4.11)

4.5.1 Runtime measurements and adaptation

Our aggregation scheme exploits the monitor mode provided by the Atheros-

based WiFi interfaces building our testbed. Madwifi [42] is used as device

driver. The monitor mode, or RFMON mode, allows a computer with

a wireless NIC to monitor all traffic received from the wireless network,

which gives us a good estimation of the channel load since it considers also

traffic from other WiFi sources not participating the WMN. The monitor

mode is similar to the promiscuous mode used for packet sniffing in wired

4.5. Aggregation in Error-prone Channels 51

networks.

A typical drawback of a packet aggregation scheme is that it increases

the processing delay at each node and becomes less suitable for delay sen-

sitive applications (e.g. VoIP). Moreover, (4.11) was derived under satura-

tion conditions, as a result the computed optimal burst size will affect the

transmission delays if the offered traffic is low. In [41] an additional param-

eter representing the channel utilization ratio is used in order to module

the burst length. According to the authors the channel is considered as

busy when either a node is sending a frame or the network allocation vec-

tor indicates that the channel is reserved. However, using off-the-shelf

IEEE 802.11 interfaces, the packet aggregation scheme implemented in our

testbed cannot extract such information from the MAC layer. We have

then decided to indirectly estimate the channel occupation exploiting the

monitor mode provided by the Atheros-based WiFi interfaces building our

testbed. The monitored parameters are:

• Exponential moving average of both packet rate (R) and per-packet

airtime (A), A is computed as the product of packet length (bits) and

transmission rate (Mbps) plus PLCP headers duration;

• Number of active neighbors N in the last n seconds. This parameter

is used in order to compute both the p and τ values that appear in

the Bianchi’s model [35], and the C, and D parameters used in (4.11).

In order to speed-up computation, a look-up table is used. Numerical

values are pre-computed for 1 ≤ N ≤ 30.

An estimate of the channel load (µ) is produced every n seconds, as the

ratio between the air time and the time between two successive transmis-

sions over the channel

µ =A

(1/R)= AR. (4.12)

Using (4.11), we then approximate the optimal burst length as follows:

LOpt = min [µf(ETX), BMax] , (4.13)


1 1.05 1.1 1.15 1.2 1.25 1.3 1.35 1.4

400

600

800

1000

1200

1400

1600

Average number of retransmissions

Opt

imal

fram

e le

ngth

Figure 4.9: Optimal burst length versus increasing values of the ETX metric.

where BMax is the Maximum Transmission Unit (MTU) supported by the

local area network technology. This parameter has been set to 1500 bytes

which is the MTU supported by an Ethernet LAN. Based on (4.13), and

estimating the parameters described before, a node will then be able to

update LOpt according to the link conditions. Figure 4.9 plots the optimal

burst length versus increasing values of the ETX metric

4.5.2 Hop-by-hop packet aggregation

According with our architecture, packets aggregation and de-aggregation

is performed at each hop. Albeit such an approach could lead to increasing

delays as the number of hops increases, we postulate that, at intermediate

nodes, medium access delay is sufficient to collect enough packets so that

burst generation is triggered by the optimal frame length without incur-

ring in any aggregation delay. The pseudo code for the hop-by-hop burst

generation process is given in Alg. 1.

4.6. Evaluation Methodology 53

Algorithm 1 Hop-by-hop burst generation process.

1: if size(queue) ≥ LOpt then

2: if size(queue) ≤ BMax then

3: generate a burst no longer than LOpt bytes

4: else

5: generate a burst no longer than BMax bytes

6: end if

7: else if Aggregation timer is expired then

8: aggregate all the packets in the queue

9: end if

4.6 Evaluation Methodology

4.6.1 Testbed configuration

The testbed exploited during our experimentation consists of 4 wireless

mesh routers deployed in a typical office environment implementing a

flat WMN suitable to be exploited as backhaul in dual-tier architectures.

Testbed’s nodes are all Fujitsu notebooks model P7010D equipped with a

1.20 GHz Intel Pentium M processor and 512 MB of memory. All nodes run

Debian GNU/Linux with kernel 2.6 and are equipped with a single IEEE

802.11b/g wireless NIC. Each node participating the WMN is co-located

with an interfering node consisting in a Linksys WRT54G wireless router.

All measurement are run with the IEEE 802.11 interfaces operating in “b”

mode with RTS/CTS disabled.

Our testbed is implemented on top of Roofnet [1], an experimental IEEE

802.11-based WMN deployed at Cambridge, Massachusetts (USA) by the

Massachusetts Institute of Technology (MIT). Roofnet routes packets using

a modified version of DSR [11] called SrcRR [1] exploiting ETT [3] as rout-

ing metric. Routing is implemented using the Click modular router [30],

developed at MIT. Interfering nodes exploits statically configured IP routes

in order to build network connectivity.

A Click router is built by assembling several packet processing modules,

called elements, forming a directed graph. Each element is in charge of a


specific function such as packet classification, queuing, or interfacing with

networking devices. Click comes with an extensive library of elements sup-

porting various types of packet manipulations. Such a library enables easy

router configuration by simply choosing the elements to be used and the

connections among them. We extended the default Roofnet configuration

by implementing the additional elements responsible for packet aggregation

and de-aggregation.

4.6.2 Traffic Generation

VoIP flows were generated using Jugi’s Traffic Generator (JTG), a freely

available synthetic traffic generator [43]. Beside being able of generating

and injecting different traffic patterns over TCP and/or UDP sockets, JTG

can read the information about packet transmission intervals and sizes from

files, allowing us to create an exact duplicate of a trace starting from a pre-

recorder stream. Traffic is then collected at the receiver side where suitable

tools are available for analysis.

In our settings, each mesh node sustains the same traffic, consisting in

an increasing number of VoIP sessions. Being very demanding in terms

of loss and delay constraints, VoIP services are traditionally an interest-

ing benchmark case, especially when dealing with mesh structures, where

multihop communication could introduce unpredictable delays. A typical

VoIP source in fact tends to transmit a large number of packets with a

small payload, and such a combination is known to lead to large protocol

overheads [32].

We have emulated each VoIP call with a single UDP stream modeled

according to the parameters of the G.729.3 codec [44], a worldwide used

speech codec for VoIP applications. Table 5.4 summarizes the key features

of the G.729.3 VoIP codec being tested in our experiments. Background

traffic, generated by the interfering nodes is modeled according to a TCP

socket working in saturation regime. The tests, whose results are reported

in the next section, refer to downlink traffic only.


Codec Packet Interval Bitrate Payload

G.729.3 30 ms 8 Kbps 30 bytes

Table 4.1: Key features of the G.729.3 codec

Figure 4.10: Traffic flows used during the performance measurements campaign. VoIP

bundles and TCP flows are represented respectively by solid and dashed lines.

In order to collect reliable measures of delays, before each experiment we

synchronized each node with a common reference (Node 1 ) using NTP [45].

All measurements were performed over 3 minutes intervals; results are

averaged over 10 runs. Traffic flows are sketched in Fig. 4.10 where VoIP

bundles and TCP flows are represented respectively by dashed and solid

lines.

4.6.3 E-Model

We resort to the E-Model [46, 46] as an objective method to evaluate speech

quality in VoIP systems. The outcome of an E-Model evaluation is called

R-factor (R). The R-factor is a numerical measure of voice quality, ranging

from 0 to 100, with 70 as lower bound for a VoIP call of acceptable quality.

In the E-Model several different parameters affecting the quality of a con-

versation are taken into account. The main assumption is that the various


impairments have an additive (dB-like) behavior at the psychological scale:

R = R0 − Is − Id − Ie + A (4.14)

where R0 is the basic signal-to-noise ratio (environmental and device noises),

Is accounts for the impairments on the coded voice signal (loud connec-

tion and quantization), Id represents the effect of delay, Ie the effect of low

bit rate codecs and A is the advantage factor, corresponding to the user

allowance due to the convenience in using a given technology. The main

advantage of the E-model is that, for a given codec, i.e. given Ie, only

delays and losses are needed for speech quality estimation. By choosing

the default values suggested by ITU-T [46], the R-factor equation can be

further simplified to

R = 94.2 − Id − Ief , (4.15)

where Id is the impairment factor caused by the end-to-end delay and Ief

is the equipment impairment factor:

Id = 0.024Ta + 0.11(Ta − 177.3)H(Ta − 177.3)

Ief = Ieopt+ C1 ln (1 + C2P ). (4.16)

where Ta and P are respectively the one-way delay in ms and the loss rate,

H(x) is the step function, and Ieopt, C1, C3 are codec-specific parameters.

Their values for G.729 codec under random packet losses are respectively

11, 40 and 10.

4.7 Performance Measurements

Our measurements campaign aimed at evaluating the number of concurrent

VoIP flows that can be sustained, i.e. the voice capacity of the system. Ac-

cording to ITU recommendations, we considered R = 70 as the minimum

required value of R for acceptable quality VoIP calls.

4.7. Performance Measurements 57

4.7.1 Channel aware traffic aggregation

Three different setups are considered. The first setup (Bulk) does not use

any aggregation policy and is used as benchmark. The second setup (Ag-

gregator) exploits our adaptive aggregation policy however channel load

information is not utilized (µ = 1). The third setup (AdjAggregator) ex-

ploits the channel load information in order to modulate the optimal burst

length according to (4.13). The aggregation timer-out has been set to 20

ms. No background traffic has been used during this set of measurements.

In the rest of this Section we will focus our attention on the 2-hops

route terminated at node number 3. We expect the mean packet delay

to be higher when our aggregation policy is applied without channel load

correction in particular for a low number of concurrent VoIP calls. This

is confirmed from the results plotted in Fig. 4.11, which reports on the

average delay vs. number of concurrent flows. Packet loss and R-Factor

are plotted respectively in Fig. 4.12 and in Fig. 4.13. Being n the number

of concurrent VoIP flows, we can roughly identify three zones:

1. n ≤ 8, the three setups show the same performances;

2. 8 < n < 32, the Bulk setup has reached its maximum number of

concurrent voice sessions, while the two aggregation schemes are still

able to sustain additional VoIP calls with the AdjAggregator showing

slightly worse performances in terms of both delay and packet loss;

3. n ≥ 32, both aggregation schemes have reached their maximum num-

ber of voice session.

Overall, both aggregation policies provides at least a factor 4 perfor-

mance increase, since the number of sustained sessions reaches 32, whereas

the plain IEEE 802.11 protocol allows for just 8 VoIP sessions. The AdjAg-

gregator trades low latency for small number of VoIP calls with a slightly

higher packet loss when the number of concurrent VoIP sessions increases.

We ascribe that behavior to a negative feedback involving our channel load


0 10 20 30 40 500

50

100

150

200

250

300

Number of concurrent flows

Ave

rage

del

ay (

ms)

BulkAggregatorAdjAggregator

Figure 4.11: Average delay Vs increasing number of concurrent flows.

driven packet aggregation policy, that finally leads to an oscillation in the

optimal frame size and, as a consequence, to an alternation between burst

of short packets and burst of long packets.

Finally, we have explored the impact of the aggregation timer on the

QoS figures. This scenario exploits a star-shaped network topology (see

Fig. 4.14) where all nodes are in radio range. Figure 4.15 reports on the

outcome of the measurements. As we can see, when the number of concur-

rent flows is lower than 13, the burst is triggered by the aggregation timer

thus lowering its value leads to better performances. On the other hand,

when the network load increases (more than 13 concurrent flows) the per-

formances do not depend on the timer’s value in that the burst is triggered

by the optimal burst length formula. It is worth noting that, for low values

of the aggregation timer (5ms, 10ms), the average delay remains constant.

This behavior is due to the fact that when the aggregation delay is small

compared to the packet inter-arrival time, the optimal burst size is never

reached within the window set by the aggregation time-out.


0 10 20 30 40 500

10

20

30

40

50

60


Pac

ket l

oss

(%)


Figure 4.12: Average packet loss Vs increasing number of concurrent flows.

0 10 20 30 40 500

10

20

30

40

50

60

70

80

90

100


R−

Fac

tor


Figure 4.13: Average R-factor Vs increasing number of concurrent flows.


Figure 4.14: Star-shaped network topology exploited in order to evaluate the impact of

the aggregation timer.

0 5 10 15 20 250

5

10

15

20

25

30

35

40


Ave

rage

del

ay (

ms)

20 ms10 ms5 ms

Figure 4.15: Delay Vs. number of concurrent flows for different values of aggregation

timer.

4.7.2 Impact of background traffic

The system’s performances were analyzed with and without background

traffic. We reported on the results for the scenario in Fig. 4.16, 4.17,

and 4.18. In this case, our adaptive aggregation policy provides almost

a factor 5 performance increase, since the number of sustained sessions

reaches 53, whereas the plain IEEE 802.11 protocol allows for just 11 VoIP

4.8. Conclusions 61

5 10 15 20 25 30 350

50

100

150

200

250

300

350

400


Ave

rage

del

ay (

ms)

w/o Aggregatorw/ Aggregator

Figure 4.16: Delay Vs. number of concurrent VoIP flows without background interference.

sessions. However, as we can see from Fig. 4.19, 4.20, and 4.21, when

background interference is present the relative performance boost provided

by our packet aggregation scheme is lower than the previous scenario, but

it is still providing a factor 3 benefit.

4.8 Conclusions

This chapter presented a novel scheme for traffic aggregation in WMNs,

where service time reduction at the MAC layer is possible if several pack-

ets are compounded into a unique burst frame. The scheme receives as

input some measurable link metrics, and each node can evaluate the opti-

mal burst length, based on a closed formula under the saturation approx-

imation. The entire measurements campaign was performed on a testbed

deployed at UFL premises. The software implementation of the proposed

mechanism has been released under an open-source license, with the aim

of providing the reference scientific community with a basis for developing


10 20 30 40 50 60 700

5

10

15

20

25

30

35

40

45

50


Pac

ket l

oss

(%)


Figure 4.17: Losses Vs. number of concurrent VoIP flows without background interference.

10 20 30 40 50 60 700

10

20

30

40

50

60

70

80

90

100


R−

Fac

tor


Figure 4.18: R-Factor Vs. number of concurrent VoIP flows without background interfer-

ence.

4.8. Conclusions 63

5 10 15 20 25 30 350

50

100

150

200

250

300

350

400


Ave

rage

del

ay (

ms)


Figure 4.19: Delay Vs. number of concurrent VoIP flows with background interference.

5 10 15 20 25 30 350

5

10

15

20

25

30

35

40

45

50


Pac

ket l

oss

(%)


Figure 4.20: Losses Vs. number of concurrent flows with background interference.

further innovative solutions for service differentiation in WMNs.


5 10 15 20 25 30 350

10

20

30

40

50

60

70

80

90

100


R−

Fac

tor


Figure 4.21: R-Factor Vs. number of concurrent flows with background interference.

Overall, the results show that the aggregation scheme proposed here

has a very large gain. With respect to the specific case of VoIP traffic,

in fact, we experienced a factor 5 increase in the number of simultaneous

VoIP flows. Among the various possible research directions to be pursued

to extend the current work, two appear more promising. The first one is to

perform measurements on larger topologies to obtain further insight in the

scalability properties of the solution proposed in this thesis. The second

one involves investigating the adaptive aggregation policy self-interference

generated by the channel load driven burst modulation.

When ideas fail, words come in very

handy.

Johann Wolfgang von Goethe

Chapter 5

A DiffServ architecture for Wireless

Mesh Networks

5.1 Introduction

The term QoS, in the field of telephony, was defined in the ITU standard

X.902 [47] as “A set of quality requirements on the collective behavior of

one or more objects”. In packet-switched networks this has been translated

into the definition of control mechanisms able to guarantee (either in a

deterministic or in a stochastic sense) a given level of performance to one

or multiple data flows, with regard to one or multiple metrics (i.e., delay,

jitter, packet drop rate, bandwidth).

As already stated in Sec. 1.1, deploying Internet-wide QoS solutions

proved to be a considerable endeavor making over-provisioning of network

resources a more appealing (and cheaper) option. Moreover, the current

bottleneck in terms of QoS support is represented by the last mile of the

Internet connection. Therefore, techniques able to provide QoS over access

networks are believed to represent a critical milestone to enhance the end-

users’ quality of experience.

However, even if this is considered a strategic goal to achieve, little

efforts have been dedicated so far to investigate efficient techniques for

supporting QoS in IEEE 802.11-based WMNs. It is worth noting that,

due to the contention-based nature of the IEEE 802.11 MAC protocol,

65

66 Chapter 5. A DiffServ architecture for Wireless Mesh Networks

adding more mesh routers in order to increase network capacity may prove

not to be a viable solution due to the increased interference.

This chapter describes an architecture for achieving service differentia-

tion and performance isolation (at layer 2.5) in IEEE 802.11-based WMNs

is proposed. It is not the candidate’s intention to provide strict QoS per-

formance bounds (which is still an open issue in IEEE 802.11 WLANs),

instead this section proposes a lightweight and backward compatible Diff-

Serv architecture that aims at enhancing the perceived quality of experi-

ence by combining traffic prioritization and packet aggregation in IEEE

802.11-based WMNs. It is worth stressing that the proposed technique

does not require any modification to the IEEE 802.11 MAC and can be

readily implemented over existing hardware.

The remainder of the chapter is organized as follows. Section 5.2, ad-

dress the performance isolation issue in IEEE 802.11 WMNs. In Sec. 5.3

the system architecture is sketched. Section 5.4 describes the experimental

setup of our testbed while Sec. 5.5 reports the outcomes of the measure-

ment campaign. Finally, Sec. 5.6 draws some conclusions.

5.2 Providing intra-cell airtime fairness

The half-duplex nature of IEEE 802.11 devices requires the the sender to

wait for an acknowledgment (ACK) signal after transmitting each frame.

If the transmitting station does not receive the ACK it reschedules the

transmission like if a collision occurred. If a node sustains repeated un-

successful transmission it may degrade its transmission bit-rate in order

to employ more robust but less efficient modulation schemes. As a result,

since the CSMA/CA algorithm gives to each node the same channel access

probability, nodes transmitting at low bit-rates will capture the wireless

channel for long periods of time at the expenses of the nodes transmit-

ting at higher bit-rates. Such behavior combined with the First-Come

First-Served scheduling policy implemented in most commercial AP lead

to the well known “IEEE 802.11 performance anomaly” extensively dis-

5.2. Providing intra-cell airtime fairness 67

cussed in [48].

WMNs are particularly susceptible to the “IEEE 802.11 performance

anomaly”. In [49] the causes of packet loss in a large outdoor WMNs are

analyzed. The authors concludes that the loss rate distribution is substan-

tially uniform across the whole range of loss rates and that a large number

of links are characterized by intermediate loss rates. Such a scenario makes

extremely challenging the use of IEEE 802.11-based WMNs for delivering

multimedia broadband services which, unlike “pure data” applications like

FTP or HTTP, are characterized by strict requirements in terms of of

bandwidth, latency, and packet loss.

5.2.1 Deficit Round Robin (DRR) Scheduling

This section briefly introduces the DRR algorithm, for a detailed analy-

sis the reader is referred to [50]. Analytical bounds to DRR latency and

fairness are analyzed in [51]. DRR is a modified weighted round robin

scheduling discipline. It can handle packets of variable size without know-

ing their mean size. According to the DRR algorithm, each flow contending

for a link has a corresponding queue i fed with all the packets belonging

to this flow. Each queue i has a counter associated called Deficit Counter

(DCi), which indicate the amount of resources the flow can use in a round.

Flows are visited in a round robin fashion. Each flow is visited only once

during each round. Upon each visit the flow’s deficit counter is increased

by a fixed quantity Q called quantum, if Q not smaller than the maxi-

mum packet length allowed in the network, then the algorithm complexity

is O(1). A packet is sent only if its length is smaller than the deficit

counter’s current value, otherwise the flow is skipped. After a packet is

sent the deficit counter is decreased by the size of the transmitted packet.

Only backlogged flows are served. When a flow is not backlogged its deficit

counter is set to zero.


5.2.2 Airtime DRR (A-DRR) Scheduling

The proposed scheme aims at providing intra-cell airtime fairness as op-

posed to the bandwidth fairness provided by traditional scheduling policy,

i.e. Fair Queuing or, in case of equally sized data packets, Round-Robin.

The A-DDR scheduler serves packets at the head of each nonempty queue

which deficit counter greater than the expected frame transmission time.

A frame whose transmission time exceed the counter is held back until

the next visit of the scheduler and the deficit counter is increased by the

quantum value. The deficit counter is decreased by the expected transmis-

sion time of each frame being served. The building blocks the scheduler

and their relationships are sketched in Fig. 5.1. Incoming frames are first

classified according to the destination address and then fed to a suitable

buffer queue. The A-DRR scheduler exploits the ETX metric in order to

estimate the channel time spent serving each nonempty queue. Let S be

the size of the packet, B the link bandwidth, and ETX the outgoing link

metric, the expected transmission airtime will be:

TXAirtime =S

BETX

Note that this definition of transmission airtime only takes into account

the time spent actually using the channel without considering the backoff

time spent waiting for the radio channel. This approximation is supported

by [14] where the authors conclude that although backoff can be estimated

and included in ETT metric, it is not worth the extra computation com-

plexity.

The pseudo code of the enqueue and dequeue processes is given respec-

tively in Alg. 2 and Alg. 3, while variables and data structure exploited by

both algorithms are summarized in Table 5.1.

5.2. Providing intra-cell airtime fairness 69

Algorithm 2 Enqueuing process.

1: for each incoming packet p do

2: i = p.NextHop()

3: if i not in QueuePool then

4: QueuePool.PushBack(i)

5: end if

6: QueuePool(i).Enqueue(p)

7: end for

Algorithm 3 Dequeuing process.

1: while true do

2: if QueuPool is not empty then

3: i = QueuePool.PullFront()

4: DC(i) = DC(i) + Q

5: while (DC(i) > 0) and i is not empty do

6: airtime = ComputeTxAirtime(Head(i))

7: if airtime < DC(i) then

8: DC(i) = DC(i) - airtime

9: p = QueuePool(i).Dequeue()

10: Send(p)

11: else

12: Break

13: end if

14: end while

15: if i is not empty then

16: QueuePool.PushBack(i)

17: end if

18: end if

19: end while


Figure 5.1: Block diagram for Aggregation Buffer with Airtime DRR Scheduler

Variable Default Description

QueuePool {∅} Array containing currently backlogged queues

Q 12000µs Quantum value

DCi 0 Queue i deficit counter

Table 5.1: Variables and data structure used by the A-DRR algorithm

5.3 Architectural Overview

The proposed traffic prioritization scheme exploits the DiffServ framework

in order to allow classification and differentiated treatment. DiffServ QoS

provision is a coarse-grained, class-based mechanism as opposed to the fine-

grained, flow-based mechanism that characterize IntServ. The DiffServ

framework defines a set of mechanism to classify and mark packets belong-

ing to a specific class. Forwarding properties associated with a traffic class

are implemented as Per-Hop Behaviors (PHBs). Different PHBs may be

defined to provide, for example, low-loss, low-latency forwarding properties

or best-effort forwarding properties. The PHB is indicated by encoding a

6-bit value, called the Differentiated Services Code Point (DSCP), into the

8-bit Differentiated Services (DS) field of the IP packet header (the for-

mer Type of Service, ToS field). DiffServ recommends the following PHB

behaviors:


Priority DSCP PHB Weights

Best Effort 0 Default 1

Low (LO) 0x0A AF11 2

Medium (ME) 0x12 AF21 4

High (TCP) 0x1A AF31 8

High (VoIP) 0x22 AF41 8

Table 5.2: Traffic Classes supported by our architecture

• Default. Typically best-effort traffic.

• Expedited Forwarding (EF). Low-loss, low-latency traffic class.

These characteristics are suitable for voice, video and other real-time

services.

• Assured Forwarding (AF). It defines four separate classes. Within

each class, packets are given a drop precedence (high, medium or low).

The combination of classes and drop precedence yields twelve separate

DSCP codes from AF11 through AF43.

• Class Selector. Defined to maintain backward compatibility with

the IP Precedence field.

The overall architecture of the traffic prioritization scheme is sketched

in Fig. 5.2. Network traffic entering a mesh router is classified by DSCP

code and then fed to a suitable queue. Traffic differentiating is provided

by means of a Deficit Weighted Round Robin (DWRR) scheduler which

pulls packets from buffers, according to some input weights (see Table 5.2).

The aggregation buffer has been modified in order to exploit the A-DRR

scheduling policy (see Fig. 5.3).

5.4 Evaluation Methodology

The measurements campaign has been carried out exploiting the same

testbed setup introduced in Sec. 4.6.1. In order to validate our traffic


Figure 5.2: Architecture of the opportunistic traffic differentiation scheme supporting

three different traffic classes.

Figure 5.3: Block diagram for Aggregation Buffer with Airtime DRR Scheduler

differentiation scheme four different application scenarios have been con-

sidered:

• Data-set A. Aims at verifying the capability of our scheme to dif-

ferentiate multiple saturated TCP flows. During this set of measure-

ments each traffic class has been fed with persistent TCP flows.

• Data-set B. Assesses the capability of our scheme to protect higher

priority TCP flows against lower-priority UDP streams. During this


Figure 5.4: Reference network topologies for for Data-set A and B.

set of measurements the high priority and the best effort queues are

fed with, respectively, a persistent TCP flow and an UDP stream at

increasing bit-rates, while the other queue are left empty. Table 5.3

summarizes the parameters of the UDP traffic.

• Data-set C. Aims at verifying the capability of our scheme to differ-

entiate multiple saturated TCP flows sharing a common intermediate

hop. In this scenario each traffic class has been fed with persistent

TCP flows.

• Data-set D. Assesses the capability of our scheme to protect higher

priority VoIP flows against lower-priority saturated TCP streams pro-

viding at the same time performance isolation among VoIP flows ex-

ploiting heterogeneous links. During this set of measurements the

high priority and the best effort queues are fed with, respectively, an

increasing number VoIP calls and a persistent TCP streams aimed at

modeling background traffic.

A single and a 2-hops string topologies have been used for data-set A

and B (see Fig. 5.4), while data-set C utilizes a dual string topology (see

Fig. 5.5) involving both 1-hop and 2-hops routes. Data-set D exploits a

star-shaped network topology (see Fig. 5.6) where all nodes are in radio

range, however Node 4 is placed in such a way to experience worse channel

conditions than both Node 2 and Node 3.

We have emulated each VoIP call with a single UDP stream modeled

according to the parameters of the G.729.3 codec [44], a worldwide used

speech codec for VoIP applications. Table 5.4 summarizes the key features


Figure 5.5: Reference network topologies for for Data-set C.

Figure 5.6: Reference network topologies for for Data-set D.

Run Payload Inter-generation time Bit-rate

1 1460 bytes 48 ms ≈ 250 Kbps

2 1460 bytes 24 ms ≈ 500 Kbps

3 1460 bytes 12 ms ≈ 1000 Kbps

4 1460 bytes 6 ms ≈ 2000 Kbps

5 1460 bytes 3 ms ≈ 4000 Kbps

Table 5.3: Parameters of the UDP noise traffic

Codec Packet Interval Bitrate Payload

G.729.3 30 ms 8 Kbps 30 bytes

Table 5.4: Key features of the G.729.3 codec

of the G.729.3 VoIP codec being tested in our experiments. In order to

collect reliable measures of delays, before each experiment we synchronized

each node with a common reference (Node 1 ) using NTP [45].


BE LO ME HI Total

Throughput (βi) 357/162 719/331 1449/667 2908/1351 5433/2510

Conf. int. (z95%) 11.11/9.24 1.99/3.14 3.72/5.13 7.28/4.34 -

Relative ratio (ρi) 0.99/0.97 1.98/1.98 4.00/3.99 8.03/8.07 15

Table 5.5: Outcomes of the experiments involving data-set A (1-hop/2-hops)

5.5 Performance Measurements

5.5.1 Data-set A

The outcomes of the experiments involving the data-set A are summarized

in Table 5.5. For each of the four traffic classes, the table reports the

average measured throughput in Kbps (βi), the confidence interval, and

the relative throughput ratios (ρi) relative to both the 1-hop and the 2-

hops scenarios. Being ϕi the input weight, it stands:

ρi =βi

∑

i ϕi∑

i βi

i ∈ {BE, LO, ME, HI}. (5.1)

In the ideal case ρi = ϕi. The numerical results contained in the table

reveal that relative flows priorities are maintained for both the 1-hop and

the 2-hops scenarios.

5.5.2 Data-set B

We will now analyze the results of the measurements performed using data-

set B. This test aims at investigating the performances of an high priority

TCP flows competing with an UDP stream at increasing bit-rates aimed

at modeling background traffic. Figure 5.7 shows that the introduction

of our traffic differentiation scheme effectively protects the high priority

flows, while, as expected, in a standard deployment the TCP performances

progressively decrease when the UDP bit-rate increases. Increasing the

number of hops leads to a more complex scenario. As we can see from

Fig. 5.8, using a standard setup, the UDP stream progressively saturate


0.5 1 1.5 2 2.5 3 3.5 40

1

2

3

4

5

6

UDP Bitrate (kbit/s)

Thr

ough

put (

bit/s

)

TCP (Bulk)UDP (Bulk)TCP (DiffServ)UDP (DiffServ)

Figure 5.7: High priority TCP flows competing with an UDP stream at increasing bit-

rates, 1-hop scenario.

the entire bandwidth annihilating the TCP flow. However, exploiting our

traffic differentiation scheme does not lead to the ideal behavior seen in the

1-hop scenario. Instead, increasing the bit-rate of the UDP stream results

in a similar share of the channel bandwidth among the two competing

flows.

5.5.3 Data-set C

We postulate that, the reason behind the behavior found in the previous

data-set lies in the scheduling policy of TCP ACKs at intermediates hops.

In fact, IP packets carrying TCP ACKs are not marked as high priority

traffic and are then buffered with the UDP streams, as shown in Fig. 5.9.

They are therefore likely to be lost or to experience high latency as a result

of the UDP streams non-responsiveness to link congestion.

Such behavior is most visible in data-set C where multiple full-rate

TCP flows share resources at an intermediate hop (Node 2 ). As shown in


0.5 1 1.5 2 2.5 3 3.5 40

0.5

1

1.5

2

2.5

3

3.5

4

UDP Bitrate (Mbit/s)

Thr

ough

put (

Mbi

t/s)

TCP (Bulk)UDP (Bulk)TCP (DiffServ)UDP (DiffServ)

Figure 5.8: High priority TCP flows competing with an UDP stream at increasing bit-

rates, 2-hops scenario.

Figure 5.9: Being not marked as high priority traffic, IP packets carrying TCP ACKs are

buffered with the low priority UDP packets at intermediate hops.

Fig. 5.10 the performance of the high priority flow relayed by node num-

ber 2 are drastically reduced when another high priority flow is generated

locally. Please note that the 2-hops flow is generated at node number 1

at t = 0s and ends at t = 240s, while the single hop flow is generated at

node 2 at t = 120s and ends at t = 360s. In order to mitigate this phe-

nomenon we implemented a Wireless ACK Re-scheduling Policy (WARP)

designed to give to TCP ACKs full preemptive access to the medium. Ex-

perimental results show that WARP is capable of providing a considerable

performance boost to the relayed flow as can be seen from Fig. 5.11. It


0 50 100 150 200 250 300 3500

0.5

1

1.5

2

2.5

3

3.5

Time (s)

Thr

ough

put (

Mbi

t/s)

1−hop route2−hops route

Figure 5.10: High priority TCP flows sharing resources at an intermediate node, WARP

disabled.

is worth stressing that our approach is totally state-less and requires no

admission control making it particularly suitable for resource limited mesh

routers.

5.5.4 Data-set D

This measurements campaign aims at determining the voice capacity [52],

i.e. the maximum number of sustained VoIP calls with high quality (70 <

R < 80) and related parameters: delay and packet loss. Using our op-

portunistic scheduling we achieved performance isolation among flows ex-

ploiting heterogeneous links. In particular, as we can see in Fig. 5.12 and

Fig. 5.13, the proposed scheduler successfully address the “IEEE 802.11

performance anomaly” maintaining an high voice quality over reliable links

(Node 2 and 3) as opposed to the legacy scenario where flows exploiting a

lossy link (Node 4) affect the performances of the whole cell. Similar result

may be found w.r.t packet delays and loss ratio (Fig. 5.14-5.15-5.16-5.17)


0 50 100 150 200 250 300 3500

0.5

1

1.5

2

2.5

3

Time (s)

Thr

ough

put (

Mbi

t/s)

1−hop route2−hops route

Figure 5.11: High priority TCP flows sharing resources at an intermediate node, WARP

enabled.

10 20 30 40 50 600

10

20

30

40

50

60

70

80

90

100


R−

Fac

tor

Aggregaton (RR)Aggregator (ADRR)

Figure 5.12: Average R-factor versus number of concurrent VoIP flow (Node 2 ).


10 20 30 40 50 600

10

20

30

40

50

60

70

80

90

100


R−

Fac

tor


Figure 5.13: Average R-factor versus number of concurrent VoIP flow (Node 4 ).

10 20 30 40 50 600

20

40

60

80

100

120

140

160

180

200


Ave

rage

del

ay (

ms)


Figure 5.14: Average dalay versus number of concurrent VoIP flow (Node 2 ).


10 20 30 40 50 600

20

40

60

80

100

120

140

160

180

200


Ave

rage

del

ay (

ms)


Figure 5.15: Average delay versus number of concurrent VoIP flow (Node 4 ).

10 20 30 40 50 600

5

10

15

20

25

30

35

40


Pac

ket l

oss

(%)


Figure 5.16: Average packet loss versus number of concurrent VoIP flow (Node 2 ).


10 20 30 40 50 600

5

10

15

20

25

30

35

40


Pac

ket l

oss

(%)


Figure 5.17: Average packet loss versus number of concurrent VoIP flow (Node 4 ).

5.6 Conclusions

This chapter presented a lightweight service differentiation architecture

capable of addressing the the “IEEE 802.11 performance anomaly”. The

proposed architecture is capable of providing both traffic prioritization and

performance isolation in IEEE 802.11-based WMNs. The optimal sched-

uled list is computed exploiting channel probing capabilities embedded in

the mesh routers. Results show that our scheme is capable of protect-

ing VoIP calls against saturated TCP flows providing at the same time

performance isolation among flows exploiting heterogeneous links.

If knowledge can create problems, it

is not through ignorance that we can

solve them.

Isaac Asimov

Chapter 6

Holistic network monitoring

6.1 Introduction

The quest for the autonomic management of information and communi-

cation systems dates back to more than two decades ago. It became a

compelling need when such systems started growing more and more com-

plex. The risk, in fact, was that the support/management of the infras-

tructure would become too expensive, up to the point to undermine the

development of new technologies. The idea of automatic management, or

self-management, was officially embraced in the IBM initiative on Auto-

nomic Computing [53, 54].

In the networking field, in particular, autonomicity is often identified

with the principle of Autonomic Network Management (ANM) [55]. The

need for efficient ANM indeed reflects the fact that the complexity of the

network has a serious impact on the design of robust and performing ar-

chitectures. But, despite the expectations, while ANM is emerging as one

of the hottest research topics, little concrete results have been achieved so

far. This can be ascribed, on one hand, to the complexity of the issue itself,

whose theoretical foundations have not been completed so far, and on the

other one to the lack of a research platform on which novel solutions can

be tested in a controlled and replicable fashion.

In such a scenario, due to their reconfigurability and ease of deploy-

ment, WMNs provide us the opportunity to design from scratch an auto-

83

84 Chapter 6. Holistic network monitoring

nomic control plane on top of a network of practical interest. WMNs rely

on a multi-hop wireless backhaul for delivering connectivity to the end-

users. WMNs provide a technological bridge between the ad hoc network-

ing paradigm and traditional wireless networks such IEEE 802.11-based

WLANs. However, unlike ad hoc networks, where node mobility was the

major concern, research on WMNs moved the focus on network scalability.

This chapter proposes a novel Knowledge Plane [56] tailored for the

WMNs scenario and capable of enabling consistent sharing of services

ontology among the entities participating the WMNs. Then, JANUS, a

novel and freely available1 monitoring framework exploiting the proposed

Knowledge Plane is introduced. The following use case scenarios may be

envisioned for the current prototype:

• Experiments reproducibility. Experiments carried out over current

WMN testbeds are characterized by a scarce reproducibility due to

the extreme time-varying nature of the network. In such a scenario,

the prototype’s monitoring capabilities are suitable to be exploited

in laboratory/field network testbeds in order to enhance experiments

reproducibility. The information contained in the Knowledge Plane

can in fact be exploited as check point of the network conditions (in

terms of link states, load, environmental noise, etc) for each experi-

ment providing providing precious information for both the analysis

of the collected data and the design of further experiments.

• Manned/Unmanned network profiling. Network wide performance tun-

ing may be a challenging task in WMNs where several factor may influ-

ence the global behavior. Nowadays a wide rage of techniques is avail-

able to support network and network devices management. Common

examples include SNMP [58], ICMP [59], and netconf [60]. However,

such solutions are developed using a strongly centralized approach,

while the distributed and self-organizing nature of WMNs suggest a

transition from network management (in terms of manual tweaking)

1The code is released under the BSD License [57].

6.1. Introduction 85

to network sensing (in terms of distributed and automated fault detec-

tion and/or performance analysis). In such a context, the proposed

Knowledge Plane is suitable to be exploited as rollback point for a

working or well performing network configuration in manual network

tuning as well as objective method to evaluate the effects of network

configuration changes in an Autonomic Networking scenario.

The Knowledge Plane here introduced is intended as a network construct

additional to both the Data and the Control Plane. We remark that the

Knowledge Plane is not meant to support the domain-specific knowledge,

as it is nowadays embedded into the network design itself. In the case of

the TCP congestion control loop, for example, roundtrip times knowledge

regulate the congestion window size. At such level of granularity, accurate

parameters can be safely estimated at the appropriate layer (transport

layer in this case). In what follows, conversely, we address a separate and

distributed cognitive construct aimed at equipping the network with an

high level view the tasks performed (i.e. frequency planning, resources

allocation, load balancing, etc.).

The Knowledge Plane is then required to encompass consistent syntax

and semantic in order to allow its exploitation for monitoring purposes as

well as to adapt the behavior of the node depending on the particular oper-

ating conditions (e.g., traffic type, channel perturbations, network status,

node selfishness and/or maliciousness, among the others). In our approach,

such a feature is obtained by exploiting both a meta-model, general enough

to support the different aspects of existing mesh networking implementa-

tions and a common meta-data exchange facility. These elements have

been identified respectively in the Meta Object Facility (MOF) [61] and

the XML Metadata Interchange (XMI) [62]. As it will be clear in the fol-

lowing, the exploitation of these two standards allows uniformity among

involved models to be easily gained. The philosophy of our approach is

aligned with [54], where a consistent definition of the available resources

and controls is considered mandatory to effective autonomic computing.


6.2 Related work

A large number of protocols exists to support network and network devices

management. Common protocols include SNMP [58], ICMP [59], and net-

conf [60]. Also, the MOME project [63] is maintaining a database with

more than 400 measurement tools. However, most of such tools are de-

signed on centralized architectures meaning that each node participating

to the network runs a process which gathers information about the current

network state. When a problem is recognized, the running process sends

alerts to some management entities. Upon receiving these alerts, the man-

agement entities are programmed to react by taking some actions (e.g.,

operator notification, event logging, system reboot/shutdown, etc.). Man-

agement entities can also poll end-stations to check the values of certain

variables.

A Distributed Architecture for Monitoring Mobile Networks (DAMON)

is introduced in [64]. DAMON relies on agents within the network to

actively monitor network behavior and to send this information to data

repositories. DAMON’s generic architecture supports the monitoring of

any protocol, device, or network parameter. VISUM [65] is a distributed

framework for monitoring wireless networks. Data, collected by agents

distributed over several host, are gathered at a centralized repository and

can be exploited by a visualization tool.

In MobileMAN [66], the information collected at different layers of the

networking stack are shared in a common local memory structure and

exploited to adapt the behavior to the current system status. Such an

approach satisfies the layer separation principle, i.e., protocols belonging

to different layers can be added/removed from the protocol stack without

modifying the protocols operating at the other layers. Moreover, it is

full compatible with existing standards, since it does not change the core

functionality of each layer maintaining all the advantages of a modular

architecture.

In [54], a conceptual architecture for autonomic computing is sketched.

6.2. Related work 87

The authors analyze the motivation behind the quest for autonomic com-

puting and focus on the control loops introduced by the self-management

routines. Several control disciplines are identified (e.g. self-configuring,

self-healing, etc) together with the need for an high level orchestrations

among them in order to control the mutual interaction of control loops,

that could otherwise lead to unpredicted and possibly disruptive effects.

In the architecture envisioned in [54], control loops leverage a common

knowledge of the system. However, in order to enable effective data sharing

across heterogeneous systems, a common syntax and semantic is required

in order to communicate the system status or to act on the system.

Along this line, in [56] the authors summarize this need in a new concept:

the Knowledge Plane. In the envisioned scenario, the Knowledge Plane

is supposed to collect information about the network status as well as

about services constraints and polices. A comparison with the Internet is

due in this case. The current Internet is the offspring of a simple idea:

building a transparent core network and move all the complexity to the

edges. This approach led to a situation where the network core is not

aware of its expected behavior and the end-user applications cannot tell

what’s happening in the network that appears to them as a black box.

According to the authors, the use of a Knowledge Plane has two main

targets. On one hand it will make a network able to describe itself, and

as result capable of supporting self-configuring and self-healing operations.

On the other hand it should give the applications the capability to reason

about the operating environment. In fact, current Internet design is based

on a transparent core network routing packets between intelligent edges.

As a result the core network only deals with packets without knowing their

purpose, while the edges understand the data being carried with the core

network appearing to them as a “black box”. The deployment of a network

wide Knowledge Plane would allow the core network to understand the

applications running across it and the behavior that they expect from the

network. The paper envision modeling of the entities to be understood as

the approach to achieve such reasoning features.


This thesis proposes a novel Knowledge Plane which addresses the in-

teroperability issues raised in [54]. In our study the focus is on the wireless

mesh networking paradigm: the interest there is due to the fact that, being

meant as unplanned systems, WMNs are required to cope with dynamically

changing environment and operations conditions, thus naturally demand-

ing for self-configuring and self-healing capabilities. Moreover, unlike other

network technologies, where pragmatic considerations make the manage-

ment plane hard to change, being an emerging paradigm, WMNs allows

us to craft from scratch a Knowledge Plane. The proposed approach lever-

ages a common meta-modeling language and meta-data exchange in order

to provide a consistent definition of the knowledge across heterogeneous

WMN architectures. Our approach is a step toward the definition of a

network-wide knowledge base that can be exploited by nodes in order to

adapt their behavior (e.g. for identifying malicious and/or not cooperative

nodes). To the best of the authors’ knowledge there are no other works

that address such issue in the WMN scenario.

6.3 Autonomic Network Management

The driving factor for ANM [55] is the consideration that nowadays net-

works cannot be considered static objects. On the contrary, real world

networks, grow, change, evolve and (sometimes) disappear. Legacy net-

work management tackles the issue of network adaptation, intended as the

ability of management policies to cope with minor changes in the system

configurations. As networks become more and more dynamic there is a

growing need to resort to human operators tuning in order to adapt them

to the new, changing environment. Such labor-intensive tasks have a high

cost and are intrinsically error-prone. The latter feature is extremely harm-

ful as communication networks get used to control critical infrastructures

(e.g., electrical power grid). In the networking scenario we can envision

an autonomic manager dedicated to self-management functionalities. Such

a manager must monitor the status of the resources it manages, analyze

6.3. Autonomic Network Management 89

Figure 6.1: Autonomic manager architecture.

the current conditions against some policies and take some actions if such

policies are not verified.

An autonomic computing system system is defined by its capacity to

monitor the operating environment, model its behavior and take actions

according to some policies. An autonomic computing architecture con-

sists of one or more control loops capable of dynamically managing various

aspects of the computing architecture. Figure 6.1 shows the conceptual

structure of an autonomic manager. In this figure the control loop is de-

composed into four distinct functions sharing a common knowledge of the

operation environment. Such functions are generally refereed with the

acronym MAPE [54]:

• Monitor : it probes the managed resources for operating parameters

(e.g. links status). It also performs aggregation, filtering and report-

ing operations over such data;

• Analyze: it provides the autonomic manager with a mechanism to

model the operating environment. Such a model can then be exploited


in match data with the system dynamics and to forecast future trends;

• Plan: it provides the reasoning framework that is supposed to define

the actions in order to achieve a specific objectives (defined as policies

in the autonomic manager knowledge base);

• Execute: it is in charge for the implementation of the actions output

of the plan function.

The Knowledge Base represents the data used by the autonomic man-

ager in MAPE process. The Manageability Interface presents to the Auto-

nomic Manager a transparent interface to the various management tech-

nologies that exist in the market today, e.g. SNMP, Java Management Ex-

tension (JMX), Control And Provisioning of Wireless Access Points (CAP-

WAP), etc. In [54] Web Services are envisioned as suitable technology for

the implementation of the Manageability Interface. The Knowledge Base

can be built using the Manageability Interface by querying the Managed

Resource and/or generated by the Autonomic Manager during its opera-

tion. In such a scenario exploiting a common semantic is mandatory in

order to enable effective data sharing across the MAPE process.

6.4 Overview of the Proposed Approach

As stated in Sec. 6.3, the applicability of the ANM concepts lies in the

definition of a common syntax and semantic for the Knowledge Base. How-

ever, at present, both commercial and academic solutions for wireless mesh

networking are characterized by a significant diversities in their implemen-

tations. Moreover, the node specialization feature described in Sec. 2.1

introduces an additional heterogeneity, in that nodes with different capa-

bilities are participating the same WMN; e.g. powerful gateways providing

both Internet connectivity and WLAN access to clients and stripped down

nodes providing just relaying functionalities.

6.4. Overview of the Proposed Approach 91

Hence, the key issue in the definition of the Knowledge Base is to make

it consistent across different WMNs implementations and yet expressive

enough to handle the dynamic and distributed nature of such systems.

The MOF allows models to be exported from one application into another,

transmitted across a network and stored into suitable repositories. Such

benefits are extended to non-UML models as long as they are expresses us-

ing a MOF-based language. In such a context, defining mappings between

the meta-models which correspond to different wireless mesh networking

paradigms and the MOF meta-model would automatically imply the pos-

sibility to exploit MOF as a common language for defining the Knowledge

Base and XMI as a common language for meta-data exchange enhanc-

ing re-usability and interoperability. In this section we shall illustrate all

details of our approach.

XMI defines the way a generic MOF-compliant model can be represented

as an XML document. For a given meta-model, each XMI-conforming

implementation will produce a DTD (or an XML Scheme), representing

the meta-model, and an XML document, representing an instance of the

given meta-model. The specific generation rules rely on a MOF definition

of the model’s meta-model; therefore, a meta-model can have its models

interchanged through XMI only if it is represented as an instance of the

MOF meta-meta-model. It is worth pointing out that XMI works at all

abstraction levels of the meta-model architecture defined by MOF. This

implies that it can be used for both the object serialization and the meta-

data exchange.

Our architecture is a particular case of the MOF meta-data architecture.

An example of this last architecture, tailored for the UML [67] environment,

is shown in Fig. 6.2. Here:

• The lowest layer, sometimes called original level [68], is that originat-

ing the model and often contains run-time data. At this level XMI

can be used for handling the object serialization.

• The model layer includes the meta-data relative to the lowest layer.


Figure 6.2: The MOF four-layer architecture.

Meta-data are aggregated as models. At this level XMI can be used

for handling the model or the meta-data exchange among tools using

the same meta-model.

• The meta-model layer includes the description of both the structure

and the semantics of the meta-data (i.e., the meta-meta-data). The

meta-meta-data are aggregated as meta-models. A meta-model is an

“abstract language” for describing different kinds of data. At this

level, XMI can be used for representing the model language (i.e., the

meta-model).

• The meta-metamodel layer includes the description of both the struc-

ture and the semantics of the meta-meta-data. The use of XMI at this

level allows an MOF model to be represented as an XML document.

6.4. Overview of the Proposed Approach 93

In the standard MOF stack, the meta-metamodel (also called MOF

Model) is self-defined and allows the definition of meta-models at the

third layer. The UML meta-model is one of the well-known examples

of meta-models; it is possible to define also other generic languages for

meta-modeling.

Due to the peculiarities of the scenario, our modeling constructs are

fundamentally different than the ones provided by UML. In such a context

extending the UML meta-model in order to create a MOF meta-model

defining the abstract syntax of such modeling constructs would imply car-

rying all the overhead of the UML meta-model. This issue is particularly

relevant since we plan an extensive exploitation of the XMI format in order

to circulate the network models among the nodes participating the WMN.

As stated in Sec. 2.1, a WMN is composed by several nodes that com-

municates with each other exploiting the wireless medium. Connection

with Internet is provided by specialized nodes called Gateways. Such mod-

eling constructs do not fit easily into any of the UML modeling paradigms,

then a meta-model that is tightly coupled with the modeling domain and

that does not carry all the overhead of the UML meta-model can provide

a better support. The following key concepts have been identified and

integrated in the proposed meta-model (see Fig. 6.3):

1. Node Specialization. Each node must implement at least one of the

following functionalities: Relay, Gateway, Access Point, and End-

Terminal.

2. Routing Metrics. Consists of at least one parameter exploited by the

routing algorithm in order to determine whether one route should

perform better than another. Metrics can cover information such as

bandwidth, delay, hop count, etc.

3. Multiple Interfaces. Each node participating the WMN communicates

with the others exploiting one or multiple channels. Such a behavior

can be implemented either using a single interface that dynamically


Figure 6.3: Meta-model for WMNs.

adjust its communication frequency or using multiple interfaces each

of them tuned to one frequency. We can also envision a scenario

multiple interfaces are dynamically tuned to a certain frequency in

order to optimize resources allocation.

Albeit the MOF four-layers architecture may seems too cumbersome for

“bare” network monitoring in WMNs, we argue that the ANM scenario re-

quires a “paradigm shift” analogous to that characterizing the software en-

gineering community with the larger and larger exploitation of model engi-

neering [69]. Such a shift was motivated by the consideration that, without

interoperability between different environments, users are forced to use a

small set of development tools or, alternatively, to totally renounce to mod-

eling. In the same way, the ANM paradigm requires consistent modeling

of the various networking aspects in order to enable effective orchestration

of heterogeneous network devices. Moreover, it is worth pointing out that

XMI provides a mechanism for specifying differences between models. This

feature is particularly useful when updates must be disseminated quickly

6.5. System Architecture 95

or very often and transmitting the entire model is resource consuming in

terms, for example, of time and/or network load.

6.5 System Architecture

This Section describe JANUS, the prototype developed in order to prove

the suitability of our meta-model to a practical case study, namely the wire-

less mesh networking paradigm. JANUS is a novel monitoring framework

designed with the goal of addressing the peculiarities of WMNs. It exploits

Pastry [70], a peer-to-peer overlay network, in order to make network in-

formation, collected at different layers of the stack, available to all nodes in

the system. Such information can be used for monitoring purposes as well

as to adapt the behavior of the node depending on the particular operating

conditions (e.g., traffic type, channel perturbations, network status, node

selfishness and/or maliciousness, among the others).

JANUS is implemented in the form of a Java application built on top

of Scribe [71], which is a scalable group communication system allowing

participants to subscribe to a topic and to publish messages. Scribe exploits

Pastry in order to build an efficient multicast tree for the distribution of

events to a topic. Any Scribe node is allowed to create a new topic making

it available for subscription to the other nodes. A credential-based system

is used for controlling the publication of message for a specific topic. Also,

we used FreePastry [72] as the reference peer-to-peer platform. FreePastry

is an open-source implementation of Pastry’s API from Rice University,

which comprises, among the other, a Scribe implementation. The building

blocks of JANUS and their relationships are sketched in Fig. 6.4. In this

section we shall illustrate the implementation details of each block.

It is worth pointing out that, with JANUS, we aim at providing a frame-

work where information about the entities participating the WMN can be

extracted and the corresponding models can be represented and shared.

Application built on top of JANUS can exploit the available knowledge in

order to, for example, diagnose failures, implement self-healing policies, or


Figure 6.4: Building blocks and relationships in the JANUS architecture.

monitoring the behavior of malicious nodes.

6.5.1 Managed Resource

The Managed Resource is a network node participating the WMN and

running the JANUS software. The testbed exploited during our experi-

mentation has been introduced in Sec. 4.6.1.

6.5.2 Agent

The Agent provides an implementation of the Manageability Interface de-

picted in Sec. 6.3. It is implemented in the form of a daemon running on

each managed device. All the Agents share a list of objects that they can

monitor. An object is a particular aspect of the managed resource, as for

example an Agent can track TCP connections running across the managed

device’s outgoing links. The Client can then query each link and gather

the status of each TCP connection. Agents can also send traps to the


Figure 6.5: Interactions between Agent and Client.

Client in order to asynchronously notify some events2. Figure 6.5 shows

the interactions between agents and clients.

Information about the Managed Resource are collected by the Platform

Specific Module and then converted in a format suitable for the integra-

tion into the Mesh Knowledge Base. Listing 6.1 shows an XMI docu-

ment conforming with the meta-model introduced in Sec. 6.4 representing

a node’s link cache. The link cache itself is basically a list of “known”

nodes, including the link metrics between those nodes. Each link cache

entry can be described by the following tuple

LS = 〈SA, DA, M〉,

where SA is the source node’s address, DA is the destination node’s ad-

dress, and M is the link metric, being

M = 〈ETX, B〉

where ETX is the Expected Transmission Count (ETX) [3] and measures

2In the current implementation traps from the Agent to the Client are not supported.


the expected number of transmissions, including retransmissions, needed

to send a unicast packet across a link, and B is the link bandwidth.

6.5.3 Client

The Client provides a framework for the implementation of an Autonomic

Manager. At initialization time each Client tries to connect to a bootstrap

host in order to subscribe a Scribe group. If no bootstrap host is found,

then a new Scribe ring is initialized by the Client. Please note that the

bootstrap host is required only at initialization time. Each Client periodi-

cally queries the agent in order to gather the managed objects. Gathered

objects are first used for updating the local MKB and then published on the

Scribe ring. When objects are delivered each Client takes care of merg-

ing them with the local MKB (during the bootstrap phase the MKB is

initialized with the locally collected objects).

Clients support plug-ins for extending their capabilities. Such plug-

ins exploits the MKB in order implements an arbitrary MAPE process.

Current prototype ships with a Listener module implementing monitor

functionality and allowing an external application for querying the node’s

MKB. JANUS has been exploited for monitoring the topology of a 6-nodes

wireless testbed deployed in a typical office environment implementing a

single-tier structure (see Sec. 2.1). The connection made available by the

Listener module running in each Client is exploited by a web server run-

ning on node number one in order to build a real-time map of the network

topology. More specifically the web server queries the Listener for the

Link Cache. The resulting XML document is then translated in a format

compatible with GeoPlot [73]. GeoPlot is a java applet that creates a geo-

graphical image of a data set. Basically, GeoPlot plots a set of nodes and

a set of lines that connect these nodes on an image specified by the user.

Figure 6.6 shows one sample of such a map.


Listing 6.1: A fragment of the link cache as represented in the MKB.�

<Janus . Network xmi . id=”pa l a n t i r”>

<Janus . Network . ownedElement>

<Janus . Node xmi . id=”ec−a0−b9−dc−76−c5” />

<Janus . Node xmi . id=”1c−12−78−6c−83−c0” />

</Janus . Network . ownedElement>

<Janus . subSequent>

<Janus . subSequent . from>

<Janus . Node xmi . i d r e f=”ec−a0−b9−dc−76−c5” />

</Janus . subSequent . from>

<Janus . subSequent . to>

<Janus . Node xmi . i d r e f =”1c−12−78−6c−83−c0” />

</Janus . subSequent . to>

<Janus . Metric>

<Janus . Metric . parameters>

<Janus . Parameter>

<Janus . Parameter . l abe l >ETX</Janus . Parameter . l abe l >

<Janus . Parameter . value >0.17</Janus . Parameter . value>

</Janus . Parameter>

<Janus . Parameter>

<Janus . Parameter . l abe l >Bitrate </Janus . Parameter . l abe l >

<Janus . Parameter . value >0.9</Janus . Parameter . value>

</Janus . Parameter>

</Janus . Metric . parameters>

</Janus . Metric>

</Janus . subSequent>

</Janus . Network>� �


Figure 6.6: JANUS: Snapshot of the network topology for the 6-nodes WMN testbed.

6.5.4 Mesh Knowledge Base

The Mesh Knowledge Base (MKB) is a collection of all the aspects (e.g.

status of the interfaces, link cache, etc.) of the Managed Resource that

can be tracked by the Agent. Such MKB is defined as a model conforming

to the meta-model introduced in Sec. 6.4. XMI is exploited as meta-data

exchange facility. Being XML-based, the XMI meta-data exchange facility

allows to access the model information using its DOM (Document Object

Model) [74] representation. DOM provides an object oriented application

programming interface that allows parsing HTML or XML into a well de-

fined tree structure and operating on its contents. The MKB is navigated

by the Client using XPath [75] expressions. XPath is a language for ad-

dressing XML documents and can be considered as a small query language.

As for example the subtree containing the link cache is identified by the

following XPath statement:

GET /Janus/Janus.Network/Janus.Network.ownedElement/Janus.subSequent

6.6. Conclusions 101

6.6 Conclusions

WMNs are emerging as leading paradigm for ubiquitous Internet access.

Being meant as unplanned systems, WMNs are required to show advanced

self-configuration and self-optimization capabilities. However, while early

deployments, mostly based on the IEEE 802.11 standard, are already in

place and commercial solutions are available, considerable research efforts

are still required. In particular, due to their dynamic and distributed na-

ture, WMNs pose significant management challenges claiming themselves

as a natural playground for the application of Autonomic Network Man-

agement Schemes.

In this chapter we proposed a novel Knowledge Plane tailored for the

WMNs scenario and capable of enabling consistent sharing of services on-

tology among the entities participating the WMNs. Such features can be

can be exploited for both monitoring purposes and to adapt the behavior of

the node depending on the particular operating conditions. Moreover, we

have developed JANUS, a novel and freely available monitoring framework

exploiting the proposed Knowledge Plane.

As future work, we are planning to extend the meta-model underlying

the Knowledge Plane JANUS framework in order support other network-

ing aspects. Nevertheless, a number of issues remain open. Deploying

applications on top of JANUS is likely to enrich the Knowledge Plane but,

at the same time, the increasing volume of data can lead to scalability

issues that need extensive investigation. In this context, we would also like

to extend the prototype’s capabilities by supporting incremental updates

and by differentiating the messages according to their temporal and spa-

tial characteristics. Moreover, while models can be exchanged, e.g., using

XMI, the semantic meaning of the models and meta-models in each envi-

ronment may be different. Ontology may serve as an appropriate tool in

this context.

Any sufficiently advanced technology

is indistinguishable from magic.

Arthur C. Clarke

Chapter 7

Conclusions and future work

WMNs are emerging as leading paradigm for ubiquitous Internet access.

Being meant as unplanned systems, WMNs are required to show advanced

self-configuration and self-optimization capabilities. However, while early

deployments, mostly based on the IEEE 802.11 standard, are already in

place and commercial solutions are available, considerable research efforts

are still required. In particular, the dynamic and distributed nature of

WMNs raises significant challenges in terms of QoS provisioning and net-

work management. The outcome of this research activity have been the

following:

• A packet aggregation scheme capable of reducing service time by com-

pounding several frame into a single burst at the MAC layer. A closed

formula is provided in order to compute the optimal burst length

according measurable link layer parameters. Results show that the

proposed technique is able to effectively differentiate services and im-

prove the network scalability. With respect to the specific case of

VoIP traffic, in fact, we experienced a factor 4 increase in the number

of simultaneous VoIP sessions.

• A lightweight architecture combining service differentiation with a

packet aggregation policy in IEEE 802.11-based WMNs. The pro-

posed architecture is capable of providing both traffic prioritization

and performance isolation in IEEE 802.11-based WMNs. The opti-

103

104 Chapter 7. Conclusions and future work

mal scheduled list is computed exploiting channel probing capabilities

embedded in the mesh routers. Results show that our scheme is ca-

pable of protecting VoIP calls against saturated TCP flows providing

at the same time performance isolation among flows exploiting het-

erogeneous links.

• A Knowledge Plane tailored for the WMNs scenario and capable of

enabling consistent sharing of services ontology among the entities

participating the WMNs. Such features can be can be exploited for

both monitoring purposes and to adapt the behavior of the node de-

pending on the particular operating conditions. Moreover, we have

developed JANUS, a novel and freely available monitoring framework

exploiting the proposed Knowledge Plane.

All proposed solutions have been implemented and tested over a real-

world WMN testbed based on the IEEE 802.11 standard. Source code

has been released under a BSD License making it freely available to the

research community.

As future work, we are planning to extend the meta-model underlying

the Knowledge Plane in order support other networking aspects. Never-

theless, a number of issues remain open. Deploying applications on top of

JANUS is likely to enrich the Knowledge Plane but, at the same time, the

increasing volume of data can lead to scalability issues that need extensive

investigation. In this context, we would also like to extend the prototype’s

capabilities by supporting incremental updates and by differentiating the

messages according to their temporal and spatial characteristics. Moreover,

while models can be exchanged, e.g., using XMI, the semantic meaning of

the models and meta-models in each environment may be different. On-

tology may serve as an appropriate tool in this context.

With regard to QoS provisioning, among the various possible research

directions to be pursued to extend the current work, two appear more

promising. The first one is based on the use of IEEE 802.11e-compliant

cards. In this case, indeed, the layer 2.5 priority classes could be mapped

105

to the service classes offered by the underlying MAC protocol, achieving

a better differentiation of services with respect to what happens in our

framework. The second one involves investigating the aggregation policy

self-interference generated by the channel load driven burst modulation

technique.

List of Tables

3.1 Design Trade-offs for a WMN testbed. . . . . . . . . . . . 33

3.2 Comparison between routing platforms for WMNs. . . . . 37

4.1 Key features of the G.729.3 codec . . . . . . . . . . . . . . 55

5.1 Variables and data structure used by the A-DRR algorithm 70

5.2 Traffic Classes supported by our architecture . . . . . . . . 71

5.3 Parameters of the UDP noise traffic . . . . . . . . . . . . . 74

5.4 Key features of the G.729.3 codec . . . . . . . . . . . . . . 74

5.5 Outcomes of the experiments involving data-set A (1-hop/2-

hops) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

107

List of Figures

1.1 A star-shaped architecture for IEEE 802.11-based WLANs. 2

1.2 A two-tier architecture for WMNs. . . . . . . . . . . . . . 3

2.1 Alternative protocol stacks for WMNs. . . . . . . . . . . . 12

4.1 Aggregated MSDU (A-MSDU) frame format. . . . . . . . . 42

4.2 Block diagram for the packet aggregator. . . . . . . . . . . 43

4.3 IEEE 802.11 Protocol Stack. . . . . . . . . . . . . . . . . . 44

4.4 IEEE 802.11 PPDU Format. . . . . . . . . . . . . . . . . . 44

4.5 IEEE 802.11 Frame Format. . . . . . . . . . . . . . . . . . 45

4.6 Ethernet frame SNAP-encapsulated in IEEE 802.11 frame 46

4.7 IEEE 802.11 access scheme based on the DCF. . . . . . . . 47

4.8 IEEE 802.11 Saturation throughput versus an increasing

length of the payload for different BERs. . . . . . . . . . . 50

4.9 Optimal burst length versus increasing values of the ETX

metric. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.10 Traffic flows used during the performance measurements cam-

paign. VoIP bundles and TCP flows are represented respec-

tively by solid and dashed lines. . . . . . . . . . . . . . . . 55

4.11 Average delay Vs increasing number of concurrent flows. . 58

4.12 Average packet loss Vs increasing number of concurrent flows. 59

4.13 Average R-factor Vs increasing number of concurrent flows. 59

4.14 Star-shaped network topology exploited in order to evaluate

the impact of the aggregation timer. . . . . . . . . . . . . 60

109

110 LIST OF FIGURES

4.15 Delay Vs. number of concurrent flows for different values of

aggregation timer. . . . . . . . . . . . . . . . . . . . . . . . 60

4.16 Delay Vs. number of concurrent VoIP flows without back-

ground interference. . . . . . . . . . . . . . . . . . . . . . . 61

4.17 Losses Vs. number of concurrent VoIP flows without back-


4.18 R-Factor Vs. number of concurrent VoIP flows without

background interference. . . . . . . . . . . . . . . . . . . . 62

4.19 Delay Vs. number of concurrent VoIP flows with back-


4.20 Losses Vs. number of concurrent flows with background

interference. . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.21 R-Factor Vs. number of concurrent flows with background

interference. . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1 Block diagram for Aggregation Buffer with Airtime DRR

Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.2 Architecture of the opportunistic traffic differentiation scheme

supporting three different traffic classes. . . . . . . . . . . 72

5.3 Block diagram for Aggregation Buffer with Airtime DRR

Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.4 Reference network topologies for for Data-set A and B. . . 73

5.5 Reference network topologies for for Data-set C. . . . . . . 74

5.6 Reference network topologies for for Data-set D. . . . . . . 74

5.7 High priority TCP flows competing with an UDP stream at

increasing bit-rates, 1-hop scenario. . . . . . . . . . . . . . 76

5.8 High priority TCP flows competing with an UDP stream at

increasing bit-rates, 2-hops scenario. . . . . . . . . . . . . 77

5.9 Being not marked as high priority traffic, IP packets carrying

TCP ACKs are buffered with the low priority UDP packets

at intermediate hops. . . . . . . . . . . . . . . . . . . . . . 77

LIST OF FIGURES 111

5.10 High priority TCP flows sharing resources at an intermedi-

ate node, WARP disabled. . . . . . . . . . . . . . . . . . . 78

5.11 High priority TCP flows sharing resources at an intermedi-

ate node, WARP enabled. . . . . . . . . . . . . . . . . . . 79

5.12 Average R-factor versus number of concurrent VoIP flow

(Node 2 ). . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.13 Average R-factor versus number of concurrent VoIP flow

(Node 4 ). . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.14 Average dalay versus number of concurrent VoIP flow (Node

2 ). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.15 Average delay versus number of concurrent VoIP flow (Node

4 ). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.16 Average packet loss versus number of concurrent VoIP flow

(Node 2 ). . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.17 Average packet loss versus number of concurrent VoIP flow

(Node 4 ). . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.1 Autonomic manager architecture. . . . . . . . . . . . . . . 89

6.2 The MOF four-layer architecture. . . . . . . . . . . . . . . 92

6.3 Meta-model for WMNs. . . . . . . . . . . . . . . . . . . . 94

6.4 Building blocks and relationships in the JANUS architecture. 96

6.5 Interactions between Agent and Client. . . . . . . . . . . . 97

6.6 JANUS: Snapshot of the network topology for the 6-nodes

WMN testbed. . . . . . . . . . . . . . . . . . . . . . . . . 100

Bibliography

[1] J. Bicket, D. Aguayo, S. Biswas, and R. Morris, “Architecture and

Evaluation of an Unplanned 802.11b Mesh Network,” in Proc. of ACM

MOBICOM, Cologne, Germany, 2005.

[2] S. Shakkottai, T. S. Rappaport, and P. C. Karlsson, “Cross-layer De-

sign for Wireless Networks,” IEEE Communications Magazine, vol. 41,

no. 10, pp. 74 – 80, Jun. 2003.

[3] D. S. J. D. Couto, D. Aguayo, J. Bicket, and R. Morris, “A high-

throughput path metric for multi-hop wireless routing,” in Proc. of

ACM MobiCom, San Diego, California, USA, 2003.

[4] R. Bruno, M. Conti, and E. Gregori, “Mesh Networks: Commod-

ity Multihop Ad Hoc Networks,” IEEE Communications Magazine,

vol. 43, no. 3, pp. 123 – 131, Mar. 2005.

[5] I. Akyildiz, X. Wang, and W. Wang, “Wireless mesh networks: a

survey,” Elsevier Computer Networks, vol. 47, no. 4, pp. 445 – 487,

Mar. 2005.

[6] “Ieee standard for local and metropolitan area networks part 16: Air

interface for fixed broadband wireless access systems,” IEEE 802.16-

2004, 2004.

[7] I. Chlamtac, M. Conti, and J. Liu, “Mobile ad hoc networking: im-

peratives and challenges,” Elsevier Ad Hoc Networks, vol. 1, no. 1, pp.

13 – 64, Jan. 2003.

113

114 BIBLIOGRAPHY

[8] R. Draves, J. Padhye, and B. Zill, “Comparison of Routing Metrics for

Static Multi-Hop Wireless Networks,” in Proc. of ACM SIGCOMM,

Portland, Oregon, USA, 2004.

[9] J. J. Garcia-Luna-Aceves, “Loop-free routing using diffusing compu-

tations,” IEEE/ACM Transaction on Networking, vol. 1, no. 1, pp.

130–141, Feb. 1993.

[10] C. E. Perkins and P. Bhagwat, “Highly Dynamic Destination-

Sequenced Distance-Vector Routing (DSDV) for Mobile Computers,”

in Proc. of ACM SIGCOMM, London, United Kingdom, 1994.

[11] D. Johnson, Y. Hu, and D. Maltz, “The dynamic source routing

protocol (dsr) for mobile ad hoc networks for ipv4,” IETF RFC 4728,

Feb. 2007. [Online]. Available: http://www.ietf.org/rfc/rfc4728.txt

[12] C. Perkins, E. Belding-Royer, and S. Das, “Ad hoc On-Demand

Distance Vector (AODV) Routing,” IETF RFC 3561, Jul. 2003.

[Online]. Available: http://www.ietf.org/rfc/rfc3561.txt

[13] C. Santivanez and R. Ramanathan, “Hazy Sighted Link State (HSLS)

Routing: A Scalable Link State Algorithm,” BBN, Tech. Rep. 1301,

August 2001.

[14] R. Draves, J. Padhye, and B. Zill, “Routing in Multi-Radio, Multi-Hop

Wireless Mesh Networks,” in Proc. of ACM MOBICOM, Philadelphia,

Pennsylvania, USA, 2004.

[15] “User-network interface specification,” ATM Forum, September 1993.

[16] “Private network-network interface specification,” ATM Forum, April

2002.

[17] R. Braden, D. Clark, and S. Shenker, “Integrated services in the

Internet architecture: an overview,” IETF RFC 1633, Jun. 1994.

[Online]. Available: http://tools.ietf.org/html/rfc1633.txt

BIBLIOGRAPHY 115

[18] R. Braden, L.Zhang, S. Berson, S. Herzog, and S. Jamin, “Resource

reservation protocol,” IETF RFC 2205, Sep. 1997. [Online]. Available:

http://tools.ietf.org/html/rfc2205.txt

[19] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss,

“An architecture for differentiated services,” IETF RFC 2475, Dec.

1998. [Online]. Available: http://tools.ietf.org/html/rfc2475.txt

[20] X. Xiao and L. M. Ni, “Internet QoS: A Big Picture,” IEEE Network,

vol. 13, no. 2, pp. 8 – 18, 1999.

[21] V. Kawadia and P. R. Kumar, “A cautionary perspective on cross-layer

design,” IEEE Wireless Communication Magazine, vol. 12, no. 1, pp.

3 – 11, Feb. 2005.

[22] “Ieee standards for information technology – telecommunications and

information exchange between systems – local and metropolitan area

network – specific requirements – part 11: Wireless lan medium access

control (mac) and physical layer (phy) specifications,” IEEE 802.11,

1999 Edition, 1999.

[23] T. Clausen and P. Jacquet, “Optimized link state routing

protocol,” IETF RFC 3626, Oct. 2003. [Online]. Available:

http://www.ietf.org/rfc/rfc3626.txt

[24] A. Raniwala and T. cker Chiueh, “Architecture and algorithms for an

IEEE 802.11-based multi-channel wireless mesh network,” in Proc. of

IEEE INFOCOM, Miami, Florida, USA, 2005.

[25] V. Angelakis, M. Genetzakis, N. Kossifidis, K. Mathioudakis, M. Nte-

lakis, S. Papadakis, N. Petroulakis, and V. A. Siris, “Heraklion mesh:

An experimental metropolitan multi-radio mesh network,” in Proc. of

ACM WiNTECH, Montreal, Quebec, Canada, 2007.

116 BIBLIOGRAPHY

[26] J. So and N. Vaidya, “Multi-channel MAC for ad hoc networks: han-

dling multi-channel hidden terminals using a single transceiver,” in

Proc. of ACM MOBIHOC, Roppongi Hills, Tokyo, Japan, 2004.

[27] P. Bahl, R. Chandra, and J. Dunagan, “SSCH: slotted seeded channel

hopping for capacity improvement in IEEE 802.11 ad hoc wireless

networks,” in Proc. of ACM MOBICOM, Philadelphia, Pennsylvania,

USA, 2004.

[28] A. Adya, P. Bahl, J. Padhye, A. Wolman, and L. Zhou, “A multi-radio

unification protocol for IEEE 802.11 wireless networks,” in Proc. of

BroadNets, San Jose, California, USA, 2004.

[29] “Seattle wireless.” [Online]. Available:

http://www.seattlewireless.net/

[30] E. Kohler, B. C. Robert Morris, J. Jannotti, and M. F. Kaashoek,

“The Click modular router,” ACM Transaction on Computer System,

vol. 18, no. 3, pp. 263 – 297, Aug. 2000.

[31] H. Wang and C. Wang, “Open source software adoption: a status

report,” IEEE Software, vol. 18, no. 2, pp. 90 – 95, Mar. 2001.

[32] S. Ganguly, N. V, K. Kim, A. Kashyap, D. Niculescu, R. I. S. Hong,

and S. Das, “Performance optimization for deploying VoIP services in

mesh networks,” IEEE Journal on Selected Areas in Communications,

vol. 24, no. 11, pp. 2147–2158, Nov. 2006.

[33] J. Jun and M. L. Sichitiu, “The nominal capacity of wireless mesh

networks,” IEEE Wireless Communications, [see also IEEE Personal

Communications], vol. 10, no. 5, pp. 8–14, 2003.

[34] J. Li, C. Blake, D. S. J. D. Couto, H. I. Lee, and R. Morris, “Capacity

of ad hoc wireless networks,” in Proc. of IEEE/ACM MobiCom, Rome,

Italy, 2001.

BIBLIOGRAPHY 117

[35] G. Bianchi, “IEEE 802.11 - Saturation Throughput Analysis,” IEEE

Communication Letters, vol. 2, no. 12, pp. 318–320, Dec. 1998.

[36] J. Yin, X. Wang, and D. Agrawal, “Optimal packet size in error-prone

channel for IEEE 802.11 distributed coordination function,” in Proc.

of IEEE WCNC, Atlanta, Georgia, USA, 2004.

[37] F. D. Pellegrini, F. Maguolo, A. Zanella, and M. Zorzi, “A cross-layer

solution for VoIP over ieee802.11,” in Proc. of WPMC 2005, Alborg,

Denmark, September, 18-22 2005.

[38] W. Wang, S. C. Liew, and V. O. K. Li, “Solutions to Performance

Problems in VoIP Over a 802.11 Wireless LAN,” IEEE Transaction

on Vehicular Technology, vol. 54, no. 1, pp. 366–384, January 2005.

[39] D. Kliazovich and F. Granelli, “Packet concatenation at the ip

level for performance enhancement in wireless local area networks,”

ACM/Springer Wireless Networks, 2007.

[40] K. Lu, D. Wu, and Y. Fang, “A novel framework for medium access

control in ultra-wideband ad hoc networks,” Dynamics of Continuous,

Discrete and Impulsive Systems, vol. 12, no. 3, pp. 427–441, Jun. 2005.

[41] K. Lu, J. Wang, D. Wu, and Y. Fang, “Performance of a burst-frame-

based CSMA/CA protocol for high data rate ultra-wideband networks:

analysis and enhancement,” in Proc. of ACM QShine, Waterloo, On-

tario, Canada, 2006.

[42] “Madwifi.” [Online]. Available: http://madwifi.org/

[43] “Jtg.” [Online]. Available: https://hoslab.cs.helsinki.fi/savane/projects/jtg/

[44] “A silence compression scheme for g.729 optimized for terminals con-

forming to recommendation v.70,” ITU-T Recommendation G.729 An-

nex B, Nov. 1996.

118 BIBLIOGRAPHY

[45] D. Mills, “Simple Network Time Protocol (SNTP) Ver-

sion 4,” IETF RFC 2030, Oct. 1996. [Online]. Available:

http://www.apps.ietf.org/rfc/rfc2030.html

[46] “The e-model, a computational model for use in transmission plan-

ning,” ITU-T Recommendation G.107, Nov. 2005.

[47] “Information technology - open distributed processing - reference

model: Foundations,” ITU-T Recommendation X.902,, Nov. 1995.

[48] M. Heusse, F. Rousseau, G. Berger-Sabbatel, and A. Duda, “Perfor-

mance anomaly of 802.11b,” in Proc. of IEEE INFOCOM, San Fran-

cisco, California, USA, 2003.

[49] D. Aguayo, J. Bicket, S. Biswas, G. Judd, and R. Morris, “Link-

level measurements from an 802.11b mesh network,” ACM SIGCOMM

Computer Communication Review, vol. 34, no. 4, pp. 121 – 132, Oct.

2004.

[50] M. Shreedhar and G. Varghese, “Efficient fair queueing using deficit

round robin,” in Proc. of ACM SIGCOMM, Cambridge, Mas-

sachusetts, USA, 1995.

[51] L. Lenzini, E. Mingozzi, , and G. Stea, “Tradeoffs between low com-

plexity, low latency, and fairness with deficit round-robin schedulers,”

IEEE/ACM Transaction on Networking, vol. 12, no. 4, pp. 681 – 693,

Aug. 2004.

[52] F. Maguolo, F. D. Pellegrini, A. Zanella, and M. Zorzi, “Cross-layer

solutions to performance problems in VoIP over wlan,” in Proc. of

EURASIP EUSIPCO, Florence, Italy, 2006.

[53] J. O. Kephart and D. M. Chess, “The vision of autonomic computing,”

IEEE Computer Magazine, vol. 36, no. 1, pp. 41 – 50, Jan. 2003.

[54] “Practical autonomic computing: Roadmap to self managing technol-

ogy,” IBM, 2006.

BIBLIOGRAPHY 119

[55] R. Mortier and E. Kiciman, “Autonomic network management: Some

pragmatic considerations,” in Proc. of ACM SIGCOMMM, Pisa, Italy,

2006.

[56] D. D. Clark, C. Partridgeo, J. C. Ramming, and J. T. Wroclawski,

“A knowledge plane for the internet,” in Proc. of ACM SIGCOMMM,

Karlsruhe, Germany, 2003.

[57] “JANUS.” [Online]. Available: http://www.wing-project.org/

[58] J. Case, M. Fedor, M. Schoffstall, and J. Davin, “A simple

network management protocol,” IETF RFC 1157, May 1990. [Online].

Available: http://www.ietf.org/rfc/rfc1157.txt

[59] J. Postel, “Internet control message protocol,” IETF RFC 0792, Sep.

1981. [Online]. Available: http://www.ietf.org/rfc/rfc0792.txt

[60] R. Enns, “Netconf configuration protocol,” IETF RFC 4741, Dec.

2006. [Online]. Available: http://tools.ietf.org/html/rfc4741

[61] Object Management Group, “Meta Object Facility (MOF)

Specification, Version 1.4.1, July 2005.” [Online]. Available:

http://www.omg.org/docs/formal/05-05-05.pdf

[62] ——, “XML Metadata Interchange (XMI) Specifica-

tion, Version 1.3, May 2003.” [Online]. Available:


[63] “MOME Project.” [Online]. Available: http://www.ist-mome.org/

[64] K. Ramachandran, E. M. Belding-Royer, and K. C. Almeroth, “DA-

MON: A distributed architecture for monitoring multi-hop mobile net-

works,” in Proc. of IEEE SECON, Santa Clara, California, USA, 2004.

[65] C. C. Ho, K. N. Ramachandran, K. C. Almeroth, and E. M. Belding-

Royer, “A scalable framework for wireless network monitoring,” in

Proc. of WMASH, Philadelphia, Pennsylvania, USA, 2004.

120 BIBLIOGRAPHY

[66] M. Conti, S. Giordano, G. Maselli, and G. Turi, “Mobileman: Mobile

metropolitan ad hoc networks,” in Proc. of Eight International IFIP-

TC6 Conference, Venice, Italy, 2003.

[67] Object Management Group, “Unified Modeling Language (UML)

Specification, Version 2.0, August 2005.” [Online]. Available:


[68] D. Karagiannis and H. Kuhn, “Metamodelling platforms,” in Proc. of

EC-Web, Aix-en-Provence, France, 2002.

[69] R. Riggio, D. Ursino, H. Kuhn, and D. Karagiannis, “Interoperability

in meta-environments: an xmi-based approach,” in Proc. of CAiSE,

Porto, Portugal, 2005.

[70] A. Rowstron and P. Druschel, “Pastry: Scalable, distributed object

location and routing for large-scale peer-to-peer systems,” in Proc.

of IFIP/ACM International Conference on Distributed Systems Plat-

forms, Heidelberg, Germany, 2001.

[71] M. Castro, P. Druschel, A. Kermarrec, and A. Rowstron, “Scribe:

A large-scale and decentralised application-level multicast infrastruc-

ture,” IEEE Journal on Selected Areas in Communication, vol. 20,

no. 8, pp. 1489 – 1499, Oct. 2002.

[72] “Freepastry.” [Online]. Available: http://freepastry.org/FreePastry/

[73] “Caida geoplot.” [Online]. Available:

http://www.caida.org/tools/visualization/geoplot/

[74] W3C, “Document Object model (DOM) Level 3 Core Specification

Version 1.0.” [Online]. Available: http://www.w3.org/TR/2004/REC-

DOM-Level-3-Core-20040407/

[75] ——, “XML Path Language (xpath) Version 1.0.” [Online]. Available:

http://www.w3.org/TR/xpath/

Documents

Cross-Layer Design in Wireless Mesh Networksassets.disi.unitn.it/uploads/doctoral_school/... · Figure 1.2: A two-tier architecture for WMNs. mesh routers form and maintain the wireless