Abstract - nitt.edu · service (QoS) to real and data applications passing through a multihop mesh...

Abstract

In this report we address the problem of providing end-to-end quality of

service (QoS) to real and data applications passing through a multihop mesh network

based on the IEEE 802.16 WiMax standard. It builds on the scheme proposed in [33].

An important addition is the spatial channel reuse in the mesh. This can substantially

improve the system performance. Other new elements are to include multiple channels

and radios in the setup and also to support limited mobility. These are the important

extra features from practical point of view. Finally we also consider the possibility of

supporting the QoS when the last hop is an IEEE 802.11 based wireless LAN.

ii

Contents

Acknowledgment i

Abstract ii

1 Introduction 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Literature Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Our Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Organization of report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 System Model 7

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 802.16 PHY and MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Our approach to QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Routing and Scheduling in Mesh Networks 13

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Optimization problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Transmission Constraints . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Approximate Solution and Algorithms . . . . . . . . . . . . . . . . . . . . 18

3.3.1 Algorithms for optimal solutions . . . . . . . . . . . . . . . . . . . 21

3.3.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

iii

CONTENTS iv

3.4 Slot Assignment Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.1 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.5 Interference-Aware tree structure routing and scheduling . . . . . . . . . 28

3.5.1 Tree routing structure . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5.2 Interference-aware tree route construction Algorithm . . . . . . . 29

3.5.3 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5.4 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6 MC-MR networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.6.1 Channel,node and interference constraints . . . . . . . . . . . . . 32

4 Providing QoS 35

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 QoS for Real Time Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1 Scheduling of CBR traffic . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.2 Scheduling of VBR Traffic . . . . . . . . . . . . . . . . . . . . . . . 38

4.3 QoS for TCP Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4 Joint Scheduling of UDP and TCP Flows . . . . . . . . . . . . . . . . . . . 44

4.5 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6 Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5 Mobility Support 54

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2 Mobility model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3 Providing QoS to mobile nodes . . . . . . . . . . . . . . . . . . . . . . . . 56

5.4 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6 QoS through WLAN-WiMax interconnected network 59

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2 802.11 MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.3 Fluid model of 802.11 MAC . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.3.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.4 QoS through an interconnection of WLAN and WiMax mesh . . . . . . . 66

CONTENTS v

6.5 Simulation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7 Summary and Future directions 74

7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.2 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Bibliography 75

List of Figures

3.1 A sample network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Multiple TCP flows through multiple queues with fixed rates . . . . . . 42

4.2 Overall Scheduling of TCP and UDP flows to provide QoS. UDP flows

get priority over TCP flows in each queue. RED applied on TCP flows

at entry nodes. (We have separated UDP flows and TCP flows in each

queue by a dotted line indicating each queue might be implemented via

two queues.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Network used in simulations . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4 Number of TCP connections . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.5 Number of UDP connections . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1 Random walk model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1 An 802.11 LAN downloading data files . . . . . . . . . . . . . . . . . . . 63

6.2 WLAN scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.3 Simulation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.4 Internet of WLAN and Wimax mesh . . . . . . . . . . . . . . . . . . . . . 72

6.5 Network seen by the flows from the MBS to the AP . . . . . . . . . . . . 72

6.6 Interconnected Network of WLAN and Wimax mesh . . . . . . . . . . . 73

vi

List of Tables

3.1 Comparision of routing strategies β . . . . . . . . . . . . . . . . . . . . . 31

4.1 Physical Layer Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Burst Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Performance of UDP Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.4 Performance of TCP Flows when maximum window size is set to E[w] . 51

4.5 Performance of TCP Flows when E[w] window is controlled by RED . . 51

5.1 Performance of static UDP Flows . . . . . . . . . . . . . . . . . . . . . . . 58

5.2 Performance of mobile UDP Flows . . . . . . . . . . . . . . . . . . . . . . 58

5.3 Performance of TCP static flows . . . . . . . . . . . . . . . . . . . . . . . 58

5.4 Performance of TCP mobile flows . . . . . . . . . . . . . . . . . . . . . . 58

6.1 Performance of UDP Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.2 Performance of TCP Flows when maximum window size is set to E[w] . 69

6.3 Performance of TCP Flows when E[w] window is controlled by RED . . 69

vii

Chapter 1

Introduction

1.1 Introduction

It is difficult to buy a laptop computer today that doesn’t come with a

Wi-Fi chip: a built-in radio that lets users surf the Web wirelessly from the boardroom,

the bedroom, or the coffee bar. Wi-Fi has become popular because a single base sta-

tion – a box with a wired connection to the Internet, such as a DSL, cable, or T1 line

– can broadcast to multiple users across distances as great as 100 meters indoors and

400 meters outdoors. These systems are based on the IEEE 802.11b protocol. How-

ever, the media access controller (MAC) and physical layer (PHY) specifications for

this protocol are suboptimum for outdoor citywide wireless networks or metropoli-

tan area networks (MAN). This means that the technology has very little range and

capability in a metropolitan setting or over any substantial distance. However a new

technology called WiMax has arrived which provides wireless broadband Internet con-

nections at speeds similar to Wi-Fi’s, but over distances of up to 50 kilometers from

a central tower. WiMax is a second-generation protocol that allows for more efficient

bandwidth use, interference avoidance, and is intended to allow higher data rates over

longer distances.

Wireless Interoperability for Microwave Access or WiMax is a wireless

1

Chapter 1. Introduction 2

digital communications system, also known as IEEE 802.16, that is intended for wire-

less ”metropolitan area networks”. WiMax can provide broadband wireless access up

to 30 miles for fixed stations, and 3 - 10 miles for mobile stations. In contrast, the

WiFi/802.11 wireless local area network standard is limited in most cases to only 100 -

300 feet.

With WiMax, data rates like those of WiFi are easily supported, but the

issue of interference is lessened. WiMax operates on both licensed and non-licensed

frequencies, providing a regulated environment and viable economic model for wire-

less carriers.

Although WiMax, has been designed to provide wireless broadband ac-

cess in the Metropolitan Area Network (MAN), delivering performance comparable

to Wifi, traditional cable, DSL or T1 offerings. To provide the coverage and data rates

envisioned, even on uneven terrain, the use of multihop communication seems desir-

able. Hence WiMax supports a Mesh mode (the other mode being point to multipoint)

in which unlike the traditional cellular systems, the nodes can communicate without

having a direct connection with the base station.

1.2 Problem Definition

In a IEEE 802.16d Mesh network, a node that has a direct connection

to backhaul services outside the Mesh network, is termed a Mesh Base Station (MBS).

All other nodes of a Mesh network are termed Mesh Subscriber Stations (MSS). In

IEEE 802.16d standards these nodes are stationary, i.e., the standards do not support

mobility (see however 802.16e amendment [2] to the 802.16 standard which supports

the mobility). The standard specifies a centralized scheduling scheme for mesh net-

works. Under this scheme, the SSs notify the MBS their data transfer requirements and

the quality of their links to their neighbours. The MBS uses the topology information

along with the requirements of each MSS to decide the routing and the scheduling. The


MAC scheme used is TDMA and the resource allocation is in terms of time slots within

a frame. The standard does not specify an algorithm for scheduling of the slots to dif-

ferent MSSs; neither does it specify any routing algorithm. Scheduling and routing

will have significant impact on the performance of the system and will largely decide

the end to end QoS to different users. We will focus on these problems.

The WiMax standard also supports a distributed scheduling scheme in

which each mesh node uses the local topology, channel and traffic information to de-

cide which channel to use. The distributed approach is simple and robust as com-

pared to the centralized approach. However it results in lower channel utilization and

will provide less control over QoS. Thus it is recommended ([11]) that the distributed

scheduling be used only for unlicensed spectrum while the centralized for licensed.

The standard recommends centralized scheduling for the traffic entering/leaving the

mesh while distributed scheduling for Intra-net traffic. A part of the frame can be

reserved for centralized scheduling and another for distributed scheduling and these

can be configured. Since most of the traffic is expected to be Internet traffic we will

concentrate on centralized mode.

IEEE 802.11 based WLAN has been becoming quite ubiquitous. This

technology has matured over the years and its equipment has become quite cheap.

However, as commented before the media access controller (MAC) and physical layer

(PHY) specifications for this protocol(802.11) are suboptimum for outdoor citywide

wireless networks or metropolitan area networks (MAN). An attractive scenario in the

future is that the last hop of the network will be an 802.11 based WLAN and it will be

connected to a WiMax network to access the broadband Internet. The WiMax network

might be a P-MP single hop network or a mesh network. therefore, providing end-to-

end QoS to different applications in such an interconnected network is an important

research issue.


1.3 Literature Survey

In the following we survey the literature on scheduling and routing for

wireless networks.

Scheduling algorithms to provide QoS in single hop (point to multipoint)

IEEE 802.16 networks are considered in [13], [18], [36] and [40]. See also ([19]) for a

performance analysis.

The problem of scheduling and routing in adhoc multihop wireless net-

works has been extensively studied in recent years (see [4], [15], [26] for general sur-

veys and tutorials). Scaling laws for fundamental limits on information transfer in

multihop wireless networks are surveyed in [42]. The dominant MAC (multiple access

control) protocols being considered for multihop networks are the CSMA/CA based

IEEE 802.11 and the TDMA based IEEE 802.16. Since 802.11 technology is much more

mature and cheaper, most of the current mesh network deployments are based on it.

However, due to co-channel interference it does not provide satisfactory performance

([28], [41]). See [21] for a recent contribution to provide QoS in 802.11 based mesh

networks. The performance of an 802.16 based mesh network can be much superior.

The studies on multihop 802.16 networks are [8], [9], [23], [34], [35] and

[39]. In [39] a simple heuristic scheduling and a Tree routing algorithm are proposed

to achieve efficient channel utilization. [8] and [23] provide fair access to all nodes and

also efficient utilization of resources. In [35] also routing and scheduling algorithms

are provided which are efficient for the overall system but spatial reuse of the channels

is not allowed (because the 802.16 standard at that time did not allow spatial reuse).

In [34] also channel spatial reuse is not allowed but within this limitation this study

provides QoS to individual TCP and real time connections. The QoS guarantee to

individual flows has not been provided in any other multihop wireless network study

that we are aware of (all the other studies mentioned above provide scheduling and

routing for the aggregate traffic generated at different nodes which as we will see is not


sufficient to guarantee QoS to individual connections). In [9] the authors study the

distributed scheduling.

1.4 Our Contribution

In this report, we present algorithms for centralized scheduling of real

and non-real time traffic with the objective of providing QoS within the framework of

the IEEE 802.16 mesh mode. Our algorithms use the network resources efficiently and

fairly and can be used in real time by the MBS.

In literature, there are many papers which deal with interference aware

optimal tree routing structure. We develop a new metric for constructing an interference-

aware optimal tree routing structure, whose performance is better than the previous

algorithms. We also extend our scheme of providing QoS to individual data and real

application to multi-channel, multi-radio fixed mesh networks. Furthermore, 802.16e

scenarios of limited mobility support is also considered. Finally, we also consider the

scenario where an end user is connected to an IEEE 802.11 based WLAN. The Access

point of the WLAN is connected to the Internet via a WiMax network. We demonstrate

that our ideas to provide QoS can be extended to such a setup.

1.5 Organization of report

The organization of the report is as follows. Chapter 2 describes the sys-

tem model. We obtain an optimal and fair routing and link scheduling algorithm for

the aggregate traffic in Chapter 3. We also obtain an approximate algorithm to allocate

slots to various links, satisfying the given interference constraints. In Chapter 4 we

provide scheduling schemes for flows within an aggregate to provide QoS to individ-

ual flows. In Chapter 5, we consider the multi hop scenario where the infrastructure

modes are fixed but some clients can be mobile. Chapter 6 develops algorithms to pro-

vide QoS in an WLAN-WiMax interconnected network. Section 7 concludes the report


and suggests future directions.

Chapter 2

System Model

2.1 Introduction

In this chapter we briefly explain the PHY and MAC layers of the IEEE

802.16 standard. Then we outline our QoS architecture for an 802.16 based network.

The rest of the report will develop these ideas.

2.2 802.16 PHY and MAC

An IEEE 802.16 network consists of a Base Station (BS) and multiple Sub-

scriber Stations (SSs). The BS serves as a gateway for the SSs to the external network,

and each SS acts as an access point that aggregates traffic from end users in a certain

geographical area. IEEE 802.16 support two modes of operation: Point-to-Multipoint

(PMP) mode and mesh mode. In PMP each SS directly communicates with the BS

through a single-hop link, which requires all SSs to be within clear LOS transmission

range of the BS. In contrast, in the mesh mode, the SSs can communicate with the mesh

BS and with each other through multi-hop routes via other SSs. The mesh topology not

only extends the network coverage and increases capacity in non-LOS environments,

but it also provides higher network reliability and availability when node or link fail-

ures occur, or when channel conditions are poor. IEEE 802.16 operates at 10-66 GHz for

Line-of-Sight (LOS), and 2-11 GHz for non-LOS connection. In this report we consider

7

Chapter 2. System Model 8

the mesh mode. The mesh mode supports two different physical layers, WirelessMAN-

OFDM and WirelessHUMAN. Both of these use 256 point FFT OFDM TDMA/TDM

for channel access and operate in a frequency band below 11GHz. The first operates

in the licensed band but the second uses the unlicensed band. The standards also sup-

port adaptive modulation and coding where the burst profile of a link (i.e., modulation

scheme and the coding rate) and hence the link rate is changed depending upon the

channel conditions.

The IEEE 802.16 mesh mode uses Time Division Multiple Access (TDMA)

for channel access among the mesh BS and SS nodes, where a radio channel is divided

into frames. Each frame is further divided into time slots that can be assigned to the

BS or different SS nodes. A frame consists of a control subframe and a data subframe.

Each frame is further divided into 256 minislots for transmission of user data and con-

trol messages. In the control subframe, transmission opportunities, which typically

consist of multiple minislots, are used to carry signalling messages for network con-

figuration and scheduling of data subframe minislot allocation. There are two types

of control subframes: network control subframe and scheduling control subframe. A

network control subframe follows after every NS scheduling control subframes, where

NS is a configurable network parameter.

In the network control subframes, Mesh Network Configuration (MSH-

NCFG) and Mesh Network Entry (MSH-NENT) messages are transmitted for creation

and maintenance of the network configuration. A scheduling tree rooted at the mesh

BS is established for the routing path between each SS and the mesh BS. Active nodes

within the mesh network periodically advertise MSH-NCFG messages which contain

a Network Descriptor that includes the network configuration information. A new

node that wishes to join the mesh network scans for active networks by listening to

MSH-NCFG messages. Upon receiving the MSH-NCFG message, the new node estab-

lishes synchronization with the mesh network. From among all the possible neighbor


nodes that advertise MSH-NCFG, the new node select one as its sponsor node. Then

the new node sends a MSH-NENT message with registration information to the mesh

BS through the sponsor node. Upon receipt of the registration message, the mesh BS

adds the new node as the child of the sponsor node in the scheduling tree, and then

broadcasts the updated network configuration to all SSs.

In the IEEE 802.16 mesh mode, both centralized scheduling and dis-

tributed scheduling are supported. Mesh Centralized Schedule (MSH-CSCH) and

Mesh Distributed Schedule (MSHDSCH) messages are exchanged in the scheduling

control subframe to assign the data minislots to different stations. The number of

transmission opportunities for MSH-CSCH and MSH-DSCH in each scheduling con-

trol subframe are network parameters that can be configured. Centralized scheduling

is mainly used to transfer data between the mesh BS and the SSs, which corresponds to

external traffic from the Internet; while distributed scheduling targets data delivery be-

tween two SSs in the same WiMax mesh network, which corresponds to intranet traffic.

In the standard, the data subframe is partitioned into two parts for the two scheduling

mechanisms respectively. The centralized scheduling handles both the uplink, where

the traffic goes from the SSs to the mesh BS, and downlink, where the traffic goes from

the mesh BS to the SSs. In the mesh mode, Time Division Duplex (TDD) is used to

share the channel between the uplink and the downlink.

In distributed scheduling, all SSs are peers and they compete for trans-

mission opportunities based on a pseudo-random election algorithm. A three-way

handshaking procedure is employed to reserve minislots for transmitting data between

neighboring SSs. In centralized scheduling, the mesh BS acts as the centralized sched-

uler and determines the allocation of the minislots dedicated to centralized scheduling

among all the stations. The time period for centralized scheduling is called scheduling

period, which is typically a couple of frames in length. There are two stages in each


scheduling period. In the first stage, the SSs send bandwidth requests using the MSH-

CSCH:Request message to their sponsor nodes, which are routed to the mesh BS along

the scheduling tree. Each SS not only sends its own bandwidth request but also relays

that of all its descendants in the scheduling tree. The SSs transmit MSH-CSCH:Request

messages in such an order that the sponsor nodes always transmit after all their chil-

dren. In this way, the mesh BS collects bandwidth requests from all the SSs. In the

second stage, the mesh BS calculates and distributes the schedule by broadcasting the

MSH-CSCH:Grant message, which is propagated to all the SSs along the scheduling

tree.

2.3 System Model

We consider the following scenario. Consider a Mesh network with M

MSSs labeled 1,2,. . . ,M . The MBS is labeled 0. We consider Uplink and Downlink

Centralized Scheduling of the MSSs, which, according to the standards uses TDMA with

spectral reuse. Also the data is directed either to or from the MBS. We assume that each

node transmits at the maximum allowed power, if needed. (Although power control

is also an important issue in performance of a mesh network, the standard currently

does not emphasis it and hence we donot address this in this Chapter). As the channel

condition on a link changes, the data rate is also changed so as to meet the desired BER.

Let rij denote the rate and E[rij] the average rate of the channel from node i to node

j. Resource allocation is done by the MBS in units of (mini) time slots. One time slot

consists of multiple OFDM symbols. Each allocation is valid for K frames consisting

of N time slots (for simplicity of notation we will take K=1).


2.4 Our approach to QoS

IEEE 802.16 supports real and nonreal time applications. The real time

applications, e.g., IP telephony and video conferencing, use UDP while data applica-

tions use TCP. Real time applications and interactive data (file transfer and web brows-

ing) require QoS. To provide QoS to these applications will require careful routing and

scheduling of traffic through the mesh network. We will consider these problems for

both types of traffic. Since UDP traffic and real time QoS requirements are very dif-

ferent from TCP traffic and interactive data QoS requirements, we will consider these

problems separately and then show how to integrate them in the same system.

To provide the QoS, we will generally follow the QoS-architecture de-

veloped in [34] since this seems to be the only architecture available for 802.16 mesh

networks which guarantees end-to-end per flow QoS. However, due to 802.16 mesh

requirements at that time [34] did not consider spectral spatial reuse. This can be a se-

rious limitation because spectral-reuse can provide significant capacity improvement.

Thus, in our current proposal we will remove this restriction.

We will use a two step approach. In the first step we will provide routing

and scheduling for the aggregate traffic for each source-destination pair of MSSs (one

of these MSSs will be the MBS). The aggregate traffic will be the mean total traffic of

all the real and data applications between different source-destination pairs. This of-

course does not guarantee the QoS to individual flows. In the second step we develop

scheduling algorithms to share the long-term throughput guaranteed in step one be-

tween real and data applications of each source-destination pair to guarantee QoS to

individual flows. We will justify the two step approach and will provide simulation

results to verify the claims on QoS guarantees.

Chapter 3 provides the routing and scheduling for step 1 to satisfy the

aggregate demands of source-destination pairs. In Chapter 4, we detail our step 2 to


ensure the end-to-end QoS to individual real and interactive data applications. Chap-

ter 5 extends our approach to include mobility support for some nodes. Chapter 6 will

show how we can indeed further extend our approach to accommodate a wifi network

at the last mile.

Chapter 3

Routing and Scheduling in Mesh

Networks

3.1 Introduction

In this chapter we consider the problem of routing and scheduling in a

wireless mesh network to satisfy certain aggregate traffic requirements. The algorithms

developed will form the first stage of our architecture to provide end-to-end QoS to

individual flows in an 802.16 based mesh network. This problem has been addressed

in numerous other recent studies. We will first address the the general problem which

can be useful in other mesh networks also (e.g., in 802.11 based mesh networks). Later

on we will also consider a tree-based routing and scheduling problem which has been

studied particularly in the context of WiMax mesh networks.

This chapter is organized as follows. In section 3.2, we state and explain

the optimization problem, to obtain optimal and fair routing and scheduling for the

aggregate traffic requirements of various source destination pairs. The computational

complexity of this problem is very high. Thus, section 3.3, provides the simpler solu-

tions which do our task at less complexity and guarantees a solution. In section 3.4,

we develop an approximate algorithm which uses the solution obtained in section 3.3

13

Chapter 3. Routing and Scheduling in Mesh Networks 14

to allocate slots to various links which satisfies the given transmission and traffic con-

straints. In Section 3.5, we consider the problem of optimal Tree routing and schedul-

ing, instead of multi-path routing obtained in the previous sections. A Tree-structure

is particularly considered in the WiMax networks. In section 3.6, we extended single

channel multi-hop networks to multi-channel multi-radio multi-hop mesh networks,

with finite number of orthogonal channels.

3.2 Optimization problem

The algorithms developed in this chapter can be used for uplink as well

as downlink simultaneously. Let λ(s, d) be the mean number of bits per slot to be

transmitted from MSS s to MSS d. This is the sum of mean throughput required by all

the real time and data connections transmitting from MSS s to MSS d. The calculation

of mean throughput requirements for TCP connections is shown in Section 4.3. For the

CBR connections, it is the traffic they generate per slot. For a VBR connection it equals

the equivalent bandwidth. For downlink, MSS s(source) will always be the MBS and

for uplink MSS d(destination) will be the MBS. We develop algorithms in this chapter

which will decide the routes that λ(s, d) will follow and also the slots in which each

link will transmit.

We develop algorithms which provide routes and schedules that will be

functions of λ(s, d) and the mean link rates E[r(i, j)] but otherwise would not vary

with time. By exploiting the current queue lengths at different links and the channel

states one could vary the routes and the schedules to obtain better performance ([33],

[34]) but we will not do this. This is because frequently varying routes and sched-

ules in real time is computationally more complex and can also cause loops in the

path traversed by a packet and resequencing problem at the receiver. Furthermore,

our QoS architecture requires reservation of resources at intermediate MSSs along a

route. Thus frequent route variation is not desirable. In addition, in case of spectral


spatial reuse, changing the routes and schedules is more complicated. Thus we will

change the routes and schedules of link transmissions only when some of the λ(s, d)

and/or E[r(i, j)] change drastically and/or some links/nodes fail. These algorithms

will be run at the MBS and then the schedules broadcast to different nodes via Mesh

Centralized Schedule messages.

The algorithms we develop will satisfy the traffic requirements λ(s, d) of

each source-destination pair (s, d) if possible. If not, then we will provide a “fair” so-

lution which is also efficient. When it is possible to satisfy certain (fair) traffic require-

ments of all source-destination pairs, we will provide routing and scheduling which

optimizes a cost function.

In this chapter we use the approach developed in [31] which in turn was

partly motivated by [24].

In [34], where spatial reuse is not allowed it was shown that the routing

and scheduling problems can be decoupled and that a Tree structure can be optimal

for routing. In the present general scenario this may not be true (although the 802.16

standard seems to prefer the Tree structure ([8], [39])).

The cost function to optimize will be a sum of the link cost functions

f(Γ(i, j)n(i, j)) where Γ(i, j) is the total mean traffic rate per slot and n(i, j) is the frac-

tion of slots assigned to link (i, j). Better cost functions can be obtained as a function

of higher moments of traffic arriving at link (i, j) but higher moments are difficult to

obtain and handle. Thus it is desirable to use only the first moments. But even then

f will often be a nonlinear function. For example, using Kleinrock’s independence

assumption ([38]) or approximating the queues at each link by an M/M/1 queue, we

get

f(Γ(i, j), n(i, j)) =Γ(i, j)

n(i, j)E[r(i, j)]− Γ(i, j) (3.1)

as the mean queue length at the link (i, j) and [n(i, j)E[r(i, j)] − Γ(i, j)]−1 as the mean


delay. Similarly we can consider packet loss probability if the buffer lengths are small.

Using Lagrange multipliers one can accommodate constrained optimization (see [31]

for more details).

The cost functions provided above may not be very good approxima-

tions of mean delay and queue lengths. Better approximations are provided in [31].

However it is an important direction for future research.

We consider the following joint routing and scheduling problem:

Find n(i, j) and αp(s, d) that minimizes

∑(i,j)∈L

f(Γ(i, j), n(i, j)) (3.2)

subject to

Γ(i, j) =∑(s,d)

∑p:(i,j)is on p

αp(s, d)λ(s, d) ≤ n(i, j)E[r(i, j)], (3.3)

0 ≤ αp(s, d) for each p, (s, d) (3.4)

and ∑p

αp(s, d) = 1 for each (s, d) (3.5)

where αp(s, d) is the fraction of (s, d) traffic on route p,L is the set of links and the inner

summation in (3.18) is over all possible routes for (s, d). The condition (3.18) is required

to satisfy the stability condition at each link (i, j).

3.2.1 Transmission Constraints

In addition to (3.18)-(3.5) the network should also satisfy some transmis-

sion constraints. These constraints occur due to the wireless nature of the links. In the

802.16 standard these are given by stating that two links can be scheduled for trans-

mission in the same slot if they are 1, 3 or 7 hops away from each other. However in a

practical system it may or may not be possible to schedule two links in a slot depending

upon the power of transmission, the distance between the receiving nodes and other


geographical factors. This can be decided in a particular scenario by actually taking

measurements and finding the SINR (Signal to Interference and Noise Ratio) at differ-

ent nodes. In the following we will assume that this has been done for the network

under consideration. Sometimes we can write these constraints as necessary and/or

sufficient inequality constraints. For example, if no spatial channel reuse is allowed

(as was done in the 802.16 standard in 2004 or if in the current standard we choose the

option that spatial reuse is allowed only with a hop distance of 7, in which case it may

effectively be no spatial reuse) then necessary and sufficient conditions are

∑(i,j)

n(i, j) ≤ 1. (3.6)

It is shown in [31] that if our transmission constraints are such that a node can receive

successfully if and only if one of its neighbouring nodes transmits in a slot and that a

node can transmit only on one of its links at a time, then the necessary and sufficient

conditions are

∑j:(i,j)∈L

n(i, j) ≤ 1 for all i

and∑

i=(i,j)∈Ln(i, j) ≤ 1 for all j. (3.7)

If we put the constraint that only one incoming or outgoing link at a node can be active

at a time, then it is shown in [8] that necessary and sufficient conditions, in the context

of WiMax mesh networks are

∑j:(i,j)∈L

n(i, j) +∑

j:(i,j)∈Ln(i, j) ≤ 1 for all nodes i. (3.8)

It is argued in [8] that by using directional antennas and careful placement of nodes,

these constraints can be quite realistic in the WiMax.


In a mesh network formed from 802.11 nodes, RTS-CTS-DATA-ACK

model, for a successful transmissions, neighbours of the transmitter as well as the re-

ceiver have to refrain from transmission at that time. Thus, for link (i, j), if N(i) are

the neighbouring nodes i and E(i) is the set of links incident on it, The transmission

constraints are : ∑i∈N(i)

∑l∈E(i)

n(l) ≤ 1 for each link(i, j) (3.9)

Our general setup can work with transmission constraints of the type

3.6-3.10 along with the optimization problem considered above.

The problem of transmission constraints has also been studied in [5], [17]

and [25]. Sometimes corresponding to these constraints, one may only be able to get

only sufficient inequality constraints. In the following we will assume the transmission

contraints have been put as linear inequality constraints and call them (T ). To be spe-

cific, in our examples in this report we will use the following scenario:

Consider a link (i, j), where i is the transmitting node and j is the receiving node.

When a link (i, j) is active, for successful transmission, node i can transmit only at link

(i, j) and node j can receive only at (i, j), i.e,

∑e′ ∈ E(i)) ∪ E(j)) ∪ Ein(N(i))) ∪ Eout(N(j)))

n(e′) ≤ 1 ∀ (i, j) ∈ E (3.10)

Where E(i) are adjucent links to node i, E(j) are adjucent links to node j, Ein(N(i)) are

incoming links on node i, Ein(N(i)) are outgoing links on node j

3.3 Approximate Solution and Algorithms

Obtaining the optimal solution for (3.2)-(3.5),(T )(transmission constraint)

can be very time consuming because of the nonlinear cost function. Infact, one needs

from n(i, j) an integral number of slots with in the scheduling frame. Also, if it is not


possible to satisfy the λ(s, d) requirements of each (s, d), the above optimization prob-

lem may not provide any solution. Thus in the following we first develop algorithms

which will check for feasibility of the demands λ(s, d). If these are not feasible, then we

provide a solution which may be “fair” to all (s, d) pairs. Finally we obtain a solution

which is fair to all (s, d) pairs and optimizes the nonlinear cost function.

Consider the following optimization problem:

maxλ such that (3.11)

∑p

αp(s, d) ≥ λ for all (s, d) (3.12)

and (3.18), (3.4) and (T ) are satisfied where the summation in (3.12) is over all possible

paths p in the network. A solution to the above optimization problem can be consid-

ered “fair” and efficient. This is because if there is a routing and scheduling algorithm

which satisfies all the traffic requirements λ(s, d) then λ will be ≥ 1. If not, it provides

the largest fraction of traffic that can be satisfied for each (s, d). This concept of fairness

has also been considered in [25], [34] and [36]. Furthermore unlike (3.2)-(3.5), this prob-

lem is a linear program (LP) and hence can be solved much faster than the nonlinear

problem (3.2)-(3.5).

As mentioned above, a solution n(i, j) and αp(s, d) satisfying (3.18), (3.4),

(3.11), (3.12) and (T ) will be considered efficient and fair. However observe that the

service provider will frequently need to run an algorithm in real time to obtain a solu-

tion and hence complexity of the algorithm will be an important issue. In general the

scheduling problem is NP hard because the n(i, j) need to be integer valued (should

be the number of slots in a frame assigned to link (i, j)). However if we ignore the

integrality of n(i, j) and consider them as non-negative fractions as considered above,

(3.18), (3.4), (3.11), (3.12), (T ) becomes an LP problem which is computationally much

more tractable.


If the number of nodes in the mesh is large, then complexity of the above

LP can also be of concern because the number of variables αp(s, d) can be exponential

in number of nodes. However in that case this LP can be reformulated in term of link

flows ([5], [3]) and this problem can be taken care of. Another way to handle it, in

terms of αp(s, d) itself is by solving the dual problem as discussed in [24].

If λ obtained from the above optimization problem is ≥ 1 then there is

a route and schedule for all (s, d) pairs and links which can satisfy the traffic require-

ments of all users. If λ < 1 then, λ is the largest fraction of traffic requirements of all

(s, d) pairs that can be satisfied by the network. Our solution of the above problem

can also provide λ > 1. When this happens, the network has more BW/throughput

than needed to satisfy the current QOS requirements of all the users. Then the above

solution allocates the extra resources to different (s, d) pairs in a fair way. The extra re-

sources can be used by the TCP connections usefully because in our QoS requirements

we have only specified the minimum mean throughput a TCP desires.

One can further improve the efficiency of the system if the optimal λ in

(3.11) is less than 1. In [31] a method is suggested where the fraction of demands

satisfied for some of the (s, d) pairs can be increased without decreasing the fraction

for other (s, d) pairs below the optimal λ obtained above.

The routing and scheduling provided above will ensure that the slot as-

signment n(i, j) for link (i, j) is such that its average rate n(i, j)E[r(i, j)] is sufficient

to carry the overall traffic passing through it. However, it will not ensure that the

throughput (rate) seen by traffic of a pair (s, d) will indeed get its required share of

throughput. This may partly happen because the TCP connections passing through

fewer hops tend to get more throughput than the other TCP connections sharing links

with it (see [7], [34]). Thus to ensure that the traffic of some (s, d) pairs does not hog

most of the throughput at a link, we will store the traffic of different (s, d) pairs in

different queues at each link and provide the required throughput to each queue via


WRR (Weighted Round Robin). This will ensure that traffic of each (s, d) pair will get

its share of throughput at each link on its routes.

In next subsection, we will improve upon the above solution to take into

account the cost function 3.18.

3.3.1 Algorithms for optimal solutions

Once we have verified via LP in Section 3.3 above the feasibility of traffic

demands of different (s, d) pairs, either we can satisfy the full demand (λ = 1) or we

have restricted the demand of different (s, d) pairs in a fair way via multiple stages of

LP in Section 3.3. In either case we now know that the traffic demands of different (s,

d) pairs can be met. The next step is to obtain certain routing and scheduling that can

optimize a system cost function 3.18. For illustration purposes we fix it to be the sum

of mean queue lengths at each queue:

Γ(i, j)

n(i, j)E[r(i, j)]− Γ(i, j) (3.13)

is the mean queue length at link (i, j) when mean traffic Γ(i, j) is flowing through it

and n(i, j) fraction of a slot is assigned to it. As mentioned before, (3.13) is the mean

queue length when we approximate the queue at link (i, j) by an M/M/1 queue.

The cost function (3.13) is not a linear or convex function of its variables

n(i, j) and αp(s,d). Thus it is not easy to compute the global minimum of the sum of

(3.13). In the following we explore some algorithms to compute the minimizer of sum

of (3.13).

Dinkelbach’s algorithm

This algorithm provides an efficient solution of optimization problem:

Maxx∈Sf(x)

g(x). (3.14)


where f, g are continuous functions from �nto � It has been shown that x∗ solves the

above Fractional Programming Problem if and only if it solves the global optimization

problem,

Maxx∈S(f(x)− λg(x)) (3.15)

with constant λ∗ = f(x∗)g(x∗)

. This fact can be used to obtain an efficient algorithm for (3.14)

if there is an efficient solution of the global optimization problem (3.15). The global op-

timum is easy to obtain if f and g are linear or convex functions. Dinkelbach’s original

iterative algorithm is based on the above result and can be described as follows.

1. Select some x(0) ∈ S. Set λ(0) = f(x(0))

g(x(0))and k = 0.

2. Solve the constrained global optimization problem to get the optimal point x(k+1).

3. If λ(k)f(x(k+1))− g(x(k+1)) = 0, then set x∗ = x(k+1) and λ∗ = λ(k), and stop.

4. If λ(k)f(x(k+1))− g(x(k+1)) > 0, then set λ(k+1) = f(x(k+1))

g(x(k+1)), k = k + 1 and go to step

2.

We use MATLAB to implement this iterative algorithm.

Sum of Fractions

As mentioned above, Dinkelbach algorithm provides a global optimum

for function fg

if f and g are linear or convex. In our case the link cost for each link is a

linear function of the variables but we need to optimize a sum of such functions. The

overall function does not satisfy these requirements. Thus, our cost function being a

non-linear function without some nice features which can be exploited with the current

state-of-the-art will fetch us only a local minimum. The current methods for sum of

fractions, use SQP (Sequential Quadratic Programming) method. The other popular

ones are Interior-reflective Newton method, Complex method, Zoutendijk’s method,


Rosen’s Gradient Projection method, interior and exterior penalty function method.

We will use SQP.

Min-max algorithm

Instead of minimizing the sum of link cost functions, one could consider

minimizing the maximum of link cost functions. For the cost function (3.13) one ad-

vantage of doing this is that instead of using a non-linear optimization algorithm, one

can use LP. This as we know provides a huge computational advantage. The cost func-

tion will be,

minmax(i,j)

Γ(i, j)

n(i, j)E[r(i, j)]− Γ(i, j) (3.16)

3.3.2 Example

In this subsection we provide an example to demonstrate the above al-

gorithms for routing and scheduling.

Consider the 5 node example shown in Figure 3.1. The transmission constraints for

this graph when each node can transmit and receive on one link at a time are:

n(1, 2) + n(1, 5) ≤ 1

n(2, 3) + n(2, 5) ≤ 1

n(3, 4) ≤ 1

n(4, 1) ≤ 1

n(5, 4) + n(5, 3) ≤ 1

n(2, 5) + n(1, 5) ≤ 1

n(2, 3) + n(5, 3) ≤ 1

n(5, 4) + n(3, 4) ≤ 1


Figure 3.1: A sample network

We have seen earlier that these are necessary and sufficient conditions for our network

model.

Now consider the traffic demands: E[λ(2, 1)] =3, E[λ(2, 4)] =3, E[λ(3, 4)]

=1. After running the LP once, at the end of stage one we obtain λ = 0.75. Thus it is

not possible to satisfy the traffic of all the users by more than 75% of their demands

simultaneously. Also we get n(3, 4) = 0.25 and n(5, 4) = 0.75. Thus, node 4 cannot

receive any more traffic. For stage 2 to see any possible improvement in efficiency, we

need to remove links (3, 4) and (5, 4). Then, one sees that we cannot transmit any more

data from any of the sources. Thus we cannot improve the efficiency any more. Next

we run the three optimization algorithms: Dinkelbach, Sum of fractions, min-max(LP).

Each of the algorithms provide us with the following routings: α(2−5−4−1)(2, 1) = 1,

α(2−5−4)(2, 4) = 1, α(3−4)(3, 4) = 1. Also all the three algorithms provide n(2, 5) = 1,

n(5, 4) = 0.75, n(3, 4) = 0.25, n(4, 1) = 1. One can check with exhaustive search that

we cannot improve over this result in terms of fairness, as well as getting maximum


throughput.

With traffic demands E[λ(1, 4)] =4, E[λ(2, 1)] =3, E[λ(5, 2)] =3, the LP

in the first stage provides λ = 0.5. Now running the sum of fractions algorithm with

50% load we get the routes as α(1−5−4)(1, 4) = 1, α(2−5−4−1)(2, 1) = 1, α(5−4−1−2)(5, 2) =

1. Then we observe that the link (4, 1) is fully loaded. Thus traffic λ(5, 2) and λ(2, 1)

can no longer be sent. Hence, now in second stage we transmit only traffic (1, 4). The

second stage provides λ2 = 0.5 and hence we can further transmit 1 unit of λ(1, 4)

traffic. Observe that now the link (5, 4) is fully loaded. Now we rerun the sum of

fractions algorithm with total load E[λ(1, 4)]′ = 3, E[λ(2, 1)]′ = 1.5 and E[λ(5, 2)]′ = 1.5

and obtain that all the traffic of λ(1, 4) follows the path (1 − 5 − 4), of λ(2, 1) follows

path (2 − 5 − 4 − 1) and of λ(5, 2) follows the path (5 − 4 − 1 − 2). Also n(1, 2) = 0.5,

n(1, 5) = 0.5, n(2, 5) = 0.5, n(5, 4) = 1, n(4, 1) = 1, n(2, 3) = 0.5, n(3, 4) = 0 and n(5, 3) = 0.

Again this can be shown to be a globally optimal solution from fairness and cost point

of view. Observe that although link (2, 3) is not being used, we do get n(2, 3) = 0.5. But

this does not increase the cost of the solution.

If we apply the Dinkelbach algorithm after stage 1 and then stage 2 of the

LP, the total routed traffic obtained is E[λ(1, 4)]′ = 2.99, E[λ(2, 1)]′ = 1.5 and E[λ(5, 2)]′ =

1.5. One sees that this algorithm is sending slightly less traffic for λ(1, 4) than the sum

of fractions. But this loss of traffic is insignificant and could be attributed to computa-

tional errors. This method also routes all the three traffic streams almost entirely along

the same paths as the sum-of-fractions algorithm (there are some differences in the

fourth decimal place). Also, due to slightly less load carried in this solution, the n(i, j)

are also almost same as the above solution except for n(2, 3) (which is not relevant) and

n(2, 5) = 0.3757.

Next we ran the min-max algorithm. We just summarize the results for

this. Since stage 1 λ does not depend on the non-linear algorithm, λ = 0.5, but λ2 = 0.46.

The traffic for the three streams is still carried entirely by the three routes given above.


The n(1, 2) = 0.5, (we are rounding off to two decimal places) n(1, 5) = 0.5, n(2, 3) = 0.47,

n(2, 5) = 0, n(3, 4) = 1, n(4, 1) = 0, n(5, 4) = 1.

The total cost of the three solutions above are 6751, 6453, 5595.

3.4 Slot Assignment Problem

The computation of feasible scheduling space is NP-hard. In addition,

the link scheduling problem is also NP-hard [43]. Our approach to the problem is

quite flexible and is a promising method to handle more sophisticated interference

conditions, multiple channels and multiple antennas.

LP, discussed in section 3.3 with interference constraint (3.6-3.10) will

give an optimal routing and scheduling, αp(s, d) and n(i, j) respectively. Let T be the

number of slots per scheduling frame in 802.16. Then n(i, j)T number of slots are to

be allocated to each link (i, j) per scheduling frame. But, the n(i, j)T may not be a

integer valued. We will take �n(i,j)T � slots for assignment. This ofcourse reduces the

total capacity of the link (i, j). But this can be taken care of by solving the LP with the

constraints (3.18) i.e,

Γ(i, j) =∑(s,d)

∑p:(i,j)is on p

αp(s, d)λ(s, d) ≤ n(i, j)E[r(i, j)] (3.17)

replaced by

Γ(i, j) =∑(s,d)

∑p:(i,j)is on p

αp(s, d)λ(s, d) ≤ (1− ε) n(i, j)E[r(i, j)] (3.18)

where ε is small fraction (say 0.05) After each n(i, j)T is truncated to its integer value,

the actual allocation of slots to different links still requires a careful algorithm. We

present one in the following section.

3.4.1 Algorithm

• Step 1


Construct a constraint graph (CG) for the give graph G(V,E) as follows. The

number of nodes in constraint graph CG is equal to number links in graph G.

Two nodes in the constraint graph are connected by a link, if they are interfering

links in the graph G.

S : The set of nodes in the graph

v : A node in the set S

N(v) : Adjacent node set of v

d(v) : Degree of node v

B : A set of links which can be active simultaneously.

n(v) : Number of slots to be allocated to link in G(V,E); which corresponds to

node v in CG.

• Step 2

B ← ∅S ′ ← S

while S ′ �= ∅ choose v such that d(v) = min(d(w)), w ∈ S ′ and in case of more

than one node with minimum degree take one with

maximum slots yet to be allocated.

B ← B ∪ v

S ′ ← S ′ − {v ∪N(v)}

• Step 3

Allocate min(d(w)), w ∈ Bslots to setB, and remove nodes v from the set S such

that d(v) = min(d(w)), w ∈ S ′, v ∈ S ′.

• go to step 2, if S is nonempty.


3.5 Interference-Aware tree structure routing and schedul-

ing

In [34], it was shown that a tree can provide an optimal (and desired)

routing structure for 802.16. However in [34] channel spatial reuse was not allowed.

In previous sections of this chapter we considered joint routing and scheduling with

channel reuse. The optimal routes obtained do not necessarily provide a tree structure.

Infact we will see that often the traffic of a source destination pair is split along two or

more paths. However, tree routing in WiMax mesh networks seems to be a preferred

structure([8],[39]). Even though the 802.16 standard does not mandate a Tree, the pro-

cedure prescribed in the standard for a new node to join the mesh would lead to a tree

if the routes are not changed with time. Thus, in this chapter

we will obtain an ’optimal’ tree structure with spatial channel reuse.

We will compare its performance with the optimal solution obtained in section 3.3.

We will also compare its performance with other tree routing solutions obtained in

literature([39]).

3.5.1 Tree routing structure

To achieve efficient spectral utilization and high throughput in 802.16

mesh networks, the route construction within the mesh network is crucial. To this

end, we propose an interference-aware route construction algorithm that considers the

interference condition in the mesh network. For link (u, v) we define the blocking

value,

B(u, v) =∑(i,j)∈

N(u, v)E[r(i, j)]

E[r(u, v)])(3.19)

where N(u,v) is the set of links interfering with link(u,v). Depending upon differ-

ent interference models we may obtain different N(u,v) sets for the link (u,v). Our

interference-aware tree routing construction algorithm is similar to that in [39]), differ-

ent except for the blocking value of the link. The blocking value of a route is the sum


of blocking values of the links on it.

In the interference-aware route construction scheme, the blocking metric

information is incorporated into the Network Descriptor of a MSH-NCFG message.

When a new node is scanning for active network during the network entry process,

the new node chooses the potential Sponsoring Node based on the blocking metric

information (i.e blocking value of the route)to reduce the interference of the multi-hop

route and hence to improve the throughput.

3.5.2 Interference-aware tree route construction Algorithm

S← {0}Ns ← {1, 2, . . . , n}p(i)← ∅, i ∈ {1, 2, . . . , n}Do if Ns �= ∅

m← arg maxi∈(Ns⋂

neighbour(s))σ(i) // node m with high σ(m) value joins first

C(m) = Neighbour(m) // all nodes with in transmission distanceof node m

W (m)← C(m)⋂

S // candidate parent nodes of node m

p(m)← argmini∈W (m)B(i) // select the node with minimum blocking

Add mtoS

Remove mfromNs

END

So far we consider the minimal interference along the path but after an SS enters the

network, the interference value on the path of other SSs in the network chang. There-

fore, the entry order of different nodes impacts the construction of the routing tree.

Thus, the routing tree can be reconstructed periodically.


3.5.3 Scheduling

Once the route is constructed, scheduling of the links to satisfy the traffic

requirements of different source-destination pairs can be done as before. Let λ(s, d) is

the total throughput requirement for source destination pair (s, d). To obtain n(u, v),

the fraction of slot to be assigned to link (u, v)., we consider the following optimization

problem:

Find n(u, v) for each link (u, v) that maximizes β such that

β∑

(s,d):(u,v)is on route(s,d)

λ(s, d) ≤ n(u, v) E[r(u, v)], (3.20)

∑(i,j)∈N(u,v)

n(i, j) + n(u, v) ≤ 1 . (3.21)

To allocate slots to the links follow the algorithm in 3.4.1.

3.5.4 Simulations

We simulate the formations of a WiMax mesh network as follows

Initially we start with a mesh containing one MBS and one MSS. Then MSSs are added

sequentially to the network, according to the algorithm 3.5.2. Let us assume λ(s, d) =

200 bytes per slot. For each (i, j), E[r(i, j)] is chosen arbitrarily suitable to wimax phys-

ical layer specifications. In TableTable 3.5.4 we provide the maximum β supported by

the network for different number of nodes. Also provided in the table are β obtained

if the tree in [39] is used and when we use yhe optimal routes from LP in section 3.3.


Table 3.1: Comparision of routing strategies βnumber multi-path tree routing tree routingof nodes routing our metric [39]

2 1.6 1.6 1.63 0.3741 0.3741 0.37414 0.2993 0.2993 0.29935 0.3118 0.2302 0.23026 0.2465 0.1871 0.18717 0.2037 0.1609 0.13308 0.1736 0.1109 0.10849 0.1512 0.1301 0.1247

10 0.1339 0.1197 0.1151

3.6 MC-MR networks

We develop a network model that characterizes the multi-hop and multi-

radio features in a fixed broadband wireless network with a limited number of orthog-

onal channels and with multiple radios at each node. Our model provides both nec-

essary and sufficient conditions for a feasible channel assignment and schedule in the

network. Our model also has the flexibility of specifying the neighbors and the inter-

ferers for each node in an arbitrary fashion to reflect the actual system conditions. We

consider a fixed multi-hop wireless network with n nodes. We represent the network

with a directed graph G = (V, E) where V represents the set of nodes in the network

and E is the set of links.

There are C orthogonal channels in the network, denoted by the set OC =

1,2, . . . C. Each node v has κ(v) radios. One of the practical constraints on radios is that

it is not useful to have two radios tuned to the same channel at a given node, since local

interference at the node will ensure that only one of them is active at any time. There-

fore, it is possible that κ(v) ≤ C, though this is not a restricting factor in our model.


3.6.1 Channel,node and interference constraints

We now present a mathematical constraint model for the MC-MR fixed

wireless mesh network. We first define a 0− 1 scheduling variable

nti(e) = 1 If link is active on channeliin time slot t

= 0 other wise

Note that nti(e) is set to one if there is a transmission on channel i over link e in time

slot t.

Link-Channel Constraint: By definition, the maximum number of channels that can

active on link e at any time slot t is ρ(e). Thus, we have

∑i ∈ OC

nti(e) ≤ ρ(e) ∀e ∈ E, ∀t (3.22)

Node-Radio Constraint: A node can use at most κ(v) radios in a given time slot for

transmission or reception or both. This leads to the following constraint.

∑e ∈ E(v)

∑i ∈ OC

nti(e) ≤ κ(v) ∀ v ∈ V, ∀ t (3.23)

Interference Constraint: In 3.4, we stated different interference models considered

in the literature. They can be extended from single channel case to finite orthogonal

channel case.

Let us consider RTS-CTS-DATA-ACK model interference model of IEEE 802.11,(see

3.4) to identify pairs of nodes that can simultaneously transmit. In this model, neigh-

bors of both an intended transmitter and receiver have to refrain from both transmis-

sion and reception. Interference will occur only among users sharing the same channel,

say channel i. Consider a node v and its neighborhood N(v) in G. Let one of the links

e in E(v) be active on channel i and let u be the other endpoint of the link. For e to be


active on channel i, all other links incident on v, E(v) \ e have to be idle and, in addi-

tion, each neighbor of v must remain idle, on channel i The same argument applies to

u For silencing N(v) due to the non-overlapping neighborhoods of nodes in N(v) we

have to include them in separate constraints, as follows.

∑e ∈ E(v) ∪ E(v′)

nti(e) ≤ 1 ∀ v′ ∈ N(v), ∀i ∈ OC, ∀t (3.24)

Interestingly, these constraints are the same whenever any link incident on v has to be

active, since it prevents other links incident on {v}∪N(v) from being active at the same

time on the same channel. Therefore, we can rewrite these constraints as follows.

∑e ∈ E(v) ∪ E(v′)

nti(e) ≤ 1 ∀ v′ ∈ N(v), ∀v ∈ N(v), ∀t (3.25)

Thus, we formally state the interference constraint in terms of an link e.

∑e′ ∈ E(t(e)) ∪ E(h(e))

n(e′) ≤ 1 ∀i ∈ OC ∀ e ∈ E, ∀t (3.26)

Note that there are only E interference constraints in all, under this approach, with the

number of variables per constraint never exceeding twice the maximum degree of the

graph. The reduction in number of constraints significantly reduces the complexity of

modeling interference and increases the convergence speed of any linear optimization

problem using these constraints.

In the same way if we consider Our model of interference,(see 3.4) then

interference constraints in terms of an link e.

∑e′ ∈ E(t(e)) ∪ E(h(e)) ∪ Ein(N(t(e))) ∪ Eout(N(h(e)))

n(e′) ≤ 1 ∀i ∈ OC ∀ e ∈ E, ∀t (3.27)


For optimal routing and scheduling of aggregate traffic, consider the following opti-

mization problem:

max λ such that (3.28)∑p

αp(s, d) ≥ λ for all (s, d) (3.29)

Γ(i, j) =∑(s,d)

∑p:(i,j)is on p

αp(s, d)λ(s, d) ≤∑

i ∈OC

ni(e)E[ri(e)], (3.30)

0 ≤ αp(s, d) for each p, (s, d) (3.31)∑i ∈ OC

ni(e) ≤ ρ(e) ∀ e ∈ E, ∀ t (3.32)∑e ∈ E(v)

∑i ∈ OC

ni(e) ≤ κ(v) ∀ v ∈ V, ∀ t (3.33)

where the summation in (3.29) is over all possible paths p in the network. In addition

to 3.29-3.33 the network should also satisfy interference constraints 3.26 or 3.27. A

solution to the above optimization problem can be considered “fair” and efficient. This

is because if there is a routing and scheduling algorithm which satisfies all the traffic

requirements λ(s, d) then λ will be ≥ 1. If not, it provides the largest fraction of traffic

that can be satisfied for each (s, d). This concept of fairness has also been considered in

[25], [34] and [36].

After obtaining optimal routing and scheduling, αp(s, d) and ni(e) respectively , to

allocate slots to the links follow 3.4.In slot assignment problem for this case of finite

orthogonal channels, The number of nodes in constraint graph CG is equal to,

∑e ∈ E

ρ(e) (3.34)

To provide QoS to individual flows follow chapter 4.

Chapter 4

Providing QoS

4.1 Introduction

Once the routing and scheduling to satisfy the aggregate demands of

each (s, d) pair are obtained, as done in Chapter 3. We have guaranteed an end to end

pipe for each λ(s, d). However, if we send the traffice of (s, d) on this pipe, as such,

it will not guarantee end-to-end QoS to individual flows. Thus, in this chapter we

provide the schemes for scheduling of different flows of each (s, d) pair along its pipe

so as to guarantee them their QoS.

Section 4.2 considers the real time traffic. Section 4.3 provides details for

the TCP connections. Section 4.4 shows how to combine the real time and data traffic

to provide QoS to individual connections.

In this chapter we also verify via simulations that our QoS architecture

does indeed provides the QoS. Our QoS architecture will also be scalable in the sense

that it will not require per flow processing at intermediate nodes.

4.2 QoS for Real Time Traffic

In this section we design scheduling algorithms to guarantee QoS to in-

dividual UDP connections. Two important real time applications are IP telephony and

video conferencing. For these applications, the end to end delay of a packet should not

35

Chapter 4. Providing QoS 36

exceed (say) 150 msec. If a packet exceeds this delay, it will be dropped. For satisfac-

tory performance the fraction of packets dropped for an application should be less than

(say) 2%. To satisfy these QoS requirements, we propose that at the end of a (schedul-

ing) frame we drop the packets which could not be transmitted through the wireless

network. This will ensure a maximum delay of about 40 msec ( for 4 frames of 10 msec

each) in the wireless network (the rest of the delay margin is left for the remaining part

of the network that a packet may have to travel). We develop algorithms which will

ensure that a particular user will not experience drop probability greater than 2%.

Packets generated by audio encoders (in IP telephony) usually generate

a constant bit rate (CBR) traffic. But a video encoder (say MPEG) one may use in video

conferencing generates variable bit rate (VBR) traffic (although downloading a stored

video may arrive as a CBR traffic). To satisfy the QoS requirements of these two types

of applications efficiently we require different considerations. Therefore we consider

these two cases separately. We consider scheduling of CBR traffic in Section 4.2.1 and

VBR traffic in Section 4.2.2.

Based on the routing and scheduling algorithm of Section 3, we know

the fraction αp(s, d) of total average traffic requirement λ(s, d) of each pair (s, d) passing

through a route p. Then, as we will detail in Section 4.4, based on the average through-

put requirement of each UDP and TCP connection of (s, d), we will decide which of the

CBR, VBR and TCP connections of (s, d) will pass through which route. Knowing the

route that each connection will take, we decide the QoS architecture in the following

to provide the QoS to each connection.

4.2.1 Scheduling of CBR traffic

Let X (a constant) be the total amount of traffic generated during a frame

by different CBR connections of a particular (s, d) pair following a particular route

denoted by links p1, p2, ..., ph (this will be known based on the algorithm in chapter 3).

As mentioned above, in order to provide delay guarantees to these flows, we propose


dropping of data that cannot be transmitted at the end of the scheduling frame. Now,

the scheduler has to ensure that the amount of data dropped conforms to the QoS

requirements of the flow. Let the upper bound required on the drop probability of the

packets of these flows be ε. (For simplicity of notation we are taking this upper bound

same for all CBR applications. If different flows have different requirements then ε is

the minimum of these requirements. Of course one can handle the general case in the

same way for each flow separately).

The scheduling problem for this CBR-UDP traffic is to calculate the num-

ber of slots nj, j = 1, . . . , h required at link pj such that X units of data can be transmit-

ted to the MBS per scheduling frame and the end to end drop probability is bounded

by ε.

We decompose the drop probability ε into {εj, j = 1, . . . , h} such that∏hj=1(1 − εj) ≥ (1 − ε). At link pj the number of slots allocated for these flows has to

ensure that the drop probability is upper bounded by εj . We use nj for the allocation

of slots for link pj , r(j) for r(pj) and Xj for∏j

k=1(1 − εk) X to simplify the notation.

Then, nj has to satisfy

limn→∞

∑nk=1(Xj − njrk(j))

+

n Xj

≤ εj. (4.1)

This reduces to E((Xj − njr(j))+) ≤ εjXj. We can rewrite it as

∫ Xjnj

0

(Xj − njr) fj(r) dr ≤ εjXj (4.2)

where fj(·) is the pdf of the link rate r(j) which is assumed to be known. The quantity

on the left in (4.2) is a non-increasing function of nj and hence it is easy to compute the

required nj .

Since the drop probability ε is small, we do not loss much in optimality

if in the above calculation we replace Xj with X . Also, instead of arbitrarily choosing

the values {εj, j = 1, . . . , h}, we can consider the optimization problem


min{ h∑

j=1

nj

}subject to

h∏j=1

(1− εj) ≥ (1− ε) and

∫ Xjnj

0

(Xj − njr) fj(r) dr ≤ εjXj, j = 1, . . . , h.

The above allocation of slots to satisfy the QoS was proposed in [34]. However, it was

observed in [34] that even though one can obtain the required number n(j) of slots

needed to satisfy the QoS as above, in practice, due to very small probabilities ε, the

number of slots needed actually becomes X/rmin(j) where rmin(j) is the minimum rate

supported by link pj . By taking rmin(j) as the minimum rate supported in the standard,

n(j) becomes independent of statistics of r(j). This may be much easier to do and will

entail only a small loss of optimality. Similar comments will hold for VBR scheduling

in Section 4.2.2.

4.2.2 Scheduling of VBR Traffic

Consider K VBR flows generated at an (s, d) that will follow the same

route p1, p2, ..., ph. Let Dn(k) be the amount of data generated by flow k in frame n.

We assume that the arrival process {Dn(k), n ≥ 0 } for each k = 1, . . . , K is stationary

and ergodic with known statistics. We also assume that the arrival processes from the

various sources are mutually independent. As in the case of CBR traffic, we provide

delay guarantees to the VBR flows by dropping the data not transmitted by the end of

each frame. The problem is to calculate the number of slots required by this VBR traffic

on each node on its route in order to bound the drop probability by ε. Again obtain

εj, j = 1, ..., h as in Section 4.2.1.

The amount of resources required utilizes the statistics of the arrival


process. Since the data not transmitted at the end of a frame is dropped we need to

consider only the marginal distribution of Dn(k) to calculate the amount of resources

required at the first node. Also, since the drop probability is typically small, we can

assume that the statistics of the arrival process is not distorted after flowing through

the first node. Hence we can use the same analysis for each of the nodes along the

route. Choose εbj and εd

j such that (1-εbj)(1-εd

j ) ≥ (1-εj). Now, find Cj such that

P

(K∑

k=1

D1(k) > Cj

)≤ εb

j. (4.3)

This Cj/K is called the equivalent bandwidth of the VBR source [38]. If we take εbj to

be same for all j, Cj becomes independent of j which simplifies the further design.

Therefore we do that in the following and denote it by C. The MBS can treat a VBR

source as a CBR flow generating C/K units of data per frame and calculate the number

of slots required to satisfy the drop probability requirement of εd as in Section 4.2.

In practice, the exact statistics of a VBR arrival process may not be avail-

able. The statistics that is generally available is the maximum, the minimum and the

average data rates. In order to satisfy the QoS requirements of the flows, we can calcu-

late the value of C by using a source model that has all the known characteristics of the

original source but has the worst case behaviour (i.e., gets the largest equivalent BW).

It is shown in [20] that for the case of K independent, homogeneous, stationary sources

with arrivals in a slot taking values in a finite set (this class covers Markov modulated

sources modulated by finite state Markov chains) the worst case drop probability is ob-

tained by replacing these sources by i.i.d. ON-OFF sources having the same maximum,

minimum and average rates.

Simulation results in [34] show that the slot allocation provided in Sec-

tions 4.2.1 and 4.2.2 does indeed provide QoS to individual flows.


4.3 QoS for TCP Traffic

This section develops scheduling algorithms which can guarantee the

QoS for TCP connections. Some TCP applications, e.g., email do not require any QoS.

However web traffic and file transfer may require certain minimum response time. We

try to satisfy these QoS requirements by providing adequate minimum mean through-

put to individual connections. But, if there is insufficient bandwidth to satisfy the min-

imum mean throughput of all the TCP connections, then again there is the question of

how should we do the allocation in a fair way. In this case unlike the UDP connections

where we recommend admission control, one other option is to give these connections

less bandwidth than requested.

Initially we will consider the case of persistent TCP connections. These

are long lived connections which need to send a large file. The QoS requirement for

these connections is the maximum response time. Later on we will also consider TCP-

ON-OFF connections (see [16] for details on this model) which model the web traffic

using HTTP 1.1. In this model, a TCP connection transfers multiple files. Between

transfer of two files, a TCP connection may not have a file to transfer (OFF period) for

sometime. This is the dominant traffic type in the current Internet. An appropriate

QoS requirement for these connections is the mean file download time.

For both of the above TCP types the QoS can be satisfied if we ensure a

minimum mean throughput to each connection. In the following we provide schedul-

ing schemes to ensure this. First we compute the average throughput these connections

need to satisfy their QoS. These computations can be used also to compute the total av-

erage throughput requirement of all TCP connections for any particular (s, d) that we

need in chapter 3.

We consider TCP persistent connections first. Let NP persistent TCP

connections of an (s, d) be passing through a particular route. Let λPj be the minimum

throughput requirements (in packets/sec) and sPj the packet lengths (in bits) of the


jth persistent TCP connection. Thus the total average throughput requirement of the

persistent TCP connections is λP =∑NP

j=1 λPj sP

j bits/sec.

We now consider TCP-ON-OFF traffic. Let NO TCP-ON-OFF flows of

(s, d) be following the same route as the NP persistent connections mentioned above.

For simplicity assume all of them to have the same mean download time requirement

of T on (this is the mean time that will be taken to download a file by such a connection)

and the same mean number of packets D to be downloaded during an ON period.

Let the packet size of a connection be sO. Let the mean time between two downloads

be T off . Then the throughput required by such a TCP flow to satisfy its QoS require-

ment is λm = D sO

T on . Also the long term average throughput required by this flow is

λa = D sO

(T on+T off ). The probabilty of a connection being ON is T on

T on+T off . Making the

assumption that the ON-OFF processes of different connections are independent, the

mean number of connections ON at anytime is NO T on

T on+T off . Now since each connection

requires a throughput of λm when ON, the total throughput requirement of ON-OFF

traffic at node i is

λO =( NO T on

T on + T off

)λm = NOλa.

The above approximation improves as the number of connections NO increases.

The overall average throughput needed for the persistent and ON-OFF

connections is λT = λP + λO bits/sec.

Let L = NP + NO TCP connections of an (s, d) be passing through a

particular route as decided by the algorithm in Chapter 3. Suppose they have been

guaranteed a mean throughput of λT bits/sec at each node on its route (say via WRR as

mentioned before). We will see below that this is not sufficient to guarantee minimum

throughput to individual TCP connections passing through the same set of links. This

will require extra care. First we consider persistent connections.

Consider the system shown in Fig.4.1. Let the NP TCP connections are

passing through (say) four queues. TCPi has window size Wi (assume it is fixed) and


Figure 4.1: Multiple TCP flows through multiple queues with fixed rates

propagation delay Δi (representing delays in the rest of the network). At each queue

the link speed is c = λP bps (ensured say, by WRR discussed above). In this scenario

the packets/acks of different TCPs will be either at the first queue (and not at the other

three queues) or propagating in the rest of the network (in propagation pipes Δis). If

TCPi gets a throughput of λi packets/sec, then by Little’s law ([37], [38]) it has on

the average (under stationarity, proved in [16]) λi Δi packets in the propagation pipe.

Thus the average queue length in the first queue is∑NP

i=1(Wi − λi Δi) (actually it will

be a little less than this; some packets might be getting serviced at the other queues).

Since TCPi has packet length sPi (in bits) the mean queueing delay in the first queue

is∑NP

i=1(Wi − λi Δi) sPi /c. As there is no queueing delays in the other queues, the total

mean round trip time of TCPi is approximately 1c

∑NP

j=1(Wj−λj Δj) sPj +

3 sPi

c+Δi. Thus

the total throughput obtained by TCPi is

Wi c∑NP

j=1(Wj − λj Δj) sPj + 3 sP

i +Δi cpackets/sec. (4.4)

To provide a desired throughput (or minimum throughput) to different

TCPs, one needs to adjust c, Wj , sPj appropriately in (4.4) such that it becomes equal

to the desired throughput for each i (which may be different for different TCP con-

nections). The bandwidth c (in bits/sec) should equal∑NP

i=1 λPi sP

i (if λPi packets/sec is


the minimum mean throughput desired by connection i). It is possible that a service

provider may not have the freedom to choose Wi and sPi for different TCP connections

(these are selected by the receivers and the networks through which the connections

are passing). However even though the maximum window size Wi may not be con-

trollable, if it is large enough, its mean size can be reduced to an appropriate size by

dropping its packets in a controlled way (say) via RED [14] at the nodes in the mesh

such that the required throughput can be provided to each TCP. We explain this in the

following.

Let us fix a desired queueing delay of d∗ sec in the first queue. Define for

each i, Δ̃i = Δi +3 sP

i

c. We fix the desired mean window size of E[Wi] such that

E[Wi]

d∗ + Δ̃i

= λPi for each i. (4.5)

Now we use RED control for each TCP connection i and specify its RED parameters

such that at average queue length d∗ c, it will drop the packets of TCPi with probability

pi, where

pi =8

(3 (Eπ[Wi] + 4)2 + 5)

for each i. (This has been used in [34] and is based on [27]. It provides a reasonable

approximation for small values of pi. We are working on better approximations.) Then

it can be shown (see [32] and [33]) that this system will operate under steady state such

that the first queue will have the mean queue length d∗ c and each of the TCPs will have

their mean window size E[Wi] satisfying the above requirements. Furthermore, TCPi

will get the throughput λPi packets/sec.We will verify these claims via simulations in

Section 4.5.

To include also the NO TCP-ON-OFF connections in the above setup,

we make c = λT bps. Futhermore, we use RED to control the window size of a ON-

OFF connection also where its mean window size E[W ] should satisfy (4.5) with λPi


replaced by λm.

It is shown in [22] and [30], that the TCP connections can be grouped

such that one needs only a few RED parameters to take care of the throughput require-

ments of different TCPs and per flow processing is not required.

Once we have ensured that the overall TCP traffic originating at the dif-

ferent nodes gets the bandwidth it requires at each node on its route, to ensure that

the different persistent and ON-OFF TCP connections in it get the throughput they

want, we set the window sizes according to (4.5). To provide the needed mean win-

dow size, as explained above we can use RED at the bottleneck node along the route of

the TCP connections. If the link rates are all fixed, then after ensuring that these flows

get their required throughputs at each link, the node through which the TCP flows en-

ter the mesh network is the bottleneck. However due to the random variation of the

link rates in wireless links, any link along the route can momentarily turn into a bot-

tleneck (whenever its channel state is poor). To make our scheme work, one method

is to implement RED control at all nodes along the path of the TCP flows. However

this involves difficulties in practical implementation since every node has to acquire

the RED parameters of all the flows passing through it. An alternate method is to force

the ingress node to be the bottleneck by providing about 3-5% extra bandwidth to the

flows at the other nodes along the route. This extra bandwidth whenever not used by

these TCP flows, can be provided to the best effort traffic.

4.4 Joint Scheduling of UDP and TCP Flows

In this section we address the problem of scheduling in presence of both

UDP and TCP traffic. The requirements of UDP traffic were discussed in Section 4.2

and of TCP traffic in Section 4.3. From the arguments in these sections, in order to

provide QoS to UDP we had to consider the worst case channel conditions whereas

for TCP we had to consider the average channel rates. Thus there is a huge difference


between the average bandwidth requested and the average bandwidth provided to

guarantee the QoS of the CBR and VBR connections. Here we utilize this extra band-

width for scheduling of TCP flows.

We provide priority to UDP traffic over TCP traffic in the network. It has

been observed in [22], [30] and [34] that by doing this the delays experienced by UDP

flows can be drastically reduced without affecting the throughput of the TCP flows. In

the present context, it will allow us to save resources to provide QoS.

Let λU(s, d) and λT (s, d) be the average throughput required by the to-

tal UDP (for a CBR connection it is its rate, for a VBR connection, it is its equivalent

bandwidth computed by taking h to be the maximum number of hops of a node from

MBS) and TCP traffic generated by (s, d). Then we define λ(s, d) = λU(s, d) + λT (s, d)

as the average requirement of (s, d). We use this requirement in chapter 3 to obtain the

routing and scheduling for all the pairs. It is possible that the overall traffic of (s, d) is

split over several routes. Let αp(s, d) be the fraction of (s, d) traffic on route p.

If αp(s, d) < 1 then we will send αp(s, d) fraction of λU(s, d) and λT (s, d)

on route p. On a link (i, j) on p out of a total n(i, j) slot assignment in chapter 3,

a fraction n′(i, j, s, d) would be assigned for λ(s, d)αp(s, d) traffic of (s, d) which is ≥λ(s,d)αp(s,d)

E[r(i,j)].

This slot assignment is sufficient to satisfy the average throughput re-

quirement of (s, d) traffic but may not be sufficient for the QoS of the real time traffic.

For this we do the following. First, from the above assigment of UDP and TCP traffic

on route p we assign a number of UDP and TCP flows of (s, d) to the route p. Since we

want to send the traffic of a particular flow on a single route (it is advisible not to split

the traffic of a particular flow on more than one route), we may need to change a little

bit, the fraction αp(s, d) of UDP and TCP traffic on route p so as to obtain an integral

number of UDP and TCP flows of (s, d) on p. In the process, if an αp(s, d) is very small,

one may just make it zero. This can compromise a bit on the optimality of the solution


but due to other benefits we would prefer such a solution.

Once the UDP and TCP flows of (s, d) to be routed on route p have been

identified, we can compute the fraction of slots nU(i, j, s, d) needed on a link (i, j) on

route p to satisfy the QoS of those CBR and VBR connections via the methods detailed

in Section 4.2. Finally we assign n(i, j, s, d)�= max(nU(i, j, s, d), n

′(i, j, s, d)) fraction

of slots of link (i, j) for the traffic of (s, d) passing through it. Also, we give priority

to the real time traffic of (s, d) over the TCP traffic of (s, d) on each link (i, j). Thus,

since n(i, j, s, d) ≥ nU(i, j, s, d), the QoS of the real time traffic will be satisfied. Also,

because n(i, j, s, d) ≥ n′(i, j, s, d), the long term average rate of TCP and UDP traffic of

(s, d) on (i, j) will be satisfied and hence the TCP traffic gets its share of throughput on

each link (i, j). Often n(i, j, s, d) will be much less than nU(i, j, s, d) +λT (s,d)αp(s,d)

E[r(i,j)](the

number of slots needed on link (i, j) to satisfy the QoS of TCP and UDP flows of (s, d)

if we do not give priority to UDP flows) and hence this multiplexing of UDP and TCP

traffic of (s, d) on (i, j) provides significant gains in resource requirement. At present

the traffic mix in Internet is such that the real time traffic makes less than 10% of the

overall traffic. It is likely to be so in near future. In that case n(i, j, s, d) will most likely

be close to n′(i, j, s, d) and hence the optimal solution obtained in Chapter 3 will not

need to be modified.

In Fig. 4.2 we show our overall QoS architecture when there are three

nodes. Node i has NiU UDP flows and NiT TCP flows entering the Mesh. Flows from

nodes 1 and 3 enter node 2. At node 2 the flows from the three nodes are stored in

separate queues and are provided their required throughput via WRR. In each queue

the UDP packets are given priority over the TCP packets. The TCP flows are controlled

via RED algorithms at their entry nodes.

We comment on the scalability of our overall scheme. At each node we

need one queue for each source node whose traffic is passing through this node. In a

mesh the number of nodes will not be large (it will be a few tens of nodes) and hence


Node

Node 1

Node 3

2

queueson threeWRR

N TCP Connections

N UDP Connections

TCP Connections

N UDP Connections

2U

3U

2T

1T

1UN

N TCP Connections

UDP Connections

N3T

Figure 4.2: Overall Scheduling of TCP and UDP flows to provide QoS. UDP flows getpriority over TCP flows in each queue. RED applied on TCP flows at entry nodes. (Wehave separated UDP flows and TCP flows in each queue by a dotted line indicatingeach queue might be implemented via two queues.)

even in a large overall network this will not cause any problem. We also commented

earlier that the RED control for TCP traffic can be used only at the node it enters. Also

as in [22] and [30], we could classify TCP connections according to the mean window

size (equivalently, their probability of loss) they need. Thus, even at the entry node

we do not need to provide different RED parameters for each TCP but rather for each

TCP class. The number of TCP classes needed will not be more than twelve (as shown

in [22], [30] although one can work with even fewer). Furthermore, the computational

complexity of our algorithms is rather low (at least if we ignore the nonlinear opti-

mization in Chapter 3) and hence these can be implemented easily in real time for a

reasonably large network.

4.5 Simulations

We consider the network shown in Fig. 4.3. There are 20 SSs and 1 MBS

(labeled 0) The network characteristics are summarized in Tables 4.1 and 4.2. The frame

duration is 10ms and scheduling is done over 3 frames. The channel rates of the chan-

nels vary randomly from one scheduling period (of 3 frames) to another independently.

In Fig. 4.3, the numbers written on the links represent the the link rates in the following


way, if the number is x , then links rate is 48 ∗ x bytes per mini slot. We consider the

Figure 4.3: Network used in simulations

transmission constraints (3.7). For the uplink, from each MSS node data needs to be

transmitted to the MBS. For the downlink, MBS will transmit data to MSSs. Each VBR

source is a Markov modulated source with transition matrix

⎛⎜⎜⎜⎜⎜⎜⎝0.4 0.3 0.2 0.1

0.2 0.4 0.2 0.2

0.2 0.3 0.2 0.3

0.1 0.4 0.2 0.3

⎞⎟⎟⎟⎟⎟⎟⎠and with rates 73 kbps, 146 kbps, 293 kbps and 586 kbps in the four states for a source

with 256 kbps. For a source with 128 kbps in each state, the rate is half of that of a 256

kbps source. The packet sizes of the CBR connections are 100 Bytes, of the VBR connec-

tions are 1500 Bytes and of the TCP connections are 1000 Bytes. The TCP connections

also have an extra propagation delay of 0.05 sec.


Figure 4.4: Number of TCP connections

Figure 4.5: Number of UDP connections

Figs. 4.4 and 4.5 provides the details on the number of TCP and UDP flows respectively

used in the example. The first 20 columns in Fig. 4.4 indicate the number of TCP flows

transmitting data from 20 SSs to the MBS. The next 20 columns indicate the number in

the downstream. There are 5 classes of TCP flows depending upon their throughput

requirements which are 16, 32, 64, 128, and 256 Kbps respectively. The entry (i, j) in

Fig. 4.4 inidcates number of TCP connections of type i at node j. Similarly the number

of UDP connections are shown in Fig. 4.5. Theseare all sending traffic in upstream.

There are 5 classes of UDP connections depending upon their requirement. The first

3 represent CBR traffic sending data at rates 16, 32, 64 Kbps respectively. The last 2

classes represent VBR traffic sending data at mean rates 128 and 256 Kbps respectively.

The ack traffic in each queue is also given higher priority (along with

the CBR and the VBR traffic) than the TCP data packets. From αp(s, d), we identified

the CBR, VBR and TCP connections of (s, d) that will use the route p. Also given the

n(i, j) for each link (i, j), using the algorithm in section 3.4.1 we obtain the allocation

of slots to different links in each scheduling period of three frames. Finally we obtain

via the WRR, the bandwidth allocation on each link for the traffic of each (s, d) passing

through it and also the mean window size for each TCP connection.

The results obtained from these simulations are provided in Tables 4.3,


Table 4.1: Physical Layer ParametersBandwidth 20 MHz

Number of Subcarriers 256Frame Duration 10ms

No. of OFDM symbols / frame 844No. of OFDM symbols / minislot 4

Total No. of minislots / frame 211No. of minislots / frame for uplink Centr. Sched. 194

Table 4.2: Burst Profilesburst Coding Uncoded Uncoded

profile Modulation Rate bytes per bytes perNo. OFDM symbol minislot

1 QPSK 1/2 24 96

2 QPSK 3/4 36 144

3 16QAM 1/2 48 192

4 16QAM 3/4 72 288

5 64QAM 2/3 96 384

6 64QAM 3/4 108 432

4.4 and 4.5. Table 4.3 provides the maximum drop probability of 0.0 for the CBR and the

VBR connections while the maximum average delays are 28.01 and 28.09 msec for CBR

and VBR flows respectively. Tables 4.4 and 4.5 provide the error= Achieved average

throughput - minimum required throughput for the different TCP connections. From

these results we see that the QoS of the real and data traffic is being met very well. This

has happened when most of the links are heavily loaded.

We have simulated several other networks with different traffic mixes

and have made similar observations.


Table 4.3: Performance of UDP FlowsCBR Flows VBR Flows

Max Avg Delay 28.01 ms 28.09 msMax Drop Prob 0.000% 0.000%

Table 4.4: Performance of TCP Flows when maximum window size is set to E[w]Percent Error Fraction of Flows

< -20 0.0079-20 to -15 0.0191-15 to -10 0.092-10 to -5 0.0408-5 to 0 0.06120 to 5 0.0736

5 to 10 0.122410 to 15 0.147315 to 20 0.1115

> 20 0.3956

Table 4.5: Performance of TCP Flows when E[w] window is controlled by REDPercent Error Fraction of Flows

< -20 0.052-20 to -15 0.034-15 to -10 0.041-10 to -5 0.058-5 to 0 0.0830 to 5 0.1133

5 to 10 0.08610 to 15 0.08715 to 20 0.060

> 20 0.382


4.6 Admission Control

To provide QoS guarantees to different connections, admission control

is required: if a new connection request arrives and the network does not have suffi-

cient resources to provide it the QoS requested, the service provider should reject the

request. A more relaxed rule would be: limit admission control decision (to reject) to

applications with real time hard constraints, e.g., IP telephony and video conferencing.

For other requests (e.g., audio/video streaming, web browsing) if there are insufficient

resources, one can provide throughput less than requested by them. Of course here

also a service provider may decide to reject an admission request if he is unable to pro-

vide beyond a certain fraction of requested throughput. In the following we will limit

ourselves to the first option: reject a request if its QoS cannot be satisfied.

Our admission control rule is simple and based on only the mean through-

put requirements of the new TCP/UDP connection (for the VBR connection it is the

equivalent BW). When a new connection request comes (say at (s, d)), it is sent to the

MBS. The MBS chooses one of the routes p for which αp(s, d) > 0 at present (picking p

with highest αp(s, d) will be desirable). Then if λ bits/slot is the mean throughput re-

quirement of the new request and (i, j) is a link on p, we compute n̄(i, j) = λ/E[r(i, j)],

the number of slots required on link (i, j) to satisfy the mean throughput requirement.

These requirements are summed up for all (i, j) on p and the MBS decides if it has the

necessary number of slots (beyond the requirements of existing connections) to sup-

port the new request. If it has, the request is accepted. If not, then the MBS tries other

routes with αp(s, d) > 0 till it gets one where the requirements are satisfied. If not, the

request is denied. On first thought this procedure may look strange because one may

expect that a route p on which αp(s, d) = 0 may also satisfy the QoS requirements. But

this is unlikely because our routing and scheduling algorithm picks ’good’ routes to

send the traffic of each (s, d). Of course the traffic of a new UDP connection will be

given priority over the TCP connections of (s, d) on the route selected.


It is possible that if a routing and scheduling decision is being run for

sometime, due to new connection arrivals or departures and other reasons, the cur-

rent routing/scheduling may not be efficient. Thus, the MBS will occasionally run the

routing and scheduling algorithm of Chapter 3 to reroute/reschedule the total traffic

of different (s, d) pairs. It may periodically do it after every (say) M frames and/or

when one of the following events happens:

(a) A node/link fails.

(b) The E[r(i, j)] of some links (i, j) and/or the mean traffic requirements λ(s, d) of

some (s, d) pairs change drastically.

(c) The admission control policy has been blocking too many calls in recent past.

Chapter 5

Mobility Support

5.1 Introduction

IEEE 802.16d and the previous versions the standard were designed for

fixed nodes. However, in 802.16e mobility is also being supported. The scenario en-

visaged is that most of the traffic will be carried by the fixed nodes but some mobile

nodes may also carry traffic. Although 802.16e is for P-MP mode only, considering that

limited mobility will eventually be supported in the mesh mode also, we extend our

QoS architecture to this case.

QoS has been studied in Adhoc networks also and has been found to be

a rather challenging goal [17], [41], [44]. Our current scenario will have most of the

nodes fixed and hence supporting QoS on a small fraction of mobile nodes will not

be that difficult. We assume that at the most 15 percent of the total traffic at a time is

carried by the mobile nodes. In the following we first describe our mobility model and

then show how we accommodate mobile nodes in our setup.

5.2 Mobility model

There are various theoretical mobility models available in literature ([45],[46])

. One of the most versatile and natural model is the random work model which has

been used in various studies ([46]). We will briefly describe this model and then will

54

Chapter 5. Mobility Support 55

incorporate it in our study.

Figure 5.1: Random walk model

We specify the geographical area of the mesh (See Fig. 5.1). Let the ge-

ographical area of the mesh be the rectangular area shown in Fig. (5.1) along with

the Mesh BS and the other fixed SS s .We consider the motion of one mobile SS de-

noted by the point X in the figure at (say) time zero. It chooses a direction by random

variable θ1 taking values in (0, 360). Then it chooses a speed S1 with a distribution

within values [0,α] , α > 0. It moves in direction θ1 with speed S1 for a random time

t1. Then it changes direction to theta2 and chooses speed S2 and moves accordingly

till time t2 and so on. We assume that {θ1,θ2 ,....} , {S1,S2,S3,.....} and {θ1,θ2 ,....} form

iid sequences, independent of each other. This way the mobile node traces a random

walk in �2 with a typical realization in the figure . At some random time it may leave

the Mesh and possibly enter a neighboring Mesh. Of course it is possible that the node

may stay in the Mesh but may close all its connections. We will be interested in the mo-

bile node until it has at least one connection left and the node is in the current Mesh’s

geographical area.

At a time there may be multiple mobile nodes active in a Mesh. Each


mobile node will be assumed to travel as a random walk, each random walk indepen-

dent of other. In the next section we look at how a mobile node can transmit in a Mesh.

Next we will show how to provide its QoS.

5.3 Providing QoS to mobile nodes

Let us discuss how a mobile node will transmit its data in the uplink

and/or downlink. When a connection (say the first on the mobile node) request arrives

at a mobile node it will choose a neighbor with the strongest link. If that happens to

be the MBS then it can directly communicate with it. If the chosen neighbor is some

other node then it sends its data (if uplink) to that neighbor. In turn that neighbor will

send this data along with the other data it receives to the MBS. Since the mobile node

is moving, with time the strongest neighbor may change. But that in principle causes

no problem except that with time the mobile node will keep transmitting to a different

node. This possibility is also there in our optimal setup of fixed nodes in chapter 3.

The uplink data from the mobile node could be using TCP and/or UDP.

Next, let us discuss the down-link traffic. If at a time the mobile node

is communicating via neighbor (say) SS1, the MBS will be sending it packets by first

sending them to SS1. SS1 will then transmit directly to the mobile node. But it can

happen that SS1 may get some packets for the mobile node, and the mobile node has

already moved out of the neighborhood of SS1 (say now its neighbor is SSm ). One

option is that these packets can be sent from SS1 to SSm. But this will require that SS1

knows now that it needs to send packets to SSm. By the time SSm gets these packets,

the mobile node might move out of the neighborhood of SSm too. Therefore, we will

consider the option that the packets SS1 receives for the mobile node after it moves out

of the neighborhood, will be discarded by SS1. In case of UDP traffic these packets will

simply be dropped. In case of TCP traffic , these will be retransmitted by the source.

We will see that with proper routing and scheduling of traffic, this is a viable option


atleast in an urban scenario where the speed of the mobile station may not be very

large.

Next we discuss how to provide QoS to the traffic generated by (for)

the mobile nodes. If we do not provision for this traffic but the mobile traffic is very

small (say < 5 % of the total traffic at any given time), we may not have any problem.

At each node, this extra traffic needs to be taken care of according to its class: Voice

, Video, TCP with minimum throughput requirement. However, if this traffic may be

(say) upto 20 percent of the overall traffic , we may need to provision resources for

this. In our optimization problem in chapter 3 , we solve for routing and scheduling

by increasing the traffic requirements of each (s,d) by 0.20 %.

5.4 Simulations

We have simulated the network in the figure Fig. 4.3. Number of flows

admitted in the network are tabulated in figures Fig.4.4 and Fig. 4.5. There are 947

static TCP and UDP flows in the network. There are 160 mobile flows in the network.

Out of these there are 60 UDP(CBR) flows. They transmit at the rates 16, 32, 64 Kbps,

20 flows in each class. The 100 TCO flows are divided equally in five classes which

have the minimum throughput requirements of 16, 32, 64, 128 and 256 Kbps. The QoS

received by the different flows are summarized in Tables 5.1 - 5.1. From these one sees

that the QoS of CBR flows is easily met.


Table 5.1: Performance of static UDP FlowsCBR Flows VBR Flows


Table 5.2: Performance of mobile UDP FlowsCBR Flows

Max Avg Delay 41.01 msMax Drop Prob 0.006%

Table 5.3: Performance of TCP static flowsPercent Error Fraction of Flows

< -20 0.070-20 to -15 0.014-15 to -10 .014-10 to -5 0.033-5 to 0 0.0290 to 5 0.049

5 to 10 0.02310 to 15 0.02815 to 20 0.023

> 20 0.735

Table 5.4: Performance of TCP mobile flowsPercent Error Fraction of Flows

< -20 0.060-20 to -15 0.066-15 to -10 0.037-10 to -5 0.009-5 to 0 0.0090 to 5 0.047

5 to 10 0.04710 to 15 0.15015 to 20 0.137

> 20 0.433

Chapter 6

QoS through WLAN-WiMax

interconnected network

6.1 Introduction

IEEE 802.11 based WLAN is ubiquitous. This technology has matured

over the years and its equipment has become quite cheap. Thus not only it is being

used as a WLAN in offices and homes everywhere, numerous ([48]) experiments are

being conducted around the world to form city-wide mesh networks based on 802.11.

However, due to the CSMA/CA based MAC, it is also being acknowledged that at

least in its current form its performance in a mesh environment (when there three or

more hops) is not satisfactory. In particular TCP, the most prevalent transport layer

protocol performs very poorly on such a mesh([47]).

Given the above scenario and the need to have WMAN(Wireless Metropoli-

tan Area Network), an attractive scenario in the future will be that the last hop of the

network will be an 802.11 based WLAN which will be connected to a WiMax network

to access the broadband Internet. The WiMax network might be P-MP single hop net-

work or a mesh network as we have been considering in the report. Although in near

future P-MP deployment is expected, keeping in view the futuristic goals and the par-

ticular focus of this report, we will limit ourselves to a WiMax mesh. Thus, in this

59

Chapter 6. QoS through WLAN-WiMax interconnected network 60

chapter we extend our end-to-end QoS architecture studied in the report so far to a

network where atleast some of the end users are connected to ths SSs of WiMax via an

802.11 WLAN. There may be one or more APs (Access points) of 802.11 directly con-

nected via wires to some SSs. Each of the APs could be connected to one or more MSs

(mobile stations) with in its building. The MSs may be communicating with the out-

side world via TCP and UDP connections with VoIP, video stream and/or Interactive

data applications which may require end-to-end QoS.

The chapter is organized as follows. In Section 6.2, we briefly describe

the 802.11 MAC. In section 6.3, we provide a simplified model of an 802.11 WLAN

based on the theoretical and simulation studies carried out in ([49],[50]). In Section

6.3.1, we use the model of section 6.3 to provide QoS to connections across the WLAN-

WiMax mesh. We also provide simulation data to support our claims.

6.2 802.11 MAC

The 802.11 standard specifies a common medium access control (MAC)

Layer, which provides a variety of functions that support the operation of 802.11-based

wireless LANs. In general, the MAC Layer manages and maintains communications

between 802.11 stations (radio network cards and access points) by coordinating access

to a shared radio channel and utilizing protocols that enhance communications over a

wireless medium. Often viewed as the ”brains” of the network, the 802.11 MAC Layer

uses an 802.11 Physical (PHY) Layer, such as 802.11b or 802.11a, to perform the tasks

of carrier sensing, transmission, and reception of 802.11 frames.

Before transmitting frames, a station must first gain access to the medium,

which is a radio channel that the stations share. The 802.11 standard defines two

forms of medium access, distributed coordination function (DCF) and point coordi-

nation function (PCF). DCF is mandatory and based on the CSMA/CA (carrier sense

multiple access with collision avoidance) protocol. With DCF, 802.11 stations contend


for access and attempt to send frames when there is no other station transmitting. If

another station is sending a frame, the stations wait until the channel is free.

As a condition to accessing the medium, the MAC Layer checks the

value of its network allocation vector (NAV), which is a counter resident at each station

that represents the amount of time that the previous frame needs to send its frame. The

NAV must be zero before a station can attempt to send a frame. Prior to transmitting

a frame, a station calculates the amount of time necessary to send the frame based on

the frame’s length and data rate. The station places a value representing this time in

the duration field in the header of the frame. When stations receive the frame, they

examine this duration field value and use it as the basis for setting their corresponding

NAVs. This process reserves the medium for the sending station.

An important aspect of the DCF is a random back off timer that a station

uses if it detects a busy medium. If the channel is in use, the station must wait a random

period of time before attempting to access the medium again. This ensures that multi-

ple stations wanting to send data don’t transmit at the same time. The random delay

causes stations to wait different periods of time and avoids all of them sensing the

medium at exactly the same time, finding the channel idle, transmitting, and colliding

with each other. The back off timer significantly reduces the number of collisions and

corresponding retransmissions, especially when the number of active users increases.

With radio-based LANs, a transmitting station can not listen for collisions while send-

ing data, mainly because the station can not have it is receiver on while transmitting

the frame. As a result, the receiving station needs to send an acknowledgement (ACK)

if it detects no errors in the received frame. If the sending station does not receive an

ACK after a specified period of time, the sending station will assume that there was a

collision (or RF interference) and retransmits the frame.

For supporting time-bound delivery of data frames, the 802.11 standard

defines the optional point coordination function (PCF) where the access point grants


access to an individual station to the medium by polling the station during the con-

tention free period. The stations can not transmit frames unless the access point polls

them first. The period of time for PCF-based data traffic (if enabled) occurs alternately

between contention (DCF) periods.

The access point polls stations according to a polling list, then switches

to a contention period when stations use DCF. This process enables support for both

synchronous (i.e., video applications) and asynchronous (i.e., e-mail and Web brows-

ing applications) modes of operation. since PCF is actually not being implemented in

the current 802.11 products, we will limit ourselves to the DCF mode.

6.3 Fluid model of 802.11 MAC

We will first consider the case where several TCP connections at various

MSs are downloading files. The connections will be initially considered persistent.

Generalization to ON-OFF TCP connections will be immediate as done before. Most

of the TCP connections download files only, the uploading is not that common. Thus

we will not consider uploading in this report. We have observed in [51], that if even

one TCP connection is downloading a file (assuming it has long enough window size)

then in 802.11b the UDP traffic does not get enough throughtput and even one V0IP or

video stream will not be able to get its QoS. Thus, it was found essential to use 802.11e

where due to EDCA, the voice and video traffic gets priority and hence it is possible to

support QoS of several voice and video streams. Accordingly, when we consider voice

and video streams also we will limit ourselves to 802.11e. Till then, for TCP downloads

only we will consider 802.11b, which is so far the mostly widely used WLAN.

Let there be N TCP connections downloading files (see Fig. 6.1). Some of

these connections may be originating at the same MS. In the following we will assume

that each TCP connection originates at a different MS. In [50] it is seen that this will

have no impact on the TCP throughput computation. We assume that connection i has


Figure 6.1: An 802.11 LAN downloading data files

packet size Si and propagation delay (delay outside the WLAN) Δi.Let the maximum

window size of connection i be Wmax(i). Initially we assume that there are no pocket

drops in the network outside the WLAN. We also assume that there is sufficient buffer

at the AP to store∑N

i=1 SiWmax(i) bits so that there are no tail drops at the AP queue.

Even though some packets get dropped due to collisions in the MAC, in the current

scenario that probability is very low. This is because in our setup, AP is the bottleneck

queue and a few MSs will have an ACK waiting at their queues to be transmitted. This

happens independently of N . Thus, then the TCPi will have its window size Wmax(i)

most of the time. Therefore we will assume that each TCP has a fixed window size. We

also assume that collectively, the TCP connections can transfer sufficient data to the AP

so that the AP queue is never empty.

It has also been found in [50] theoretically and verified via simulations


that the total TCP throughput (equal to the throughput of the AP queue)is independent

of N (as long as N ≥ 3). This throughput (in bps) does depend upon the packet size

Si, but not significantly. We denote this throughput as λ bps. Also, it is shown in [50]

this system will have stationary distribution. Let E[S] be the mean sojourn time of a

packet in the AP queue under stationarity. This is shown to be approximately same

for packets of all connections. Then,( see Fig. 6.1), the throughput λi packets / sec of

connection i will be approximately (this is fluid approximation)

Wmax(i)

E[S] + Δi

packets / sec. (6.1)

The E[S] in the above expression depends on N , Si s, Δi s and can be computed from

N∑i=1

Wmax(i)

E[S] + Δi

Si = λ (6.2)

Now equation (6.1) will give the throughput λi for i = 1, 2, . . . , N.

If in the rest of the network (outside WLAN), packets of connections i are

being dropped independently with probability pi, then the window size of connection

i will change with time. Let E[W (pi)] denote its mean window size under stationarity.

Then using E[W (pi)] instead of Wmax(i) in equation (6.1) will provide a reasonable

approximation of the throughput λi. If we need to provide certain throughput λi to

TCPi for each i as QoS, then we can use equations (6.1) and 6.2 to provide the E[Wi]

we need for this requirement. To obtain needed E[Wi], we should drop packets of TCPi

with a probability pi which can be computed.

6.3.1 SimulationNetwork Scenario

We have simulated the network in the figure Fig. 6.2. It has one router connected to an

AP via a wired connection. There are 5 MSSs connected to the AP. 3 TCP connections

pass through the router only and 10 TCP connections pass through the router and the


WLAN. There are 5 TCP connections which are passing through the WLAN only to

the MSS. The 3 TCPs not passing through the WLAN require 1000Kbps each, the 5

TCP connections passing only through the WLAN require 900 Kbps each and 5 TCP

connections passing through the router and the AP require 600 Kbps while the other 5

TCP connections require 1200 Kbps. Packet size is 1500 bytes.

We have used priority queue as interface queue to let control packets have more pref-

erence. The queue has a maximum capacity of 3000 packets.

Calculations

Delay at the Router queue: 30 ms

Delay assumed from AP queue: 30ms

For 600Kbps flows from server 1 through router:

E[w1] = (600000/(1500 ∗ 8)) ∗ (0.03 + 0.03)

= 3

For 1200Kbps flows from server 1 through router:

E[w2] = (1200000/(1500 ∗ 8)) ∗ (0.03 + 0.03)

= 6

For 900Kbps from server 2 directly to AP:

E[w3] = (900000/(1500 ∗ 8)) ∗ (0.03)

= 2.25

∼ 2


For 1000Kbps flows among wired clients through router:

E[w4] = (1000000/(1500 ∗ 8)) ∗ (0.03)

= 2.5

∼ 2

Simulation results

Simulation results are provided in Table 6.3. From these one sees that

the QoS of TCP downlink flows is easily met in 802.11 based network( The fluid model

of 802.11 MAC).

We use the above fluid approximation of WLAN in the next section to

provide QoS in a WLAN-WiMax mesh interconnected network.

6.4 QoS through an interconnection of WLAN and WiMax

mesh

Consider a WiMax mesh network considered so far in this report. We

have been considering the users directly connected to the SSs. Now we assume that

atleast at some of the SSs, some users are connected through a 802.11 WLAN ( see Fig

6.4).

Let us assume SS1 is connected via a wired network to the AP of an

802.11 WLAN. Let N MSs are each downloading a file from the MBS or external inter-

net. Let the route selected from the MBs to the MSS1 has three other nodes on the way.

In Fig. 6.5 we draw the network seen by the flows from the MBS to the AP at the SS1.

The output link at the MBS will use RED control. There may be other UDP and TCP

connections downloading (and/or uploading) data at SS1. Let λi packets per second be


the minimum throughput requirement and Si bits be the packet size of the ith TCP con-

nection. At the LAN we will assume that the conditions specified in Section 6.3 hold.

Thus, we know the total download traffic requirements of all the connections at SS1.

Now as in chapter 3, we do routing and scheduling in the network such that sufficient

resources are available in the network to satisfy its end-to-end QoS requirements. We

will also assume that the∑

i=1:N(λiSi) ≤ λ. where λ is the AP throughput available. If∑i=1:N(λiSi) ≥ λ then certainly this traffic demand cannot be met. If

∑i=1:N(λi Si) < λ

then we can increase some or all λi so as to attain equality. A fair way to increase would

be to aim for αλi, for alli, α ≥ 1. such that∑

i=1:N(λi Si) = λ. Let the total downlink

throughput requirement of SS1 traffic be C bps. Suppose we have done routing and

scheduling such that a pipe of C bps has been created from MBS to SS1. This could

have been via multiple routes but for convenience we assume it is via a single route

which is depicted in Fig 6.4 (If there are multiple routes, each can be considered sep-

arately in the same way). Now, as before, the queue at MBS, dedicated to this traffic

will be RED controlled. We aim for a queue length at this queue such that there will

be δ1 sec delay in this queue. Then considering ith TCP connection at the AP, its RTT

will be δ1 +5Si

C+ E[S] where Si

Cis the transmission delay at each of the queues and

E[S] is the mean sojourn time in the AP queue (actually we should also add the delay

experienced by the ACKs : in our set up it will be negligible). Thus from equation (6.1)

λi =E[W (pi)]

δ1 +5Si

C+ E[S]

, i = 1, 2, . . . N. (6.3)

where E[S] is computed from equation (6.2). Here pi is the probability with which

TCPi packets will be dropped in the MBS RED queue. We select pi such that equations

(6.2) and (6.3) are satisfied (in equations (6.2) and (6.3) there are N + 1) unknowns

E[w(pi)] i = 1, 2, . . . , N and E[S] for N + 1 equations

We will see in the next section that the above scheme to provide QoS in

a WLAN-WiMax mesh networks does indeed provide the required QoS.


6.5 Simulation Example

We have simulated the network in the Fig.6.6. There 20 MSSs in the

given network. 10 MSSs have APs connected to them. All APs are connected with

mobile clients which are downloading files through TCP connections. For other MSSs

(which do not have APs connected to them), the downlink TCP flows are terminated

at the MSS itself. Number of TCP uplink and UDP uplink flows are the same as we

simulated earlier in Section 4.5. Simulation results are provided in Tables 6.1, 6.2 and

6.3.


Table 6.1: Performance of UDP FlowsCBR Flows VBR Flows


Table 6.2: Performance of TCP Flows when maximum window size is set to E[w]Percent Error Fraction of Flows

< -20 0.0045-20 to -15 0.009-15 to -10 0.0133-10 to -5 .00566-5 to 0 0.04080 to 5 0.0453

5 to 10 0.060010 to 15 0.085015 to 20 0.1530

> 20 0.5850

Table 6.3: Performance of TCP Flows when E[w] window is controlled by REDPercent Error Fraction of Flows

< -20 0.0430-20 to -15 0.0340-15 to -10 0.0385-10 to -5 0.0306-5 to 0 0.03850 to 5 0.0385

5 to 10 0.043010 to 15 0.041915 to 20 0.0374

> 20 0.9862


Figure 6.2: WLAN scenario


Figure 6.3: Simulation results


Figure 6.4: Internet of WLAN and Wimax mesh

Figure 6.5: Network seen by the flows from the MBS to the AP


Figure 6.6: Interconnected Network of WLAN and Wimax mesh

Chapter 7

Summary and Future directions

7.1 Summary

In this report we have designed efficient, fair and practically implementable algorithms

for routing and centralized scheduling in IEEE 802.16 mesh networks. We provide end

to end QoS to different flows in the network. For this, we first provide an optimal and

fair joint routing and scheduling solution to satisfy the aggregate mean traffic require-

ments of different source-destination pairs. Then we do scheduling at individual links

to provide QoS to each flow. For this, we have handled UDP and TCP traffic separately

at first and then jointly. Our algorithms are able to provide QoS to real and nonreal time

individual flows efficiently and fairly. First we consider the multi-path routing, which

has inherent advantage of multipath diversity.Later on we also consider tree routing

because it is a preffered routing structure in the 802.16 standard. We have also pro-

vided an admission control policy which is an important part of any QoS framework.

We have extended this frame work to provide limited mobility support also.

Finally, we also considered an interconnection of WLAN and WiMax net-

works and showed that the our QoS architecture can provide QoS even in this setup.

74

Chapter 7. Summary and Future directions 75

7.2 Future Directions

The multihop wireless networks is a very challenging and difficult current area of re-

search. Following are some of the directions of research that can be further explored:

1. Link scheduling itself is a hard problem. We consider the link scheduling in cen-

tralized manner. It becomes even more challenging if it needs to be done in a

distributed fashion.

2. One needs to obtain good non-linear optimization algorithms which can be used

in large networks.

3. Our approximations for mean delays and mean queue lengths work reasonably

only for one or two links. To be able to provide good QoS it is important to

obtain good approximations of these quantities. Also, once the approximations

are obtained, it will be important to develop non-linear optimization algorithms

to optimize the resulting cost functions.

4. We have considered centralized routing and scheduling problem. It will often

be needed that these are obtained and implemented by different nodes in a dis-

tributed fashion.

5. We have considered fixed transmit power of different nodes. Allowing power

control opens up several new problems.

6. Cross layer design issues are important in this set-up. Scheduling and routing

themselves involve MAC and routing layer. But physical layer issues come up if

power control is also included in the problem.

Bibliography

[1] Air Interface for Fixed broadband Wireless Access Systems, IEEE STD 802.16, Oc-

tober 2004.

[2] Air Interface for Fixed and mobile broadband Wireless Access Systems”, IEEE

P802.16e/D12, February 2005.

[3] R. K. Ahuja, T. L. Magnanti and J. B. Orlin, “ Network flows: Theory, Algorithms

and Applications”, Englewood Cliffs: Prentice Hall, 1993.

[4] I. F. Akyildiz, X. Wang and W. Wang, “ Wireless mesh networks: A survey”, Com-

puter Networks,Vol 47, No.4, 2005, pp. 445-487.

[5] M. Alichery, R. Bhatia and L. Li, “Joint channel assignment and routing for

throughput optimization in multiradio wireless Mesh networks”, in Proc. Conf. Mo-

bicom, 2005.

[6] M. Andrews and L. Zhang, “ Routing and scheduling in multihop wireless net-

works with time-varying channels”, Proceedings of the 15th Annual ACM-SIAM Sym-

posium on Discrete Algorithms, Jan 2004.

[7] C. Barakat, E. Altman and W. Dabbous, “ On TCP performance in heterogeneneous

networks: A survery”, IEEE Communication Magazine, Vol 38, Jan 2000, pp. 40-46.

[8] M. Cao, V. Raghunathan and P.R. Kumar, “ A tractable algorithm for fair and effi-

cient uplink scheduling of multi-hop WiMax mesh networks”, Preprint, To appear in

76

BIBLIOGRAPHY 77

Proceedings of WiMesh 2006: Second IEEE Workshop on Wireless Mesh Networks, Sept.

2006, Reston, VA.

[9] M. Cao, W. Ma, Q. Zhang, X. Wang and W. Zhu, “ Modelling and performance

analysis of the distributed scheduler in IEEE 802.16 mesh mode”, ACM MobiHoc,

2005.

[10] D. Z. Chen, O. Daescu, Y. Dai, N. Katoh, X. Wu and J. Xu, “Efficient algorithms

and implementations for optimizing the sum of linear fractional functions with

applications”, J., Combinatorial Optimization, Vol 9, 2005, pp. 69-90.

[11] W-P. Chen, C-F Su, R. Rabbat and T. Hamada, “ Radio resource management un-

der fixed mobile convergence architecture”, .

[12] W. Dinkelbach, “ On nonlinear fractional programming”, Management Science,

1967.

[13] M. Ergen, S. Coleri and P. Varaiya, “QoS aware adaptive resource allocation tech-

niques for fair scheduling in OFDMA based broadband wireless access”, IEEE

Transactions on Broadcasting, Vol. 49, No. 4, Dec 2003.

[14] S. Floyd and V. Jacobson, “Random early detection gateways for congestion

avoidance”, IEEE/ACM Trans. Networking, Vol. 1, 1993, 397-413.

[15] L. Georgiadis, M.J. Neely and L. Tassiulas, “ Resource allocation and cross-layer

control in wireless networks”, Foundations and Trends in Networking, 2006, Vol 1,

No.1, pp.1-144, Now Publishers.

[16] A. Gupta and V. Sharma, “A Unified approach for analyzing persistent, non-

persistent and ON-OFF TCP sessions in the Internet”, Performance Evaluation, Vol.

63, 2006, 79-98.

BIBLIOGRAPHY 78

[17] R. Gupta, J. Musacchio and J. Walrand, “ Sufficient rate conditions for QoS flows

in adhoc networks”, Preprint, 2004.

[18] M. Hawa and D. W. Petr, “Quality of service scheduling in cable and broadband

wireless access systems”, 10th IEEE International Workshop on Quality of Service, May

2002, pp. 247-255.

[19] C. Hoymann, “Analysis and performance evaluation of the OFDM-based

metropolitan area network IEEE 802.16”, Computer Networks, Vol 49, 2005, pp. 341-

363.

[20] I. Hsu and J. Walrand, “ Admission control for multiclass ATM traffic with over-

flow constraints”, Computer Networks and ISDN Systems, Vol. 28, 1996, 1739-1751.

[21] H. Jiang, W. Zhuang, X. Shen, A. Abdrabou and P. Wang, “Differentiated ser-

vices for wireless mesh backbone”, IEEE Communication Magazine, Vol 44, No.7,

July 2006, pp. 113-119.

[22] V. Kamble and V. Sharma, “ A simple approach to provide QoS and fairness in In-

ternet”, in Proc. International Conf. on Signal Processing and Communications (SPCOM

2004), Bangalore, Dec. 2004.

[23] D. Kim and A. Ganz, “ Fair and efficient multihop scheduling algorithm for IEEE

802.16 BWA systems”, in IEEE Broadnets’05 Boston, 2005.

[24] M. Kodialam and T. Nandagopal, “Characterizing achievable rates in wireless

multi-hop networks: The joint routing and scheduling problem”, ACM Mobicom,

September 2003.

[25] M. Kodialam and T. Nandagopal, “Characterizing the capacity region in multi-

radio, multichannel wireless mesh networks”, in Proc. ACM Mobicom, 2005.

BIBLIOGRAPHY 79

[26] X. Lin, N. B. Shroff and R. Srikanth, “A tutorial on cross-layer optimization in

wireless networks”, IEEE Journal on Selected Areas in Communication, Vol 24, August

2006, pp. 1-12.

[27] J. Pandhye, V. Firoiu, D. Towsley and J. Kurose, “Modelling TCP throughput : A

simple model and its empirical validation”, ACM Proc. SIGCOMM’98, 1998.

[28] V. Raghunathan and P. R. Kumar, “ A counter-example in congestion control of

wireless networks”, ACM Conference MSWiM’05.

[29] S. Ramanathan and E. L. Llyod, “Scheduling algorithms for multihop radio net-

works”, IEEE/ACM Transactions on Networking, Vol. 1, Apr. 1993, pp. 166-177.

[30] V. Reddy, V. Sharma and M. B. Suma, “Providing QoS to TCP and real time con-

nections in the Internet”, Queueing Systems, Vol. 46, 2004, 461-480.

[31] S. R. Sandeep, “Joint routing and scheduling for multihop wireless networks”,

M.E. Thesis, Electrical Communication Engineering Dept, Indian Institute of Science,

Bangalore June 2006, (Also presented in poster session of Conference on Stochastic

Networks, Urbana, IL, June 2006).

[32] V. Sharma and P. Punyaslok, “ Stability and analysis of TCP connections with RED

control and exogenous traffic”, in Queuing Systems, Vol 48, 2004, 193-235.

[33] H. Shetiya, “ Efficient routing and scheduling algorithms for IEEE 802.16 mesh

networks”, M.E. Thesis, Dept. of ECE, Indian Institute of Science, Bangalore, 2005.

[34] H. Shetiya and V. Sharma, “Algorithms for routing and centralized scheduling

to provide QoS in IEEE 802.16 mesh networks”, in Proc. of 1st ACM workshop on

Wireless Multimedia Networking and Performance Modelling (WMuNeP 2005) in 7th

International Symposium on Modelling, Analysis and Simulation of Wireless and Mobile

systems (ACM/IEEE MSWiM 2005), October 2005.

BIBLIOGRAPHY 80

[35] H. Shetiya and V. Sharma, “Algorithms for routing and centralized scheduling in

IEEE 802.16 Mesh Networks”, in Proc IEEE Wireless Communications and Networking

Conference (WCNC06), April 2006.

[36] V. Singh and V. Sharma, “ Efficient and fair scheduling of uplink and downlink

in IEEE 802.16 OFDMA Networks”, IEEE Wireless Communications and Networking

Conference (WCNC06), April 2006.

[37] Jean Walrand, “An Introduction to Queueing Networks”, Prentice Hall, 1988.

[38] J. Walrand and P. Varaiya, “High Performance Communication Networks”, Mor-

gan Kaufmann, San Francisco , 1996.

[39] H-Y. Wei, S. Ganguly, R. Izmailov and Z. J. Haas, “ Interference aware IEEE 802.16

WiMax mesh networks”, in 61th IEEE Vehiclular Technology Conf., (VTC 2005), Stock-

holm, 2005.

[40] I. C. Wong, Z. Shen, B. L. Evans and J. G. Andrews,“A low complexity algorithm

for proportional resource allocation in OFDMA systems”, Signal Processing Systems

(SIPS), 2004.

[41] S. Xu and T. Saadawi, “ Does the IEEE 802.11 MAC protocol work well in multihop

wireless adhoc networks ?”, IEEE Communication Magazine, Vol 39, No.6, June 2001,

pp.130-137.

[42] F. Xue and P.R. Kumar, “ Scaling laws for adhoc wireless networks: An Informa-

tion theoretic approach”, Foundation and Trends in Networking, Vol. 1, No.2, 2006,

pp.145-270, Now Publishers.

[43] A. Raniwala, K. Gopalan and T. Chiueh, ”Centralized Algorithms for Multi-

channel Wireless Mesh Networks”, ACM Mobile Computing and Communications

Review, April 2004.

BIBLIOGRAPHY 81

[44] R Gupta, Z Jia, T Tung and J Walrand,”Interference-aware QoS Routing (IQRout-

ing) for Ad-Hoc Networks”,Proceedings of Globecom 2005

[45] Lin, G. Noubir G and Rajmohan Rajaraman, ” Mobility models for ad hoc network

simulation”, Proceedings of INFOCOM 2004. Twenty-third AnnualJoint Confer-

ence of the IEEE Computer and Communications Societies

[46] Kuo-Hsing Chiang Shenoy, N.,”A random walk mobility model for location man-

agement in wirelessnetworks”, Personal, Indoor and Mobile Radio Communica-

tions, 2001 12th IEEE International Symposium on

[47] A Wennstrom, S Alfredsson, A Brunstrom, ”TCP over Wireless Networks” ,Karl-

stad University Studies 2004

[48] European Wireless 2007 Tutorial 2: Metropolitican Wireless Mesh Networks: Ar-

chitecture and Protocols. Cedric Westphal Nokia, United states.

[49] Eitan Altan,Vinod Sharma,”Modelling and Analysis of HTTP 1.1-type TCP con-

nections passing through a WLAN”,Submitted for publication.

[50] G Kuriakose, S Harsha, A Kumar, V Sharma, ”Analytical Models for Capacity

Estimation of IEEE 802.11 WLANs using DCF for Internet Applications”,Submitted

for publication, Apr 2006.

[51] S Harsha, A Kumar, V Sharma,”Performance and Admission Control for

QoS guarantees of VoIP and Data Transfers on IEEE 802.11e WLANS using

EDCA”,Submitted for publication.

Abstract - nitt.edu · service (QoS) to real and data applications passing through a multihop mesh...

Documents

Transcript of Abstract - nitt.edu · service (QoS) to real and data applications passing through a multihop mesh...