traffic scheduling and qos for wireless broadband networks

Università degli Studi di Roma "La Sapienza"

Facoltà di Ingegneria

Tesi di Laurea in Ingegneria Elettronica

Traffic Scheduling and QoS for Wireless Broadband Networks

Relatore Correlatore Prof. Francesco Delli Priscoli Prof. Alberto Isidori

Laureando Emiliano Pandolfi

Anno Accademico 2000/2001


1

Alla mia famiglia che mi ha sempre sostenuto

A mia moglie Antonella che mi

è sempre stata vicina


2

SUMMARY

1 INTRODUZIONE..................................................................................................6

2 THE WINE PROJECT: WIRELESS INTERNET NETWORKS ..........................13

2.1 Introduction ................................................................................................................13

2.2 Wireless Internet Networks .......................................................................................15

2.3 WINE Reference Model .............................................................................................21

2.4 WINE System Model .................................................................................................23

2.5 WINE Network Configuration.................................................................................24

2.6 WINE Architecture Layering....................................................................................25 2.6.1 Protocol Layering Functionality...........................................................................27 2.6.2 Link Layer Protocols ............................................................................................28 2.6.3 Wireless Adaptation Layer (WAL) ......................................................................29 2.6.4 Network Layer Protocols......................................................................................31 2.6.5 Transport Layer Protocols ....................................................................................33

3 WIRELESS LANS..............................................................................................37

3.1 What is a Wireless LAN.............................................................................................37

3.2 Advantages of WLANs...............................................................................................38

3.3 How wireless LANs work...........................................................................................40

3.4 Wireless LANs technology .........................................................................................43

3.5 WINE Testbeds...........................................................................................................45 3.5.1 IEEE 802.11 standard ...........................................................................................46 3.5.2 BLUETOOTH ......................................................................................................51 3.5.3 HIPERLAN ..........................................................................................................54

3.6 QoS in WLANs ...........................................................................................................58

4 QOS AND SCHEDULING POLICIES ................................................................60

4.1 Introduction ................................................................................................................60

4.2 QoS mechanism ..........................................................................................................61


3

4.3 QoS approach: IntServ and Diffserv ........................................................................62

4.4 The IntServ Model......................................................................................................63

4.5 The DiffServ Model ....................................................................................................67

4.6 Managing Queues .......................................................................................................70

4.7 Traffic control: Policing and Shaping ......................................................................71 4.7.1 Leaky-Bucket........................................................................................................71 4.7.2 Token-Bucket .......................................................................................................72 4.7.3 Dual Leaky Bucket (DLB) ...................................................................................73

4.8 Scheduling policies......................................................................................................76 4.8.1 First Come First Served........................................................................................77 4.8.2 Fixed Priority Scheduling.....................................................................................77 4.8.3 Weighted Fair Queuing (WFQ)............................................................................78 4.8.4 Earliest Deadline First (EDF) ...............................................................................81 4.8.5 Hierarchical Link Sharing ....................................................................................82

5 QOS IN WINE PROJECT ..................................................................................84

5.1 Introduction ................................................................................................................84

5.2 Wireless Adaptation Layer (WAL)...........................................................................89 5.2.1 WAL functional entities .......................................................................................91 5.2.2 Link Layer Modules .............................................................................................94 5.2.3 Signalling..............................................................................................................99

5.3 QoS Contract ............................................................................................................100 5.3.1 Basic definitions .................................................................................................100 5.3.2 QoS classes characterization ..............................................................................102

5.4 QoS Module Design ..................................................................................................105 5.4.2 Main Scheduler algorithm ..................................................................................107

6 THE SINGLE CONTROLLER ALGORITHM ...................................................115

6.1 QoS Contract and other Basic Definitions .............................................................115

6.2 Traffic Control Module Design and Modeling ......................................................119

6.3 MT i Buffer Controller Design................................................................................125

7 OPNET SIMULATION OF THE WAL ..............................................................136

7.1 Introduction ..............................................................................................................136

7.2 OPNET Modeler general description .....................................................................137


4

7.2.1 Key features........................................................................................................138 7.2.2 Typical applications............................................................................................140 7.2.3 Modeling methodology ......................................................................................141 7.2.4 Editors and tools .................................................................................................145

8 SIMULATIONS OF TRAFFIC CONTROL MODULE .......................................149

8.1 Adaptation of the theoretical procedures...............................................................149

8.2 Main Features Description ......................................................................................152

8.3 Opnet Implementations of MT Scheduler..............................................................155 8.3.1 Models Analysis .................................................................................................157

8.4 Simulations Results ..................................................................................................164 8.4.1 Compliant Campaign..........................................................................................164 8.4.2 Non-Compliant Campaign..................................................................................170

9 CONCLUSIONS...............................................................................................183

10 CONCLUSIONI ...................... ERRORE. IL SEGNALIBRO NON È DEFINITO.

11 FIGURE........................................................................................................185

12 TABLE..........................................................................................................190

13 ACRONYMS.................................................................................................191

14 REFERENCES & STANDARDS ..................................................................196


5

Traffic Scheduling and QoS for

Wireless Broadband Networks


6

1 INTRODUZIONE

Questo lavoro di tesi si concentra sulla realizzazione e simulazione di uno scheduler del

traffico per architetture wireless da utilizzarsi per garantire l’obiettivo di Qualità del Servizio

nel progetto WINE .

Il progetto WINE (Wireless Internet Network) nasce ed è sostenuto dalla Comunità

Europea nell’ambito del V Programma-Quadro ed al quale vi partecipano importanti

compagnie, università ed enti di ricerca ad alto livello quali:

� PHILIPS Italia

� VTT Finlandia

� INTRACOM Grecia

� AQL Francia

� ACCORDE Spagna

� CEFRIEL Italia

� Università “La Spienza” di Roma Italia

� Università di Atene Grecia

� Università di Belfast Regno Unito

� Università di Cantabria Spagna

Il progetto si propone di elaborare ed implementare un’architettura Internet per una rete ad

accesso wireless che sia in grado di funzionare efficientemente su una molteplicità di

interfacce radio diverse offrendo un servizio di trasporto per applicazioni multimediali.

Una configurazione tipica di una WLAN prevede un dispositivo

trasmettitore/ricevitore chiamato Access Point (AP) connesso alla rete via cavo tramite lo

standard Ethernet. I dispositivi non collegati fisicamente alla wired sono detti Mobile

Terminal (MT) e per inviare o ricevere dati alla wired devono colloquiare necessariamente

con l’AP. In altre parole un AP come minimo riceve, bufferizza e scambia dati tra la rete

wireless e la wired.


7

I vantaggi di una WLAN sono molteplici:

� Mobilità: permette di migliorare la produttività ed il servizio, specialmente in

particolari situazioni di lavoro in cui è necessario accedere in tempo reale a

determinate informazioni spostandosi all’interno di una certa area (uffici, ospedali,

magazzini, ecc.).

� Semplicità di installazione: non necessita di cavi da stendere.

� Flessibilità di installazione: la tecnologia wireless permette di arrivare dove una

normale wired non può arrivare come per esempio in edifici e luoghi storico-artistici.

� Riduzione del costo totale: per una WLAN il costo dell’hardware è elevato, ma i

tempi ed i costi di installazione sono notevolmente ridotti. Eventuali cambiamenti

successivi come spostamenti, nuove installazioni, non implicano alcun costo

infrastrutturale.

� Scalabilità:queste tipo di LAN sono pensate per subire continui cambiamenti

La ricerca di sistemi di telecomunicazioni orientati verso la massima flessibilità e

l’indipendenza rispetto alla particolare piattaforma utilizzata si giustifica col fatto che l’utente

di servizi di telecomunicazione, da una parte, è sempre più attratto dal poter comunicare

attraverso scambi di dati, voce ed immagini sia fisse che in movimento, dall’altro, non è per

nulla interessato alla tecnologia di accesso utilizzata affinchè tutto ciò sia possibile.

Pertanto nel fututro prossimo è probabile che ci si orienti verso una gamma di alternative

possibili, scegliendo tra queste soluzioni quelle di volta in volta a più basso costo ed a

maggior qualità.

Qualche anno fa si credeva che l’ATM (Asynchronous Transfer Mode) sarebbe stato il

modo si trasmissione dominante nella tecnologia digitale e che si sarebbe imposto sia nelle

reti locali che in quelle geografiche. Tutte queste aspettative riposte nell’ATM hanno dato il

via a numerose ricerche orientate verso una sua applicazione nell’ambito wireless che

purtroppo non hanno dato i risultati sperati: infatti l’Aynchronous Transfer Mode ha fallito

nel produrre l’attesa rivoluzione sia dal punto di vista del mercato che da quello tecnologico.

Inoltre le soluzioni wireless ATM si sono rivelate costose e complesse da realizzare. La

conseguenza di ciò è che l’ATM è largamente utilizzata solo nelle dorsali delle reti di

telecomunicazioni.


8

Accanto a questo obiettivo di miglioramento della flessibilità di un sistema di

telecomunicazione nei confronti della tecnologia utilizzata, un grande impegno della ricerca è

orientato verso il miglioramento della Qualità del Servizio, problema tutt’altro che semplice

da risolvere in ambiente wireless. Infatti, se da una parte una rete fissa realizzata mediante

l’utilizzo di fibra ottica rende possibili comunicazioni a larghissima banda con eccellente

qualità ed a fronte di una ingente spesa per la realizzazione della struttura complessiva,

dall’altra, una rete con accesso wireless rappresenta una soluzione molto più economica,

veloce da realizzare e maggiormente apprezzata dall’utente medio e che presenta una qualità

molto più scadente a causa della ridotta banda disponibile e dei disturbi di canale che possono

facilmente degradare la qualità della comunicazione.

Ai succitati problemi bisogna aggiungere le cattive prestazioni della maggior parte

delle implementazioni del protocollo TCP quando è chiamato ad operare in ambiente wireless

e la bassa Qualità del Servizio offerta per definizione dal protocollo IP in quanto fornisce un

servizio detto di tipo “Best Effort”, ovvero tenta di portare ogni datagramma da sorgente a

destinazione il più velocemente possibile senza alcuna assicurazione sul ritardo end-to-end o

sul numero di pacchetti persi.

Il progetto WINE basandosi sullo studio dell’arte delle attuali soluzioni di reti

wireless e dei modelli elaborati per affrontarle, per superare i problemi di cui sopra, si pone

come obiettivo la realizzazione di una architettura globale migliore modificando l’attuale

mediante l’inserimento di un ulteriore strato. Tra gli strati protocollari della rete IP, di

trasporto e di applicazione presenti nel modello standard della rete Internet e quelli di livello

inferiore (Underlyng Network layers) dipendenti dalla particolare tecnologia di accesso radio

adottata nel sistema wireless, è stato inserito uno strato di adattamento: il WAL (Wireless

Adaptation Layer) avente lo scopo di fornire in modo trasparente allo strato IP ed agli strati

UNs garanzie sulla qualità del servizio offerto, sopperendo alle eventuali carenze nelle

caratteristiche del servizio offerto dalla specifica tecnologia in uso.

Lo scopo del WAL è di assistere in modo efficiente gli UNs layers nel rispetto del

contratto di QoS. In altre parole il WAL deve fare in modo da garantire da un lato

l’ottimizzazione dello sfruttamento della banda disponibile e dall’altro il rispetto dei diversi

contratti di QoS: in generale queste due richieste sono in contrasto tra di loro.


9

Il WAL consiste di un insieme di moduli che hanno il compito di processare il traffico IP per

migliorarne le caratteristiche. Ogni modulo può essere attivato o disattivato in funzione dello

strato sottostante il WAL stesso. A dispetto del fatto che l’architettura del WAL è la stessa

per qualsiasi Underlying Network, un sottoinsieme dei moduli del WAL possono essere scelti

e possono includere alcuni parametri che devono essere opportunamente tarati per soddisfare

le richieste della rete sottostante presa in considerazione. Inoltre un LLCT (Logical Link

Control Translator) opportunamente configurato è posto all’interfaccia tra il WAL e la UN

sottostante con il compito di adattare il WAL alla UN considerata.

I moduli del WAL previsti nel progetto WINE sono:

1) FEC (Forward Error Connection) Module

2) ARQ (Automatic ReQuest) Module

3) Snooping Module

4) Traffic Control Module

I primi tre moduli hanno lo scopo di migliorare l’affidabilità del collegamento, garantendo

così che il massimo tasso tollerabile di perdite di datagrammi IP sia in accordo con il contratto

di Qualità del Servizio.

Il Modulo di Controllo del Traffico ha lo scopo di:

a) Regolare l’ammissione nella Underlying Network di traffic compliant in accordo con

il contratto di QoS

b) Massimizzare lo sfruttamento della banda disponibile

c) Garantire che i datagrammi IP ammessi nella Underlying Network siano portati

dall’Access Point (AP) al Mobile Terminal (MT) e viceversa rispettando il massimo

ritardo tollerato ed il massimo jitter tollerato in accordo con il contratto di QoS.

Questo lavoro è incentrato sul modulo di controllo del traffico da implementare su un

certo AP, proponendo una architettura originale ed una procedura originale. Il componente

fondamentale di un Traffic Control module di un dato Access Point è l’MT i Scheduler che

gestisce tutto il traffico diretto verso verso un dato MT i.

L’ MT i Scheduler è composto dai seguenti elementi:

� un insieme di FIFO buffers alimentate con il traffico offerto

� un controllore centralizzato chiamato anche MT i Buffer Controller che basandosi sul

traffico offerto e sullo stato di riempimento dei buffers FIFO controlla:


10

o l’ammissione del traffico offerto nei buffers FIFO

o il recupero del traffico immagazzinato all’interno di questi buffers per

trasmetterli verso l’LLCT e quindi sull’interfaccia radio.

Le principali novità della soluzione adottata sono:

1) Il progetto di un modulo di Controllo del Traffico che include sia il controllo di

congestione (cioè decidere quale datagramma IP deve essere ammesso all’interno

della rete wireless), sia lo scheduling (cioè decidere quale datagramma IP tra tutti

quelli ammessi deve essere servito con priorità dalla rete wireless ). In particolare il

controllore effettua simultaneamente entrambi il controllo di congestione e

l’operazione di scheduling.

2) Il modellare, secondo la teoria del controllo, del problema del rispettare il contratto di

QoS mentre si massimizza lo sfruttamento della banda disponibile.

3) La soluzione del problema precedentemente citato mediante la teoria del controllo

realizza un controllore che porta il sistema totale verso l’equilibrio ideale a cui il

sistema totale ottiene prestazioni ottime. Questo equilibrio ideale deve essere

periodicamente aggiornato in quanto dipende dallo stato in cui si trova il controllore e

dal traffico offerto. Inoltre non è necessaria nessuna conoscenza a priori sul tipo di

traffico offerto. Infine, il controllore proposto, nonostante derivi da calcoli matematiici

è flessibile ed assai semplice da implementare.

4) La gestione del controllo di congestione in modo closed-loop, in quanto la decisione

sull’ammissione o meno del traffico all’interno delle rete wireless è basata sullo stato

attuale del buffer.

La tesi è suddivisa in quattro parti:

� La prima partefornisce una introduzione al progetto WINE in generale ed alle reti

Wireless di uso più comune;

� La seconda parte introduce ad alcune politiche di scheduling ed alla QoS nel progetto

WINE;


11

� Nella terza parte viene descritto l’algoritmo dell’MT Scheduler implementato che ha

lo scopo di trovare il modo migliore per assegnare le risorse di banda tra le varie classi

di traffico considerate tenendo conto dei vincoli stabiliti dal contratto di QoS;

� Nella quarta parte viene descritto OPNET (OPtimum NETwork performance) il tool di

simulazione utilizzato per implementare l’algoritmo dell’MT Scheduler e viene

descritta l’implementazione dello stesso con le relative simulazioni.

La terza e la quarta parte forniscono il contributo originale al lavoro svolto.


12

PART ONE The WINE project and Wireless

Network


13

2 THE WINE PROJECT: Wireless Internet NEtworks

2.1 INTRODUCTION

The rapid growth of Internet services and almost exponential evolution of the number of

users have been concurrent with the growth of cellular telephony. Telecommunications

markets worldwide are undergoing immense change due to rapid technological progress

leading to the introduction of new products and services. In the effort to satisfy increasing

consumer demand for advanced services beyond basic telephony, both established and

emerging service providers are now under intense competitive pressure.

Internet technologies and applications have grown more rapidly than anyone could have

envisioned even five years ago, opening up brand new modes of communication,

collaboration and coordination between consumers, businesses and trading partners. The Web

has quickly culminated into a myriad of highly sophisticated hardware and software

applications that are enabling companies to use the massive technology infrastructure of the

Internet to create new value for their stakeholders.

There is no question that networking technology has played a huge role over the course of the

last decade in shaping the way people work, live, play and learn. The Internet has grown in

importance immensely as a brand new way of interaction especially as the

telecommunications and entertainment markets are now converging.

The success of the IP standard protocol (upon which the Internet is based), with its

flexible and cost-effective packet based approach for transmitting information, has proved to

be the key to leveraging a single network for carrying data, voice and video, accessible

anywhere, at any time, for anyone. A unified, IP-based network that integrates data, voice and

video opens the door to an incredible number of applications that will make people more

productive and businesses more competitive all by increasing efficiency, saving time and


14

dramatically reducing costs. The multiservice network combines data, voice and video traffic

into a single, intelligent network, a reliable, secure and scalable environment that companies

can use as a strategic business asset and consumers as a complete communication platform.

The mass market will join in 2002. Internet-capable phones will proliferate as three

barriers drop: slow connections disappear with the debut of high-end general packet radio

service (GPRS) phones; cautious buyers warm to second-generation units; and the price

barrier falls with low-end models that cater to the market. A third of all Europeans will use

the mobile Internet in 2004. According to Nokia and Ericsson, no major manufacturer will

produce a mobile phone in 2003 without some form of Internet browser. Although they will

support new content formats like XML, phones will not abandon proven WAP standards.

This evolution has been different to what has been proposed some years ago.

Previously it was claimed that ATM (Asynchronous Transfer Mode) shall be dominant digital

transmission technology that shall be scaled from local area networks to large area networks.

Because of this, a very large amount of research was done toward Wireless ATM systems.

It was claimed that economics, guaranteed Quality of Service (QoS) and

telecommunication standardisation push would deliver global ATM scenario. It is now clear

that this vision has not been completely achieved. In fact, ATM has failed to produce the

intended revolution on local area networks and it is now predominantly deployed in backbone

connectivity. Some researchers and companies are even doubtful, if ATM should be used

even in backbone networks. The basis of this doubt is that Internet connectivity, protocols

based on UDP/TCP/IP, are now dominating applications and networking. In fact, major

cellular network manufactures have announced that they would like to base the backbone

connectivity in 3 rd generation cellular networks to IP networking instead of ATM. Also

Wireless-ATM (WATM) solutions that have, for instance, been implemented in 4th

framework projects have proved to be complex and expensive to implement. Also,

performance expectations have not been reached. There are lots of experience on WATM in

the consortium both from 4th framework research and otherwise. In competition with WATM

physical and link layer solutions there are solutions like IEEE 802.11 that are based on

contention and reservation of communication media. Currently there are commercial products

for 2 Mbps and 10 Mbps data rates.


15

Research challenges in this area include handling impairments of wireless channel,

efficient routing and mobility management, and global end-to end optimisation of Internet

connections with QoS guarantees. The cellular phone and wireless communication

manufacturers and service providers are trying to find new value-added services and

connectivity possibilities over the existing cellular telephony and slow bit-rate data services.

The term “Wireless Internet” has become common in white papers and press releases.

Wireless access to Internet is also required in economical sense, as wireless technology will

provide easier and cheaper installation for customer premises. Also co-use of Local

Multipoint Distribution System (LMDS) would be available for many Internet Service

Providers, who undoubtedly desire rapid deployment scenario. As there will be variety of

different wireless media, from cellular telephony to high speed LMDS networks, demands for

wireless TCP/IP networking technologies will be high. However, the present day wireless

Internet claims are only short-time solutions and are not really providing full Internet

connections. In the application domain, technologies such as WAP (Wireless Application

Protocol) are not providing transparent Internet connectivity, where users can use unmodified

TCP/IP based applications. WAP, for example, requires dedicated services that have been

adapted for WAP usage.

In the communication protocols domain technologies such as WATM, UMTS, GPRS

and GSM-data are not providing effective and optimised IP-connectivity. Instead the IP-

traffic is very sub-optimally embedded into the native transmission system. The result is very

often grossly ineffective use of the digital transmission capacity, long latencies and need to

build customised gateways between radiolinks and true IP-backbone network.

2.2 WIRELESS INTERNET NETWORKS

WINE (Wireless Internet NEtworks) is an European Community 5th framework project

whose purpose is to study the necessary technologies to build fully IP-based optimised

wireless Internet connections. The aim of the project is to build QoS aware wireless IP

networks. Instead of basing systems on underlying WATM (Wireless ATM), partners believe


16

that true wireless Internet system should be optimised and should be as far as possible

independent from radiolinks.

The project takes IPv6 as the starting point of the development. The goal is to build

wireless access points and optimised wireless links for IPv6 traffic. The unique goal of the

consortium is to study all the necessary issues in the protocol layers to find globally optimised

end-to-end delivery solution.

The project shall be done with three complementary approaches. First, theoretical issues

are studied in the wireless IP with protocols, queuing models etc. Second, large simulations

and case studies over research networks are done to verify theoretical results and to gain extra

information on large-scale environment. Third, results are implemented into different

underlying communication hardware platforms. This is unique approach since the project

does not concentrates or favours any single radiolink or manufacturer solution. The goal is to

build a wireless IP adaptation layer, that is configurable so that it can be optimised for

different platforms and links.

The innovative claims in the project are:

• Development and research on true, transparent Wireless Internet Connectivity. This

is to be verified with actual prototype systems

• Global end-to-end transmission optimisation

• The transmission is based from the start existing Internet philosophy and namely

IPv6 protocols, not to WATM (i.e. IP-over-ATM solutions)

• The aim is to build wireless and cellular IP-networks

• The project is not following any single hardware platform restrictions, instead is

developing an adaptation layer to make it possible to have transparent IP services

over different air-interfaces

• Three very different platforms are demonstrating the results; Bluetooth, HiperLAN-2

and IEEE 802.11

• Provisioning of a generic solution for enhancement of Internet wireless links

• Performance optimization on an end-to-end basis. That is, the WINE technical

approach is not biased towards any specific wireless interface or transport protocol

• Full compatibility with existing Internet


17

• Easy deployment in both existing and future systems. This implies that the WINE

system should be easily installed and configured without demanding any particular

software/hardware upgrades

• Easy migration to IPv6

• Efficient combination of IPv6 and mobility

• Applicability to the greatest possible extent. Contribution to the relevant IETF

working groups is one of the main goals of WINE. Eventual contributions to other

organizations, e.g. ETSI/BRAN, are also subject of the WINE effort.

The WINE Consortium is not aiming to produce a commercial product. The consortium

consists of many research institutions and Universities (VTT Electronics, Philiphs Research,

University of Rome, Alliance Qualite Logicel, COGEFO, Intracom S.A., University of

Athens, ACORDE, University of Cantambria, Queen's University of Belfast), with primary

goal to produce state-of-the-art research in a new and evolving area, the area of wireless

internet.

The approach to the problem of transporting TCP/IP traffic over a radio link starts from

the assumption that the area of interest should be placed to IP and link (LLC) protocols, rather

than on higher layer. A study is proposed on new protocols at network and link layers to

improve throughput and reduce latency of the wireless link, keeping transparency with upper

layer protocols. Other encapsulation schemes should be investigated in order to make the

transmission of IP traffic more efficient by not transmitting unnecessary IP header fields in

each packet (such an approach may also find use in the design of fast packet switching and

routing).

The WINE research plan is sketched as follows:

• Selection of the dominant existing and emerging wireless networks to build testbeds

for experimentation and validation.

• Leveraging of background work in the area of mobile/wireless IP. The focal point is

on the continuation/contribution of the underway IETF work.

• First stage specification of the WINE network architecture.

• Modeling of the fading radio channel in terms of average error rate and channel

burstiness.


18

• Integration of the wireless testbeds with both IPv4 and IPv6 protocol stacks and

performance evaluation.

• Development of OPNET simulation models to study the behaviour of the

implemented wireless testbeds. Comparison with the implementation obtained

results. Feedback from the wireless testbeds to the simulation models should be

performed, in terms of real measurements.

• Simulation and validation of the WINE system.

• Implementation of the WINE system. Feedback from the real system will eventually

reshape the simulation models.

• Contribution to the IETF working groups with scientific work and obtained results.

The typical environments for the network architectures foreseen in the WINE project

can be identified in two main categories: the domestic scenario and the business one. We will

refer to the above scenarios as Domestic and Business Premises Networks (DPN and BPN,

respectively). The first ones cover the home and its immediate vicinity while the second ones

cover larger areas such as offices, university campuses or airports and train stations, etc. The

two environments are intrinsically different as long as applications are concerned. In fact,

while in DPN, entertainment and Internet access play a dominant role, in BPN, information

sharing mostly occurs within corporate intranets, including access to file and printer servers,

laptop synchronization and videoconferencing. In the near future, anyway, the demand for

wireless connectivity to information access points, as considered in WINE, is going to grow

in both application environments.

In an hypothetical reference connection scheme that we can imagine, some devices

connected to the access network (generally in wired mode) play the role of residential

gateways that interface the internal wireless network to the external access one thus providing

inter-connectivity to every host working in the internal network. Intra-connectivity is

achieved in a seamless way through the internal wireless network. In a deeper analysis, we

can better identify the kind of hosts present in the internal network by considering their

environments. In DPN is foreseable the presence of PCs, PC peripherals, cordless or mobile

phones, TV sets, remote controls, laptops, MP3 players and even domestic appliances. In

some cases, upgradability, user profiling and fault diagnosis through Internet have already

been studied for a number of certain devices. In BPN there may be PC, cordless or mobile


19

phones, laptops, faxes, video projectors, more refined videoconferencing tools, data or printer

servers, workstations, etc.

The increasing demand of wireless Internet networks at home and in offices has a lot of

motivations.

In BPN temporary office installations or installations into spaces where building

characteristics or protection prohibits the extensive use of cabling could make proper wireless

networking appear to a stationary user (like a terminal, PC or workstation user) as a nearly

indistinguishable approximation of a fixed network (a sort of Ethernet wireless extension). In

case a portable computer represents the equipment under consideration, the end-user would

probably carry it in various locations within the office and use it while stationary. Moreover,

this “cordless user” would probably appreciate also the possibility to access the public

network through base stations installed in locations such as railway stations, airports and

shopping centers performing in such a way a wireless access to Internet from public

locations. A mobile user would like to remain connected also when in transit from one

location to another.

In DPN, as already mentioned, a wide range of devices can benefit of a suitable

interconnectivity with the Internet network by obtaining remote “addressability”, control and

activation. On the other hand, we have to realize that, in DPN, the auto-configuration of

involved devices is mandatory: With respect to this, consider the effort spent by large

companies in the standardization of the “Universal Plug and Play” (UPnP™) architecture (by

Microsoft) and the development of the “JINI™” technology (by SUN Microsystems). In this

environment, mostly PC act as residential gateway between the home network and the access

network, but also mobile phones could, in principle, do the same as long as suitable links will

be established with the access networks. Then, the VCR could represent the Home server,

capable of storing A/V streams (MPEG-2 etc.) and exchange them with the TVsets, without

need for cables. This situation can be referred to as wireless access to residential gateways (in

home networks).

Such a wide user scenario suggests the utilization of various radio technologies to

provide the proper implementation of the wireless link. In the WINE project we have

considered three reference wireless implementations upon which specific test-bed are being

developed. These are:


20

1. BLUETOOTH

2. IEEE 802.11

3. HIPERLAN/2

The cost of the equipment necessary for the implementation of related wireless

solutions should be significantly different even if some similarity in a way exists in the

services they provide. Figure 2-1 gives an idea of the achievable performances and usage

environments.

Figure 2-1:Reference wireless technologies mapping

Figure 2-1 : :reflects the present estimations concerning the reference radio technologies

utilization. As can be seen, a great percentage of Bluetooth equipped devices is envisioned in

the consumer market, especially due to the cheapness of the related hardware. On the

contrary, the IEEE 802.11 standard is expected to work as a sort of wireless Ethernet

replacement in offices. Despite of their higher cost, HIPERLAN/2 devices will probably

appear both in offices and at home due to their capacity to transfer large amounts of data,

including audio and video streams, without cables. Wireless LAN devices will be treated with

some details in paragraph 3.3.

The WINE system should enable stationary hosts to be attached to the network, so as to

communicate with mobile hosts. Some switches (without the IP layer) could be present in

BLU

ET

OO

TH

IEE

E 8

02

.11

HIP

ER

LAN

D 2

BPN

DPN

1 Mbps 10 Mbps 25 Mbps


21

very large networks and some network elements can act as both a switch and access points, or

both router and access points at the same time. An example WINE cellular network is

depicted in the figure below:

Internet

Router

Switch

Fixed Host

Access Point

Mobile

Router

Mobile TerminalMobile Terminal

Access Point

Access Point

Fixed Host

Switch

Mobile

Termin Terminal Terminal

Figure 2-2: WINE cellular network

2.3 WINE REFERENCE MODEL

The WINE reference model illustrated in Figure 2-3 has been based on the ETSI/BRAN

reference model for HIPERLANs. As shown, the following entities are introduced:

• Mobile Terminal (MT).

• Wireless Domain.

• Access Point (AP).

• IP-based network infrastructure.


22

The project objective is to specify the protocol stack subsystem on both the MT and AP

so as to optimize the transmission of IP traffic over the wireless domain. In particular, WINE

specifies the functionality of the network, wireless adaptation, and link layers both for the

mobile terminal and access point, as well as the transport layer on the MT.

Figure 2-3:The WINE reference model

The WINE system on the mobile terminal covers the transport, network, wireless

adaptation and link layers. As depicted in Figure 2-5 such a system is interfaced with the user

applications in the uplink direction and with the radio link in the downlink direction.

The counterpart of the WINE system on the AP covers the network, wireless adaptation

and link layers. It is interfaced with the radio link regarding the wireless domain side. The

same system is interfaced with the core IP network (Internet side). Finally, the core IP

network could be either a corporate intranet, a home residential gateway interconnecting to

the access network, or in general an IP interface to an ISP.

Application entities WINE system

for MT Radio system

Wirelessdomain

Radiosubsystem

WINE system for AP

Fixed networksubnetworking unit

TCP/ UDP

MT

Radio access network

WINE access network Internet


23

2.4 WINE SYSTEM MODEL

Figure 2-4: The WINE system model

In Figure 2-4 a simplified illustration of the WINE system is given. As shown, the

WINE system Mobility interfaces directly with IP. That is, there is a single entry point where

the datagrams released by the IP layer are intercepted by the WINE protocol layers.

Furthermore, the WINE system processes the IP datagrams and selects the proper link layer

scheme that best matches the protocol type being serviced. After selecting and/or enforcing

the proper link layer scheme, the link layer frame(s) is(are) communicated to the already

activated wireless interface for transmission. In general, the WINE system is not dependent on

any particular wireless interface. However, at a low level the WINE system is compliant with

the interface supported by the wireless link in use. It is apparent that any wireless access

network enhanced with the WINE system could be easily interfaced with the existing Internet

infrastructure through an interworking function running on the access point. In WINE, IP

routing functionality will be applied on the access point to perform the necessary interworking

function. In a home environment, the WINE system could be interfaced with any available

WINE systemWINE system

IPv4 IPv6

TCP

Application

Wireless I/F

MT

IPv4 IPv6

Wireless I/F

IPv4 IPv6

TCP

Application

Wireless subnetFixed network


24

technology such as DSL or cable. In the business environment, fixed Ethernet could be

interfaced with the WINE system.

Mobility and cellular IP aspects are subject for investigation for the WINE system.

Mobile IP, and the most suitable/efficient micro-mobility approach (to cope with the

movement within the subnet) among the existing ones, will be incorporated by the WINE

system.

2.5 WINE NETWORK CONFIGURATION

One of the principal aims of the WINE project is to develop a system concept

providing wireless and mobile connectivity to IP-based services by means of a cellular

network structure.

Internet

Default Router

Switch

Fixed Host

Access Point

Mobile Terminal

Router

Switch

Mobile TerminalMobile Terminal

Access PointAccess Point

Figure 2-5: WINE network configuration

The WINE network configuration is illustrated in Figure 2-5. As shown, the WINE

enabled devices (mobile terminals and access points) are linked to the Internet backbone via a

default router, whose requirements are outside the scope of the present discussion. The main


25

networking devices are: Mobile Terminals (MTs), Access Points (APs), and a certain number

of switches (SWs). Such a network configuration affects the design and will be the subject of

discussion of the following chapters.

As an example of the mobility implications, it can be seen as network architecture with

mobility support for an integrated services IP subnetwork. Therefore, it offers enhanced

services in comparison with those traditionally provided by the Internet. The mobility support

enables to a ssociate a unique universal identifier to a mobile terminal , its home address

(HA), through which it is possible to locate the MT anywhere in the Internet, independently

of its current point of attachment. In addition, a wider choice of services is provided. In fact, a

user of the network can choose a best effort (BE) service or negotiate through an appropriate

signalling protocol a higher QoS, and ask for a controlled load service (CLS) or a guaranteed

service (GS) resource reservation before commencing a communication.

The IP subnetwork consists of SWs, APs, and MTs registered to the network and the

default router. The possibility of managing fixed hosts to the network through wired links is

also provided. It should be clarified since now that the Figure 2-6 illustrates a logical network

configuration that could be mapped onto a variety of physical topologies, such as a ring, bus

or star one. With respect to SWs, they could be absent. They are present only to consider the

most general topology. In the simple case, we could have a single AP corresponding to the

router.

2.6 WINE ARCHITECTURE LAYERING

The WINE architecture is basically a model that defines protocol tasks and service

interfaces, in a layered way, incorporating the transport, network and link layers of the

Internet reference model.

The main requirements to be satisfied are: adherence to protocol layering, support of existing

and future transport protocols and applications, full compatibility with existing Internet, and

ease deployment. The WINE project has adopted a link layer approach to cope with the issue

of error recovery over wireless links, as opposed to the more complicated and not necessarily


26

effective connection split approach. The end-to-end approach, applied in the majority of wired

links, has been discarded for two reasons. First, error recovery is best addressed by a local

link layer scheme so as to hide the error-prone nature of the wireless link to higher layers.

Second, the link layer hardening approach is not transport protocol specific and consequently,

can support both dominant Internet transport protocols (e.g., TCP, UDP) and future ones.

802.11MAC

BLUETOOTHMAC

HIPERLAN2MAC

802.11LLC

BLUETOOTHLLC

HIPERLAN2LLC

Link Layer Modules

Wireless Adaptation Layer

IPv4 / IPv6

TCP UDP RTP

Applications

ApplicationData

IPdatagram

WirelessMIB

Figure 2-6: The WINE protocol stack model

Roughly speaking, the WINE system provides the following overviewed functionality

in a per layer basis:

◊ Link layer : connection establishment and management, handoff treatment, error

detection and correction, retransmissions, cellular structure.

◊ Wireless adaptation layer (WAL): optimization of IP traffic, configurability of

the network interface.

◊ Network layer: IP mobility (both macro and micro mobility), packet scheduling.

◊ Transport layer: mainly congestion control and TCP enhancements for wireless

communication.


27

◊ Application protocols: support both for reliable/delay-tolerant and time-sensitive

applications.

Remarkable consequences of the WINE approach consist in the following items:

• The WINE system basically acts between IP and existing LLC layer (this means that there

is no need to change applications or transport protocols, like in the WAP solution).

• IP traffic classification is performed.

• QoS provisioning by the WINE system is considered an important requirement.

• A generic wireless interface, (the upper part of the WAL), shields the upper layers from

the wireless channel impairments independently on the specific radio technology.

• The lower part of the WAL mostly works as a specific LLC translator that controls and

monitors the behavior of the MAC and PHY levels implementations provided by the

specific radio technology.

A block diagram of the protocol layers’ interaction is described in the Figure 2-6.

The end goal of the link layer is to present a reliable channel with low packet loss rate to

the Internet Protocol. This is very important since upper layer Internet protocols were not

designed for wireless environments. Standardization is well established for the network layer

Internet Protocol and wireless media in frequent use. Therefore there is little flexibility in

those layers for innovation of improved IP over wireless. The WAL allows the development

of innovative, flexible, and dynamic methods for optimizing performance taking into account

the requirements of the upper layers and the impairments of the lower ones.

2.6.1 Protocol Layering Functionality

In this section, insights are given for the protocol layering of the WINE architecture and

the principle protocol functionalities.

The WINE protocol layering is depicted in Figure 2-6. In compliance with the

ETSI/BRAN framework, WINE intents to clearly define the boundary between the radio-

dependent and the radio-independent functions. In particular, great effort will be dedicated to

design an upper architecture (layers upper than the physical and access layers) which is radio-


28

independent. Thus, the WINE will try to generate the RTI (Radio Technology independent)

part of the layering architecture shown in Figure 2-6.

Another important aspect is to provide a combined RTI layering, as opposed to the

different behaviour of each one wireless interface. The wireless interfaces provide

functionalities for the physical and medium access control layers, being transport and

scheduling, respectively. Bluetooth and HIPERLAN/2 provide also LLC functionalities, such

as fragmentation, FEC (Forward error correction) and ARQ (Automatic repeat ReQuest)

mechanisms. IEEE 802.11 does not provide any LLC functionality. The main functionality of

the remaining layers is then highlighted:

� Transport layer: At this layer, TCP is considered and eventual enhancements for

wireless communications should be examined (it is mandatory not to modify it); for

real-time applications we leave open the possibility of using UDP or others state-of-

the-art real time protocols (RTP), but no effort will be spent in their design.

� Network layer: this layer mainly provides services such as routing, segmentation and

re-assembly, and macro-mobility support.

� Wireless Adaptation and Logical Link Control layers: The combination of these layers

provides optimized IP performance over the wireless link.

2.6.2 Link Layer Protocols

Link Layer (LL) protocols for wireless IP-based communications are necessary to

ensure reliable transmission of frames between the access points and the mobile terminal as

well as for signalling between peer LLC entities.

As far as the user plane is concerned, a Link Layer approach can be employed to shield

upper layers (like TCP or UDP) from the wireless channel impairments. However, transport

protocols have different requirements in terms of error robustness, for example the LL could

provide a service that matches TCP’s characteristics, but not UDP’s ones. Such considerations

suggest to differentiate the services offered by the Link Layer according to the particular

traffic classes that need to be carried. If the LL is aware of the transport protocol that has to be

carried (which violates the layering principle), a specific service could be implemented,

tailored on the protocol’s needs. Traditional Link Layer approaches are Forward Error

Correction (FEC), Automatic-Repeat-Request (ARQ) and combinations of the two


29

techniques. While FEC is effective for random bit errors, interleaving is needed when the

channel memory results in error burstiness. Interleaving always comes at the price of

increased latency, which may be undesirable for some applications. On the other hand, ARQ

is based on error detection and packet retransmission with different implementation schemes

(among these, for instance, selective repeat with negative acknowledgments and Go-Back-N).

In case of TCP, Link Layer protocols try to shield the TCP sender from the wireless link

impairments by performing a local loss recovery instead of handling errors end-to-end at the

transport layer. This is particularly relevant because TCP has not been designed to handle

packet losses other than those due to network congestion. So its reaction (sharp reduction of

the offered throughput) reflects this cause only and it is clearly inadequate in the case of

wireless losses.

An alternative to Link Layer protocols is represented by split connection (SC) protocols.

In SC systems, TCP connections between senders and mobile (or unwired) receivers are split

at the base stations. This is done also to have the possibility to use a different protocol on the

wireless hop (since TCP is not well tuned for error prone links, the TCP sender of the wireless

link often times-out, causing stall). Link Layer schemes can perform better than split-

connection protocols whose implementation violates the end-to-end semantics of the TCP

acknowledgements. Moreover, unless extra copies are avoided by using a proper kernel

implementation, every packet is processed twice by the TCP at the base station; therefore split

connection solutions are generally inefficient. Anyway, the best results are obtained with a

TCP-aware implementation (with snooping) of LL protocols, in spite of the layer separation

foreseen by the OSI or TCP/IP models.

2.6.3 Wireless Adaptation Layer (WAL)

Different methods for compensating wireless impairments at the link layer have been

examined thoroughly. The end goal of the link layer is to present a reliable channel with low

packet loss rate to the Internet Protocol. This is very important since upper layer Internet

protocols were not designed for wireless environments.

The WINE project is considering the most effective strategies available to improve the

performance of wireless Internet. In order to cope with different wireless mediums, an

additional software layer is being designed in between the network layer and the wireless

medium specific link layer. This layer is termed the Wireless Adaptation Layer (WAL), and is


30

paired with a modular link layer below. Standardization is well established for the network

layer Internet Protocol and wireless mediums in frequent use. Therefore there is little

flexibility in those layer for innovation for improved IP over wireless. The WAL allows the

development of innovative, flexible, and dynamic methods for optimizing performance taking

into account upper layer requirements and lower layer impairments.

The WAL can be considered the intelligence of the WINE architecture. It is responsible

for examining the current situation and received packets to make decisions which optimize

performance. The WAL itself does not modify packets, however it makes the decision to hand

off packets to link layer modules, which can. In this way it is not a traditional protocol layer.

The WAL performs the following functions:

◊ Examination of packets from upper and lower layers for decision making

◊ Data collection from Wireless SNMP MIBs for configuration

◊ QoS classification and mapping to wireless interfaces

◊ Awareness of mobility changes. WAL is aware when IP layer mobility makes a

handoff, or when wireless interface changes AP, possible techniques for maximizing

performance could be enabled.

◊ Selects link layer modules according to the available information Includes ARQ,

FEC, Snoop, Header/Packet Compression, and other methods.

This layer handles packet examination, QoS classification, and the enabling of link

layer techniques using modules. The logical entity where link layer techniques, such as those

described in the introduction, are implemented. Figure 2-6 shows the location of the WAL

and Link Layer Modules. Link layer techniques are programmed in modules, which can be

selected by the WAL if the conditions indicate link layer techniques are necessary. Each

module is implemented as a function which packets can be passed to from above and below

by the WAL. The format of these modules should be specified in detail for future work.

The following are possibilities for Link Layer Modules:

◊ Snoop for TCP streams

◊ Link ARQ module, very configurable (e.g., Window size, SACK)

◊ Header/Payload Compression


31

◊ Link Layer Mobility

◊ Link Layer Forward Error Correction (FEC) techniques

These modules may or may not be used depending on the current system situation, i.e.

what is the wireless interface?, what is the channel condition?, what transport is used?, as

examples. With this modular link layer system additional features can be added and tested in a

systematic way. In order to make decisions about QoS classification, and link layer module

enabling, the WAL must have access to information. This information can be collected from

the following sources:

• Packets received from IP (Destination, ToS, Transport Type, TCP options, etc..)

• Wireless Interface Used (i.e. Bluetooth, 802.11, HIPERLAN/2)

• Wireless interface information (Bandwidth, signal, errors, throughput), mobility

situation.

These statistics are collected into the Wireless SNMP MIBs.

• Status of link layer modules once enabled

Access to wireless interface and mobility information is very important to the intelligent

WAL. To provide a standard way to do this, WINE has selected the Simple Network

Management Protocol (SNMP) with the addition of a wireless Management Information Base

(MIB). This subject will not be pursued further since it's not of interest in this work. The

WAL will be seen by the network layer as a standard network interface, and therefore will be

transparent to the IP layer. IP packets are transferred from the network layer to the WAL and

vice versa using standard operating system functions. The basic interface between the WAL

and the wireless interface is exactly the same as described above. A standard operating system

buffer is used to pass the packet on from the WAL to the underlying wireless network

interface and vice versa.

2.6.4 Network Layer Protocols

The network layer uses the Internet Protocol version 6 (IPv6), while supporting IPv4 as

well. It handles all requirements needed for a connectionless networked environment. IPv6


32

provides connectivity with the rest of the networked world. The Internet Protocol tends to

replace network layer entities in every network. Thus, Internet support is a necessity even in a

wireless environment. To further facilitate the wireless devices IPv6 is chosen to be deployed.

In the WINE architecture, the network layer should also provide the transport layer with

mobility support. The nature of this service has to be completely transparent to the upper

layer. Communications involving mobile terminals (hosts) or just between stationary

terminals should appear to the transport layer without any significant differences. In practice,

mobile communications are in particular subject to problems such as intermittent

connectivity, high bit error frequency and limited bandwidth. This is because the access to the

network is often of wireless type. This effort at the network layer is directed towards

improving the mobility service so as to enable seamless mobile communications with QoS

support. The network layer is the responsible entity for handling the mobility of terminals. As

such, it should support roaming and handoffs.

Mobile IP is the mobility module in the Internet Protocol. It is an additional feature of

IPv6 that allows terminals to recognize mobility inherently. That is, every terminal notices the

mobility headers (e.g., home address, binding update) and performs the necessary mobility

related conversions in the packet.

The network layer has macro-mobility management as its primary function. With the

term macro-mobility is intended mobility across independent domains. Unique standard for

mobility throughout the Internet could be hardly imposed and would not offer an optimal

solution. On the one hand, this would conflict with the philosophy that inspired the Internet

designers. However, an optimal solution for any network does not exist. Allowing network

operators to choose freely a separate protocol to handle intra-domain mobility would favour

competition between designers and enable future developments.

In the WINE network layer will be adopted Mobile IPv6 to manage macro-mobility as

this will be the future standard for inter-domain communications. A standard version of

Mobile IPv4 will be also supported in the network layer to make it possible for WINE MTs to

operate in IPv4 networks as well. However, it is not very efficient in signalling when a MT

switches points of attachments. Every change must be propagated back to the MT home

network, as well as every correspondent node in the Internet. The overhead becomes too large

when the mobile node moves frequently in a foreign network far away from home. To address

this shortcoming, various solutions have been proposed for micro-mobility. As regards to


33

micro-mobility Mobile IP will not be employed. A micro-mobility protocol will be evaluated

and selected either at the network or link layer. WINE will evaluate proposals such as:

• Ericsson/Columbia Cellular IP.

• Lucent HAWAII.

• INRIA HMIPv6.

• SIMPLE Link layer micro-mobility scheme.

The common point in these proposals is the minimization of the signalling between a

mobile terminal moving in a foreign network, the home agent, and correspondent nodes. To

achieve this goal, every proposal assumes that a foreign network is comprised of several

subnetworks under the same administrative domain. Hence, they are oriented towards a

design in which movements within the same administrative domain should not propagate

outside. A change in the point of attachment may also change the link address but not the

primary care-of-address, used for communication under Mobile IP.

Essentially, the micro-mobility schemes try to cope with local mobility locally, while

mobile IP takes over when the mobile terminal leaves its home domain.

The interface between the network layer (IP) and the transport layer (TCP, UDP) must

provide full access to all the mechanisms of the network layer including among others,

options for ToS. With respect to the ToS interface parameter, this must be passed from an

application downwards to the IP layer so as to differentiate IP datagrams or eventually

facilitate the packet scheduling in combination with the DiffServ scheme. The

network/transport layer interface should support up-call notifications for signal measurements

(e.g., for protocols that might be adaptable) and mobility status.

2.6.5 Transport Layer Protocols

This part will discuss the protocol functionality of the transport layer protocols

incorporated in the WINE architectural model as well as the interface between the transport

and application layers. WINE aims to serve IP-based services, consequently, the notion of

“everything over IP” must be followed. In this direction, the dominant Internet transport

protocols have been adopted and future ones should be also supported. This will satisfy the

requirement for multi-transport protocol support. The discussion on two types of transport


34

protocols, being the reliable and time-sensitive ones. The former provides a reliable

connection oriented service over IP while the latter is mainly targeted to support time-

sensitive applications directly on top of IP with the provision of a connectionless and non-

guaranteed datagram delivery service. TCP and UDP fall into these two categories,

respectively. The main objective is to emphasize on the functional requirements of these

protocols when operating over a wireless link and establish the basic design guidelines to be

followed in WINE.

The main objective is to support TCP communications on the mobile terminal in the

same way as in the wired world. Thus, our design should cope with both interoperability with

existing Internet as well as providing an acceptable TCP performance. The following

requirements must be met for TCP when it operates over a wireless link:

◊ End-to-end semantics must not be violated.

◊ The TCP congestion control and avoidance algorithms must be fully supported.

◊ TCP must interpret any packet loss, duplication or corruption as congestion.

◊ The NewReno and SACK options should be supported.

◊ Any eventual TCP enhancement or extension must not violate the existing

behaviour of the protocol in terms of compatibility with peer TCP.

◊ Existing TCP mechanisms should be exploited in case of additional intelligence so

as to cope with handoffs and wireless errors.

◊ Existing proposals for TCP performance enhancement over a wireless link should be

applied without affecting other protocol mechanisms, specifically those coping with

congestion control.

◊ Any underlying protocol enhancement that masks the wireless impairments to upper

layers must be transparent to TCP.

◊ Any acceptable TCP enhancements must be applied only on the MT.

◊ Special care should be taken when tuning TCP timers in order to be fine coupled

with the link layer’s retransmission timers.

◊ Notifications from network layer via upcalls to signal link layer status,

measurements and handoff hints, should be utilized at the TCP layer to efficiently

and fast recover after “bad” transmission periods.


35

The use of TCP over a wireless underlying infrastructure encounters problems related to

physical reception errors and to the subsequent packet loss. In TCP, packet loss indicates

network congestion. TCP has been designed to deal with it, by slowing down the packet

transmission rate. This mechanism performs well when congested network paths are the real

cause. In a wireless environment, where corrupted packets are due to noisy channels, the

above mechanism further degrades the performance. Instead, fast retransmission performs

better by far, than delayed transmission of packets. This improved behaviour in conjunction

with robust link layer should be adopted for TCP over mobile network layering, and the

following design guidelines should be considered.

• TCP implementations. Existing TCP Reno implementations should be used

supporting the basic congestion control algorithms. Furthermore, TCP options such as

NewReno and SACK should be used. Finally, end-to-end semantics and compatibility

with both existing applications and Internet must be prevented.

• TCP enhancements. In WINE, a link layer oriented approach has been selected that

does not impose for any TCP modifications. However, by means of both simulation

and implementation, we shall evaluate elegant TCP enhancements available from

previous research efforts. Precisely, the following schemes should be evaluated, and

applied in case the performance of the WINE system is further enhanced:

- Snoop: Even a link-layer approach, is well proven for the TCP communications

over wireless. It applies on the AP. Snoop is among the services that WAL should

optionally activate.

- Fast retransmit: This approach is very promising to cope with handoff and is

closely related to Mobile IP. It is applied on the MT .

- TCP-unaware: This approach mimics Snoop without any knowledge of the

payload type. It is applied on both the MT and the AP.

- Other approaches designed throughout the project duration.

- All possible TCP enhancements should not violate the basic operation of the

algorithms, i.e., it is not allowed to make TCP sender distinguish between losses

due to congestion and wireless errors.


36

• Reliable link layer. TCP should operate over a highly reliable link layer that tries to

hide physical transmission errors, as much as possible, using link layer intelligence. In

this stage, several link layer approaches should be tested and the impact to the TCP

performance should be compared against typical TCP behaviour over wireless. Link

layer approaches should employ techniques such as ARQ, FEC, buffering, and Snoop.

TCP could then consider more safely that losses are only due to congestion.

• Inter-layer signalling. An inter-layer signalling should be introduced between the

underlying network protocol (e.g., Mobile or Cellular IP) and the TCP, notifying the

later for extreme network condition. Such conditions could be that BER is beyond

Link Layer’s recovery capabilities or that packets will experience extended round-trip

delays while performing network handovers. This signalling should also include

methods to co-ordinate the retransmission timers between the TCP and link layer (e.g.,

link layer should not retries forever). In either case, a TCP retransmission timer should

never time out due to any of the side-effects imposed by the wireless medium. In

general, this approach makes transport or application protocols to adapt their

behaviour accordingly.


37

3 WIRELESS LANs

3.1 WHAT IS A WIRELESS LAN

A wireless LAN (WLAN) is a flexible data communication system implemented as an

extension to, or as an alternative for, a wired LAN within a building or campus. Using

electromagnetic waves, WLANs transmit and receive data over the air, minimizing the need

for wired connections. Thus, WLANs combine data connectivity with user mobility, and,

through simplified configuration, enable movable LANs.

Over the last seven years, WLANs have gained strong popularity in a number of vertical

markets, including the health-care, retail, manufacturing, warehousing, and academic arenas.

These industries have profited from the productivity gains of using hand-held terminals and

notebook computers to transmit real-time information to centralized hosts for processing.

Today WLANs are becoming more widely recognized as a general-purpose connectivity

alternative for a broad range of business customers.

In a typical WLAN configuration, a transmitter/receiver (transceiver) device, called an

access point, connects to the wired network from a fixed location using standard Ethernet

cable. At a minimum, the access point receives, buffers, and transmits data between the

WLAN and the wired network infrastructure. A single access point can support a small group

of users and can function within a range of less than one hundred to several hundred feet.


38

Figure 3-1:Typical WLAN configuration

End users access the WLAN through wireless LAN adapters, which are implemented

as PC cards in notebook computers, or use ISA or PCI adapters in desktop computers, or fully

integrated devices within hand-held computers. WLAN adapters provide an interface between

the client network operating system (NOS) and the airwaves (via an antenna). The nature of

the wireless connection is transparent to the NOS.

3.2 ADVANTAGES OF WLAN S

The widespread reliance on networking in business and the meteoric growth of the

Internet and online services are strong testimonies to the benefits of shared data and shared

resources. With wireless LANs, users can access shared information without looking for a

place to plug in, and network managers can set up or augment networks without installing or

moving wires. Flexibility and mobility make wireless LANs both effective extensions and

attractive alternatives to wired networks. Wireless LANs provide all the functionality of wired

LANs, without the physical constraints of the wire itself. Wireless LAN configurations range

from simple peer-to-peer topologies to complex networks offering distributed data

connectivity and roaming. Besides offering end-user mobility within a networked

environment, wireless LANs enable portable networks, allowing LANs to move with the

knowledge workers that use them.


39

Wireless LANs offer the following productivity, convenience, and cost advantages over

traditional wired networks:

• Mobility : Wireless LAN systems can provide LAN users with access to real-time

information anywhere in their organization. This mobility supports productivity and

service opportunities not possible with wired networks.

• Installation Speed and Simplicity: Installing a wireless LAN system can be fast and easy

and can eliminate the need to pull cable through walls and ceilings.

• Installation Flexibility : Wireless technology allows the network to go where wire cannot

go.

• Reduced Cost-of-Ownership: While the initial investment required for wireless LAN

hardware can be higher than the cost of wired LAN hardware, overall installation

expenses and life-cycle costs can be significantly lower. Long-term cost benefits are

greatest in dynamic environments requiring frequent moves and changes.

• Scalability: Wireless LAN systems can be configured in a variety of topologies to meet

the needs of specific applications and installations. Configurations are easily changed and

range from peer-to-peer networks suitable for a small number of users to full

infrastructure networks of thousands of users that enable roaming over a broad area.

Figure 3-2: A wireless peer-to-peer network


40

3.3 HOW WIRELESS LAN S WORK

Wireless LANs use electromagnetic airwaves (radio or infrared) to communicate

information from one point to another without relying on any physical connection. Radio

waves are often referred to as radio carriers because they simply perform the function of

delivering energy to a remote receiver.

The data being transmitted is superimposed on the radio carrier so that it can be

accurately extracted at the receiving end. This is generally referred to as modulation of the

carrier by the information being transmitted. Once data is superimposed (modulated) onto the

radio carrier, the radio signal occupies more than a single frequency, since the frequency or

bit rate of the modulating information adds to the carrier. Multiple radio carriers can exist in

the same space at the same time without interfering with each other if the radio waves are

transmitted on different radio frequencies.

To extract data, a radio receiver tunes in one radio frequency while rejecting all other

frequencies. The access point (or the antenna attached to the access point) is usually mounted

high but may be mounted essentially anywhere that is practical as long as the desired radio

coverage is obtained.

Figure 3-3: Client and Access Point

End users access the wireless LAN through wireless-LAN adapters, which are

implemented as PC cards in notebook or palmtop computers, as cards in desktop computers,

or integrated within hand-held computers. Wireless LAN adapters provide an interface

between the client network operating system (NOS) and the airwaves via an antenna. The

nature of the wireless connection is transparent to the NOS.


41

Figure 3-4: Multiple access point and roaming

Wireless LANs can be simple or complex. At its most basic, two PCs equipped with

wireless adapter cards can set up an independent network whenever they are within range of

one another. This is called a peer-to-peer network. On-demand networks such as in this

example require no administration or preconfiguration. In this case each client would only

have access to the resources of the other client and not to a central server. Installing an access

point can extend the range of an ad hoc network, effectively doubling the range at which the

devices can communicate. Since the access point is connected to the wired network each

client would have access to server resources as well as to other clients. Each access point can

accommodate many clients; the specific number depends on the number and nature of the

transmissions involved. Many real-world applications exist where a single access point

services from 15-50 client devices. Access points have a finite range, on the order of 500 feet

indoor and 1000 feet outdoors. In a very large facility such as a warehouse, or on a college

campus it will probably be necessary to install more than one access point. Access point

positioning is accomplished by means of a site survey. The goal is to blanket the coverage

area with overlapping coverage cells so that clients might range throughout the area without

ever losing network contact. The ability of clients to move seamlessly among a cluster of

access points is called roaming. Access points hand the client off from one to another in a

way that is invisible to the client, ensuring unbroken connectivity.

To solve particular problems of topology, the network designer might choose to use

Extension Points to augment the network of access points. Extension Points look and function

like access points, but they are not tethered to the wired network as are APs. EPs function just

as their name implies:


42

Figure 3-5: Use of an extension point

they extend the range of the network by relaying signals from a client to an AP or another EP.

EPs may be strung together in order to pass along messaging from an AP to far-flung clients,

just as humans in a bucket brigade pass pails of water hand-to-hand from a water source to a

fire. One last item of wireless LAN equipment to consider is the directional antenna.

Let’s suppose you had a wireless LAN in your building A and wanted to extend it to a

leased building, B, one mile away. One solution might be to install a directional antenna on

each building, each antenna targeting the other. The antenna on A is connected to your wired

network via an access point. The antenna on B is similarly connected to an access point in that

building, which enables wireless LAN connectivity in that facility.

Figure 3-6: The use of directional antennas


43

3.4 WIRELESS LAN S TECHNOLOGY

Manufacturers of wireless LANs have a range of technologies to choose from when

designing a wireless LAN solution. Each technology comes with its own set of advantages

and limitations.

A narrowband radio system transmits and receives user information on a specific radio

frequency. Narrowband radio keeps the radio signal frequency as narrow as possible just to

pass the information. Undesirable crosstalk between communications channels is avoided by

carefully coordinating different users on different channel frequencies. A private telephone

line is much like a radio frequency. When each home in a neighbourhood has its own private

telephone line, people in one home cannot listen to calls made to other homes. In a radio

system, privacy and non-interference are accomplished by the use of separate radio

frequencies. The radio receiver filters out all radio signals except the ones on its designated

frequency. From a customer standpoint, one drawback of narrowband technology is that the

end-user must obtain a certain license for each site where it is employed.

Most wireless LAN systems use spread-spectrum technology, a wideband radio

frequency technique developed by the military for use in reliable, secure, mission-critical

communications systems. Spread-spectrum is designed to trade off bandwidth efficiency for

reliability, integrity, and security. In other words, more bandwidth is consumed than in the

case of narrowband transmission, but the trade-off produces a signal that is, in effect, louder

and thus easier to detect, provided that the receiver knows the parameters of the spread-

spectrum signal being broadcast. If a receiver is not tuned to the right frequency, a spread-

spectrum signal looks like background noise.

There are two types of spread spectrum radio: frequency hopping and direct sequence.

Frequency-hopping spread-spectrum (FHSS) uses a narrowband carrier that changes

frequency in a pattern known to both transmitter and receiver. Properly synchronized, the net

effect is to maintain a single logical channel. To an unintended receiver, FHSS appears to be

short-duration impulse noise.


44

Figure 3-7: Frequency hopping spread spectrum

Direct-sequence spread-spectrum (DSSS) generates a redundant bit pattern for each bit

to be transmitted. This bit pattern is called a chip (or chipping code). The longer the chip, the

greater the probability that the original data can be recovered (and, of course, the more

bandwidth required). Even if one or more bits in the chip are damaged during transmission,

statistical techniques embedded in the radio can recover the original data without the need for

retransmission. To an unintended receiver, DSSS appears as low-power wideband noise and is

rejected (ignored) by most narrowband receivers.

Figure 3-8: Direct sequence spread spectrum

A narrowband radio system transmits and receives user information on a specific radio

frequency. Narrowband radio keeps the radio signal frequency as narrow as possible just to

pass the information. Undesirable crosstalk between communications channels is avoided by

carefully coordinating different users on different channel frequencies.


45

A third technology, little used in commercial wireless LANs, is infrared. Infrared (IR)

systems use very high frequencies, just below visible light in the electromagnetic spectrum, to

carry data. Like light, IR cannot penetrate opaque objects; it is either directed (line-of-sight)

or diffuse technology. Inexpensive directed systems provide very limited range (3 ft) and

typically are used for personal area networks but occasionally are used in specific wireless

LAN applications. High performance directed IR is impractical for mobile users and is

therefore used only to implement fixed sub-networks. Diffuse (or reflective) IR wireless LAN

systems do not require line-of- sight, but cells are limited to individual rooms.

Emerging wireless LAN standards will help boost the bandwidth of wireless LAN products

considerably, but more importantly some of the innovations in the home computing side of

the market will enable new types of E-commerce applications in which wireless plays a

central role in the home.

3.5 WINE TESTBEDS

In the WINE project context, the analysis of technologies suitable for wireless Internet

networking, their state-of-the-art evaluation and the definition of a common optimised

protocol stack is based also on the implementation of wireless Internet communication test

beds. In these test-beds, in fact, a wireless adaptation layer will be inserted in the software

protocol stack to hide details concerning the particular wireless technology used to the upper

levels of the internet protocol. The proper design of the components of this layer will result in

the best exploitation of the wireless link perceived by the supported applications. The

availability of the WINE test-beds allows the development, test, optimisation and

measurement of the real time behaviour of the software architecture and the assessment of the

best performances actually achievable. Above all, test-beds are useful to validate a common

network simulation model; with this model, particular Internet traffic conditions can be

emulated to test also critical situations to be tackled in reality.

What follows is to provide specifications about the WINE test-beds based on the three

reference wireless technologies examined:


46

� The IEEE 802.11, of which a part was ratified in June 1997, uses radio or infrared

frequencies to achieve a data transfer rate of 1-2 Mbps in a client-server or ad-hoc

network.

� The HiperLAN is an ETSI family of standards which achieves a data transfer rate of 18

Mbps - 54 Mbps. The different types of the HiperLAN family, of which only HiperLAN/1

has so far been ratified in 1996, allow for data transfer between wireless and different

types of fixed networks.

� Bluetooth represents the evolution of IrDA protocol for wireless data transmission

between cell phones, laptop computers, organizers and other peripherals. Instead of being

based on infrared technology, Bluetooth standard uses radiowaves; it was developed by

“Bluetooth SIG” consortium estabilished on 1998 by Ericsson, IBM, Intel, Nokia and

Toshiba.

3.5.1 IEEE 802.11 standard

In June 1997, the IEEE 802.11 Working Group ratified a standard for WLANs

operating at a maximum speed of 2 Mbps. This standard was lacking in many areas, resulting

in no guarantee of interoperability. This resulted in all of the major WLAN manufacturers

working together with the University of New Hampshire Interoperability Lab to ensure that

products are interoperable across multiple vendor platforms.

Table 3-1: IEEE 802.11 family of Standards

The IEEE 802.11 Working Group is now concentrating its efforts on producing

standards for high-speed WLAN. Until recently, The WLAN speed has been confined to a


47

maximum of 2 Mbps. Two task groups, TGa and TGb, have been formed to work on future

standards.

TGa is developing a high-speed physical layer (PHY) in the 5 GHz unlicensed ISM

band that can be used with the existing 802.11 MAC layer specification and be suitable for the

transport of not only data but voice and images. The 5 GHz ISM band will allow for speeds of

20-25 Mbps. TGa has accepted a combined proposal from NTT and Lucent Technologies as

the basis for its work, and the draft standard is now being produced.

Figure 3-9: IEEE 802.11 Reference Model

TGb is developing a high-speed PHY extension in the 2.4 GHz band. The current

802.11 MAC provides for multiple data rates within the same area and allows for the

computation of higher data rates, even by stations that may not support them. This means that,

in theory, stations could support a higher data rate and be backward compatible with existing

products. A combined proposal from Harris and Lucent Technologies has been accepted

which will allow a maximum throughput of 11 Mbps.

As any 802.x protocols, the 802.11 protocol covers the MAC and Physical Layer.

The Physical Layer is further divided into two sublayers: Physical Layer Convergence

Procedure (PLCP) Sublayer, Physical Media Dependent (PMD) Sublayer.

PLCP adapts the capabilities of the physical medium dependent system to the Physical Layer

service. PLCP defines a method of mapping the 802.11 PHY sublayer Service Data Units

(PSDU) into a framing format suitable for sending and receiving user data and management

information between two or more stations using the associated physical medium dependent

system. This allows 802.11 MAC to operate with minimum dependence on the PMD

sublayer.


48

PMD defines the characteristics and method of transmitting and receiving data through a

wireless medium between two or more stations each using the same modulation system.

Up to now, IEEE 802.11 specifies five physical layers:

� Frequency Hopping Spread Spectrum (FHSS)

� Direct Sequence Spread Spectrum (DSSS)

� InfraRed (IR)

� High Rate Direct Sequence Spread Spectrum (HR/DSSS)

� Orthogonal Frequency Division Multiplexing (OFDM)

The last two are used in high speed Wireless LAN. IEEE 802.11a uses OFDM, IEEE 802.11b

uses HR/DSSS.

Currently, Binary Phase-Shift Keying (BPSK) and quadrature phase-shift keying

(QPSK) modulation schemes are used in DSSS WLAN systems. They are sufficient in 1 and

2 Mbps systems, but they do not meet the demands of higher data rate transmission schemes.

To achieve the higher speeds, different modulation techniques should be implemented.

The techniques adopted by the IEEE 802.11 are:

� Complementary Code Keying (CCK)

� Orthogonal Frequency Division Multiplexing (OFDM)

The IEEE 802.11b selects CCK proposed by Lucent Technologies and Harris

Semiconductor for high data rate at 2.4 GHz band. CCK supports both 5.5 Mbps and 11 Mbps

modulation, and it's backward compatible with the 1-2 Mbps scheme. One of the main

benefits of CCK is its resistance to multi-path interference. This allows CCK-based devices to

be less susceptible to multi-path interference, which in turn allows these WLAN devices to

provide better system performance.

For 5 GHz band, the IEEE 802.11 committee ratifies a specification suggested by 802.11a

task group. The new specification is based on OFDM modulation scheme. The RF system

operates at 5.15-5.25, 5.25-5.35 and 5.725-5.825 GHz U-NII bands. The OFDM system

provides a data rate of 6-54 Mbit/s. Since the similarity of IEEE 802.11a and HIPERLAN/2

Physical Layer, the two specification will feature essentially the same Physical Layer. This

will open a world wide development opportunities for WLAN system designers.


49

IEEE 802.11 use Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) to

access medium. The basic idea is: If a station wants to transmit, it first sense the medium. If

the medium is busy, the state defers its transmission to a later time. Otherwise, it is allowed to

use the medium. Because of the Hidden Node Problem, collision could occur. In the Figure

3-10, if both station A and C try to send data to station B at the same time, collision will

occur.

To avoid collisions, a RTS/CTS mechanism is implemented: when a station gets the

chance to send, it sends a short message first. This message is called Ready To Send (RTS).

The destination returns a Clear To Send (CTS) message. After that, the source station can

begin to send the data. Since collisions may not be detected by source station, the destination

will ACK every packet.

Figure 3-10: Hidden Node Problem

The standard uses Inter Frame Spaces (IFS) to provide 4 types of priorities:

� SIFS-Short Inter Frame Space

� PIFS-Point Coordination IFS

� DIFS-Distributed IFS

� EIFS-Extended IFS

The IFSs define minimum time a station need to wait after it senses the medium is free. The

smaller the IFS, the higher the priority. If collision occurs, an exponential backoff algorithm

is used to compete the medium.

The main idea behind Power Saving mechanism is that the AP will maintain a list of

stations currently working in Power Saving mode, and will buffer the packets sent to these


50

stations. When the stations specially require to get the packets by sending a polling request, or

they change their operation mode, the AP will send the packets to the stations.

The AP also send periodically information about which Power Saving stations has

packets buffered at the AP, so Power Saving stations should wake up to receive Beacon

Frames (which bear the former information). If there are packets for them, they will stay

awake and send a poll message to the AP to get the packets.

802.11 comprises the two lower levels of the ISO/OSI protocol stack. Therefore, it

defines the physical level (PHY) and the Media Access Control (MAC).

Three different physical types are described in the standard : Diffused Infra-Red

(DFIR), Direct Sequence Spread Spectrum (DSSS) and Frequency Hopping Spread Spectrum

(FHSS). Both spread spectrum techniques are used in the unlicensed 2.4-2.483 GHz band,

because of the wide availability in most countries and reasonable hardware costs compared to

higher frequencies. Infrared equipments are mainly thought for point to point applications

within reduced ranges. This fact has reduced their market and made them less interesting in

comparison to the radio-frequency alternatives.

Spread spectrum technology is based on widening the spectrum of the information

signal, spreading out its power over a larger bandwidth. The result is a “noisy” signal,

impossible to decode for a non-synchronized receiver. Besides, the effects of intentional or

natural interference, multipath fading and propagation delay are minimized. DSSS technique

is carried out by the convolution of a pseudo-noise (PN) sequence with the information signal,

obtaining a wide band signal. Then the spread information is modulated with a conventional

RF scheme: DBPSK for bit rates up to 1 Mbps and DQPSK at 2 Mbps. On the other hand, in

frequency hopping systems the information signal is modulated following a GFSK scheme.

The carrier frequency "hops" within a discrete set of values in the 2.4 GHz band, established

by a PN code. The hop rate can be higher than the data bit rate (Fast Frequency Hopping

systems, FFH) or lower (Slow Frequency Hopping, SFH) with a minimum rate of 2.5 hops/s.

FHSS throughput is up to 1.6 Mbps.

The Media Access Control is independent of the PHY type and uses a Carrier Sense

Multiple Access with Collision Avoidance (CSMA/CA). While standard Ethernet MAC

detects collisions, CSMA/CA works by a "listen before talk" scheme in order to avoid them.

This means that a station wishing to transmit must first sense the radio channel to determine if

another station is transmitting. If the medium is not busy, the communication may proceed.


51

This method also implements a time gap scheme to ensure a balanced channel sharing. The

802.11 MAC also provides roaming mechanisms between base stations, power management

capabilities and data encryption.

On September 1999, the IEEE ratified a revision of the 802.11 standard, called 802.11

High Rate or 802.11b. It provides higher data rates, whereas maintaining the 802.11 protocol

and ensuring interoperability amongst products with the same physical layer.

The standard is based on DSSS technology, with speeds up to 11 Mbps and fallback

rates of 5.5 Mbps, 2 Mbps and 1 Mbps over the same bandwidth as 802.11 systems. To that

point, a new modulation scheme has been proposed only for 5.5 and 11 Mbps rates. It is

called Complementary Code Keying (CCK) and is a variation on M-ary Orthogonal Keying

modulation that uses an I/Q modulation architecture with complex symbol structure. IEEE

802.11 DSSS equipments have been used and tested for many years in a steady growing

market. Now, the fact that 802.11b revision has speeded up the throughput to standard

Ethernet levels and ensured interoperability makes this wireless technology a suitable test

platform.

3.5.2 BLUETOOTH

Bluetooth is a short-range, low-cost radio link thought to be a cable replacement

between portable and/or fixed electronic devices; it is designed to operate in a person’s

operating space, i.e. the space around a person that typically extends up to 10 meters in all

directions.

The Bluetooth radio transmission uses a slotted protocol with a FHSS (Frequency

Hopping Spread Spectrum) technique in the globally available unlicensed 2.4 GHz ISM

(Industrial, Scientific and Medical) band. The hop frequency is up to 1600 hops per second,

the frequency spectrum is divided into 79 channels (or 23 in some countries) of 1 MHz

bandwidth each.

The frequency hopping scheme is combined with fast ARQ (Automatic Repeat

Request), CRC (Cyclic Redundancy Check) and FEC (Forward Error Correction) to achieve

appropriate reliability on the wireless link. Each device is identified by a globally unique 48-

bit address derived from the IEEE 802 standard.


52

Communication between Bluetooth devices follows a strict master-slave scheme, i.e. there is

no way for slave devices to communicate directly with each other. A device acting as master

can have up to 7 active slaves connected.

Master and slaves form a so-called piconet, in which the master defines the timing and

the hop pattern. The slaves have to stay synchronized to the master while participating in the

piconet.

Between master-slave pairs, both Synchronous Connection Oriented (SCO) links

(typically used for voice) and an Asynchronous Connectionless link (ACL) are supported. For

ACL links, Time Division Duplex (TDD) is used to control access to the slots that are not

already reserved for SCO connections: the master may begin to send a packet in even

numbered slots only. The slave addressed by this packet is the only device allowed to send in

the odd numbered slot following the master’s packets. To always keep up the alternation

between even and odd slots, packets must occupy an odd number of slots. Consequently,

Bluetooth defines different packet types with a length of 1, 3, or 5 slots. An example for the

TDD medium access control is depicted in Figure 3-11.

The piconet master sends a three slot packet to the second of its two slaves in the slots

0 to 2. The addressed slave may respond in the subsequent slot 3. In most cases, it will

respond at least with a packet that acknowledges the master’s transmission. In our example,

the packet sent by the second slave occupies only one slot and the master is free to address

slave 1 in slot 4. If the master does not use its transmission right like in slot 6, no slave is

allowed to send in the subsequent odd numbered slot.

Figure 3-11: Time division duplex access scheme


53

For full duplex transmission a Time-Division Duplex scheme is used, in which the

channel is divided in slots of 625ms each. Information is exchanged by means of packets,

each packet covers a single slot, but it can be extended up to five slots.

A basic Bluetooth device consists of:

◊ Radio unit

◊ Link control unit

◊ Link control and I/O management unit (for link management and host terminal interface

functions)

Figure 3-12: Bluetooth system functional blocks

The BT system provides point to point or point to multi-point connections; a connection

of two or more BT units sharing the same channel is called piconet. One BT unit acts as

master (M) of the piconet, while the other(s) act as slave(s) (S). Multiple piconets with

overlapping coverage form a scatternet. Each piconets can only have single master, but slaves

can operate in different piconets (by means of time division multiplex), a master in one

piconet can be slave in others piconets Figure 3-13.

M

S S S S

M

S S S

S/M

S S S

M

a b c

Figure 3-13: Examples of Bluetooth piconets

2.4GHzBluetooth

Radio

Buetoothlink

controller

Bluetoothlink

controller& I/O

HOST


54

Bluetooth can support an asynchronous data channel (ACL), up to three simultaneous

synchronous voice channels (SCO), or a channel that simultaneously supports asynchronous

data and synchronous voice (both the applications in one channel). The asynchronous channel

support up to 721kb/s plus 57.6kb/s in the return direction (asymmetric) or 433.9kb/s

symmetric. Each voice channel supports 64kb/s in each direction.

3.5.3 HIPERLAN

HIPERLAN includes a family of four standards: HiperLAN type1, HiperLAN type2,

HiperAccess (HiperLAN type3), HiperLINK (HiperLAN type4):

Table 3-2: HiperLAN Family of Standards

Figure 3-14: HiperLAN Reference Model

In the following part, we consider only the HiperLAN/2.


55

ETSI/BRAN HIPERLAN type 2 (HIPERLAN/2) is a short range wireless access

scheme intended for complementary access mechanism for UMTS systems as well as for

private use as a wireless LAN type system.

It offers high speed access (25 Mbit/s typical data rate) to a variety of networks

including the UMTS core networks, ATM networks and IP based networks. Spectrum has

been allocated for HIPERLAN in the 5 GHz range.The HIPERLAN/2 functional

specifications encompass the Physical (PHY), Data Link Control (DLC) and Convergence

(CL) layers . In particular, CL performs service specific functions between the DLC layer and

the network layer. In other words, Service Specific Convergence Sublayers (SSCS) are used

on top of the HIPERLAN/2 PHY and DLC layers to provide access to networks such as

Ethernet, IEEE 1394 (firewire), IP, ATM, or UMTS networks. This makes HIPERLAN/2 a

multi-network air interface. The reference protocol stack for the AP/CC is depicted in Figure

3-15

Figure 3-15: HIPERLAN/2 : reference protocol stack for the AP/CC

The PHY layer maps MAC PDUs to PHY PDUs and adds PHY signalling such as

system parameters and headers intended for RF signal synchronisation. The signal modulation

Physical Layer

Convergence Layer

Control Plane User Plane

DLC Control SAP

DLC Connection

Control Association

Control Rad io

Resource Control

RLC

DLC User SAP

Error C ontro l

Radio Link C ontrol Sub-layer

Medium Access C ontrol

Data Link C ontrol - Basic Data Transport Function

One instance per MT

One instance per AP

One instance per DLC User Connection, identified by DUC ID (MAC ID + DLCC ID)

H igher Layers

Scope of HIPERLAN /2 standards

CL SAPs


56

is based on the Orthogonal Frequency Division Multiplexing (OFDM) with several sub-

carrier modulation and forward error correction combinations that allow coping with various

channel configurations.

The main parameters have the following values:

• FFT size: 64.

• Number of used sub-carriers: 52, where 48 sub-carriers are used for data and the rest for

pilots.

• Channel spacing: 20 MHz.

• Sampling rate: 20 Msamples/s.

• Guard interval: 800 ns default mode corresponding to 16 time samples; 400 ns as an

option.

• Sub-carrier modulation: BPSK, QPSK, 16QAM and optionally 64QAM.

• Sub-carrier demodulation: Coherent.

• Mandatory FEC: a rate 1/2, constraint length 7 mother convolutional code (9/16 and 3/4

by code puncturing).

• Supported data rates: 6, 9, 12, 18, 27, 36, 54 Mbit/s.

• Interleaving: Block interleaving with the size of one OFDM symbol.

The DLC layer performs functions for MAC, Error Control (EC) and Radio Link Control

(RLC). Signalling information and payload are conveyed over logical channels which are

mapped to transport channels associated with physical resources, in a time-division duplex

(TDD) and time-division multiple access (TDMA) fashion using a dynamic time-slotted

structure (MAC frame) carrying simultaneously down-link and up-link traffic.

Each MAC frame has a fixed duration of 2 ms comprising dedicated time slots for AP

and MTs to transmit plus additional slots with contention resolution for MTs to request

resources. The MAC sublayer is responsible for assigning PHY resources to carry basic

signalling information related to network and system configuration and to fulfil transmission

requests received from the RLC sublayer. Fixed length fields are used to broadcast regular

signalling information whereas other slots are dynamically allocated to DLC connections and

control functions. The MAC frame is therefore dynamically adapted to meet the current traffic

requirements.


57

The RLC sublayer [3] performs Association Control Function (ACF), DLC Connection

Control (DCC) and Radio Resource Control (RRC). The ACF controls the association and

disassociation of mobile terminals to an AP (select the AP with the best radio link quality,

give the MT a MAC-ID upon association, release). The DCC controls DLC connections

requested by a MT with a valid MAC-ID or by the AP by assigning a DLC connection ID.

The RRC performs dynamic frequency selection (DFS), controls power saving modes and

monitors radio link quality so that MTs can initiate a handover. The EC sublayer performs

selective repeat (SR) ARQ with a packet discard mechanism intended for delay-critical

applications. There exist two CLs, namely the packet based (targeted to support Ethernet or IP

traffic) and the cell based (targeted to support ATM traffic) ones.

The packet based CL (under development in the WINE project) consists of two sublayers,

being the Common Part (CP) sublayer and the SSCS. The former mainly performs SAR

functions (basically, higher layer PDUs are segmented to fixed size DLC SDUs of 48 bytes

each). The latter adapts higher layer traffic to the HIPERLAN/2 layers. At the time of this

writing, only the Ethernet SSCS has been specified, so as for the HIPERLAN/2 system to

accept Ethernet frames.

In a HiperLAN/2 network, data is transmitted on connections between the MT and the AP that

have been established prior to the transmission using signalling functions of the HiperLAN/2

control plane.

Connections are time-division-multiplexed over the air interface. There are two types

of connections, point-to-point and point-to-multipoint. Point-to-point connections are

bidirectional whereas point-to-multipoint are unidirectional in the direction towards the

Mobile Terminal.

The connection-oriented nature of HiperLAN/2 makes it straightforward to implement

support for QoS. Each connection can be assigned a specific QoS, for instance in terms of

bandwidth, delay, jitter, bit error rate, etc. It is also possible to use a more simplistic approach,

where each connection can be assigned a priority level relative to other connections.

This QoS support in combination with the high transmission rate facilitates the simultaneous

transmission of many different types of data streams, e.g. video, voice, and data.

In HIPERLAN, mobile devices can agree upon awake patterns (e.g., periodic wake-ups to

receive data), some nodes in the networks must be able to buffer data for sleeping devices

and to forward them at the right time.


58

The power conservation functions are performed by two roles: p-supporter and p-

saver. P-saver is the power conserving device, and p-supporter are the neighbor of the p-saver

who defers transmission of packets to the p-saver. P-saver will broadcast to its neighbors the

pattern when it will sleep and when it will wake. Using such information, p-supporter can

know when to transmit the buffered packets to p-saver.

In this mechanism, the periodicity and length of the sleep/wake intervals can be

selected to match different application needs. So p-saver can decide how to make best use of

its power.

3.6 QOS IN WLAN S

QoS in a wireless mobile network is substantially more complex than in a purely wired

network, because the wired network deals with integrated services in a relatively static

manner. It is sufficient to establish or guarantee that the end-to-end path has adequate

resources to deliver an information flow between end users with the negotiated QoS. With

resource reservation one can prearrange for resources to be dedicated for the duration of the

flow, thereby guaranteeing the bandwidth, delay, and error rates contracted for by the

application. Such a contract remains in effect so long as no resource fails.

The situation in a wireless mobile network is much more volatile, because a mobile

node’s end-to-end path is likely to change as it moves through the network, and the wireless

link is subject to wide fluctuations in performance and reliability. Resource reservation is thus

complicated by the need to consider not only resource availability on the initial end-to-end

path but also on other paths likely to be be used as the node’s position changes.

Research in techniques for reserving resources in such a way as to minimize the

probability that a flow will be blocked when it is rerouted in response to a node’s movement

is essential in cellular and ad hoc wireless networks.


59

PART TWO Scheduling Policies and QoS in WINE


60

4 QoS AND SCHEDULING POLICIES

4.1 INTRODUCTION

In Chapter 1 we mentioned the need for QoS providing in the Internet: the current trend

towards multiplexing and services integration on the IP layer of an increasing number of

applications with different characteristics implies a series of issues about communication

networks management. The requirements of several applications may widely vary in terms of

parameters such as the packets transfer delay between source and destination, its variance, the

share of allocated bandwidth per connection, the percentage of packet lost, etc. Audio and

video applications, for instance, show more binding requirements with respect to transfer

delay, that are not compromised by the loss of a modest percentage of packets; on the other

hand, data applications have more loose timing requirements, but they’re more sensitive to

packet losses.

Services integration and QoS policies in wireless networks are more difficult with respect to

wired networks because:

• IP layer currently manages packet scheduling in a Best Effort way, without any

guarantees about the offered service;

• Existing standards for wireless LAN show very different characteristics about physical

medium access rules, maximum capacity of wireless channel and services that MAC

layer offers to upper layers;

• Let alone the different existing standards, available bandwidth on wireless LANs is

relatively scarce with respect to the available bandwidth for Second Generation

Ethernet Networks;

• The actual available bandwidth depends on current channel condition, which may

widely vary depending on environmental conditions;


61

• IP layer standardization is well defined and there’s not much room for modifications

which take into account wireless channel peculiarities.

4.2 QOS MECHANISM

Networks are built by concatenating network devices such as switches and routers. These

forward traffic among themselves using interfaces. If the rate at which traffic arrives at an

interface exceeds the rate at which the interface can forward traffic to the next device,

congestion occurs. Thus, the capacity of an interface to forward traffic is a fundamental

network resource. QoS mechanisms work by allotting this resource preferentially to certain

traffic over other traffic.

In order to do so, it is first necessary to identify different classes of traffic. Traffic arriving at

network devices is separated into distinct flows via the process of packet classification.

Traffic from each flow is then directed to a corresponding queue on the forwarding interface.

Queues on each interface are serviced according to some algorithm. The queue servicing

algorithm determines the rate at which traffic from each queue is forwarded, thereby

determining the resources allotted to each queue and to the corresponding flows. Thus in

order to provide network QoS, it is necessary to provision or configure the following in

network devices:

• Classification information by which devices separate traffic into flows, for example, per-

connection and per-class.

• Queues and queue servicing algorithms that handle traffic from the separate flows.

Information classification can be defined according to its modality:

• Per Flow: A “flow” is defined as an individual, unidirectional, data stream between two

applications (sender and receiver), uniquely identified by a 5-tuple (transport protocol,

source address, source port number, destination address, and destination port number).

• Per Aggregate: An “aggregate” is simply two or more flows. Typically the flows will

have something in common (e.g. any one or more of the 5-tuple parameters, a label or a

priority number, or perhaps some authentication information).


62

We can differentiate between “QoS per-Flow” and “QoS per-Aggregate” based on QoS to be

applied on a single “flow” or on a set of “flow aggregates”.

4.3 QOS APPROACH: INTSERV AND DIFFSERV

In Internet, the best effort service has been the service traditionally offered. It is its nature the

reason of the success of the Internet, which makes it very cheap and affordable by anyone

and. The fact that the IP is connectionless and does not offer any guarantee to the user makes

the IP highly adaptable to any platform as it does not impose any particular requirement to the

underlying network. The IP layer enhanced with the more reliable TCP can provide a

satisfactory service for applications that generate elastic traffic. The Internet protocol suite is

now world-wide-spread in computer networks and recognized as the standard for

interworking, the next step cannot be elsewhere if not towards the QoS provision and this

could include valid alternatives to TCP so as to allow time-sensitive applications to be

supported in the Internet. Much work can be carried out on UDP and other real-time

protocols.

As regards to IP, its main characteristics of being totally connectionless and making no traffic

differentiation can become limiting factors to its development.

Two school of thoughts are facing nowadays to propose improvements to IP, these proposes

respectively the:

• Integrated services (IntServ): network resources are apportioned according to an

application’s QoS request, and subject to bandwidth management policy.

• Differentiated services (DiffServ): network traffic is classified and apportioned

network resources according to bandwidth management policy criteria. To enable

QoS, network elements give preferential treatment to classifications identified as

having more demanding requirements.


63

The IntServ approach proposes a radical break with the past and the present Internet, adding

ATM-like connection-oriented features, introducing states and performing fine control of

resources on a per-flow basis. This is the better approach to achieve QoS guarantee. However,

a per flow management has scalability problems when the number of flows crossing a node

increases over a certain extent, typically the Internet backbone could not work with an IntServ

architecture, at least for the moment considering the available technology. The DiffServ has

born more recently and proposes a coarser control of network resources and traffic

management only on a per-class basis. It doesn’t have the IntServ scalability problems

because it treats aggregates of flows rather then single flows, but it can exert a weaker control

on the traffic and achieving certain standard of QoS is more difficult. If a DiffServ

architecture should be provided with a signaling protocol to allow a coordination between

network and users is still a mater to clarify.

4.4 THE INTSERV MODEL

The IntServ is a QoS model developed by the IETF to provide per-flow quality of service

guarantees to individual application sessions.

The IntServ architecture defines two major high-quality service classes besides the Best Effort

service class, traditionally offered by the IP: Guaranteed Service and Controlled-Load

Service. Each of them provides different kinds of a quality of service guarantees.

• Guaranteed Service: the Guaranteed Service definition, defined in provides firm

(mathematically provable) bounds on the queuing delays that a packet will experience

in a router and loss probability for packets of a given flow, under the condition that the

flow complies with its traffic contract.

• Controlled-Load Service: A session receiving Controlled-Load Service will receive

"a quality of service closely approximating the QoS that the same flow would receive

from an unloaded network element.", e.g., delay and loss. In other words, the session


64

may assume that a "very high percentage" of its packets will successfully pass through

the router without being dropped and will experience a queuing delay in the router that

is close to zero. Interestingly, Controlled-Load service makes no quantitative

guarantees about performance. It does not specify what a "very high percentage" of

packets meant quantitatively nor in which terms quality of service closely

approximates that of an unloaded network element. A flow is served with a CLS as

long as it always complies with its traffic contract.

• The IntServ model has two key features:

• Reserved Resources. An Internet node is required to know how many resources

(buffers, link bandwidth) are already reserved for on-going sessions so as it can

determine whether to allocate new resources for new sessions or not.

• Call Setup. A session requiring QoS guarantees must first be able to reserve sufficient

resources at each network node on its source-to-destination path to ensure that its end-

to-end QoS requirement be met. The call set-up process is assisted by the call

admission function, which is performed by each node on the path. The admission

control algorithm in each node determines the resources required by a new session

requesting to be served with a high quality class. It then considers the resources that

are already allocated to other on-going sessions, and determine whether it has

sufficient resources to satisfy the per-hop QoS requirement of the new session. This

decision is taken considering the impact of admitting the new session on the quality of

service of the on-going session. The admission of a new session has not to lead to no

longer satisfying the QoS guarantees agreed for the already admitted session. An

example of IntServ model is the RSVP protocol. The ReSerVation Protocol (RSVP) is

a signaling protocol that provides reservation setup and control to enable the

integrated services, which is intended to provide the closest thing to circuit emulation

on IP networks. RSVP is the most complex of all the QoS technologies, for

applications (hosts) and for network elements (routers and switches).Here is a

simplified overview of how the protocol works, as illustrated in Figure 4-1.


65

• Senders characterize outgoing traffic in terms of the upper and lower bounds of

bandwidth, delay, and jitter. RSVP sends a PATH message from the sender that

contains this traffic specification (TSpec) information to the (unicast or multicast

receiver(s)) destination address. Each RSVP-enabled router along the downstream

route establishes a “path-state” that includes the previous source address of the PATH

message (i.e. the next hop “upstream” towards the sender).

• To make a resource reservation, receivers send a RESV (reservation request) message

“upstream”. In addition to the TSpec, the RESV message includes a request

specification (Rspec) that indicates the type of Integrated Services required—either

Controlled Load or Guaranteed--and a filter specification (filter spec) that

characterizes the packets for which the reservation is being made (e.g. the transport

protocol and port number). Together, the RSpec and filter spec represent a flow-

descriptor that routers use to identify each reservation (a.k.a., a “flow” or a “session”).

• When each RSVP router along the upstream path receives the RESV message, it uses

the admission control process to authenticate the request and allocate the necessary

resources. If the request cannot be satisfied (due to lack of resources or authorization

failure), the router returns an error back to the receiver. If accepted, the router sends

the RESV upstream to the next router.

• When the last router receives the RESV and accepts the request, it sends a

confirmation message back to the receiver (note: the “last router” is either closest to

the sender or at a reservation merge point for multicast flows).

• There is an explicit tear-down process for a reservation when sender or receiver ends

an RSVP session.


66

Figure 4-1: RSVP protocol scheme

RSVP provides the highest level of IP QoS available. It allows an application to request QoS

with a high level of granularity and with the best guarantees of service delivery possible. This

sounds wonderful and leaves one wondering why we need anything else. The reason is that it

comes at the price of complexity and overhead, thus is overkill for many applications and for

some portions of the network. Simpler, less fine-tuned methods are needed, and that is what

DiffServ provides.


67

4.5 THE DIFFSERV MODEL

The ability to request and reserve per-flow resources makes it possible for an IntServ

architecture to provide individual flows with quality of service guarantees. However, as work

on IntServ and RSVP proceeded, some of the difficulties associated with the IntServ model

and per-flow reservation of resources begun to be uncovered:

• Scalability. The per-flow resource reservation in RSVP implies the need for a node to

process resource reservations requests and to maintain per-flow state for each flow that

is going to pass through that node. These actions can become an unacceptable

processing burden when hundreds of thousands of different flows must be handled.

Similarly the need to exchange and store per-flow information is another heavy burden

for core routers.

• Flexible service models. The IntServ framework provides for a small number of pre-

specified service classes. This particular set of service classes does not allow for more

qualitative or relative definitions of service distinctions. These more qualitative

definitions might well better fit our intuitive notion of service distinction.

• Better-than-best-effort service to applications, without the need for host RSVP

signaling. Few hosts in today's Internet are able to generate RSVP.

These considerations have led to the DiffServ activity. The DiffServ provides scalable and

flexible service differentiation, i.e., the ability to handle different classes of traffic in different

ways within the Internet. The need for scalability arises from the fact that hundreds of

thousands of simultaneous source-destination traffic flows may be present at a backbone

router of the Internet. We will see shortly that this need is met by placing only simple

functionalities within the core network, with more complex control operations being

implemented towards the "edge" of the network. The need for flexibility arises from the fact

that new service classes may arise and old service classes may become obsolete. The

differentiated services architecture is flexible in the sense that it does not define specific

services or service classes (e.g., as is the case with IntServ). Instead, the differentiated

services architecture provides the functional components, i.e., the "pieces" of a network

architecture, with which such services can be built.


68

The DiffServ architecture consists of two sets of functional elements:

• Edge functions: packet classification and traffic conditioning. At the incoming

"edge" of the network (i.e., at either a differentiated services capable host that

generates traffic or at the first DiffServ-capable router that the traffic passes through),

arriving packets are marked. More specifically, the Differentiated Service (DS) field

of the packet header is set to some value. The mark that a packet receives identifies the

class of traffic to which it belongs. Different classes of traffic will then receive

different service within the core network. After being marked, a packet may then be

immediately forwarded into the network, delayed for some time before being

forwarded, or may be discarded. A question not addressed by the DiffServ working

group is how the classifier obtains the "rules" for such classification. This could be

done manually, i.e., the network administrator could load a table of source addresses

that are to be marked in a given way into the edge routers, or could be done under the

control of some yet-to-be-specified signaling protocol.

• Core function: forwarding . When a DiffServ-marked packet arrives at a DiffServ-

capable router, the packet is forwarded onto its next hop according to the so-called

per-hop behavior (PHB) associated with that packet's class. The per-hop behavior

influences how a router's buffers and link bandwidth are shared among the competing

classes of traffic. A crucial tenet of the DiffServ architecture is that a router's per-hop

behavior will be based only on packet markings, i.e., the class of traffic to which a

packet belongs. Thus, the differentiated service architecture obviates the need to keep

router states for individual source-destination pairs, an important consideration in

meeting the scalability requirement discussed at the beginning of this section.

The IETF Differentiated Services provides a simple and coarse method of classifying services

of various applications. Although others are possible, there are currently two standard per hop

behaviors (PHBs) defined that effectively represent two service levels (traffic classes):

• Expedited Forwarding (EF): Has a single codepoint (DiffServ value). EF minimizes

delay and jitter and provides the highest level of aggregate quality of service. Any traffic

that exceeds the traffic profile (which is defined by local policy) is discarded.

• Assured Forwarding (AF): Has four classes and three drop-precedences within each

class (so a total of twelve codepoints). Excess AF traffic is not delivered with as high


69

probability as the traffic “within profile,” which means it may be demoted but not

necessarily dropped.

As illustrated in Figure 4-2, PHBs are applied by the conditioner to traffic at a network

ingress point (network border entry) according to pre-determined policy criteria. The traffic

may be marked at this point, and routed according to the marking, then unmarked at the

network egress (network border exit). Originating hosts can also apply the DiffServ marking,

and there are a number of advantages in doing so.

Figure 4-2: Differentiated Services Architecture

DiffServ assumes the existence of a Service Level Agreement (SLA) between networks that

share a border. The SLA establishes the policy criteria, and defines the traffic profile. It is

expected that traffic will be policed and smoothed at egress points according to the SLA, and

any traffic “out of profile” (i.e. above the upper-bounds of bandwidth usage stated in the

SLA) at an ingress point have no guarantees (or may incur extra costs, according to the SLA).

The policy criteria used can include time of day, source and destination addresses, transport,

and/or port numbers (i.e. application Ids). Basically, any context or traffic content (including

headers or data) can be used to apply policy.


70

Figure 4-3: IPv6 and IPv4 DS field

When applied, the protocol mechanism that the service uses are bit patterns in the “DS-byte,”

which for IPv4 is Type-of-Service (ToS) octet and for IPv6 is the Traffic Class octet. As

illustrated in Figure 4-3, although the DS field uses the IPv4 ToS byte, as defined in RFC 791

(IP), it does not preserve the original IPv4 ToS bit values as defined by RFC 1349 (ToS). The

IP Precedence bits (0-2) are preserved, however. And although it is possible to assign any

PHB to the codepoints in this range, the (required) default PHBs are equivalent to IP

Precedence service descriptions, as described in detail in RFC 1812.

The simplicity of DiffServ to prioritize traffic belies its flexibility and power. When DiffServ

uses RSVP parameters or specific application types to identify and classify constant-bit-rate

(CBR) traffic, it will be possible to establish well-defined aggregate flows that may be

directed to fixed bandwidth pipes. As a result, you could share resources efficiently and still

provide guaranteed service.

4.6 MANAGING QUEUES

It is clear that, in order to provide network QoS, it is necessary to provision or configure the

following in network devices:

• Classification information by which devices separate traffic into flows.

• Queues and queue servicing algorithms that handle traffic from the separate flows.

As a consequence, apart from the kind of approach to QoS that is used, it will be a matter of

managing network traffic as a set of separate packet streams. Usually two separate procedures

can be adopted:


71

• Traffic has to be analyzed, and eventually limited, to avoid congestion;

• The packet to be sent must be chosen between several streams of packets.

In the following paragraphs we’ll briefly summarize those two aspects of network traffic

management, usually referred to as Traffic Control and Scheduling Policies.

4.7 TRAFFIC CONTROL : POLICING AND SHAPING

Policing and Shaping offers two kinds of traffic regulation mechanisms. Are used to control

the rate at which traffic is sent to the network. Their main purpose is to avoid network

congestion.

Policers and shapers usually identify traffic descriptor violations in an identical manner. They

usually differ, however, in the way they respond to violations, for example:

• A policer typically drops traffic.

• A shaper typically delays excess traffic using a buffer, or queueing mechanism, to

hold packets and shape the flow when the data rate of the source is higher than

expected.

Traffic shaping and policing can work in tandem. For example, a good traffic shaping scheme

should make it easy for nodes inside the network to detect misbehaving flows. This activity is

sometimes called policing the flow’s traffic.

4.7.1 Leaky-Bucket

The Leaky-Bucket is the most simple mechanism to perform traffic control. The size (depth)

of the bucket and the transmit rate generally are user configurable and measured in bytes. The

leaky bucket control mechanism uses a measure of time to indicate when traffic in a FIFO

queue can be transmitted to control the rate at which traffic is leaked into the network. It is

possible for the bucket to fill up and subsequent flows to be discarded.


72

Figure 4-4: The leaky bucket

As the leak rate is a fixed parameter, there will be many instances when the traffic volume is

very low and large portions of network resources (bandwidth) are not being used. It can thus

be said that the leaky bucket implementation does not efficiently use the available network

resources.

4.7.2 Token-Bucket

The token bucket is a control mechanism that dictates when traffic can be transmitted based

on the presence of tokens in a bucket. Whereas the leaky bucket fills with traffic and steadily

transmits traffic at a continuous fixed rate when traffic is present, traffic does not actually

transit the token bucket. The token bucket makes use of the network resources more

efficiently by allowing flows to burst up to a configurable burst threshold.


73

Figure 4-5: The tocken bucket

The token bucket contains tokens, each of which can represent a unit of bytes. The

administrator specifies how many tokens are needed to transmit however many number of

bytes. When tokens are present, a flow is allowed to transmit traffic. If there are no tokens in

the bucket, a flow cannot transmit its packets.

A variation of the simple token bucket implementation with a singular bucket and a singular

burst rate threshold is one that includes multiple buckets and multiple thresholds. In this case,

a traffic classifier could interact with separate token buckets, each with a different peak-rate

threshold, thus permitting different classes of traffic to be shaped independently.

4.7.3 Dual Leaky Bucket (DLB)

A Dual Leaky Bucket is a combination of a leaky bucket and a token bucket. While a token

bucket allows individual flows to burst to their peak rate, it also allows individual flows to

dominate network resources for the time during which tokens are present in the bucket or up

to a defined burst threshold.

Dual Leaky Buckets (DLBs) can be used as a traffic envelope

• to provide a traffic specification on connection set-up

• to police the traffic associated with a flow which was admitted with a QoS contract

• to shape traffic in a congestion control algorithm by smoothing peaks of traffic.


74

b bytes

r bytes/s

p bytes/s

Offered traffic

Admitted traffic

The first two functions are used in connection-oriented architectures provided with an

admission control module and with negotiation capabilities. The last function can operate in a

connectionless environment as well Figure 4-6 represents a DLB.

Figure 4-6: DLB model

A DLB is defined by three parameters:

• token rate “r ”

• token bucket size “b”

• peak rate “p”

We will consider two additional parameters, which are necessary to use a DLB in practical

cases. These are:

• the minimum policed unit “m”

• the maximum packet size “M ”(this cannot exceed the maximum transfer unit (MTU) of

the network)

When the DLB is used to describe a traffic profile, the parameter r specifies the average rate,

the buffer size b is a measure of the degree of burstiness of the flow and the parameter p

provides the maximum bit rate. More precisely, when a DLB (p, r, b) declaration for a data


75

flow is given, the following relations for R(t) (the number of bytes which has been issued up

to the instant t) has to be satisfied for any interval (t0,t1):

R(t1)-R(t0) ≤ min( b+ r*(t1-t0), p*(t1-t0))

Once a flow has been admitted policing can be performed using the advertised DLB

parameters. At the beginning of the transmission the flow is given b bytes of credit to use.

The transmission consumes this credit at the source rate and at the same time the bucket is fed

at a rate of r bytes/s. If the bucket gets completely emptied during the transmission, the

subsequent packets are queued or discarded to give the bucket time to accumulate new credits.

When new tokens are available, the transmission can recommence. If, on the contrary, the

bucket reaches b bytes of credits, it stops being fed. An additional constraint imposes to the

admitted traffic rate not to go over the peak rate p in any case.

If the other two parameters are taken into account, packets smaller than m bytes are counted

as they were as big as m bytes and packets cannot be larger than M bytes in any case. In

addition, the previous relation becomes:

R(t1)-R(t0) ≤ min[M +p*(t1-t0), b+ r*(t1-t0)]

This is the actual policing criterion to determine whether or not packets belonging to a flow

are conformant with its traffic specification. If the arrival of a packet causes the previous

relation to be no longer satisfied, the packet is declared as non-conformant. Non-conformant

packets could be delayed, marked or simply discarded depending on the local network policy.

Figure 4-7: Data policing with a DLB


76

4.8 SCHEDULING POLICIES

We now turn our attention to the different scheduling policies that can be used to select

packets for transmission on a link. There are several aspects that are to be considered when

choosing a scheduling algorithm. Some of the main ones are:

• Isolation of flows: The algorithm must isolate an end-to-end session from the

undesirable effects of other (possibly misbehaving) sessions. That is, the algorithm

must be able to maintain the QoS guarantees for a session even in the presence of

other misbehaving flows. Note that isolation is necessary even when policing

mechanisms are used to shape the flows at the entry point of the network, as the flows

may accumulate burstiness within the network.

• Low end-to-end delays: The algorithm must provide end-to-end delay guarantees for

individual sessions. In particular, it is desirable that the end-to-end delay bound of a

session depends only on the parameters of the session, such as its bandwidth

reservation, and is independent of the behavior of other sessions. A higher end-to-end

delay bound usually implies a higher level of burstiness at the output of the scheduler,

and consequently requires larger buffers in the switches to avoid packet loss.

Therefore, the delay bound affects not only the end-to-end behavior of the session, but

also the amount of buffer space needed in the switches.

• Utilization : The algorithm must utilize the link bandwidth efficiently.

• Fairness: The available link bandwidth must be divided among the connections

sharing the link in a fair manner. An unfair scheduling algorithm may offer most of

the resources only to a few high quality flows. Low quality flows should be always

served with an acceptable quality.

• Simplicity of implementation: The scheduling algorithm must have a simple

implementation.. In packet networks with larger packet sizes and/or lower speeds, a

software implementation may be adequate, but scheduling decisions must still be

made at a rate close to the arrival rate of packets.

• Scalability: The algorithm must perform well in switches with a large number of

connections, as well as over a wide range of link speeds.


77

• Complexity: The amount of the time available to schedule a single packet;

In this section we will look at the most famous scheduling algorithms.

4.8.1 First Come First Served

This is one of the simplest scheduling policies whose operation is as its name suggests, i.e.,

packets are served in the order in which they are received. While this may seem like a fairly

poor way of providing differentiated service, it is quite simple to implement. In particular,

insertion and deletion from the queue of waiting packets is a constant time operation and does

not require any per-flow state to be maintained. Not surprisingly, the First Come First Served

(FCFS) policy is one of the most commonly implemented scheduling policies.

The FCFS policy does not lend itself readily to providing delay or rate guarantees. One way

to provide a delay bound is to limit the size of the queue of waiting packets.

That way, once a packet is queued up for transmission it is guaranteed to be sent out in the

time it takes to serve a full queue of packets. However, packets that arrive when the queue is

full have to be dropped. To ensure that the drop probability is below a certain threshold only a

limited number of flows should be accepted. A simple mechanism for performing this

decision is to compute an effective bandwidth that quantifies the amount of link capacity that

is required for each flow.

Given that the FCFS policy is one of the least sophisticated in its operation, it does not

explicitly provide any mechanism for fair sharing of link resources. However, with the help of

some buffer management mechanisms it is possible to control the sharing of bandwidth.

4.8.2 Fixed Priority Scheduling

This policy offers some ability to provide different grades of service with a rather coarse

granularity. Traffic is classified as belonging to one of a fixed number of static priorities.

The link multiplexer maintains a separate queue for each priority and serves a packet in a

lower priority queue only if all the higher priority queues are empty. Each queue is served in a

FCFS manner and so this scheduling mechanism is almost as simple as the FCFS policy with

the added complexity of having to maintain a few queues. Selecting a packet for transmission


78

is a fixed cost operation that only depends on the number of priority levels and is independent

of the number of flows that are being multiplexed.

While the priority scheduler does offer a certain amount of service differentiation capability,

it still does not readily allow end-to-end performance guarantees to be provided on a per-flow

basis. Rather, it only provides for one class of traffic to receive better service than another

class of traffic at a single link. As with FCFS, the provision of end-to-end delay guarantees

with a fixed priority scheduler can achieved by limiting buffer sizes. However, one important

difference, that has to be accounted for, is the fact that a lower priority packet will be served

only after all the packets from the higher priority queues are transmitted.

This is bound to affect the variability in the delay that is observed by the lower priority

packets. In general both the FCFS and fixed priority schedulers are not ideal candidates when

it comes to providing guaranteed end-to-end delay bounds.

Another problem with the priority scheduler is that different switches may have different

levels of priority and matching these levels from an end-to-end perspective is no easy feat.

4.8.3 Weighted Fair Queuing (WFQ)

The Weighted Fair Queuing (WFQ) serves excess traffic in a fair manner, where fairness is

measured relative to the amount of resources that are reserved for each flow.

The Weighted Fair Queuing (WFQ) service discipline is considered as the ideal traffic

scheduling algorithm in terms of its delay and fairness properties (advantages), but its

computation complexity is asymptotically linear in the number of connections serviced by the

scheduler. Thus, its implementation can become prohibitively expensive in high-speed

networks (drawback).

Generally speaking, WFQ queues traffic in separate queues, according to traffic class

definition, guaranteeing each queue some portion of the total available bandwidth. WFQ

recognizes also when a particular queue is not fully utilizing its allocated bandwidth and

portions that capacity out to the other queues on a proportional basis. WFQ takes queuing to

yet another level, portioning out available bandwidth on the basis of individual information

flows, according to their message parameters.


79

WFQ is a packet-by-packet version of the Generalized Processor Sharing (GPS) scheduler,

which is an ideal fluid model. The GPS discipline is proven to have two desirable properties:

� it can provide and end-to-end bounded-delay service to a session whose traffic is

constrained by a leaky bucket;

� it can ensure fair allocation of bandwidth among all backlogged sessions regardless of

whether or not their traffic is constrained.

Figure 4-8: Capacity sharing

The former property is the basis for supporting guaranteed service traffic while the later

property is important for supporting best-effort service traffic. Since GPS uses an idealized

fluid model that cannot be realized in the real world, various packet approximation algorithms

of GPS have been proposed. Among these, WFQ has been considered the best one in terms of

accuracy. The basic idea behind GPS is that a weight wi is associated with a flow i (i =

1,...,N) and the link capacity is shared among the active flows in direct proportion to their

weight. If s is the link speed, the flow i is guaranteed to obtain, as shows, a minimum service

rate of

sw

ws

N

1jj

ii ⋅=∑

=

(i = 1,...,N).

s

s

w1

w2

w3

wN


80

However, at any given time it is likely that some flows do not have a backlog of traffic

waiting to be transmitted on the link. This will translate into some unutilized link capacity that

can be shared among the backlogged active flows. The GPS shares this excess capacity

among the backlogged flows in proportion to their respective weights. If B(t) denotes the set

of the flows that are back-logged at time t ≥ 0, then the flow i is guaranteed to receive a

minimum service rate of ri(t) given by

∈⋅= ∑

∈

otherwise 0

B(t) sw

w

(t)ri

B(t)jj

i

i

Figure 4-9: Bandwidth redistribution

A peculiarity of the GPS policy is its fair handling of excess traffic, i.e. if two flows are back-

logged during any interval of time they receive service in direct proportion to their weights,

regardless of the amount of excess traffic that any of them may be generating. If Wi(t1, t2)

w3

s

sN s3 s2 s1

w1

w2

wN

Flow with no backlog of


81

denotes the amount of flow i traffic served in the interval (t1, t2), the GPS policy ensure that

for any two flows i, j back-logged during the interval (t1, t2), the following relation holds:

j

j

i

i

w

ttW

w

ttW ),(),( 2121 =

The difference between the two terms of the previous relation is one of the measures used to

quantify fairness among the many approximations of GPS. The ideal GPS has a fairness

measure of 0.

The end-to-end bounded-delay can be computed based on the weight assigned to the flow. Let

γh , h = 1,…,H denote the speed that the traffic envelope for flow i is given by Ai(t) = bi + rit ,

t >=0 and let Ri be the minimum rate guaranteed to flow i by each of the links that it traverses.

Assuming that the stability condition, Ri >= ri , holds, the end-to-end delay guarantee for flow

i is given by

∑=

+−

+=H

hh

hMAX

i

i

i

ii

L

R

MH

R

bD

1

)1(ˆγ

Were Mi denotes the maximum packet length for flow i, and LhMAX denotes the maximum

packet length at link h.

4.8.4 Earliest Deadline First (EDF)

The Earliest Deadline First (EDF) scheduler is a form of a dynamic priority scheduler where

the priorities for each packet are assigned as it arrives. Specifically, a deadline is assigned to

each packet which is given by the sum of its arrival time and the delay guarantee associated

with the flow (characterized by peak rate, average rate and burst size) that the packet belongs

to. The EDF scheduler selects the packet with the smallest deadline for transmission on the

link and hence the name.

The dynamic nature of the priority in the EDF scheduler is evident from the fact that the

priority of the packet increases with the amount of time it spends in the system. This ensures

that packets with loose delay requirements obtain better service than they would in a static

priority scheduler without sacrificing the tight delay guarantees that may be provided to other

flows. An advantage of EDF is to minimize the maximum lateness of packets. Here, lateness


82

is defined as the difference between the deadline of a packet and the time it is actually

transmitted on the link.

EDF has been proven to be an optimal scheduling discipline in the sense that, if a set of tasks

is schedulable under any scheduling discipline (i.e., if the packets can be scheduled in such a

way that all of their deadlines are met), then the set is also schedulable under EDF.

As mentioned above, the GPS policy guarantees a delay bound on a per-flow basis based on

the weight that is assigned to the flow. These weights are closely coupled to a reserved rate,

and for a flow to receive a small end-to-end delay guarantee it is necessary that it be allocated

a relatively large rate. This can lead to an inefficient use of resources, particularly if a low

bandwidth flow requires tight end-to-end delay guarantees. One of the main attractions of the

EDF policy is that it allows for the separation of delay and throughput guarantees for a flow.

The optimality of EDF and the existence of necessary and sufficient conditions for

schedulability makes EDF an attractive choice for providing delay guarantees for real-time

flows.

In terms of implementation the EDF policy is more complex than the FCFS or the static

priority scheduler. The complexity arises because the scheduler has to pick the packet with the

smallest deadline for transmission on the link.

The EDF policy by itself cannot be used to provide efficient end-to-end delay guarantees. In

order to achieve that, one could reshape the traffic at each node to a pre-specified envelope

before it is made eligible for scheduling. Coupled with traffic shapers the EDF policy can be

used to provide efficient end-to-end delay guarantees on a per-flow basis.

4.8.5 Hierarchical Link Sharing

A network may offer several different services over a single link. The link will, therefore,

have to be partitioned to support the different service classes. Alternatively, a single link in

the network may be shared by several different organizations or departments within an

organization. Each of these may want to receive a guaranteed portion of the link capacity but

are willing to allow other departments or organizations to borrow unutilized link resources.

The hierarchical structure of organizations suggests a hierarchical partitioning of the link

resources. A hierarchical link sharing structure consisting of classes that correspond to some

aggregation of traffic is suggested in and is often referred to as Class Based Queueing

(CBQ). Each class is associated with a link-sharing bandwidth and one of the goals of CBQ is


83

to roughly guarantee this bandwidth to the traffic belonging to the class. Excess bandwidth

should be shared in a fair manner among the other classes. There is no requirement to use the

same scheduling policy at all levels of a link sharing hierarchy, and it is conceivable that

classes carrying interactive traffic may benefit from a simple priority scheduling policy as

opposed to rate-based schedulers .

The GPS policy can be used in a hierarchical manner to provide both link sharing and

individual QoS guarantees to flows. At the top-level of the hierarchy, the weights reflect the

link sharing requirements, while the lower level weights are used to provide individual QoS

guarantees. Whenever an interior node receives service it is distributed among its child nodes

in direct proportion to their weights. Note that there may be more than two levels in the

hierarchy. Except for leaf nodes, other nodes only receive a logical service.


84

5 QoS IN WINE PROJECT

5.1 INTRODUCTION

It is expected that the Internet protocols will play a major role in enabling interworking

of heterogeneous segments in the next future and beyond, as confirmed by the last-two-

decade trend, and will support a variety of applications ranging from simple and traditional

FTP, telnet and e-mailing to most demanding real-time applications and multimedia. This

implies the achievement of two goals. On the one hand, a satisfactory transport of applications

on the basis of their requirements has to be guaranteed, on the other, this has to be achieved

independently of the technology which is adopted to physically transport information.

Now we will focus on transport over wireless access technologies, which is undoubtedly

the most challenging and where a conspicuous part of research in networking is nowadays

oriented.

We introduce the Underlying Network (UN) concept, as a general term to refer to any

link-layer transport network for IP traffic. In particular we will focus on wireless link-layer

transport networks. The term "underlying" points out the fact that the link-layer transport

networks have to provide the physical support, over the wireless run, to the "overlying" IP

protocols. For instance, Bluetooth, IEEE 802.11, Hyperlan II, UMTS, GPRS are UNs.

One of the main challenges of the systems beyond the third generation is an efficient

provision of an end-to-end QoS tailored to the specific requirements of each connection. To

achieve the target QoS for a certain connection means to respect for this connection a “QoS

contract” agreed at connection set-up. This QoS contract can be possibly renegotiated (not in

real-time) while the connection is in progress.

The QoS contract is established by a Connection Admission Control (CAC) Handler

that has to decide, on the basis of the present wireless network load, whether or not the

wireless network will be able to support the new connection, i.e. to respect the various QoS


85

contracts (including the one with the new connection that is going to be established). A

meaningful instance of a possible QoS contract established at the set-up of the connection c

can be as follows:

"It is agreed that the connection c, regardless of the moving within the wireless

network of the mobile terminal supporting the connection, is guaranteed, at any time, an

admission bit rate in the wireless network no lower than Rmin(c). Nevertheless, the wireless

network will do its best for guaranteeing an entry rate in the wireless network as close as

possible to Roffered(c,t). In addition the bits admitted in the wireless network are guaranteed

a transfer delay not exceeding ∆transfer_max(c) and a loss bit rate not exceeding Rloss_max(c)".

As a matter of fact, for each (wired or wireless) network utilized by a certain

connection, a QoS Contract is agreed establishing (i) the statistical characteristics of the

traffic, relevant to the connection in question, which has to be admitted in the considered

network (e.g. in terms of average bit rate and degree of burstiness) (such statistical

characteristics identify the so-called compliant traffic), (ii) as well as the QoS requirements

characterizing such compliant traffic (e.g. in terms of maximum delay tolerated by the IP

datagrams and maximum loss probability of the IP datagrams) within the considered network.

In general, a certain connection makes use of more than one (wired or wireless)

network. At connection set-up, an End-to-End QoS Contract agreed between the user and its

operator is "split" (by means of the so-called Bandwidth Broker mechanism which is currently

investigated as a solution for QoS support in future IP networking) among the various (wired

or wireless) networks crossed by the connection path. For a certain connection, the Bandwidth

Brokers are in charge of splitting the End-to-End QoS Contract in the various QoS Contracts

relevant to the various networks crossed by the connection path. The splitting is performed in

such a way that the respect of the QoS contracts in the various networks entails the

satisfaction of the End-to-End QoS Contract for the connection in question (if an end-to-end

QoS contractual condition is that the delay for a certain connection c has not to exceed Dmax

and if the connection is supported by two subnetworks e.g. a wireless network and a fixed

network, the above-mentioned contractual condition can be split in two: namely the delay in

the wireless network has not to exceed Dmax1 and the delay in the fixed network has not to

exceed Dmax2 with Dmax1+ Dmax2 = Dmax).


86

The respect of the QoS contracts, already a challenging goal in wired networks, is even

more challenging in the wireless networks in which this goal has to be achieved in

conjunction with an efficient exploitation of the available bandwidth which in the wireless

networks is a much more valuable resource than in the wired ones. As a result, in wireless

networks, traffic control strategies can be key factors for respecting the QoS contracts and, at

the same time, efficiently exploiting the available bandwidth.

Two problems arise here: the first is that IP only provides best effort packet delivery

service and may consequently be inadequate to allow the respect of the QoS Contracts; in

addition, it might make inefficient use of the available bandwidth. The second problem

derives from the fact that the various UNs, in general, avails of different mechanisms, not

devoid of remarkable deficiencies, to respect the QoS Contracts (as an example, Bluetooth

offers a connection-oriented service and the possibility of negotiating QoS at connection setup

on a per-flow basis; conversely, typical IEEE 802.11 hardware drivers have a lack of support

for specifying QoS differentiation at the MAC layer, whereas some IEEE 802.11 stations can

be optionally provided with a Point Coordination Function (PCF) to access the wireless

medium in a contention-free window and with a time-bounded service suitable for time-

sensitive applications).

One last aspect to consider is that standardization is well established for the network

layer Internet Protocol and for the UN in frequent use. Therefore, there is little flexibility in

both the IP and the UN layers for improved IP with wireless access.

In order to overcome these problems, the WINE project is proposing to add, between

the IP layer and the UN layers, the Wireless Adaptation Layer (WAL), which is transparent

with respect to both the IP layer and the UN layers, i.e. its insertion between the IP layer and

the UN layers does not modify either the usual IP protocols and the usual UN protocols.

A basic issue is that a same WAL architecture has to be able to work in conjunction

with all the UNs of the considered UN class, i.e., in the WLAN case, the WAL has to provide

the IP layer with a unique interface independent of the particular WLAN standard. So, a same

WAL architecture can be used in different APs (or MTs) in conjunction with different UNs

(e.g. in an AP a in conjunction with Bluetooth, in an AP b in conjunction with IEEE 802.11,

etc.).

The scope of the WAL is to assist the UNs in efficiently respecting the QoS Contracts.

In other words, the WAL has to assist the UNs, on the one hand, in optimizing the


87

exploitation of the valuable bandwidth and, on the other hand, in respecting the various QoS

Contracts. In general, these two requirements are in contrast each other.

The WAL consists of a set of WAL modules which process IP traffic for performance

enhancement. Each module can be activated or disabled depending on the UN the WAL is

built on. Note that, in spite of the fact that the WAL architecture (and the relevant modules) is

the same regardless of the considered UN, a subset of the WAL modules can be chosen and,

in addition, the selected modules can include some parameters that have to be properly tuned

to tailor the requirements of the considered UN. So, as the WAL is placed in an AP (or in an

MT) belonging to a given UN, it has to be properly configured (to activate and disable the

appropriate WAL modules, as well as to tune the appropriate parameters) to match the

requirements of the considered UN. A particular module always active and referred to as WAL

coordinator is in charge for coordinating the WAL module activities; in particular, the WAL

coordinator is responsible for activating and disabling the various WAL modules depending

on the requirements of the UN.

Even more, for a given UN, the WAL Coordinator decides connection-by-connection

the activation/disabling of the various modules, as well as the order in which the various

modules have to process the IP datagrams relevant to the connection in question; for each

connection, the WAL Coordinator carries out the above-mentioned decisions at connection

set-up. So, for instance, the WAL Coordinator in a given AP simultaneously supporting two

connections can decide to activate certain modules for the first connection and other for the

second.

Other basic concept of the WAL is that the various modules avail of the measurements

performed by the UNs. As a matter of fact, an appropriate UN-specific Logical Link Control

interface, (Logical Link Control Translator (LLCT)) is placed between the WAL and the

considered UN. This interface, among other things, is in charge of translating the UN-specific

measurements in format that can be used by the WAL modules. In particular, the "translated"

measurements are passed from the LLCT to the WAL Coordinator that, in turn, distributes the

appropriate measurements to the WAL modules that need them. This mechanism makes it

possible for the WAL modules to perform channel-state-dependent actions, i.e. the WAL

module behaviour can depend on the actual state of the wireless link.


88

The WAL modules perform functions that are either not provided by the UNs, or

provided in an unsatisfactory way. In this respect, note that many functions are, in theory,

foreseen by the UN standards, but in practice, not yet provided by these standards.

The WAL modules which are foreseen in the WINE project are a FEC (Forward Error

Correction) Module, an ARQ (Automatic ReQuest) Module, a Snooping Module and a Traffic

Control Module; in the framework of the WINE project, this last module has been named as

"QoS Module"; in spite of the fact that this name is misleading since the Traffic Control

Module is not the only module aiming at providing the QoS (which instead results from the

cooperation of all the modules), in the following, we will adopt the improper, but "traditional"

QoS Module name. Clearly, the FEC, ARQ and Snooping Modules aim at improving the link

reliability, thus guaranteeing that the maximum tolerated IP datagram loss probability agreed

in the QoS Contract is respected. Conversely, the QoS Module aims:

• at regulating the admission in the UN of a traffic compliant with the one agreed in the

QoS Contract,

• at maximizing the exploitation of the available bandwidth,

• at guaranteeing that the IP datagrams admitted in the UN are carried from the AP to

the MT and vice versa within the maximum tolerated delay agreed in the QoS

Contract.

From the point of view of the data path, the IP datagrams relevant to a certain

connection coming from the IP layer arrive at the WAL Coordinator which forwards them to

the various modules which the WAL Coordinator has activated for the considered connection.

Each module performs its specific functions and returns the IP datagram to the WAL

coordinator. The WAL Coordinator is also in charge of deciding the order in which the

various modules handle the IP datagram. At connection set-up, the WAL Coordinator decides

both the modules which have to be activated for the connection and the order in which these

modules have to handle the IP datagram. These decisions are performed once for all at

connection set-up and hold for the whole connection duration.

Nevertheless, in any case, the QoS Module is the last module which handles the IP

datagram within the WAL; in addition, the QoS Module is the only module which is always

activated, regardless of the UN. In light of the above, the QoS Module forwards the IP

datagram to the LLCT, which, in turn, forward them to the UN (Figure 5-4).


89

Figure 5-1: Example of the path followed by the IP datagram relevant to a certain

connection within the WAL

5.2 WIRELESS ADAPTATION LAYER (WAL)

Different methods for compensating wireless impairments at the link layer exist. The

end goal of the link layer is to present a reliable channel with low packet loss rate to the

Internet Protocol. This is very important since upper layer Internet protocols were not

designed for wireless environments.

The WINE project is considering the most effective strategies available to improve the

performance of wireless Internet. In order to cope with different wireless mediums, an

additional software layer is being designed in between the network layer and the wireless

IP layer

WAL Coordinator

WAL module1

WAL module2

QoS module

LLCT

Underlying network


90

medium specific link layer. This layer is termed the Wireless Adaptation Layer (WAL). The

WAL will run both in access points and wireless terminals.

Figure 5-2: Wireless Adaptation Layer

Standardization is well established for the network layer Internet Protocol and wireless

mediums in frequent use. Therefore there is little flexibility in those layer for innovation for

improved IP over wireless. The WAL allows the development of innovative, flexible, and

dynamic methods for optimizing performance taking into account upper layer requirements

and lower layer impairments.

The WAL can be considered the intelligence of the WINE architecture. It is responsible

for examining the current situation and received packets to make decisions which optimize

performance. The WAL itself does not modify packets, however it makes the decision to hand

off packets to link layer modules, which can. In this way it is not a traditional protocol layer.

The WAL performs these general functions:

• IP Packet examination for decision making

Transport Layer (Mobile Terminal Only)[ TCP, UDP, RTP ]

IPv4, IPv6Routing, Mobility

Wireless Adaptation Layer

Wireless Interface Driver

LLC + MAC

PHY

module X

module Q

module Z

InterfaceSpecific

Wireless S

NM

P A

gen

t


91

• Monitoring of wireless SNMP MIBs

• QoS classification, mapping, and connection setup for wireless interfaces

• Selects link layer modules according to the available information

5.2.1 WAL functional entities

Figure 5-2 shows a detailed WAL functional entity diagram, and we will examine what

each functional entity does:

5.2.1.1 802.2 encapsulator

Immediately when an IP packet is received, the packet is encapsulated in an 802.2 frame

(using the sk_buf in Linux). The WAL 802.2 framing structure is specified in next section.

5.2.1.2 Module handler

This is the intelligence of the WAL concerning link layer modules. When frame arrives

from the encapsulator the IP packet is examined along with information from the

measurement database. This entity stores state information in the storage entity. If this

packet belongs to a flow or TCP connection already handled by modules, it travels through

the same modules. Otherwise the modules this packets travels through is determined from

available information. If a module is needed which has not been loaded, the loader section

handles this function.

5.2.1.3 QoS handler

Intelligent QoS classification is done here. This entity works with the CAC entity and

information from the measurement database and IP packet to classify QoS. It must be

determined how it is handled in the queue and how it is mapped to the lower interface. This

QoS information is passed on in the 802.2 header used for internal signalling.


92

Figure 5-3 :WAL Functional Entities

5.2.1.4 QoS queue

Class based queuing system. Reads QoS information from the 802.2 header.

5.2.1.5 Connection Admission Control (CAC)

CAC module provides admission control service to the QoS handler. This is used only

when a connection orientated wireless interface such as Bluetooth or Hiperlan is used.


93

5.2.1.6 Measurement controller & database

This is the Wireless SNMP functionality inside the WAL. In order to make critical

channel and interface condition information available to the WAL intelligent entities, the

collection of Wireless SNMP statistics is done internally. The measurement controller

collects statistics from the wireless interface driver. This data is stored in the measurement

database which can be accessed by all WAL entities. Finally the measurement controller

gives an interface to the SNMP agent so that all measurement data can be passed on to the

WAL MIB and Wireless MIB. From the SNMP agent this data will then be available through

standard SNMP by external nodes.

5.2.1.7 802.2 Decapsulator

When packets have been processed by all relevant modules, the 802.2 frame is passed

on to this entity. Here the 802.2 frame is simply decapsulated and the IP packet passed on to

the IP layer.

5.2.1.8 Module X, Q, Z

This is the logical space where modules are loaded into. This is really a pool of

modules which are in no fixed order. Module loading and unloading is handled by the

module handler. In the 802.2 header it is specified which modules will be visited and in

which order.

5.2.1.9 Interface translator

The idea of an interface translator (or LLC translator) was introduced in the Patras

meeting. This entity performs the actual interfacing to the wireless interface driver. The

measurement controller is logically located inside this entity.

Downstream: The 802.2 frame is removed from packets which have only internal

signalling. The frame is then passed on to the wireless interface. If QoS or connection

information is included in the 802.2 header, then specific QoS function calls (or framing) and

connection calls are made to the wireless interface.

Upstream: Any WAL type frames will be passed by the wireless interface driver to this

entity. The 802.2 header will be examined and the frame passed on to the first relevant

module.


94

5.2.1.10 Wireless interface driver

This is the Linux driver for the wireless interface card. It is installed as a network

interface (for example: ETH0) and emulates an ethernet type interface.

Notice the packet type? entity. This entity shows the logical process performed in

network interface drivers. When a packet is to be passed up to the next layer, the packet type

is examined to determine where is should be sent. If it is an IP packet with no 802.2 framing,

it is passed to the IP layer directly. If the packet has WAL 802.2 framing, it is passed to the

WAL layer.

The MTU size of this interface is 1500 bytes. The MTU size advertised by the WAL must

then be 1500 - (802.2 header size) bytes.

5.2.2 Link Layer Modules

The Wireless Adaptation Layer, described above, is the intelligence of the WINE architecture.

This layer handles packet examination, QoS classification, and the enabling of link layer

techniques using modules.

Figure 5-3 shows the location of the WAL and Link Layer Modules. Link layer

techniques are programmed in modules, which can be selected by the WAL if the conditions

indicate link layer techniques are necessary. Each module is implemented with an interface

which packets can be passed to from above and below by the WAL.

There are some functions that can be used to handle modules. For example, under

Linux, Init_module and cleanup_module are the usual functions to load/unload modules;

module_insert() is the function called by the WAL loader after the module has been loaded:

the argument passed to module_insert() is a pointer to a callback function within the WAL

loader, that the module must call in order to register itself by the WAL. Statistics about how

each module is operating must be collected by the measurement controller and inserted into

the measurement database. This could be done by making calls to the module_ioctl() call and

requesting this data. Besides, for each module are defined the following functions:

• Open()

• Close()

• Tx()

• Rx()


95

• Ioctl()

Pointers to these functions are stored in the wal_module structure at initialization time.

The module_insert() function passes this information to the WAL, so that it can build a list of

all modules. When all the modules have been loaded, they have to be connected together by

the WAL loader. This is accomplished by calling the open() functions on each module, where

pointers to the preceding and succeding modules are indicated by the WAL loader. In this

way, the double-linked list is built and each module is informed about the functions it has to

call when sending frames back and forth. The tx() and rx() functions use standard struct

sk_buff pointers, as defined under Linux, for passing packets without memory copying.

The 802.2 framer is not loaded by the WAL because it is always present; however, its

functions can be encapsulated into a wal_module structure so that it can be linked to the

module chain.

Examples of modules are:

• SNOOP for TCP streams. This module works by setting a snoop agent at the base

station. Basically, it caches unacknowledged TCP data and performs local

retransmissions. These retransmissions are based on policies that depend on TCP

ACKs from the mobile hosts and timeouts of locally maintained timers. By using

duplicate ACKs to identify packet losses and performing local retransmissions as soon

as these losses are detected, the snoop agent shields the sender from the impairments

at the wireless link.

SNOOP for TCP streams Framing? no Asymmetry asymmetrical

Upper interaction Only for TCP protocol. Does not work with IPSec.

For channels with high packet loss. Lower interaction

IEEE 802.11 X Bluetooth X Hiperlan

References


96

• Automatic Repeat ReQuest. The ARQ module is responsible for compensating the

poor link quality of the wireless channel by retransmitting the packets that have not

delivered correctly. There are several ARQ protocols such as Go-Back-N (GBN) or

Selective Repeat (SR) that could be utilized within WAL. Go-Back-N might be a good

solution due to its simplicity, however it is ineffective in cases of heavy traffic and

poor channel quality. On the other hand SR introduces a large portion of complexity

compared to GBN but it is much more effective in terms of performance. Of course

GBN and SRP are not the only alternatives.Hybrid schemes like “Partial Selective

Repeat superIMposEd on GBN” (PRIME ARQ) try to combine the simplicity of GBN

with the efficiency of SRP. These are a few of the numerous available alternatives

that are to be studied further for the purposes of WAL. An interesting idea would be to

develop different types of ARQ modules that can be utilized within WAL in order to

provide for greater flexibility and adaptability.

Automatic Repeat ReQuest (ARQ) Framing? yes Asymmetry symmetrical

Upper

interaction

Should not be used with video or voice delay sensitive streams.

For channels with high packet loss. Lower

interaction IEEE 802.11 X Bluetooth X Hiperlan

References

• IP Header Compression. This module is used to compress IP and transport layer

headers (TCP and UDP). It is useful on low- or medium-speed wireless links and can

be proved beneficial for several reasons mentioned in RFC2507. Furthermore, it is

targeted for wireless links that experience non-trivial packet loss as well as they

eventually reorder packets. It is based on RFC2507, which in turn considers IP header

compression for point-to-point links. Special care should be taken when this scheme is

applied on multiple-access links, i.e., WLANs. RFC2507 specifies the compression

framework both for IPv4 and IPv6 headers. In addition, eventual IP/UDP/RTP header


97

compression will be in accordance to RFC2508. In connection with WAL,

demultiplexing and configuration parameters should be considered. For example,

RFC2509 includes such mechanisms for IP header compression over PPP. Even

though, such a compression mechanism is not yet in widespread use (as opposed to

Van Jacobson’s approach, RFC1144), it includes an explicit request for retransmission

of an uncompressed packet to allow decompressor re-synchonization without waiting

for a TCP retransmission. Finally, it will be the baseline specification in the context of

the WAL development framework.

IP Header Compression Framing? yes Asymmetry symmetrical

Upper

interaction

Works with longer duration streams, TCP or UDP

For lower bandwidth or overused channels. Lower

interaction IEEE 802.11 X Bluetooth X Hiperlan

References RFC2507

• Forward Error Correction. Forward Error Correction is desirable for many real-time

applications. FEC module will consist on two different modules, one at the receiver

side and the other in the sender. The one placed at the transmitter side will add the

parity bits, whereas the second one at the receiver will remove these parity bits before

error regeneration.

Forward Err.3or Correction Framing? yes Asymmetry symmetrical

Upper interaction Not useful with upper layer encryption (SSL, IPSec, etc..)

For channels with a high loss rate. Lower interaction

IEEE 802.11 X Bluetooth X Hiperlan

References


98

• Link outage protection This module is used to compensate for outage periods of a

wireless interface. This module must process packets before any other modules (to

insure access to raw TCP or UDP packet). The outage protection module will keep a

buffer of size (configurable) for each destination stream of packets. Statistics will be

monitored from the measurement controller such as signal strength and error rate for

destinations which have buffers. When an outage lasting longer than (configurable),

the buffer will be flushed directly to the llc_translator, sending the raw IP packets to

the destination immediately when the link is operational. This may produce duplicate

packets at the destination, but can improve the recovery time of TCP.

Link outage protection Framing? no Asymmetry asymmetrical

Upper

interaction

Useful with TCP or UDP.

Useful on links with frequent link outages (temporary) Lower

interaction IEEE 802.11 X Bluetooth X Hiperlan X

References

The modules specified above will be the initial modules developed by the WINE

project. Other possible modules could be developed:

• IP payload compression

• SNOOP like method for Bluetooth only

Depending on the WINE's decision on micro-mobility, another module may be

implemented. Link layer micro-mobility would be implemented as a module in the WAL.


99

5.2.3 Signalling

As far as signalling is concerned, we can identify two different classes of signalling

mechanisms. The first one is between different entities within same WAL. The second one is

between two WAL entities residing in different terminals (e.g. the AP and a MT).

5.2.3.1 Internal WAL signaling

Internal WAL signalling using the 802.2 type header is performed as packets travel

downstream. The packet will encounter the following functional entities: 802.2 encapsulator

> module handler > QoS handler > QoS queueing > modules... > interface translator

Internal WAL signalling begins at the when 802.2 encapsulation is first done on IP

packets. It is complete when the interface translator either decides to strip the 802.2 header if

it is unneeded, or to pass on the header which then is used for peer WAL signalling.

The entities in between these end points need to use the 802.2 header in order to pass on

signalling information. Some signalling that needs to be done:

• module handler: Specify which link layer modules should be visited and in

what order

• QoS handler: Specify which QoS mapping the interface translator will

perform

• QoS handler: Specify how the packet is handled in queuing entity

• QoS handler: Specify how connection oriented interface is handled

5.2.3.2 Peer WAL entity signalling

Peer WAL signalling is needed in the following situations:

• When any symmetrical link layer modules are used

• If QoS signalling between peer WAL entities is performed (to be

determined)

When the interface translator receives the 802.2 header containing internal signalling

information, it decides whether the header is passed on to the peer entity. If the header

contains critical fields used by a symmetrical module such as ARQ or FEC then that header

must be passed on to the peer WAL entity. This is also true if QoS information needed by a

peer WAL entity is included in the header.


100

5.3 QOS CONTRACT

For the purpose of the WINE demonstration, we will consider a time interval in which

the number of connections handled by the considered Access Point (AP) does not vary. The

above-mentioned assumption is the same as saying that WINE will not consider a Connection

Admission Control (CAC) Module. Nevertheless, in a real WAL the CAC Module has to

interact with the Bandwidth Broker which, in turn, has to interact with some IP RSVP-like

protocol (we are assuming, according to the current vision for access networks, that an

Int-Serv approach is foreseen in the network): at each connection set-up, the Bandwidth

Broker should communicate to the CAC Module the QoS Contract which is proposed for such

connection; then, the CAC Module should decide whether the new connection can be

accepted in the system (i.e. if the system has enough resources for supporting the new

connection) with the proposed QoS Contract. In case, the resources are not sufficient, the

CAC Module can negotiate with the Bandwidth Broker a new QoS Contract (e.g. with relaxed

QoS requirements). Anyhow, in case the new connection is accepted, the agreed QoS

Contract is communicated from the CAC Module to the WAL Coordinator which provides for

the activation of appropriate modules and for their proper configuration. In addition, the WAL

Coordinator forwards the contractual conditions to the modules which need them; in this

respect, it is evident that the knowledge of these conditions is essential for the QoS Module

operation.

5.3.1 Basic definitions

In the WINE project, we assume that a QoS Contract relevant to a certain connection

includes the following contractual conditions:

1) The definition of the Compliant Traffic relevant to the considered connection, that is

the traffic which, in any case, the wireless network is engaged to comply, i.e. the

traffic which, in any case, must be admitted in the wireless network.

2) The definition of the QoS requirements that the Compliant Traffic must satisfy. For

the QoS Module a fundamental QoS requirement (hereafter referred to as Delay QoS

Requirement) is that the delay that an IP datagram undergoes from the time at which it


101

enters in the WAL to the time at which it is forwarded to the LLCT and can hence be

transmitted on the UN air interface does not exceed a maximum tolerable delay r.

An other requirement to be considered is the one on the delay jitter (hereafter

referred to as Jitter QoS Requirement); various definitions are present in the literature

concerning jitter; in this project, we define the maximum tolerable jitter δ(t) as the

difference (in module) between the function delay τ(t) and one appropriate function

D(t). As a matter of fact, delay jitter impacts on the dimensioning of the size of the

reception buffer which has to equalize the delays; as a matter of fact, in order to

provide for delay equalization, it is sufficient to foresee an appropriate size for the

reception buffer. In other words, the Jitter QoS Requirement imposes that the delay

that an IP datagram undergoes from the time at which it enters in the WAL to the time

at which it is forwarded to the LLCT and can hence be transmitted on the UN air

interface, is not lower than a minimum tolerated delay dependent on the fixed

maximum tolerated jitter. An other fundamental QoS requirement concerns the

maximum loss probability which can be tolerated by the IP datagrams; nevertheless,

since this requirement does not impact on the QoS Module it will be no longer

considered here.

3) The management of the Non-Compliant Traffic. In the WINE project, the following

policy is adopted: the Non-Compliant Traffic is admitted (i.e. is transmitted on the air

interface) and is granted the same QoS requirements of the Compliant Traffic as long

as this admittance does not entail the infringement of the QoS requirements relevant to

the Compliant Traffic; otherwise, such a traffic is discarded. The admitted Non-

compliant Traffic is granted the same QoS Requirements as the Compliant Traffic.

In light of the above, it should be clear that the goal of the QoS Module is to pass as

much Non-Compliant Traffic as possible to the LLCT (this is the same as saying to discard as

less Non-Compliant Traffic as possible) without infringing the Delay QoS requirement for

both the Compliant Traffic and the admitted Non-Compliant Traffic.

It should be clear that the CAC Module has to monitor the amount of Non-Compliant

traffic which is passed to the LLCT. As a matter of fact, the CAC Module can very reasonably

base its decision concerning whether or not new connections can be supported by the wireless


102

system just on the monitoring of the above-mentioned traffic. For instance, if, at a certain time

t at which a certain number of connections are established, the CAC notices that the QoS

Module is able to pass a lot of Non-Compliant Traffic to the LLCT (i.e. to discard a few Non-

Compliant Traffic), this is a clear sign that further connections can be accepted in the system.

Let define a Service Class as the set of connections whose QoS Contract is

characterized by the same parameters (i.e. by the same QoS requirements). In the following

we will define as n the generic Service Class. Note that the QoS Contract does not depend on

the considered MT, but only on the considered Service Class.

In the following we will refer to as m the generic MT. Let denote as M(t) the number of

MTs with at least a connection in progress with the considered Access Point (AP) at time t.

Let denote as Mmax the maximum number of MTs which can be handled by the considered

AP, i.e. at any time t, M(t) < Mmax; in WINE, we have assumed Mmax=256. Let denote as

N(m,t) the number of different Service Classes in progress for the m-th MT at time t.

Let define an association as a couple (MT, Service Class); so, for a certain AP, we will

refer to as (m,n) the generic association where m can range in the interval [1, M(t)] and n can

range in the interval [1, N(m,t)].

Then, the total number of associations Atot handled by the considered AP at time t is

equal to:

Eq. 5.1 ∑=

=)(

1

),()(tN

itot tiCtA

Finally, let indicate as Nconn(i,j,t) the number of connections belonging to the association

(i,j) at time t.

5.3.2 QoS classes characterization

When defining the QoS classes for a wireless system, the restriction and limitation of

the air interface have to be taken into account. It is not reasonable to define comlpex

mechanisms as have been in fixed networks due to the different error characteristics of the air

interface.

In general four different QoS classes (or traffic classes) are considered:


103

• Conversational class

• Streaming class

• Interactive class

• Background class

The main distinguishing factor between these classes is how delay sensitive the traffic

is: Conversational class is meant for traffic which is very delay sensitive, while Background

class is the most delay insensitive traffic class. Conversational and Streaming classes are

mainly intended to be used to carry real-time traffic flows. The main divider between them is

how delay sensitive the traffic is. Conversational real-time services, like video telephony, are

the most delay sensitive applications and those data streams should be carried in

Conversational class.

Interactive class and Background are mainly meant to be used by traditional Internet

applications like WWW, Email, Telnet, FTP and News. Due to looser delay requirements,

compare to conversational and streaming classes, both provide better error rate by means of

channel coding and retransmission. The main difference between Interactive and Background

class is that Interactive class is mainly used by interactive application, e.g. interactive Email

or interactive web browsing, while background class is meant for background traffic, e.g.

background download of Emails or background file downloading. Traffic in the Interactive

class has higher priority in scheduling than Background class traffic, so background

applications use transmission resources only when interactive applications do not need them.

This is very important in wireless environment where the bandwidth is low compared to fixed

networks.

5.3.2.1 Conversational class

The most well know use of this scheme is telephony speech (e.g. GSM). But with

Internet and multimedia a number of new applications will require this scheme, for example

voice over IP and video conferencing tools. Real time conversation is always performed

between peers (or groups) of live (human) end-users. This is the only scheme where the

required characteristics are strictly given by human perception.

Real time conversation scheme is characterized by that the transfer time shall be low

because of the conversational nature of the scheme and at the same time that the time relation

(variation) between information entities of the stream shall be preserved in the same way as

for real time streams. The maximum transfer delay is given by the human perception of video


104

and audio conversation. Therefore the limit for acceptable transfer delay is very strict, as

failure to provide low enough transfer delay will result in unacceptable lack of quality. The

transfer delay requirement is therefore both significantly lower and more stringent than the

round trip delay of the interactive traffic case.

5.3.2.2 Streaming class

When the user is looking at (listening to) real time video (audio) the scheme of a real

time streams applies. The real time data flow is always aiming at a live (human) destination. It

is a one way transport.

This scheme is characterised by that the time relation (variation) between information

entities (i.e. samples, packets) shall be preserved, although it does not have any requirements

on low transfer delay. The delay variation of the end-to-end flow shall be limited, to preserve

the time relation (variation) between information entities of the stream. But as the stream

normally is time aligned at the receiving end (in the user equipment), the highest acceptable

delay variation over the transmission media is given by the capability of the time alignment

function of the application. Acceptable delay variation is thus much greater than the delay

variation given by the limits of human perception.

5.3.2.3 Interactive class

When the end-user, that is either a machine or a human, is on line requesting data from

remote equipment (e.g. a server), this scheme applies. Examples of human interaction whit the

remote equipment are: web browsing, data base retrieval, server access. Examples of

machines interaction with remote equipment are: polling for measurement records and

automatic data base enquiries (tele machines). Interactive traffic is the other classical data

communication scheme that on overall level is characterised by the request response pattern

of the end-user. At the message destination there is an entity expecting the message (response)

within a certain time. Round trip delay time is therefore one of the key attributes. Another

characteristic is that the content of the packets shall be transparently transferred (with low bit

error rate).

5.3.2.4 Background class

When the end-user, that typically is a computer, sends and receives data-files in the

background, this scheme applies. Examples are background delivery of E-mails, SMS,

download of databases and reception of measurement records. Background traffic is one of


105

the classical data communication schemes that on an overall level is characterised by that the

destination is not expecting the data within a certain time. The scheme is thus more or less

delivery time insensitive. Another characteristic is that the content of the packets shall be

transparently transferred (with low bit error rate).

5.4 QOS MODULE DESIGN

The structure of the QoS Module implemented in an AP, at time t, is shown in . The

figure shows that the QoS Module consists of the following building blocks:

5.4.1.1 Classifier

The Classifier in charge of sorting the IP datagrams arriving at the QoS Module

according to the associations they belong to; this sorting is carried out on the ground of the

header of the IP datagram. The correspondence among IP headers and associations is

established at each connection set-up by the CAC Module and communicated to the Classifier

via the WAL Coordinator. However, for the sake of simplicity, in the WINE demonstrator,

this correspondence will be permanently stored in the Classifier and will not be varied for the

whole demonstration duration. As shown in Figure 5-4, each of the lines going out of the

Classifier carry the IP datagrams relevant to one of the associations (i,j) (i=1,...,N),

(j=1,...,C(i,t)) handled by the considered AP at the considered time. So, the number of the

above-mentioned wires is equal to Atot(t).


106

Figure 5-4: High-level QoS Module internal structure at a certain time t

5.4.1.2 Main Scheduler algorithm

The Main Scheduler algorithm has the role, whenever an IP datagram has to be

transmitted towards the LLCT, to select the MT which has to transmit such IP datagram.

Once, such MT is selected, say MT m, the Main Scheduler advises the m-th MT Scheduler.

This last (if it stores at least one IP datagram) sends an IP datagram to the Main Scheduler

MUX (Multiplexer) which forwards such IP datagram towards the LLCT.

5.4.1.3 MT Schedulers

There are N(t) MT Schedulers. The i-th MT Scheduler handles the IP datagrams

destined to the i-th MT. The role of the i-th MT Scheduler (i=1,...,N(t)) is, whenever the Main

Scheduler algorithm selects the MT m as the MT entitled to transmit an IP datagram towards

the LLCT, to select such IP datagram among the ones stored in its buffers (these IP datagrams

are all relevant to the associations (i,j) (j=1,...,C(i,t)), thanks to the sorting performed by the

Classifier).

It is important noting that the QoS Module implemented in the MT lacks of the Main

Scheduler algorithm and includes a single MT Scheduler. As a matter of fact, we are

M T 1Schedu le r

C lassif ie r

M T mSchedu ler

... ... M T M (t)Schedu le r

.........

IP da tag ram s

F rom the W A L coo rd inato r

(1 ,1 ) (1 ,N (1 ,t)) (m ,1 ) (m ,N (m ,t))(M (t),N (M (t),t))

(M (t),1 )

M ain Schedu lera lgo r ithm

M ain S chedu le r M U X

T o the L L C T


107

assuming that the considered WLAN is not provided with ad-hoc operation and, as a

consequence, two MTs can communicate only through an AP.

5.4.2 Main Scheduler algorithm

The Main Scheduler algorithm is triggered by the WAL Coordinator, whenever an IP

datagram has to be transmitted towards the LLCT; this algorithm has to select the MT

Scheduler which has to transmit such IP datagram. The Main Scheduler performs this choice

with the target to maintain a weighted fairness among the various MTs involved in

communication with the AP.

Let R(t) denote the overall capacity handled by the considered AP at time t and let α(i,t)

denote the fraction of such an overall capacity which is assigned to the MT i at time t. Then,

the Main Scheduler task is to act so that the capacity actually assigned to an MT i at time t

tracks

Eq. 5.2 ∫t

dttRti0

)(),(α

When performing its task, the Main Scheduler has to take into account the following

issues:

i) the IP datagrams do not have a fixed length,

ii) some selected MT Schedulers can have their buffers empty due to the statistical

traffic oscillations,

iii) at certain times, some links with certain MTs can be unavailable (in this last

respect, at time t, the Main Scheduler algorithm does not select the MT

Schedulers relevant to the MTs whose links, at time t, are unavailable).

As far as this last issue is concerned, a basic Main Scheduler algorithm input is the

information about the channels among the AP and the M(t) MTs which are presently in a bad

state with respect to a selected quality parameter (e.g. the Bit Error Rate (BER)) and the ones

which are presently in a good state. The good channels are considered as available for

transmission, while the bad are considered as not-available. This information is passed to the


108

QoS Module from the WAL Coordinator which, in turn, deduces it from the UN (availing of

the translation of the LLCT). According to the approach mentioned above, appropriate

measurements are taken by the UNs over the above mentioned channels; such measurements

are "translated" into an available/not-available judgement by the LLCT; this judgement is

communicated from the LLCT to the WAL Coordinator which, in turn, requests the QoS

Module to temporarily disable the MT Schedulers handling traffic for MTs with a bad

channel. This information is stored in a binary vector with M(t) elements lstatus(m,t)

(m=1,...,M(t)), hereinafter referred to as Channel Quality Vector: lstatus(m,t)=1 means that, at

time t, the channel between the m-th MT and the AP is available (i.e. IP datagrams can be

transmitted on such channel); conversely, lstatus(m,t)=0 means that, at time t, the channel

between the m-th MT and the AP is not available (i.e. IP datagrams can not be transmitted on

such channel). The Channel Quality Vector is updated by the WAL Coordinator whenever

there is a change in the availability status of a channel. In the following, the mechanism

aiming at excluding the selection of MTs whose channels with the AP is presently bad will be

referred to as Channel-State-Dependent mechanism.

An other Main Scheduler algorithm input is the information about the bits which have

been emitted so far by the various MT Schedulers. This information is stored in a vector

having N(t) elements Bemitted(i,t) (i=1,...,N(t)), hereinafter referred to as MT Scheduler Emitted

Bit Vector: Bemitted(i,t) represents the bits which, from the time of system start-up tstart (in the

WINE demonstrator this is the starting time of the demonstration) up to the current time t,

have been emitted from the m-th MT Scheduler towards the LLCT. The information stored in

the MT Scheduler Emitted Bit Vector is essential for fairness purposes. The MT Scheduler

Emitted Bit Vector is updated whenever an IP datagram is forwarded towards the LLCT.

A last Main Scheduler algorithm input is the information about the target bits which the

Main Scheduler aims at granting to the various MT Schedulers. This information is stored in a

vector having Nmax elements Btarget(i,tstart,t) (i=1,...,Nmax), hereinafter referred to as Target Bit

Vector: Btarget(i,t) represents the total amount of bits that from the time tstart up to the current

time t, the Main Scheduler aims at granting to the i-th MT.

A simple criterion for computing Btarget(i,tstart,t) could be as follows:


109

Eq. 5.3 ∫ ∑=

=t

tstart

N

istartemittedstartett dtttiBtittiB

max

1arg ),,(),(),,( α (I=1..Nmax)

where ∑=

max

1

),,(N

istartemitted ttiB is the total amount of bits which have been emitted, in the time

interval [tstart, t], by all the MT Schedulers.

The coefficients α(i,t) represents the fraction of the overall bit rate which, at time t, has

to be assigned to the i-th MT. Clearly, for each t, α(1,t)+....+ α(N(t),t) = 1. A reasonable

criterion for selecting the coefficients α(i,t) can be to choose them proportional to the sum of

the sustainable rates of the connections relevant to the associations handled by the m-th MT at

time t, i.e.:

Eq. 5.4

∑ ∑

∑

∑ ∑

∑

= =−

=−

= =

= == )(

1

),(

1

),(

1)(

1

),(

1

),(

1

),(),,(

),(),,(

),,(

),,(

),( tN

i

tiC

jconnsusconn

tiC

jconnsusconn

tN

i

tiC

jsus

tiC

jsus

jiRtjiN

jiRtjiN

tjiR

tjiR

tiα (i=1..Nmax)

where we have taken into account that Rsus(i,j) is the sum of the sustainable rates Rsus-conn(i,j)

of the N(i,j,t) connections relevant to the association (i,j) at time t. It is evident that the

performed choice induces a weighted fairness among the MTs handled by the considered AP,

the weights being proportional to the sum of the sustainable rates of the connections handled

by the various MTs. Note that the coefficients α(i,t) vary only at the time at which a

connection set-up, or a connection termination occurs. This means that the integral appearing

in the Eq. 5.3 can be easily computed as the sum of a finite number of terms each relevant to

a time period in which no connection set-ups/terminations have occurred.

On the basis of the above-mentioned considerations and positions, we can now describe

the operation of the Main Scheduler algorithm.

Assume that, at time t, the WAL Coordinator triggers the Main Scheduler algorithm

since an IP datagram has to be forwarded to the LLCT. Then, the algorithm evolves as

follows (at tstart, Bemitted(i,tstart,tstart) is set to zero ∀ i) :


110

1) In the set of the MTs having at least a connection in progress and such that lstatus(i,t)=1,

it is sought the MT for which the difference

Eq. 5.5 Btarget(i,tstart,t) - Bemitted(i,tstart,t)

is the highest; say, this is the MT i1. Note that Btarget(i,tstart,t) is computed according to

Eq. 5.3 and Eq. 5.4. Then, the i1-th MT Scheduler is entitled to transmit the IP

datagram towards the LLCT: so, the Main Scheduler informs the i1-th MT Scheduler

that an IP datagram relevant to the i1-th MT can be transmitted towards the LLCT.

Then, the i1-th MT Scheduler, provided that its buffers are not empty, selects,

according to appropriate criteria, an IP datagram among the ones stored in its buffers,

say the k-th IP datagram relevant to the association (i1,j), and sends it to the Main

Scheduler MUX which forwards it to the LLCT. In case, the buffers of the i1-th MT

Scheduler are empty, then, this step 1) is repeated without considering any more the

i1-th MT.

In other words, the Main Scheduler algorithm triggers the MT i1 Scheduling

algorithm. In case the i1-th MT Scheduler has an IP datagram to transmit, then the MT

i1 Scheduling algorithm returns to the Main Scheduler algorithm the information:

“The MT i1 Scheduler was able to send an IP datagram towards the LLCT” and this

step is completed; otherwise, i.e. in case the i1-th MT Scheduler does not have any IP

datagram to transmit, then the MT i1 Scheduling algorithm returns the information:

“The MT i1 Scheduler was unable to send any IP datagram towards the LLCT” and

this step is repeated without considering the i1-th MT.

2) By denoting as Bsegment(i1,j,k) the number of bits of the IP datagram mentioned in the

previous step, the i1-th component of the Transmitted Bit Vector is updated as follows:

Eq. 5.6 BMT-emitted(i1,tstart,t) := BMT-emitted(i1,tstart,t) + Bsegment(i1,j,k)

Let denote as Rair-interface(t) the capacity (expressed in bps) of the air interface assigned

to the considered AP, at time t.


111

Note that the CAC Module will definitely assure that:

Eq. 5.7 ∑ ∑= =

− >)(

1

),(

1int ),,()(

tN

i

tiC

jsuserfaceair tjiRtR

Let denote as Rtrans(i,t) (i=1,...,N(t)) the bit rate which has been actually transmitted on

the air interface towards the i-th MT at time t. Then, the Throughput Θ(t) experienced on the

air interface at time t is equal to:

Eq. 5.8 )(

),()(

int

)(

1

tR

tiRt

erfaceair

tN

itrans

−

=∑

=Θ

It should be clear that the overall target of the QoS Module mentioned in preceding

section is equivalent to the maximization of the integral of the Throughput in the period from

the beginning of the demonstration (tstart) up to the demonstration, provided that all the QoS

requirements mentioned are respected.

Let denote as RLLCT(t), hereafter referred to as LLCT Rate at time t, the bite rate which

the LLCT is able to accept at time t. Moreover, let denote as Remitted(i,t), hereafter referred to

as the Emitted Rate of the i-th MT Scheduler at time t, the bit rate emitted by the i-th MT

Scheduler at time t. It is important noting that Remitted(i,t) can be either equal to RLLCT(t), or

equal to zero depending on whether at time t the i-th MT Scheduler has been enabled or not

enabled by the Main Scheduler to transmit an IP datagram towards the LLCT.

Note that, in the absence of further delays/losses (e.g. due to buffering) introduced by

the UN MAC, i.e. in the presence of an "ideal" UN MAC dynamic band reallocation

mechanism, we have RLLCT(t) = Rair-interface(t) and Remitted(i,t) = Rtrans(i,t) ∀ i. Therefore, in this

case, taking into account Eq. 5.7, the CAC Module will definitely assure that:

Eq. 5.9 ∑ ∑= =

>)(

1

),(

1

),,()(tN

i

tiC

jsusLLCT tjiRtR


112

Morever, in this ideal case, taking into account Eq. 5.8, the Throughput Θ(t) is equal to:

Eq. 5.10 )(

),()(

)(

1

tR

tiRt

LLCT

tN

iemitted∑

==Θ

Nevertheless, the actual capability of Rtrans(i,t) to track Remitted(i,t) depends on the UN

MAC dynamic band reconfiguration capabilities. As a matter of fact, in general, the UN MAC

is not able to dynamically select any Rtrans(i,t). What, in general, any UN MAC does is

(i) to reserve to the i-th MT a Nominal Rate Rnominal(i) sufficient to carry the

Sustainable Rates relevant to the connections involving the i-th MT,

i.e. ∑=

−=),(

1)(min ),,()(

tiC

jjconnsusconnalno RtjiNiR

(ii) depending on its dynamic band reconfiguration capabilities, to provide additional

band to the m-th MT if needed.

Note that, at time t, for a MT i, the Emitted Rate Remitted(i,t) can remarkably differ from the

Nominal Rate Rnominal(i), due to the following reasons:

i) the Channel-State-Dependent mechanism,

ii) the fact that the IP datagrams does not have a fixed length

iii) the fact that some selected MT Scheduler can have its buffer empty.

So, in the absence of any UN MAC dynamic band reallocation mechanism, even if Remitted(i,t)

is greater than Rnominal(i), Rtrans(i,t) can not exceed Rnominal(i), i.e. Rtrans(i,t) is not able to track

Remitted(i,t). This results in a throughput decrease with respect to the case of an "ideal" UN

MAC dynamic band reallocation mechanism.

Therefore, it should be clear that the advantages entailed on the Throughput by the

Channel-State-Dependent mechanism and by the possibility to dynamically reconfigure the

Emitted Rates relevant to the various MT Schedulers (for instance, by increasing the Emitted

Rates of the congested MT Schedulers at the expenses of the Emitted Rates of the idle MT


113

Schedulers), are lost in case of absence of any UN MAC dynamic band reallocation

mechanism.

Moreover, in case the IP datagrams emitted by an MT Scheduler can not be

immediately transmitted they have to be buffered either in the LLCT or in some UN MAC

buffer; then, the delay experienced in such buffers can entail the infringement of the Delay

QoS Requirement since this requirement is guaranteed only with respect to the time spent by

the IP datagrams in the QoS Module.

As regards the UN MAC dynamic band reconfiguration capabilities, in real UNs, the

situation usually lies in the middle among the two above-mentioned extremes, even if the

most recent WLANs avail of UN MAC dynamic band reallocation mechanisms which are

close to the ideal one. For instance, this is the case of the Bluetooth UN.


114

PART THREE MT SCHEDULER:

The Single Controller Algorithm


115

6 THE SINGLE CONTROLLER ALGORITHM

6.1 QOS CONTRACT AND OTHER BASIC DEFINITIONS

A Service Class is defined as the set of connections whose QoS Contract is

characterized by the same parameters. In the following we will define as j the generic Service

Class. Note that the QoS Contract does not depend on the considered MT, but only on the

considered Service Class.

In the following, we will refer to as i the generic MT. Let denote as N the number of

MTs with at least a connection in progress with the considered Access Point (AP) (active

MTs). Let denote as C(i) the number of different Service Classes relevant to connections in

progress at the i-th MT (active Service Classes).

Let define an association as a couple (active MT, active Service Class); so, for a certain

AP, we will refer to as (i,j) the generic association where i can range in the interval [1, N] and

j can range in the interval [1, C(i)]. Finally, let Nconn(i,j) denote the number of connections in

progress belonging to the association (i,j). So, according to the above definitions, the overall

number of connections in progress at the considered AP is equal to

∑∑= =

N

i

iC

jConn

jiN1

)(

1

),(

The actual implementation of the Traffic Control Module entails that the computations

of the control variables can not be performed at any time t, but only periodically with period

Tshort depending on the implementation platform; so, these variables can only be computed at

discrete time instants th (h = 1, 2,...) such that th+1 = th + Tshort.

Let Roff(i,j,th) denote the bit rate of the traffic relevant to the association (i,j) which, at

time t, is offered to the Traffic Control Module; let Rloss(i,j,th) denote the bit rate of the traffic


116

relevant to the association (i,j) which, at time th, the Traffic Control Module is not able, due to

congestion situation, to accept, i.e. the bit rate of the discarded traffic. These bit rates are

computed according to the following relationship:

Eq. 6.1 monit

hmonithoffhoff

T

tTtjiLtjiR

),,,(),,(

−=

Eq. 6.2 monit

hmonithlosthloss

T

tTtjiLtjiR

),,,(),,,(

−=

where Loff (i,j,th - Tmonit,th) and Llost(i,j,th - Tmonit,th) are the sum of the lengths (expressed in

bits) of the IP datagrams, relevant to the association (i,j), which, during the time interval

[th-Tmonit, th], where Tmonit is a proper monitoring period, are offered to the Traffic Control

Module and are discarded by the Traffic Control Module, respectively.

A QoS Contract relevant to a certain connection includes the following contractual

conditions:

1) The definition of the Compliant Traffic which is the traffic which has to be

anyhow admitted into the wireless network, regardless of the traffic conditions. In

this paper the Compliant Traffic relevant to a certain connection is defined as the

traffic not exceeding a Minimum Rate equal to Rmin(j); consistently, the

Compliant Traffic relevant to an association (i,j) is defined as the traffic not

exceeding a Minimum Rate equal to Nconn(i,j) Rmin(j). This means that, at a time

th, regardless of the traffic conditions, the minimum bit rate to be granted to the

association (i,j) is equal to min(Nconn(i,j) Rmin(j), Roff(i,j,th)) where Roff(i,j,th), is the

bit rate of the offered traffic, relevant to the association (i,j) (the above-mentioned

min is justified since, at time th, it is useless to grant to the association (i,j) more

than Roff(i,j,th).

2) The definition of the QoS requirements that the Compliant Traffic must satisfy.

Let denote as D(i,j,th) the delay that an IP datagram relevant to the association (i,j)

undergoes from the time th at which it enters in the WAL to the time at which it is

forwarded to the LLCT and can hence be transmitted on the UN air interface. A

fundamental QoS requirement (herafter referred to as Delay QoS Requirement) is

that the delay D(i,j,th) does not exceed a maximum value which can be tolerated


117

by the Service Class j, herafter denoted as Dmax(j). An other requirement to be

considered is the one on the delay jitter (hereafter referred to as Jitter QoS

Requirement); various definitions are present in the literature concerning jitter; in

this paper, we define the maximum tolerable jitter for the Service Class j, herafter

denoted as Jmax(j), as the difference between the maximum tolerable delay Dmax(j)

and a minimum delay which can be tolerated by the Service Class j, herafter

denoted as Dmin(j), i.e. Jmax(j) = Dmax(j) - Dmin(j). As a matter of fact, the jitter

impacts on the dimensioning of the size of the reception buffer which has to

equalize the delays: in order to provide for delay equalization, it is sufficient, in

the worst case, to foresee a reception buffer whose size is equal to

(Dmax(j) - Dmin(j)) Rpeak(j) where Rpeak(j) is the peak bit rate of a connection

relevant to the Service Class j. In other words, the Jitter QoS Requirement

imposes that the delay D(i,j,th) is not lower than a minimum tolerated delay

Dmin(j) = Dmax(j) - Jmax(j).

An other fundamental QoS requirement concerns the maximum loss probability

which can be tolerated by the IP datagrams; nevertheless, since, as explained in

the introduction, this requirement does not impact on the Traffic Control Module,

it will be no longer considered in this paper.

3) The management of the Non-Compliant Traffic, i.e. the traffic which is ruled out

by the Traffic Control Module. In the WINE project, the following policy is

adopted: the Non-Compliant Traffic is admitted into the wireless network as long

as this admittance does not entail the infringement of the QoS requirements

relevant to the Compliant Traffic; otherwise, such a traffic is discarded.

The admitted Non-Compliant Traffic is granted the same QoS Requirements as

the Compliant Traffic.

In light of the above, it should be clear that the QoS Contract relevant to a connection

belonging to the Service Class j is characterized by the set of parameters Rmin(j), Dmax(j),

Jmax(j).

The goal of the Traffic Control Module is to admit, in addition to the Compliant Traffic,

as much Non-Compliant Traffic as possible (this is the same as saying to discard as less Non-


118

Compliant Traffic as possible) without infringing the Delay and Jitter QoS requirements for

both the Compliant Traffic and the admitted Non-Compliant Traffic.

The respect of the QoS Contract entails the satisfaction, for any association (i,j) and at

any time th, of the following constraints:

Eq. 6.3 Roff(i,j,th) - Rloss(i,j,th) > min(Nconn(i,j) Rmin(j), Roff(i,j,th))

Eq. 6.4 D(i,j,th) > Dmax(j) - Jmax(j) = Dmin(j)

Eq. 6.5 D(i,j,th) < Dmax(j)

The goal of the Traffic Control Module is to minimize the cost index J(0,Ttotal):

Eq. 6.6 ∫ ∑∑= =

=Ttotal N

i

iC

j

hhlosstotal dttjiRjwTJ0 0

)(

1

),,()(),0(

where w(j) are appropriate weights which take into account operation requirements of the

Service Class j (e.g. it can be related to the charges imposed on the users of the various

Service Classes) and [0,Ttotal] is the overall time interval along which the system performance

is monitored. Note that, in the meaningful case in which all the weights are equal to one, J

represents the total amount of traffic (expressed in bits) which is discarded in the time interval

[0, Ttotal].


119

6.2 TRAFFIC CONTROL MODULE DESIGN AND MODELING

The structure of the Traffic Control Module implemented in an AP is shown in Figure

6-1. The figure shows that the Traffic Control Module consists of the following building

blocks:

- a Classifier in charge of sorting the IP datagrams arriving at the Traffic Control Module

according to the associations they belong to; this sorting is carried out on the ground of

the header of the IP datagram. The correspondence among IP headers and associations is

established at each connection set-up by a Connection Admission Control (CAC) Module

and communicated to the Classifier via the WAL Coordinator.

As shown in Figure 6-1, each of the lines going out of the Classifier carry the IP

datagrams relevant to one of the associations (i,j) (i=1,...,N), (j=1,...,C(i)) handled by the

considered AP at the considered time.

- a Main Scheduler algorithm whose role is, whenever an IP datagram has to be

transmitted towards the LLCT, to select the MT which has to transmit such IP datagram.

Once, such MT is selected, say MT i, the Main Scheduler advises the i-th MT Scheduler,

which forwards one IP datagram towards the LLCT (unless such MT Scheduler is

empty). Therefore, the Main Scheduler algorithm is in charge of partitioning the overall

capacity which can be accepted by the LLCT, hereafter denoted as RLLCT (note that RLLCT

also represents the capacity of the air interface), among the N active MTs; in other words,

the Main Scheduler algorithm is in charge of selecting the coefficients α(i) indicating the

fraction of the overall capacity RLLCT which is assigned to the MT i. Clearly, the

following constraint holds:

Eq. 6.7 1)(1

=∑=

N

i

iα

The Main Scheduler algorithm is usually designed in order to guarantee proper fairness

criteria among the active MTs. Its design is outside the scope of this paper.


120

- N MT Schedulers. The MT i Scheduler handles the IP datagrams directed to the i-th MT.

The MT i Scheduler (i=1,...,N) design is the core of this paper; as stated in the

introduction, it has both a congestion control and a scheduling role.

As far as the congestion control role is concerned, whenever an IP datagram relevant to

an association (i,j) (j=1,...,C(i)) arrives at the Traffic Control Module, the MT i Scheduler

has to decide whether this IP datagram has to be admitted in the Traffic Control Module

(and hence, eventually, transmitted over the air interface), or discarded. This means that

the MT i Scheduler is in charge of deciding the bit rates Rloss(i,j,th) (j=1,...,C(i)) of the

traffic relevant to the association (i,j) (j=1,...,C(i)) which, at time th, the Traffic Control

Module is not able, due to congestion, to accept, i.e. the bit rate of the discarded traffic.

As far as the scheduling role is concerned, whenever the Main Scheduler algorithm

selects the MT i as the MT entitled to transmit an IP datagram towards the LLCT, the MT

i Scheduler has to select the association (i,j) (j=1,...,C(i)) entitled to transmit such IP

datagram.

This means that the MT i Scheduler is in charge of partitioning the capacity which the

Main Scheduler algorithm has assigned to the MT i, i.e. α(i)RLLCT, among the C(i)

associations involving the MT i; thus, the MT i Scheduler is in charge of selecting the

coefficients δ(i,j,th) (j=1,...,C(i)) indicating the fraction of the overall capacity RLLCT

which is assigned to the associations (i,j) (j=1,...,C(i)). Clearly, for any MT i, at any time

th ∈ [0,Ttotal], the following fundamental capacity constraint must be respected:

Eq. 6.8 ∑=

≤)(

1

)(),,(iC

j

LLCTLLCTh RiRtji αδ

So far, we have considered the Traffic Control Module implemented at an AP. It is

worth noting that the Traffic Control Module implemented in an MT has a similar structure,

but lacks of the Main Scheduler algorithm and includes a single MT Scheduler.


121

Figure 6-1: High-level Traffic Control Module internal structure

The aim of this paper is the design of an MT Scheduler which minimizes the target

function Eq. 6.6) with the constraints coming from the QoS Contract (Eq. 6.3, Eq. 6.4 and

Eq. 6.5) and the capacity constraint by Eq. 6.7. In the following, without loss of generality,

we will refer to the i-th MT Scheduler (MT i Scheduler).

Figure 6-2 shows the proposed MT i Scheduler at a given time th; the figure highlights

the bit rates on the various links. The basic characteristics of the proposed MT i Scheduler are

the following:

Each MT Scheduler includes one FIFO buffer for each association (i,j). The buffer relevant to

the association (i,j) is referred to as FIFO Buffer (i,j). Let q(i,j,th) denote, the FIFO Buffer (i,j)

occupancy at time th, expressed in bits; as it is evident from

Classifier

MT 1Scheduler

Main Scheduleralgorithm

IP datagrams

(1,1)

MT 2Scheduler

MT NScheduler

To the LLCT

(1,C1)…(1,1) (2,C2)…

(N,1) (N,C(N))

…

IP datagrams selected for being transmitted towards the LLCT

From the WAL Coordinator


Decisions about the MT Scheduler entitled to transmit an IP datagram towards the LLCT

…..


122

Figure 6-2, q(i,j,th) can be computed according to the following relationship:

Eq. 6.9 q(i,j,th+1) - q(i,j,th)= (Roff(i,j,th) - Rloss(i,j,th) - δ(i,j,th)RLLCT)Tshort ; j=1..C(i)

Let denote as N(i,j,h) the number of discrete time instants that a bit entered into the

FIFO Buffer (i,j) at time th remains in this buffer. Then, the FIFO Buffer occupancies

q(i,j,th), the numbers N(i,j,h) and the delays D(i,j,th) are linked by the following

relationships:

Eq. 6.10 ∑∑+

=

−+

=

≤<),,(1),,(

),,(),,(),,(hjiNh

hl

LLCTlshorth

hjiNh

hl

LLCTlshort RtjiTtjiqRtjiT δδ

Eq. 6.11 shorth ThjiNtjiD ),,(),,( =

• The admittance in the FIFO Buffers is regulated by proper Admittance Handlers

which, following the decisions taken by the MT i Buffer Controller, either admit the

IP datagrams arrived at the MT i Scheduler, or discard them. So, an IP datagram

relevant to an association (i,j) arriving at the MT i Scheduler, is temporarily stored in

the Admittance Handler; then, following the decisions taken by the MT i Buffer

Controller, is either admitted in the FIFO Buffer (i,j), or discarded.

• The decisions of the MT i Buffer Controller are based on:

o the information about the IP datagrams arrived at the MT i Scheduler, i.e. the

traffic offered to the MT i Scheduler.

o the information about the decisions performed by the Main Scheduler.

o the FIFO Buffer (i,j) (j = 1,...,C(i)) occupancies.

As regards the issue (i), whenever an IP datagram arrives at an Admittance Handler,

the MT i Buffer Controller is informed about the association this IP datagram refers to

and about the IP datagram length (in bits); basing on this information, the MT i Buffer

Controller can easily compute (according to Eq. 6.1) the bit rates Roff(i,j,th) of the

traffic relevant to the associations (i,j) (j = 1,...,C(i)) offered to the MT i Scheduler at

time th. As regards the issue (ii), the MT i Buffer Controller is informed whenever the


123

Main Scheduler algorithm decides that the MT i Scheduler is allowed to transmit an IP

datagram towards the LLCT; these allowances are provided so that the bit rate of the

traffic which the MT i Scheduler is allowed to forward towards the LLCT is equal to

α(i)RLLCT, i.e. the capacity which the Main Scheduler allocates to the MT i Scheduler.

As regards the issue (iii), the MT i Buffer Controller can easily compute the FIFO

Buffer occupancies q(i,j,th) by means of Eq. 6.9.

• The MT i Buffer Controller, following a control based theoretical approach which will

be detailed in the following of this paper, determine the trends of the functions

Rloss(i,j,th) and δ(i,j,th) for j = 1,...,C(i). The trends of Rloss(i,j,th) are used to decide,

taking into account Eq. 6.2, the admittance into the FIFO Buffer (i,j) of the traffic

relevant to the associations (i,j) (j = 1,...,C(i)); in this respect, the MT i Buffer

Controller issues commands towards the Admittance Handlers stating whether the

incoming IP datagrams have to be admitted or discarded. The trends of δ(i,j,th)

determine the bit rates δ(i,j,th) RLLCT which are used to decide the FIFO Buffer entitled

to issue an IP datagram towards the LLCT.

It should be stressed that, according to the described arrangement, the MT i Buffer

Controller has both the congestion control role (the decision about the admittance or the

rejection of the IP datagrams, carried out through Rloss(i,j,th)) and the scheduling role (the

decision of the most urgent IP datagram to be transmitted towards the LLCT and hence the air

interface, carried out through δ(i,j,th)). It is pointed out that, up to the authors' knowledge, so

far, these two roles have always been handled by two different controllers in a nearly

uncoordinated fashion. Even more, in the existing arrangements the congestion control is

usually implemented by means a set of Dual Leaky Buckets (DLBs) regulating the flows

relevant to the various associations in an uncoordinated fashion. Then, it should be clear that

the advantages in terms of performance yielded by the proposed solution just derive from the

fact that we perform together, in a centralized fashion (at the MT i Buffer Control), both

congestion control and scheduling following an optimization criterion (the minimization of

the target function Eq. 6.6).


124

AdmittanceHandler (i,1)

AdmittanceHandler (i,1)

FIFO Buffer (i,1) whoseoccupancy is q(i,1,th) bits

MT i BufferController


AdmittanceHandler (i,C(i))

AdmittanceHandler (i,C(i))

FIFO Buffer (i,C(i)) whose occupancy is q(i,C(i),th) bits

Discarded trafficDiscarded traffic

From the Main Scheduler algorithm

Decisions about the MT Scheduler entitled to transmit an IP datagram towards the LLCT


Commands regulating the admittance of the IP datagrams in the FIFO Buffers

Decisions about the FIFO buffer entitled to transmit an IP datagrams towards the LLCT

IP datagrams relevant to the associations (i,1)

IP datagrams relevant to the associations (i,C(i))

Roff(i,1,th) Roff(i,C(i),th)

Admitted Traffic

LLCThRtiCi )),(,(δ

LLCThRti ),1,(δ

)),(,()),(,( hlosshoff tiCiRtiCiR −),1,(),1,( hlosshoff tiRtiR −

),1,( hloss tiR )),(,( hloss tiCiR

Figure 6-2: High-level internal structure of the MT i Scheduler at time th

In light of the above, neglecting the quantization effect caused by the fact that the

Traffic Control Module receives and transmits IP datagrams (i.e. bursts of bits) and reminding

Eq. 6.9, the control model of the MT i Scheduler is the one reported in Figure 6-3. From the

figure, it is evident that the variables Roff(i,j,th) can be regarded as exogenous inputs for the

control scheme.


125



+--

+--

From the Classifier),1,( hoff tiR )),(,( hoff tiCiR

),1,( hloss tiR

)),(,( hloss tiCiR

LLCTh Rti ),1,(δ

LLCTh RtiCi )),(,(δ

LLCTRi)(α

From the Main Scheduler algorithm

),1,(),1,( 1 hh tiqtiq −+

)),(,()),(,( 1 hh tiCiqtiCiq −+

Figure 6-3: Control Model of the MT i Scheduler

6.3 MT I BUFFER CONTROLLER DESIGN

This section aims at determining the MT i Buffer Controller which controls the C(i)

FIFO Buffers (i,j) (j = 1,...,C(i)) characterized by the Eq. 6.9 with the aim of minimizing the

target function Eq. 6.6, i.e. maximizing the (properly weighted) admitted traffic, while

respecting the QoS constraints Eq. 6.3, Eq. 6.4, Eq. 6.5 for all the admitted traffic, as well as

the capacity constraint Eq. 6.8.


126

The adopted approach is based on the idea of periodically computing an "ideal"

equilibrium and of controlling the system so that it tends to such an ideal equilibrium. The

ideal equilibrium is computed at time tk with tk+1 = tk + Tlong where the period Tlong is such that

Tlong > Tshort (for convenience, Tlong is selected so that it is equal to an integer number of times

Tshort). As detailed in the following, during the time interval [tk, tk+1), the control variables

Rloss(i,j,th) and δ(i,j,th) are selected so that the overall system tends to the ideal equilibrium

computed at time tk.

Such equilibrium is characterized by the following fundamental issues:

i) the exogenous inputs Roff(i,j,th) (j = 1,...,C(i)) are set at their values assumed at

time tk;

ii) all the capacity available for the MT i is assigned to the C(i) associations the

MT i is involved in, but for a security fraction ε;�

iii) the delay D(i,j,th) undergone by the IP datagrams is equal to the maximum

tolerated delay Dmax(j).

The above-mentioned equilibrium is referred to as "ideal" since, on the one hand, apart

from the security portion ε �it �succeeds in exploiting all the available capacity and, on the

other hand, maximizes the delays still meeting the constraints Eq. 6.5 on the maximum

allowed delays. In this last respect, it should be evident that, as the delay undergone by the IP

datagrams increases, the capacity of the Traffic Control Modules to absorb traffic peaks

increases as well and hence the number of IP datagrams which can be admitted (i.e. are not

discarded) also increases, thus minimizing the target function Eq. 6.6. In addition, at the

mentioned equilibrium, the constraints Eq. 6.4 on the minimum allowed delays is definitely

met.

The trade-off underlying the choice of Tlong is as follows: by increasing Tlong, on the one

hand, the transitory duration is increased as well, so that at time tk+1 the system can actually

approach the ideal equilibrium computed at time tk, but, on the other hand, the equilibrium

tends to no longer reflect the actual situation, since it has been computed in the assumption

that during the time interval [tk, tk+1) the exogenous inputs Roff(i,j,th) remain fixed at their

values assumed at time tk (see issue (i)).


127

In addition, both Tlong and Tshort are also selected by taking into account computational

issues: every Tlong seconds the MT i Buffer Controller has to compute a new ideal

equilibrium, while every Tshort seconds the MT i Buffer Controller has to compute the control

variables Rloss(i,j,th) and δ(i,j,th) aiming at leading the system towards the last computed

equilibrium.

In the following, the various variables relevant to the ideal equilibrium computed at time

tk will be indicated with the symbol "*" and with the pedex "tk".

At the ideal equilibrium, for each time th in the interval [tk, tk+1), taking into account that

q(i,j,th+1) -� q(i,j,th) = 0 and that D(i,j,th) equals Dmax(j) (see issue (iii)), Eq. 6.9 and Eq. 6.10

become:

Eq. 6.12 LLCTtlosstofft RjijiRjiRkkk

),(),(),(0 *** δ−−= −− j=1..C(i)

Eq. 6.13 LLCTtt RjijDjiqkk

),()(),( *max

* δ= j=1..C(i)

where, considering the issue (i):

Eq. 6.14 Rtk-off*

(i,j) = Roff(i,j,tk) j = 1,...,C(i)

By considering Eq. 6.12 and the issue (ii), at the equilibrium, the capacity constraint

Eq. 6.8 becomes:

Eq. 6.15 ∑ ∑= =

−=−= −−

)(

1

)(

1

*** )()1()),(),((),(iC

j

iC

j

LLCTttLLCTt RijiRjiRRjilosskoffkk

αεδ

where ε is a positive constant to be selected as explained in the following.

The Eq. 6.15 allows the computation of Rtk-loss*

(i,j) according to the following algorithm

which aims at the minimization of the cost index Eq. 6.6 and allows to respect the constraints

Eq. 6.3 and Eq. 6.15:

1) Rtk-loss*

(i,j) is set to max(Rtk-off*

(i,j) � Rmin(j), 0) for j = 1,...,C(i).

2) if Eq. 6.15 holds, then the algorithm terminates; otherwise, a parameter Rleft(i), indicating

the capacity which can still be assigned, is computed as follows:


128

[ ]∑=

−− −−−=)(

1

** ),(),()()1()(iC

jlosstofftLLCTleft jiRjiRRiiR

kkαε

and the highest not yet selected weight in the set w(j) j = 1,...,C(i) is considered, say the

weight w(j1); in case all the weights have already been selected the algorithm terminates.

In case two or more weights are equal, then, in the subset of equal weights, the weights

are selected in a circular fashion, according to their ordering number, starting from a first

weight which, in order to preserve fairness, rotates at every new ideal equilibrium.

3) ),( 1* jiR losstk− is set to )0),()().(max( 1min1

* iRjRjiR leftofftk −−− and the algorithm goes to step

2).

It should be evident that this algorithm grants to each association at least the capacity

necessary to transmit the Compliant Traffic, and allocates the remaining capacity so that the

cost index Eq. 6.6 is minimized.

Once the variables Rtk-loss*

(i,j) (j = 1,...,C(i)) are fixed, ),(* jiktδ and ),(* jiq

kt can be easily

computed on the grounds of Eq. 6.12, Eq. 6.13 and Eq. 6.14. Note that since, in virtue of the

previous algorithm, Rtk-loss*

(i,j) is not greater than Rtk-off*

(i,j), than both ),(* jiktδ and ),(* jiq

kt are

non negative.

By so doing, we have computed the ideal equilibrium which, if the overall scheme

would be frozen at time tk, would minimize the target function Eq. 6.6 while respecting all

the constraints.

Let us partition the set including all active associations at the time th ∈ [tk, tk+1) (whose

cardinality is equal to C(1)+...+C(N)) into the following two subsets:

)0),(),,(:),(( * ≥−=+ jiqtjiqjiIkh tht

)0),(),,(:),(( * <−=− jiqtjiqjiIkh tht

Let us partition the set of Class of Services which are active in a certain MT i (whose

cardinality is equal to C(i)) into the following two subsets:


129

)0),(),,(:()( * ≥−=+ jiqtjiqjiIkh tht i=1..N

)0),(),,(:()( * <−=− jiqtjiqjiIkh tht i=1..N

The cardinality of the subsets )(iIht+ will be denoted as )(iM + .

The idea behind the proposed MT i Buffer Controller is to tend, at every time

th ∈ [tk, tk+1) towards the ideal equilibrium computed at time tk. Taking this approach into

account, at the time [ )1, +∈ kkh ttt , the output control variables (Rloss(i,j,th) and δ(i,j,th)) of the

proposed MT i Buffer Controller are deduced according to the following relations:

Eq. 6.16 )0),,(),,(),(max(),,( ** jiRtjiRjiRtjiR offthofflossthloss kk −− −+=

Eq. 6.17 [ ]),(),,(),,(),(),,( *** jiqtjiqtjiKjitjikkk thhtth −+= δδ

where Rtk-loss*

(i,j), ),(* jiqkt , ),(* ji

ktδ are computed as described above and Ktk

*(i,j,th) (j = 1,...C)

are positive constants to be determined as follows:

Eq. 6.18 [ ]),(),,()(

)(),,(

**

jiqtjiqiM

itjiK

k

k

thht −

= +

εα if +∈

htIji ),(

Eq. 6.19 )1

,),(),,(

),(min(),,(

*

**

LLCTshortth

tht RTjiqtjiq

jitjiK

k

k

k −−=

δ if −∈

htIji ),(

Note that the above-mentioned choice of Ktk

*(i,j,th) entails that the control variable

δ(i,j,th) yielded by Eq. 6.17 is always non negative which is compulsory due to physical

reasons.

It should be evident that, as the FIFO Buffer (i,j) occupancy q(i,j,th) differs from the

ideal one qtk*(i,j), the control law Eq. 6.17 tends to vary the fraction of capacity δ(i,j,th)

assigned to the association (i,j) in such a way that the overall control scheme tends to the ideal

equilibrium. For instance, if the FIFO Buffer (i,j) occupancy q(i,j,th) is lower than the ideal

one qtk*(i,j), the control law Eq. 6.17 assigns to the association (i,j) a fraction of capacity


130

Centralized computation of R*tk-loss(i,j) according to the three

step algorithm. Rloss(i,j,t h)=max(R*

tk-loss(i,j)+R off(i,j,t h)-Rtk-off(i,j),0)

Centralized computation of R*tk-loss(i,j) according to the three

step algorithm. Rloss(i,j,t h)=max(R*

tk-loss(i,j)+R off(i,j,t h)-Rtk-off(i,j),0)

q*tk

(i,1) and δ*tk

(i,1) computation

according to eq. 5.12, eq. 5.13, eq. 5.14

q*tk

(i,1) and δ*tk

(i,1) computation

according to eq. 5.12, eq. 5.13, eq. 5.14

K *tk

(i,1,th) computation according to

eq. 5.18, eq. 5.19

K *tk

(i,1,th) computation according to

eq. 5.18, eq. 5.19

δ(i,1,th) computationaccording to eq. 5.17

δ(i,1,th) computationaccording to eq. 5.17

q(i,1,th+1) computationaccording to eq. 5.9

q(i,1,th+1) computationaccording to eq. 5.9

q*tk

(i,C(i)) and δ*

tk(i,C(i)) computation

according to eq. 5.12,eq. 5.13, eq. 5.14

q*tk

(i,C(i)) and δ*

tk(i,C(i)) computation

according to eq. 5.12,eq. 5.13, eq. 5.14

K *tk

(i,C(i),t h)computation according to

eq. 5.18, eq. 5.19

K *tk

(i,C(i),t h)computation according to

eq. 5.18, eq. 5.19

δ(i,C(i),t h) computation according to eq. 5.17

δ(i,C(i),t h) computation according to eq. 5.17

q(i,C(i),th+1) computationaccording to eq. 5.9

q(i,C(i),t h+1) computationaccording to eq. 5.9

),1,( koff tiR )),(,( koff tiCiR

),1,( hloss tiR )),(,( hloss tiCiR

),1,( koff tiR )),(,( koff tiCiR

LLCTRi)(α

),1,( htiq )),(,( htiCiq

)),(,( hoff tiCiR),1,( hoff tiR

),1,( htiδ )),(,( htiCiδ

)1,(* iR losstk− ))(,(* iCiR losstk−

)1,(),1,( ** iiqkk tt δ ))(,()),(,( ** iCiiCiq

kk tt δ

),1,(*ht tiK

k),1,(*

ht tiKk

δ(i,j,th) lower than the ideal one; clearly, this action produces an increase in the FIFO Buffer

(i,j) occupancy, thus tending to report such occupancy at the ideal equilibrium.

Figure 6-4 shows the internal structure of the MT i Buffer Controller summarizing the

various steps which such controller has to perform in order to deduce the output control

variables Rloss(i,j,th) and δ(i,j,th) (j = 1,...,C(i)) on the basis of Roff(i,j,th) and α(i)RLLCT which

are the inputs of the MT i Buffer Controller.

Figure 6-4: MT i Buffer Controller

In order to show that the control laws Eq. 6.16, Eq. 6.17 are appropriate, we need to

show that the ideal equilibrium is globally asymptotically stable and that even during the


131

transient, the capacity constraint Eq. 6.8, which must be always satisfied due to physical

reasons, is met.

First of all, note that by inserting Eq. 6.17 into Eq. 6.9, we get at a time [ )1, +∈ kkh ttt

Then, by taking Eq. 6.12 and Eq. 6.16 into account, we obtain at a time [ )1, +∈ kkh ttt :

[ ] shortLLCTthhthh TRjiqtjiqtjiKtjiqtjiqkk

),(),,(),,(),,(),,( **1 −−=−+

where we have assumed that the first argument of the maximum appearing in Eq. 6.16 is not

lower than zero (it should be easy to show that, in the opposite case, the arguments herafter

exposed hold even more so).

Finally, by setting at a time [ )1, +∈ kkh ttt

Eq. 6.20 ),(),,(),,( * jiqtjiqtjiekthh −=

we get at a time [ )1, +∈ kkh ttt :

),,(),,(),,(),,( *1 hshortLLCThthh tjieTRtjiKtjietjie

k−=−+

i.e.

Eq. 6.21 ( ) ),,(),,(1),,( *1 hshortLLCThth tjieTRtjiKtjie

k−=+

Taking into account Eq. 6.19 and Eq. 6.21, the trends by which ),,( htjie tends to zero

in the time interval [tk, tk+1] are the ones shown in Fig. 4.2 (in this figure Tlong has been

assumed equal to 10 Tshort).

If ),,( htjie is positive (i.e. if, at time th, the association (i,j) belongs to +htI ), than, in

virtue of Eq. 6.18, the Eq. 6.21 becomes

)(

)(),,(),,( 1

iM

iTRtjietjie shortLLCThh ++ −=

εα

[ ]( ) shortLLCTthhtLLCTthlosshoffhh TRjiqtjiqtjiKRjitjiRtjiRtjiqtjiqkkk

),(),,(),,(),(),,(),,(),,(),,( ***1 −−−−=−+ δ


132

i.e., at each discrete time instant (i.e. every Tshort seconds), the error reduces by an

amount A equal to )(

)(

iM

iTR shortLLCT +

εα(see Fig. 4.2a); note that as, due to these reductions,

),,( htjie becomes negative, then the error follows the trends herafter explained.

When ),,( htjie is positive the delay constraint Eq. 6.5 can be temporarily violated: in

usual implementation this is accepted provided that the percentage of overdelayed bits does

not exceed a given low threshold (2%, in the simulations presented in Section 7); note that the

fact that ),,( htjie is positive does not automatically mean a violation of Eq. 6.5 and that the

system tends to a situation (null error) in which the delay constraint Eq. 6.5 is definitely met.

Anyhow, it is important to assure a rapid convergence of the error to zero; in this respect, a

trade-off exists in the choice of ε since, on the one hand, an high ��entails a rapid

convergence of q(i,j,t) towards the optimum value q*(i,j), thus mitigating the effect on the

delay of possible transients in which e(i,j,th) becomes positive; on the other hand, an high ε

�reduces the available capacity (seeEq. 6.15).

If ),,( htjie is negative (i.e. if, at time th, the association (i,j) belongs to −htI ) the

following two trends are possible:

i) if LLCTshortth

t

RTjiqtjiq

ji

k

k1

),(),,(

),(*

*

≥−

δ , than, in virtue of Eq. 6.19, the Eq. 6.21

becomes 0),,( 1 =+htjie , i.e. the error converges to zero in just one discrete time

instant, i.e. in Tshort seconds (see Figure 6-6);

ii) if LLCTshortth

t

RTjiqtjiq

ji

k

k 1

),(),,(

),(*

*

<−

−δ

, in virtue of Eq. 6.19, the Eq. 6.21 becomes

),(),,(),,( *1 jiTRtjietjie

ktshortLLCThh δ+=+ , i.e., at each discrete time instant (i.e.

every Tshort seconds), the module of the error reduces by an amount A equal to

),(* jiTRktshortLLCT δ ; in this case the trend ia as in Figure 6-5, but specular with

respect to the time axis.


133

Figure 6-5: Trend of the error e(i,j,th) for th>=tk if e(i,j,tk) is positive

Figure 6-6: Trend of the error e(i,j,th) for t ∈ [tk,tk+1] if e(i,j,tk) is negative and

LLCTshortth

t

RTjiqtjiq

ji

k

k 1

),(),,(

),(*

*

≥−

−δ

Thus, we have shown that, in any situation, the error converges to zero regardless of the initial

conditions (i.e. the system is globally asymptotically stable).

Finally, as concerns the respect of the capacity constraint Eq. 6.8 during the transient,

by considering Eq. 6.15, Eq. 6.16, Eq. 6.17 and the fact that [ ]),(),,(),,( ** jiqtjiqtjiKkk thht −

is negative for any j ∈ )(iIht− , we have for any i ∈ [1, N]:

th

e( i,j,t )h

tk Tshort

A

AA

tk+1

Tlong

th

e(i,j,t )h

e(i,j,t )k

tk tk+1

Tlong

Tshort


134

[ ]=−+=∑ ∑∑= ==

)(

1

*)(

1

**)(

1

),(),,(),,(),(),,(iC

jth

iC

jhtt

iC

jh jiqtjiqtjiKjitji

kkkδδ

[ ] [ ]≤−+−+ ∑∑∑−+ ∈∈= )(

**

)(

**)(

1

* ),(),,(),,(),(),,(),,(),(itIj

thhtitIj

thht

iC

jt

h

kk

h

kkkjiqtjiqtjiKjiqtjiqtjiKjiδ

)()()()1()(

)()()1(

)(

iieiiM

ii

itIj h

αααεεααε =+−=+− ∑+∈

+


135

PART FOUR Simulation and Performance


136

7 OPNET Simulation of the WAL

7.1 INTRODUCTION

This chapter is concerned with the simulation of a meaningful subset of the functionalities

provided by the Wireless Adaptation Layer (WAL) in order to ensure the right QoS support to

each “TCP\IP connection” supported by anyone of the four segments (UMTS, GPRS, ESW,

W-LAN) belonging to the GMBS system.

Most of the simulation efforts has been devoted to emulate the traffic and congestion control

mechanisms provided by the WAL, basically through the use of a proper set of dual leaky

buckets (DLBs) and the exploitation of a scheduler module based on the Earliest Deadline

First (EDF) scheduling policy. Moreover, the adopted OPNET simulation approach, based on

the modelling of the Wireless Adaptation Layer by means of a single queue module, can be

also considered as a first step towards the insertion of the WAL module within the protocol

stack, between the IP layer and the upper layers of the underlying wireless network.

OPNET Modeler 7.0.B, the latest version of a commercial network simulation tool, and

Microsoft Visual C++ 6.0, a common C++ compiler, have been used for simulation purposes,

in order to be compliant with the directives coming from the 3rd SUITED Progress Meeting

held in Germany (Munich, 27-28 September 2000).

As regards the internal structure of this chapter, the second paragraph aims at providing an

overview of both the OPNET environment key features and the OPNET specific terminology,

whereas the third paragraph provides not only a concise discussion of the basic hypothesis the

OPNET simulation of the Wireless Adaptation Layer is based on, but even a detailed

description of the adopted simulation approach, highlighting the most interesting features of

the OPNET realization of some network, node and process models; finally, the fourth part is

devoted to the simulation results analysis, by means of OPNET graphics and relevant

comments.


137

7.2 OPNET MODELER GENERAL DESCRIPTION

Originally developed at MIT (Massachusetts Institute of Technologies), OPNET Modeler

has been introduced in 1987 as the first commercial network simulation tool and actually

provides a comprehensive development environment supporting the modelling of

communication networks and distributed systems.

Figure 7-1:OPNET Modeler

Both behaviour and performance of modelled systems can be analysed by performing discrete

event simulations; it’s worth highlighting that the OPNET environment incorporates editors

and tools for all phases of a study, including model design, simulation, data collection and

data analysis.

This paragraph, which aims at providing an overview of OPNET capabilities and structure, is

divided into the following four sub-sections:

� Key System Features: enumerates salient and distinctive characteristics of the OPNET

software.

� Typical Applications: presents some applications typically addressed with OPNET

and some of the features that provide direct support for those applications.


138

� Modelling methodology: describes the OPNET approach to each phase of the

modelling and simulation project and presents fundamental modelling constructs.

� Editors and tools: introduces the editors and tools that constitute the OPNET

environment; each editor, as far as each generic tool, supports a particular phase or

sub-phase of the simulation and modelling project.

7.2.1 Key features

OPNET is a vast software package with an extensive set of features designed to support

general network modelling and to provide specific support for particular types of network

simulation projects. This section aims at providing a brief enumeration of some of the most

important OPNET capabilities:

� Object orientation: systems specified in OPNET consist of objects, each with

configurable sets of attributes. Objects belong to “classes” which provide them with

their characteristics in terms of behaviour and capability. Definitions of new classes

are supported in order to address as wide a scope of systems as possible. Classes can

also be derived from other classes, or “specialized” in order to provide more specific

support for particular applications.

� Specialized in communication networks and information systems: OPNET

provides many constructs relating to communications and information processing,

ensuring high leverage for modelling of networks and distributed systems.

� Hierarchical models: OPNET models are hierarchical, naturally paralleling the

structure of actual communication networks.

� Graphical specification: wherever possible, models are entered via graphical editors.

These editors provide an intuitive mapping from the modelled system to the OPNET

model specification.


139

� Flexibility to develop detailed custom models: OPNET provides a flexible, high-

level programming language with extensive support for communications and

distributed systems. This environment allows realistic modelling of all algorithms,

communications protocols and transmission technologies.

� Automatic generation of simulations: model specifications are automatically

compiled into executable, efficient, discrete-event simulations implemented in the C

programming language. Advanced simulation construction and configuration

techniques minimize compilation requirements.

� Application-specific statistics: OPNET provides numerous built-in performance

statistics that can be automatically collected during simulations. In addition, modellers

can augment this set with new application-specific statistics that are computed by

user-defined processes.

� Integrated post-simulation analysis tools: performance evaluation and trade-off

analysis require large volumes of simulation results to be interpreted. OPNET includes

a sophisticated tool for graphical presentation and processing of simulation output.

� Interactive analysis: all OPNET simulations automatically incorporate support for

analysis via a sophisticated interactive “debugger”.

� Animation : simulation runs can be configured in order to automatically generate

animations of the modelled system at various levels of detail and can include

animation of statistics as they change over time. Extensive support for developing

customized animations is also provided.

� Application program interface (API) : as an alternative to graphical specification,

OPNET models and data files may be specified via a programmatic interface. This is

useful for automatic generation of models or to allow OPNET to be tightly integrated

with other tools.


140

7.2.2 Typical applications

As a result of the capabilities that were described in the previous sections, OPNET can be

used as a platform to develop models of a wide range of systems.

Some examples of possible applications are listed below:

� Standards-based LAN and WAN performance modelling: detailed library models

provide major local-area and wide-area network protocols. The library also provides

configurable application models, or new ones can be created.

� Inter-network planning : hierarchical topology definitions allow arbitrarily deep

nesting of sub-networks and nodes and large networks are efficiently modelled;

scalable, stochastic and/or deterministic models can also be used in order to generate

network traffic.

� Research and development in communications architectures and protocols:

OPNET allows specification of fully general logic and provides extensive support for

communications-related applications. Finite state machines provide a natural

representation for protocols.

� Distributed sensor and control networks, “on-board” systems: OPNET allows

development of sophisticated, adaptive, application-level models, as well as

underlying communications protocols and links. Customized performance metrics can

be computed and recorded, scripted and/or stochastic inputs can be used to drive the

simulation model, and processes can dynamically monitor the state of objects in the

system via formal interfaces provided by statistic wires.

� Resource sizing: accurate, detailed modelling of a resource’s request-processing

policies is required to provide precise estimates of its performance when subjected to

peak demand (for example, a packet switch’s processing delay can depend on the

specific contents and type of each packet as well as its order of arrival). Queuing

capabilities of Proto-C provide easy-to-use commands for modelling sophisticated


141

queuing and service policies; library models are provided for many standard resource

types.

� Mobile packet radio networks: specific support for mobile nodes, including

predefined or adaptive trajectories; predefined and fully customisable radio link

models; geographical context provided by OPNET network specification environment.

(Radio version only)

� Satellite networks: specific support for satellite nodes, including automatic placement

on specified orbits, a utility program for orbit generation and visualization and, finally,

an orbital configuration animation program. (Radio version only)

� C3I and tactical networks: support for diverse link technologies; modelling of

adaptive protocols and algorithms in Proto-C; notification of network component

outages and recoveries; scripted and/or stochastic modelling of threats; radio link

models support determination of friendly interference and jamming.

7.2.3 Modeling methodology

As previously stated, OPNET is provided with a number of editors and tools, each one

focusing on particular aspects of the modelling task. These tools fall into three major

categories that correspond to the three phases of modelling and simulation projects:

specification, data collection and simulation and results analysis.

These three phases are necessarily performed in sequence and generally form a cycle, due to a

return to the specification phase at the end of the analysis phase. Moreover, the specification

phase is actually divided into two parts: initial specification phase and re-specification phase,

with only the latter belonging to the cycle.

The simulation project cycle is depicted in the following figure:


142

Figure 7-2:Simulation project cycle

7.2.3.1 Specification phase

The workflow for OPNET (i.e. the steps required to build a specific network model) is based

on three fundamental levels, the Project Editor, the Node Editor and the Process Editor.

OPNET network models define the position and interconnection of communicating entities, or

nodes. Each node is described by a block structured data flow diagram, or OPNET node

model, which typically depicts the interrelation of processes, protocols and subsystems.

Moreover, each programmable block in a node model has its functionality defined by an

OPNET process model, which combines the graphical power of a state-transition diagram

(FSM) with the flexibility of a standard programming language (C++) and a broad library of

pre-defined modelling functions.

OPNET makes use of graphical specification of models wherever appropriate. Thus, the

model-specification editors all present a graphical interface in which the user manipulates

objects representing the model components and structure. Each editor has its specific set of

objects and operations that are appropriate for the modelling task on which it is focused. For

instance, the Project Editor makes use of node and link objects; the Node Editor provides

processors, queues, transmitters, and receivers; and the Process Editor is based on states and

transitions. As a result, since no single paradigm of visual representation is ideally suited for

all three of the above mentioned model types, the diagrams developed in each editor have a

distinct appearance and OPNET models fit together in a hierarchical fashion, as shown in the

following screen samples:

Analysis

Initial specification

Re-specification

Data collection and simulation


143

Figure 7-3:OPNET Model Hierarchy

7.2.3.2 Data collection and simulation

The objective of most modelling efforts is to obtain measures of a system’s performance or to

make observations concerning a system’s behaviour. OPNET supports these activities by

creating an executable model of the system. Provided that the model is sufficiently

representative of the actual system, OPNET allows realistic estimates of performance and

behaviour to be obtained by executing simulations through the exploitation of both the

Simulation tool and the Interactive Debugging Tool. Several mechanisms are provided to collect

the desired data from one or more simulations of a system; for example, OPNET supports

both local (related to an object) and global (related to the overall system) statistics and

modellers can take advantage of the programmability of OPNET models to create proprietary

forms of simulation output. Moreover, OPNET simulations can generate animations that are

Node model

Process model Network model


144

viewed during the run, or “played back” afterwards. Several forms of predefined or

“automatic” animations are provided (packet flows, node movement, state transitions, and

statistics). In addition, detailed, customized animations can be programmed if desired.

7.2.3.3 Results analysis

The third phase of the simulation project involves examining the results collected during the

simulation phase. OPNET provides basic access to this data in the Project Editor and more

advanced capabilities in the Analysis Tool, which provides a graphical environment that

allows users to view and manipulate data collected during simulation runs. In particular,

standard and user-specified probes can be inserted at any point in a model to collect statistics.

Simulation output collected by probes can be displayed graphically, viewed numerically, or

exported to other software packages. First and second order statistics on each trace as well as

confidence intervals can be automatically calculated. OPNET supports the display of data

traces as time-series plots, histograms, probability density and cumulative distribution

functions. Graphs (as with models at any level in the OPNET modelling hierarchy) may be

output to a printer or saved as bitmap files to be included in reports or proposals.

Figure 7-4:Graphical environment of the Analysis Tool


145

7.2.4 Editors and tools

OPNET supports model specification with a number of tools or editors that capture the

characteristics of a modelled system’s behaviour. Because it is based on a suite of editors that

address different aspects of a model, OPNET is able to offer specific capabilities to address

the diverse issues encountered in networks and distributed systems. To present the model

developer with an intuitive interface, these editors break down the required modelling

information in a manner that parallels the structure of actual network systems. Thus, the

model-specification editors are organized in an essentially hierarchical fashion. Model

specifications performed in the Project Editor rely on elements specified in the Node Editor;

in turn, when working in the Node Editor, the developer makes use of models defined in the

Process Editor. The remaining editors are used to define various data models, typically tables

of values, that are later referenced by process or node level models. This organization is

depicted in the following list:

� Project Editor : the Project Editor is used to construct and edit the topology of a

communication network model. A network model contains only three fundamental

types of objects: sub-networks, nodes, and links. There are several varieties of nodes

and links, each offering different basic capabilities. In addition, each node or link is

further specialized by its “model”, which determines its behaviour and functionality.

The Project editor also provides basic simulation and analysis capabilities.

Finally, it’s worth highlighting that the entire system to be simulated is specified by

the corresponding network model.

Figure 7-5:Generic network model


146

� Node Editor: the Node Editor is used to specify the structure of device models. These

device models can be instantiated as node objects in the Network Domain (such as

computers, packet switches, and bridges). In addition to the structure, the node model

developer defines the interface of a node model, which determines what aspects of the

node model are visible to its user. This includes the attributes and statistics of the node

model. Nodes are composed of several different types of objects called modules. At

the node level, modules are “black boxes” with attributes that can be configured to

control their behaviour. Each one represents particular functions of the node’s

operation and they can be active concurrently. Several types of connections (packet

streams, statistical wires and logical associations) support flow of data and control

information between the modules within a node.

Figure 7-6 : Generic node model

� Process Editor: The Process Editor is used to specify the behaviour of process

models. Process models are instantiated as processes in the Node Domain and exist

within processor and queue modules. Processes can be independently executing

threads of control that perform general communications and data processing functions.

They can represent functionalities that would be implemented both in hardware and in

software. In addition to the behaviour of a process, the process model developer

defines the model’s interfaces, which determines what aspects of the process model

are visible to its user. This includes the attributes and statistics of the process model.

Process models use a finite state machine (FSM) paradigm to express behaviour that


147

depends on current state and new stimuli. FSMs are represented using a state transition

diagram (STD) notation. The states of the process and the transitions between them

are depicted as graphical objects, as shown by the following figure:

Figure 7-7 : Generic process model

� Link Model Editor : the Link Model Editor is used to create, edit , and view link

models.

� Packet Format Editor: the Packet Format Editor is used to develop packet formats

models. A packet format contains one or more fields, represented in the editor

workspace as coloured rectangular boxes. The size of the box is proportional to the

number of bits specified as the field’s size. Fields can assume fixed length of inherited

length for simulation specific needs (e.g. payload encapsulation) and may be one of

several types: integer, double, structure, information, and packet.


148

Figure 7-8:Generic packet format

� ICI Editor : the ICI Editor is used to create, edit, and view interface control

information (ICI) formats. ICIs are used to communicate control information between

processes.

� Antenna Pattern Editor: the Antenna Pattern Editor is used to create, edit, and view

antenna patterns for transmitters and receivers. (Modeler/Radio only)

� Modulation Curve Editor : the Modulation Curve Editor is used to create, edit, and

view modulation curves for transmitters. (Modeler/Radio only)

� PDF Editor: the PDF Editor is used to create, edit, and view probability density

functions (PDFs). PDFs can be used to control certain events, such as the frequency of

packet generation in a source module. (Modeler only)


149

8 SIMULATIONS OF TRAFFIC CONTROL MODULE

8.1 ADAPTATION OF THE THEORETICAL PROCEDURES

This paragraph explains how the control system proposed in the previous sections has

been tailored for the implementation. The issues explained in this section have also been

adopted for the simulations whose results are disclosed in Section 8.3.

The theoretical approach which has been followed in Sections 6.2 and 6.3 refers to a

continuous stream of bits. In other words, we neglected the fact that the Traffic Control

Module receives and transmits IP datagrams which consist of variable length bursts of bits. In

the simulations we will consider four Service Classes for each single MT (Voice, FTP, Web,

Video), i.e. C(i)=4. Each Service Class is modelled as a statistical source which emits

datagrams with the statistical characteristics shown in Table 8-1. We can notice that while the

datagram length is constant for the Voice, it is not constant for the other applications. In fact

the datagram length in FTP, Web, Video has a uniform statistical distribution in three

different intervals, and in the FTP it can exceed 30kbit. It is essential to note that an IP

datagram has to be emitted entirely and cannot be broken, otherwise it becomes useless.

Now let us focus on the transmission of the datagrams from the FIFO Buffers towards the

LLCT. In the proposed algorithm the MT i Buffer Controller enables the FIFO Buffer (i,j) to

transmit δ(i,j,th)RLLCT Tshort bits every Tshort seconds. Two cases are possible:

i) the length of the first datagram in the FIFO Buffer exceeds the number of bits which the

FIFO Buffer is allowed to transmit towards the LLCT

ii) the FIFO Buffer is able to transmit one or more datagrams, but wastes the capacity

fraction not sufficient to transmit the datagram following the last one successfully

emitted


150

In both cases we have two problems. On the one hand some datagrams can not be emitted

towards the LLCT until the MT i Buffer Controller assigns a sufficient capacity to the Buffer.

On the other hand we waste a fraction of the capacity assigned to the FIFO Buffer (i,j).

The first problem implies that for a long time there may not be enough capacity to

transmit long datagrams, which therefore engulf the FIFO Buffer. In this case the FIFO Buffer

may empty slower than expected according to the theoretical approach based on a continuous

sequence of bits, and there is the possibility that some datagrams may not respect the delay

constraint. If this occurs, these datagrams become useless and must be eliminated. Therefore

the first modification which we must introduce is an inspection at the exit of the FIFO Buffer

which discards the expired datagrams (i.e. those datagrams which do not respect the delay

constraint). This causes a loss at the exit of the FIFO Buffer which was not considered in the

theoretical approach and which causes a degradation of the performances.

The second problem can be avoided introducing a recovery of the capacity. This is the

second modification which we introduce, and in the implementation this was done as follows:

the fraction of the capacity wasted in the FIFO Buffer (i,1) (because not sufficient to transmit

the following datagram) is given to the FIFO Buffer (i,2). Similarly the fraction of the

capacity which cannot be exploited from the FIFO Buffer (i,2) is given to the FIFO Buffer

(i,3), and successively from (i,3) to (i,4). The fraction wasted by the FIFO Buffer (i,4) is not

recovered and is lost. Thus we minimize the waste of the capacity.

The fluctuation of the statistical sources together with the discarding of the expired

datagrams cause a third problem, which has been evidenced during the first simulations: in

some instants the capacity assigned to the FIFO Buffer (i,j) may allow to transmit more

datagrams than those actually inside the FIFO Buffer. This is due to the discarding of

Rloss(i,j,th) in the admittance handler (i,j). As it is stated in the previous sections, the

discarding of Rloss(i,j,th) in the admittance handler (i,j) aims to report the FIFO Buffer

occupancy q(i,j,tk) to the “ideal” one qtk*(i,j). This happens in the theoretical approach in

which we refer to a continuous stream of bits, but not in real applications where we must refer

to datagrams whose length fluctuates statistically. So, especially when the traffic offered is

lower than the average, it can come true the problem evidenced previously, i.e. that the FIFO

Buffer is allowed to transmit more bits than its real occupancy in that instant. If this happens

the FIFO Buffer (i,j) does not exploit at its best the capacity which has been assigned by the


151

MT i Buffer Controller, and this means that the link efficiency is lower than it could be

expected. To avoid this risk we must introduce the third modification to the theoretical model,

i.e. we eliminate the discarding of Rloss(i,j,th) in the admittance handler (i,j). In this way all

the traffic offered is admitted into the FIFO Buffer, and the only discarding occurs at exit of

the FIFO Buffer for the expired datagrams. It is important to remark how this modification

does not change the essence of the algorithm. Even if we eliminate the discarding of

Rloss(i,j,th), we maintain its computation because it is necessary to compute qtk*(i,j), δtk

*(i,j) and

Ktk*(i,j,th) which determine the capacity assigned to each FIFO Buffer, as it is evidenced in

Figure 6-4.

Now let us explain the criteria which we followed to choose some important

parameters. In particular let us focus on (i) Tshort , (ii) w(j), (iii) ε.

(i) The actual implementation of the Traffic Control Module entails that the computation of

the control variables can not be performed at any time t, but only periodically with period

Tshort . As it has been stated in the previous paragraphs, the FIFO Buffer (i,j) is entitled to

transmit δ(i,j,th)RLLCT Tshort bits towards the LLCT every Tshort seconds. The trade-off

underlying the choice of Tshort is as follows: on the one hand a long Tshort allows to

transmit more bits, but on the other hand a long Tshort entails the infringing of the delay

constraints. Considering that the maximum datagram length is near to 40kbit (FTP), if we

want our system to be able to transmit these datagrams we should have δ(i,j,th)RLLCT Tshort

≥ 40kbit, consistently with the delay constraints. As RLLCT is fixed to 25Mbit/sec, but

δ(i,j,th) is computed dynamically in the algorithm, Tshort is not fixed. The criterion

followed consists in estimating the average of δ(i,j,th) for all the Service Classes, in order

to compute Tshort as Tshort = 40kbit

δ(i,j,th) RLLCT , verifying that the delay constraints are

satisfied. Following this criterion we chose the value Tshort=80 msec.

(ii) w(j) are the weights used in the centralized control which computes Rtk-loss,*

(i,j), as it is

explained in section 4. The aim of these weights was to fix the priorities among the

Service Classes in the assignation of the capacity Rleft(i), which was the capacity

available to transmit the Non-Compliant Traffic. We choose to put w(j)=1 for j=1,..,C(i),

i.e. none of the Service Classes has priority among the other Classes, so that the capacity


152

Rleft(i) is assigned following a fairness criterion. To avoid a possible polarization in the

assignation of Rleft(i) we assign cyclically priority to each Service Class. In this way the

order of priority changes at each cycle as in a token-ring.

8.2 MAIN FEATURES DESCRIPTION

Parameter Symbol

Parameter Meaning

Assumed Values in the Service

Class j = 1

Assumed Values in the Service Class j = 2

Assumed Values in the Service

Class j = 3

Assumed Values in the Service Class j

= 4

J Service Class Id 1 2 3 4 Typical

Application Voice1 FTP Web Video

RAV

Average Bit Rate per

connection (Nominal

Value)

29.2 Kbps (GSM)

200 Kbps (Computed during the download periods2)

40 Kbps (Computed during

the download periods3)

1,132 Mbps B Frames 1.481 Mbps P Frames 2.143 Mbps I Frames4

BAV Average IP datagrams length

580 Bits (GSM)

20000 Bits 12000 Bits 12000 Bits

Statistical Distribution of

the random variable

Bsegment(j)

CONSTANT at the value

specified in the line above

UNIFORM In the interval [320, 39680]

Bits

UNIFORM in the interval [320, 23680] Bits

UNIFORM in the interval [320,

23680] Bits

TAV

Average Interarrival Time

between consecutive IP

datagrams (nominal value)

20 ms

100 ms

300 ms

7.57 ms

Statistical Distribution of the random variable representing the

Tinterarrival(j) Between

consecutive IP datagrams of a

certain connection

CONSTANT at the value

specified in the line above

UNIFORM in the interval [0.05, 0.15]

secs

UNIFORM in the interval

[0.05, 0.55] secs

GAUSSIAN with the following

average 10.6 ms (B Frame) 8.1 ms (P Frame) 5.6 ms (I Frame)

Table 8-1: Main statistical characteristics of the considered Service Classes.

1 A GSM connection plus the IP overhead is considered. 2 The average interarrival time is computed during the download periods. As a matter of fact, the FTP connection is modeled as a sequence of download periods and pause periods. The download period durations are assumed to be random variables uniformly distributed in the range [4; 40] sec; the download period interarrival times are assumed to be random variables uniformly distributed in the range [4; 40] sec. 3 The average interarrival time is computed during the download periods. As a matter of fact, the Web application is modeled as a sequence of download periods and pause periods. The download period durations are assumed to be random variables uniformly distributed in the range [2; 20] sec; the download period interarrival times are assumed to be random variables uniformly distributed in the range [3; 30] sec. 4 The three kinds of frames corresponds at three different states of a Markov process whose transitions are statistically determined.


153

This section includes some meaningful results obtained by simulating all the procedures

explained so far; nevertheless, straightforward adaptations of these procedures have been

performed in order to take into account the burst nature of the IP datagrams.

Table 8-1 reports the main statistical characteristics of the four Service Classes (j = 1,...,

4) which have been considered for the simulations.

Table 8-2 reports the considered QoS Contracts relevant to the Service Classes

identified in Table 8-1.

j = 1 j =2 j =3 j =4

Rmin(j) 29.2 kbps 200 kbps 40 kbps 1350 kbps

Dmax(j) 0.1 sec 4 sec 1.5 sec 0.5 sec

Jmax(j) 0.09 sec 3.8 sec 1.425 sec 0.48 sec

Table 8-2: QoS Contracts associated to the various Service Classes.

The duration of the proposed simulation Ttotal (herafter referred to as Simulation Time

Period) has been assumed equal to 20 minutes.

Considering the trade-offs mentioned in Section 4 and relevant simulation results, the

time periods Tlong and Tshort have been set to 10 ms and 1 ms, respectively. Likewise, the

security fraction of non-assigned capacity ε, has been set to 0,01.

The parameter RLLCT has been assumed equal to 25 Mbps which is the bit rate supported

by the Hyperlan2 standard .

Each MT is assumed to be simultaneously involved in four connections belonging to the

four different Service Classes considered in Table 8-1 and Table 8-2; in our simulations the

number of MTs N has been progressively increased, in order to test the behaviour of the

proposed procedures in both low and high traffic conditions. In this respect, the coefficients

α(i) have been assumed equal to 1/N for any i.

Finally, all the weights w(j) appearing in the cost index Eq. 6.6 have been assumed

equal to one; so, by taking t = 0 as the simulation starting time, the cost index Eq. 6.6

becomes:


154

loss

Ttotal N

i

iC

j

hhlosstotal BdttjiRTJ == ∫ ∑∑= =0 0

)(

1

),,(),0(

which represents the overall number of bits discarded during the Simulation Time Period; this

number will be denoted as Bloss.

The Traffic Control Module arrangement proposed in this paper will be referred to as

Closed-Loop option. The performance of the Closed-Loop option will be compared with the

performance of the so-called FIFO Queue option (or Reference option) and Open-Loop

option. The FIFO Queue option corresponds to the absence of the Traffic Control Module: all

the traffic coming from the IP layer is multiplexed into a FIFO queue where it waits for being

transmitted over the air interface. The Open-Loop option, representing the existing state-of-

the-art before this paper, is based on the presence of a battery of DLBs (a DLB for each

association) which filters the incoming traffic, followed by Scheduling FIFO buffers handled

according to an Earliest Deadline First (EDF) scheduling discipline; moreover, the IP

datagrams overflown from the DLBs are not discarded, but are stored in Overflow FIFO

buffers served with lower priority than Scheduling FIFO buffers.

Let us define the Link Efficiency ηηηηlink as the ratio between the bits passed towards the

LLCT during the Simulation Time Period, and the bits which the LLCT would have been able

to accept during the Simulation Time Period, i.e.:

totalLLCT

N

i

iC

jemitted

LINK TR

jiB∑∑= == 1

)(

1

),(

η

where Bemitted(i,j) indicates the number of bits, relevant to the association (i,j), which have

been passed towards the LLCT during the Simulation Time Period.

It should be evident that Bloss and ηηηηlink are key parameters in order to assess the

efficiency of the designed Traffic Control Module.

In light of the QoS Contract (see Eq. 6.4 and Eq. 6.5), the delay D(j) experienced in

the Traffic Control Module by the IP datagrams relevant to the Service Class j must be


155

included in the range [Dmin(j), Dmax(j)]. So, whenever an IP datagram stored in the Traffic

Control Module is being passed towards the LLCT, it is checked whether its delay is in the

above-mentioned range. In case the delay is lower than Dmin(j) (i.e. in case Eq. 6.4 is not

respected), then the IP datagram is not yet passed towards the LLCT. Conversely, in case the

delay exceeds Dmax(j) (i.e. in case Eq. 6.5 is not respected), then the IP datagram is discarded.

So, in order to compute the overall discarded traffic, it is necessary to sum this last kind of

discarded traffic (which is due to the fact that, as it is stressed in Section 6.3, the constraint

Eq. 6.5 can be temporarily violated), to the traffic which is not even admitted into the Traffic

Control Module (i.e. the traffic whose bit rate is Rloss). In this respect, it is worth noting that,

in practical implementation, it could be simpler and more efficient to admit all traffic and to

perform the discarding only on the basis of the above-mentioned check.

8.3 OPNET IMPLEMENTATIONS OF MT SCHEDULER

This section illustrates the simulation campaign. The scenario which is considered is as

follows:

• Compliant Campaign: In light of the above discussion, it should be evident that the

actual performance of the Traffic Control Module can be simply monitored by

computing the discarded traffic amount (i.e. the key parameter Bloss). In this respect,

due to this discarding, by increasing N (the number of MTs simultaneously active), we

arrive at a limit N (herafter indicated as Nlimit) over which the QoS Contract is no

longer respected, since Eq. 6.3 is no longer met, i.e. the Traffic Control Module is no

longer able to admit the Compliant Traffic into the wireless network. From the

performed simulations we obtained Nlimit = 13 for the FIFO Queue Option (or

Reference) and Nlimit = 15 both for the Open-Loop and for the Closed-Loop options,

which is a self-evident confirmation of the efficiency enhancement yielded by the

presence of the Traffic Control Module.


156

• Non-Compliant Campaign: the number of MTs simultaneously active is fixed to

N=8 and we increase the number of associations for each MT, i.e. we increase the

traffic offered from a single MT. We denote with k the number of associations

simultaneously active in the MTs, and we will consider the cases of k=1, k=2, k=3. It

is important to emphasize that in a MT only one association is Compliant, while the

others are Non Compliant. This means that for k=1 all the associations are Compliant,

while when k increases the new associations are Non Compliant. Consequently it is

not necessary to verify the respect of the QoS Contract because in a previous

simulation campaign demonstrates that the MT Scheduler is able to respect the QoS

Contract up to 15 MTs with one associations for each Service Class in each MT, and

now we have 8 MTs in which only one association for each Service Class is

Compliant while the others are Non Compliant. In other words the goal of this

simulation campaign is to analyse the behaviour of the MT Scheduler when the Non

Compliant traffic increases, i.e. when the number of association for each association

increases. We will compare the Closed-loop option proposed in this paper with the

FIFO Queue option and the Open-loop option, and this comparison will be done

through the Link Efficiency ηlink, and the overall number of discarded bits totlossB −

which are key parameters in order to assess the efficiency of the designed Traffic

Control Module.


157

8.3.1 Models Analysis

The scenario of our simulation is a single MT.

Figure 8-1:MT Single Controller Scenario

In the LAN’s each MT’s communicates whit other MT in the same network or with

the external world, by means of the AP.

In this simulation we imagine to control the traffic directed into our MT. Since the

classifier shares the input traffic among the MT’s, and in each one among the traffic classes,

we had not implement sharing mechanism for this, and we imagine them already classified in

input to the QoS queues.


158

8.3.1.1 Characterization of the three different scenario

Figure 8-2 :Scenario for one associations (k=1)

Figure 8-3 :Scenario for two associations (k=2)


159

Figure 8-4 :Scenario for three associations (k=3)

The Figure 8-2, Figure 8-3 and Figure 8-4 shows the three different case of the simulations: in

the first case there is only compliant traffic, in fact the MT may accept all the traffic supply by

the four different sources. In the second case there is 1 associations of compliant traffic and 1

associations of non-compliant traffic: in this case the MT don’t accept all traffic because the

total input rate is greater than the maximum band available but it have to guarantee at least the

compliant traffic. The last case is like the second case but the traffic rate is more big and so

we will examine this case in particular because is more restrictive and results are more

significant.


160

8.3.1.2 MT Scheduler algorithm process model

Figure 8-5 :MT Single Controller algorithm process model

We can note that it is composed by five states:

� Init

It is dedicated to initializations (variables and class objects)

� idle

It is an unforced waiting state. There is not code in it, so it has not execute instructions,

but at interrupt arriving (due to the packet arrival or to the system tick expiry), it forces

transition respectively into the inpul state, calcola state or output sate

� input

In this state are handled packets arriving at the QoS queue. First of all, since the interrupt

type (that forces the transition in this state) are not different dependently on the packet

type, the stream from which the packet arrives is determined (each stream correspond to

one traffic class) to distinguish the packet type, then the arriving packets is stored, before


161

to decide if it has to be or not admitted in the QoS queue, in support queue depend on the

traffic type which it belongs to. The supporting queues (there’s one support queue for each

classes of traffic) are introduced due to the algorithm quantization. In fact, to calculate the

average rate in a time equal to TIME_CALCOLA (usually 10 ms) and other parameters, it

is necessary to store all the packets arrived in this time.

� calcola

In this state a code is executed that corresponds to the algorithm run every

TIME_CALCOLA sec. Theoretically at the input of the QoS queues, the rate Roff(t) of

every classes is a know value but in practice this value has to be calculated in this state.

Really this is an average value. It is calculated (in a time interval of TIME_CALCOLA

sec), for every classes by taking the packets from the queue support, calculating their

length, adding and dividing total by TIME_CALCOLA sec. This procedure is necessary

for the next reason:. from a theoretical point of view, the variations at the system input

and output are instantaneous, instead, from a practice point of view it require a discrete

time. After we calculate the the total number of bits arrived for every classes and for all

classes of service and using the Single Controller algorithm we calculate the Rloss(t) for

every service classes. This last operation is necessary because it is the start point of the

algorithm: in fact once we know Rloss(t) it is possible to determine (using the known value

of Rmin for every classes) which is the assigned band to every classes of service. Finally we

extract the packets from the support queue in input and we insert them in the effective

FIFO of the Scheduler.

� output

The instructions in this state are executed every TIME_OUTPUT sec (usually 1 ms and

however TIME_OUTPUT is less than or equal to TIME_CALCOLA; for our simulations

optimal value of TIME_OUTPUT is equal to TIME_CALCOLA). The value that assume

TIME_OUTPUT is critical for the correct running of the algorithm because a little value

means that big packets don’t leave the scheduler due to not enough band and a value to

big will kill all Voice packets since Dmax(Voice) = 0.1 sec. The first step that this state

execute is determine the optimum parameters of the queue:


162

� q_star(class) is the optimal length of the queue in bits in order to maintain better

performance

� delta_star(class) represents the optimal output capacity in order to maintain better

performance

After there is a verification on the packets delay that are in the scheduler: if the delay is

superior to Dmax(class) the relative packet is discarded and relative statistics updated.

Once this steps are terminated we can calculatd the actual output band fraction

delta(class) for every service class and so to determine the equivalent number of packets.

To optimize the algorithm, since only the packets of the Voice Class are constants in

lengths and rate while for the others Class (FTP, Web, Video) are variable in a specified

interval, we implemeted a band ricupero: in fact maybe that a big packet of a certain class

cannot sending because the available band in that instant in not sufficient to send that

packet and so we loss the portion of band.

8.3.1.3 Source characterization

Figure 8-6 :Simple Source Model

This is a source model supplied by OPNET. The source parameters can be fixed by

means a dialog box, in which we can choose, among other things, the packet's length and the

packet's interarrival time (so the source rate).


163

The web and FTP sources are on-off type:

TOFF T ON

Figure 8-7: ON and OFF activity periods sequence

This kinds of source should be characterized by some periods of activity and some others

of inactivity. During the first kind of period at the source there is a large amount of data

with a high transmission rate, instead in the second one it is inactive. In the figure above

it is possible to distinguish the two different transmission periods (we can observe a

“bursty” traffic behaviour). This traffic characteristic is typical of web browsing and file

transfer protocol applications because in them we have short period of transmission,

representative of the web pages request or transfer data, and long inactivity periods to

read the information by the user.

0 bits/sec

Rav(t) bit/sec


164

65

70

75

80

85

90

95

11 12 13 14 15

Number of MTs (N )

Lin

k E

ffic

ien

cy (

%)

FIFO Queue option

Open-Loop option

Closed-Loop option

05

101520253035404550

11 12 13 14 15

Number of MTs (N )

Blo

ss (

Mb

it)

FIFO Option

Closed-loop option

Open-loop option

8.4 SIMULATIONS RESULTS

8.4.1 Compliant Campaign

Figure 8-8:Link Efficiency ηlink as a function of the number of MTs N, up to Nlimit.

Figure 8-9:Overall number of discarded bits Bloss as a function of the number of MTs N, up to

Nlimit.


165

The results reported in Figure 8-8 and Figure 8-9 clearly show the advantages, at high

traffic loads, of the Closed-Loop option with respect to the Open-Loop option both in terms of

higher Link Efficiency and in terms of lower number of discarded bits.

Figure 8-10 and the following three, relevant to the Closed-Loop option and to the limit

value of N (i.e. Nlimit = 15), shows the delay D(i,j,th) experienced by the IP datagrams

relevant to the associations (i,j) (j = 1,..., 4) during the Simulation Time Period. The figure

also highlights the values Dmin(j) and Dmax(j). The figure confirms that, even for Nlimit, the

delay is always included in the range [Dmin(j), Dmax(j)], i.e. that constraints Eq. 5.3 and Eq.

5.4 are satisfied during the Simulation Time Period. It is worth noting that the delay D(i,j,th)

is close to the maximum tolerated delay Dmax(j), which is the situation that one could expect

since the proposed control continuously leads the system towards "ideal" equilibria at which

D(i,j,th) equals Dmax(j).

Likewise, Figure 8-14 and the following three, relevant to the Closed-Loop option and to the

limit value of N (i.e. Nlimit = 15), shows the bit rate of the admitted traffic Roff(i,j,th) -

Rloss(i,j,th), relevant to the associations (i,j) (j = 1,..., 4) during the Simulation Time Period.

The figure also highlights the values Rmin(j). The figure confirms that, even for Nlimit, the

Compliant Traffic is always admitted into the wireless network, i.e. that constraint Eq. 5.3 is

satisfied during the Simulation Time Period


166

Figure 8-10: Delay D(i,1,th) experienced by the IP datagrams relevant to the associations (i,1)

(Voice) during the Simulation Time Period (Closed-Loop option; N =15); the delay

constraints for the Voice are D(i,1)∈[0.01 sec, 0.10 sec]

Figure 8-11:Delay D(i,2,th) experienced by the IP datagrams relevant to the associations (i,2)

(FTP) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ); the delay

constraints for the FTP are D(i,2)∈[0.2 sec, 4 sec]


167


(Web) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ); the delay

constraints for the Web are D(i,3)∈[0.05 sec, 1.5 sec]


(Video) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ); the delay

constraints for the Video are D(i,4)∈[0.02 sec, 0.5 sec]


168

Figure 8-14:Bit rate of the admitted traffic Roff(i,1,th) − Rloss(i,1,th) relevant to the associations

(i,1) (Voice) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) for a

single MT (Rmin(1)=29.2 kbps)


(i,2) (FTP) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ) for a

single MT (Rmin(2)=200 kbps during the download period, see note 2)


169

Figure 8-16 :Bit rate of the admitted traffic Roff(i,3,th) − Rloss(i,3,th) relevant to the associations

(i,3) (Web) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ) for a

single MT (Rmin(3)=40,000 kbps during the download period, see note 3)


(i,4) (Video) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ) for a

single MT (Rmin(4)=1350 kbps)


170

0.47

0.57

0.67

0.77

0.87

0.97

1 2 3

K (Number of Associations)

LIN

K E

ffic

ien

cy

Open Loop Option

Reference Option

Closed Loop Option

8.4.2 Non-Compliant Campaign

In this paragraph we will show the results of simulations. This results will demonstrate

how it is possible to guarantee the quality of service by separating and handling opportunely

the traffic arriving at the system. The traffic in fact can be time sensitive and non time

sensitive, and dependently on this, it has to be handled: if it is time sensitive, it has to be

handled whit priority greater that the non time sensitive one.

Figure 8-18 shows the Link Efficiency ηlink as a function of the number of associations

k for each MT. Also in this case it is evident how the Closed-loop option succeeds in

exploiting the available bandwidth better than the FIFO Queue option (Reference option) and

than the Open-loop option.

Figure 8-18 :Link Efficiency ηLINK as a function of the number of associations k for each MT

Figure 8-19 shows the overall number of discarded bits Bloss-tot for all the MTs as a

function of the number of the number of associations k for each MT. It is evident how the

Closed-loop option succeeds in minimizing the parameter Bloss-tot .


171

0

200400

600

8001000

1200

140016001800

2000

1 2 3

K (Number of Associations)

Blo

ss (

Mb

it)

Open Loop Option

Reference Option

Closed Loop Option

Figure 8-19 :Overall number of discarded bits Bloss-tot as a function of the number of the

number of associations k for each MT

As we can see it is evident that the Closed-loop option proposed in this paper performs

better than the FIFO Queue option and than the Open-loop option. Since the critical case is for

k=3 (i.e. for 3 associations) because there’s a remarkable increase of Bloss and because in the

previous case (k=1, k=2) the results are good we starts to analyze the behaviour of the MT

Single Controller Scheduler in this last case.

The parameters that we analayze in detail for every class are:

• Instantly Rate

• Time Average of Input and Output Rate

• Instantly Delay

• Cumulative Distribution of the Delay

• Some global parameters like Compliant Traffic, Offered and Lost Bits


172

8.4.2.1 Analysis of Voice traffic handling by the scheduler for k=3

Figure 8-20: Bit rate of the admitted traffic Roff(i,1,th) − Rloss(i,1,th) relevant to the associations

(i,1) (Voice) during the Simulation Time Period with k=3; Roff-tot=87.6 kbps, Rmin(1)=29.2kbps

Figure 8-21: Time Average of Bit Rate of input Voice traffic and output Voice traffic


173

Next figure, relevant to the Closed-Loop option and to the value of k=3 (N is always

equal to 8 in this second campaign), shows the delay D(i,j,th) experienced by the IP

datagrams relevant to the associations (i,j) (j = 1,..., 4) during the Simulation Time Period.

The figure shows that the delay is always included in the range [Dmin(j), Dmax(j)], i.e. that

constraints Eq. 6.4 and Eq. 6.5 are satisfied during the Simulation Time Period.


(Voice) during the Simulation Time Period (Closed-Loop option; N =8, k =3); the delay

constraints for the Voice are D(i,1)∈[0.01 sec, 0.10 sec]

Figure 8-23: Cumulative Distribution of the Delay Voice Packet in the scheduler


174

8.4.2.2 Analysis of FTP traffic handling by the scheduler for k=3

Figure 8-24: Bit rate of the admitted traffic Roff(i,2,th) − Rloss(i,2 ,th) relevant to the

associations (i,2) (FTP) during the Simulation Time Period with k=3; Roff-tot=300 kbps,

Rmin(2)=200 kbps during the download period (see note 2)

Figure 8-25: Time Average of Bit Rate of input FTP traffic and output FTP traffic


175


(FTP) during the Simulation Time Period (Closed-Loop option; N =8, k =3) ); the delay

constraints for the FTP are D(i,2)∈[0.2 sec, 4 sec]

Figure 8-27: Cumulative Distribution of the Delay FTP Packet in the scheduler


176

8.4.2.3 Analysis of Web traffic handling by the scheduler for k=3


associations (i,3) (Web) during the Simulation Time Period with k=3; Roff-tot=74.7 kbps,

Rmin(3)=40 kbps during the download period (see note 3)

Figure 8-29: Time Average of Bit Rate of input Web traffic and output Web traffic


177


(Web) during the Simulation Time Period (Closed-Loop option; N =8, k =3) ); the delay

constraints for the Web are D(i,3)∈[0.05 sec, 1.5 sec]

Figure 8-31: Cumulative Distribution of the Delay Web Packet in the scheduler


178

8.4.2.4 Analysis of Video traffic handling by the scheduler for k=3


associations (i,4) (Vide) during the Simulation Time Period with k=3; Roff-tot=4050 kbps,

Rmin(4)=1350 kbps

Figure 8-33: Time Average of Bit Rate of input Video traffic and output Video traffic


179


(Video) during the Simulation Time Period (Closed-Loop option; N =8, k =3) ); the delay

constraints for the Video are D(i,4)∈[0.02 sec, 0.5 sec]

Figure 8-35: Cumulative Distribution of the Delay Voice Packet in the scheduler


180

8.4.2.5 Analysis of global parameters for for k=3

Figure 8-36:Summary of Total Rate

Figure 8-37:Input and Output Bits for classes

Figure 8-38:Compliant traffic for all classes


181

8.4.2.6 Analysis of some parameters for for k=2

The next graph are obtained when there is one associations compliant and one associations

non-compliant and how we can see they are not very interesting because the scheduler works

very well: in fact the results are almost ideal since we don’t describe them further.

Figure 8-39 :Time Average of input and output rate

Figure 8-40 :Packets Delay for all classes

Figure 8-41 :Output Rate for all classes


182

Figure 8-42 :Time Average of all total rate

Figure 8-43 :Total bits arrived and total bits lost

Figure 8-44 :Compliant coefficients of all classes


183

9 CONCLUSIONS

This paper has introduced the new concept of a Wireless Adaptation Layer (WAL)

aiming at enhancing IP performance and at providing IP protocols with QoS. The WAL

consists of a set of modules each one in charge of a particular task. The paper has focused on

the Traffic Control Module which is in charge of both congestion control and traffic

scheduling. In particular, this module has to deal with the problem of guaranteeing to each

connection its target QoS in terms of maximum tolerated delay, maximum tolerated jitter,

minimum guaranteed bit rate, and, at the same time, maximizing the exploitation of the air

interface capacity.

The paper has shown that the above-mentioned problem can be formulated as a control-

theoretical problem entailing the minimization of a proper cost index subject to a set of

constraints. The paper has shown (by also showing some meaningful simulation results) that

this problem can be efficiently solved in a control-theoretical fashion by means of a controller

which, on the basis of the present offered traffic and on the present load of the Traffic Control

Module buffers, decides:

� which traffic has to be discarded (congestion control task),

� which traffic has to be forwarded towards the air interface (scheduling task).

The structural reason explaining why the proposed Traffic Control Module succeeds in

achieving higher performance than usual arrangements, is the presence of a single controller

which:

i) performs in one shot both the congestion control and the scheduling tasks which, usually,

are independent and uncoordinated (the former task being performed by DLBs, while the

latter task being performed by a certain scheduler);

ii) performs the above-mentioned tasks in a real-time closed-loop fashion, i.e. on the basis of

the present wireless network load (deduced from the buffer states), rather than in an open-

loop fashion, on the basis of parameters established at connection set-up, as it happens in

usual implementations based on the presence of DLBs;

iii) performs the above-mentioned tasks in a centralized way for all the connections involving

the considered AP, rather than performing these tasks in an uncoordinated fashion among


184

the connections, as it happens in usual implementations based on the presence of different

uncoordinated DLBs.

The single controller mentioned above is based on the innovative approach of

periodically (with period Tlong) computing, at time tk with tk+1 = tk + Tlong, basing on the offered

traffic at this time, an "ideal" equilibrium (at which the overall system achieves optimum

performance) and of leading, during the time interval [tk, tk+1), the overall system towards

such ideal equilibrium.

The computation of the ideal equilibrium and of the control variables leading the overall

system towards such equilibrium are relatively easy and can be performed in real-time, as

demonstrated by simulation.

Finally, some simulation results have shown that, in the presence of realistic IP traffic,

the Traffic Control Module succeeds in reducing the discarded traffic (thus improving the air

interface exploitation) with respect to other reference solutions, while respecting the QoS

constraints.


185

10 FIGURE

Figure 2-1:Reference wireless technologies mapping..............................................................20

Figure 2-2: WINE cellular network..........................................................................................21

Figure 2-3:The WINE reference model....................................................................................22

Figure 2-4: The WINE system model ......................................................................................23

Figure 2-5: WINE network configuration ................................................................................24

Figure 2-6: The WINE protocol stack model...........................................................................26

Figure 3-1:Typical WLAN configuration.................................................................................38

Figure 3-2: A wireless peer-to-peer network............................................................................39

Figure 3-3: Client and Access Point .........................................................................................40

Figure 3-4: Multiple access point and roaming........................................................................41

Figure 3-5: Use of an extension point ......................................................................................42

Figure 3-6: The use of directional antennas .............................................................................42

Figure 3-7: Frequency hopping spread spectrum .....................................................................44

Figure 3-8: Direct sequence spread spectrum...........................................................................44

Figure 3-9: IEEE 802.11 Reference Model..............................................................................47

Figure 3-10: Hidden Node Problem .........................................................................................49

Figure 3-11: Time division duplex access scheme...................................................................52

Figure 3-12: Bluetooth system functional blocks.....................................................................53

Figure 3-13: Examples of Bluetooth piconets ..........................................................................53

Figure 3-14: HiperLAN Reference Model ...............................................................................54

Figure 3-15: HIPERLAN/2 : reference protocol stack for the AP/CC.....................................55

Figure 4-1: RSVP protocol scheme..........................................................................................66

Figure 4-2: Differentiated Services Architecture .....................................................................69

Figure 4-3: IPv6 and IPv4 DS field ..........................................................................................70

Figure 4-4: The leaky bucket ...................................................................................................72

Figure 4-5: The tocken bucket....................................................................................................73

Figure 4-6: DLB model ............................................................................................................74

Figure 4-7: Data policing with a DLB......................................................................................75


186

Figure 4-8: Capacity sharing ....................................................................................................79

Figure 4-9: Bandwidth redistribution .......................................................................................80

Figure 5-1: Example of the path followed by the IP datagram relevant to a certain connection

within the WAL................................................................................................................89

Figure 5-2: Wireless Adaptation Layer ....................................................................................90

Figure 5-3 :WAL Functional Entities.......................................................................................92

Figure 5-4: High-level QoS Module internal structure at a certain time t..............................106

Figure 6-1: High-level Traffic Control Module internal structure .........................................121

Figure 6-2: High-level internal structure of the MT i Scheduler at time th ............................124

Figure 6-3: Control Model of the MT i Scheduler .................................................................125

Figure 6-4: MT i Buffer Controller ........................................................................................130

Figure 6-5: Trend of the error e(i,j,th) for th>=tk if e(i,j,tk) is positive.......................................133

Figure 6-6: Trend of the error e(i,j,th) for t ∈ [tk,tk+1] if e(i,j,tk) is negative and

LLCTshortth

t

RTjiqtjiq

ji

k

k 1

),(),,(

),(*

*

≥−

−δ

.................................................................................133

Figure 7-1:OPNET Modeler...................................................................................................137

Figure 7-2:Simulation project cycle .......................................................................................142

Figure 7-3:OPNET Model Hierarchy.....................................................................................143

Figure 7-4:Graphical environment of the Analysis Tool .......................................................144

Figure 7-5:Generic network model.........................................................................................145

Figure 7-6 : Generic node model............................................................................................146

Figure 7-7 : Generic process model........................................................................................147

Figure 7-8:Generic packet format...........................................................................................148

Figure 8-1:MT Single Controller Scenario.............................................................................157

Figure 8-2 :Scenario for one associations (k=1).....................................................................158

Figure 8-3 :Scenario for two associations (k=2) ....................................................................158

Figure 8-4 :Scenario for three associations (k=3) ..................................................................159

Figure 8-5 :MT Single Controller algorithm process model ..................................................160

Figure 8-6 :Simple Source Model ..........................................................................................162

Figure 8-7: ON and OFF activity periods sequence...............................................................163

Figure 8-8:Link Efficiency ηlink as a function of the number of MTs N, up to Nlimit..............164


187

Figure 8-9:Overall number of discarded bits Bloss as a function of the number of MTs N, up to

Nlimit.................................................................................................................................164


(Voice) during the Simulation Time Period (Closed-Loop option; N =15); the delay

constraints for the Voice are D(i,1)∈[0.01 sec, 0.10 sec] ..............................................166


(FTP) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ); the

delay constraints for the FTP are D(i,2)∈[0.2 sec, 4 sec] ..............................................166


(Web) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ); the

delay constraints for the Web are D(i,3)∈[0.05 sec, 1.5 sec].........................................167


(Video) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ); the

delay constraints for the Video are D(i,4)∈[0.02 sec, 0.5 sec].......................................167


(i,1) (Voice) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) for

a single MT (Rmin(1)=29.2 kbps) ....................................................................................168


(i,2) (FTP) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ) for

a single MT (Rmin(2)=200 kbps during the download period, see note 2)......................168

Figure 8-16 :Bit rate of the admitted traffic Roff(i,3,th) − Rloss(i,3,th) relevant to the associations

(i,3) (Web) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) )

for a single MT (Rmin(3)=40,000 kbps during the download period, see note 3) ...........169


(i,4) (Video) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) )

for a single MT (Rmin(4)=1350 kbps)..............................................................................169

Figure 8-18 :Link Efficiency ηLINK as a function of the number of associations k for each MT

........................................................................................................................................170

Figure 8-19 :Overall number of discarded bits Bloss-tot as a function of the number of the

number of associations k for each MT ...........................................................................171


188

Figure 8-20: Bit rate of the admitted traffic Roff(i,1,th) − Rloss(i,1,th) relevant to the associations

(i,1) (Voice) during the Simulation Time Period with k=3; Roff-tot=87.6 kbps,

Rmin(1)=29.2kbps ............................................................................................................172

Figure 8-21: Time Average of Bit Rate of input Voice traffic and output Voice traffic........172


(Voice) during the Simulation Time Period (Closed-Loop option; N =8, k =3); the delay

constraints for the Voice are D(i,1)∈[0.01 sec, 0.10 sec] ..............................................173

Figure 8-23: Cumulative Distribution of the Delay Voice Packet in the scheduler ...............173


associations (i,2) (FTP) during the Simulation Time Period with k=3; Roff-tot=300 kbps,

Rmin(2)=200 kbps during the download period (see note 2) ...........................................174

Figure 8-25: Time Average of Bit Rate of input FTP traffic and output FTP traffic.............174


(FTP) during the Simulation Time Period (Closed-Loop option; N =8, k =3) ); the delay

constraints for the FTP are D(i,2)∈[0.2 sec, 4 sec] ........................................................175

Figure 8-27: Cumulative Distribution of the Delay FTP Packet in the scheduler..................175


associations (i,3) (Web) during the Simulation Time Period with k=3; Roff-tot=74.7 kbps,

Rmin(3)=40 kbps during the download period (see note 3) .............................................176

Figure 8-29: Time Average of Bit Rate of input Web traffic and output Web traffic............176


(Web) during the Simulation Time Period (Closed-Loop option; N =8, k =3) ); the delay

constraints for the Web are D(i,3)∈[0.05 sec, 1.5 sec] ..................................................177

Figure 8-31: Cumulative Distribution of the Delay Web Packet in the scheduler .................177


associations (i,4) (Vide) during the Simulation Time Period with k=3; Roff-tot=4050 kbps,

Rmin(4)=1350 kbps ..........................................................................................................178

Figure 8-33: Time Average of Bit Rate of input Video traffic and output Video traffic .......178


(Video) during the Simulation Time Period (Closed-Loop option; N =8, k =3) ); the

delay constraints for the Video are D(i,4)∈[0.02 sec, 0.5 sec].......................................179

Figure 8-35: Cumulative Distribution of the Delay Voice Packet in the scheduler ...............179


189

Figure 8-36:Summary of Total Rate.......................................................................................180

Figure 8-37:Input and Output Bits for classes........................................................................180

Figure 8-38:Compliant traffic for all classes..........................................................................180

Figure 8-39 :Time Average of input and output rate..............................................................181

Figure 8-40 :Packets Delay for all classes..............................................................................181

Figure 8-41 :Output Rate for all classes .................................................................................181

Figure 8-42 :Time Average of all total rate............................................................................182

Figure 8-43 :Total bits arrived and total bits lost...................................................................182

Figure 8-44 :Compliant coefficients of all classes .................................................................182


190

11 TABLE

Table 3-1: IEEE 802.11 family of Standards ...........................................................................46

Table 3-2: HiperLAN Family of Standards..............................................................................54

Table 8-1: Main statistical characteristics of the considered Service Classes........................152

Table 8-2: QoS Contracts associated to the various Service Classes. ....................................153


191

12 ACRONYMS

AAA Authentication, Accounting and Authorization

AAL ATM Adaptation Layer

ABR Available Bit Rate

AF Assured Forwarding

AH Authentication Header

ARP Address Resolution Protocol

ARQ Automatic Repeat reQuest

ATM Asynchronous Transfer Mode

BB Bandwidth Broker

BE Best Effort

BER Bit Error Rate

BHS BMSS Hub Station

BMSS BRAHMS Multimedia Satellite System

BMWS Broadband Multimedia Wireless System

BNL BRAHMS Network Layer

BRAHMS Broadband Access for High speed Multimedia via Satellite

BSAT BRAHMS Satellite Access Terminal

CAC Connection Admission Control

CBR Constant Bit Rate

CDMA Code Division Multiple Access

CDV Cell Delay Variation

CLP Cell Loss Priority

CLS Controlled Load Service

CN Correspondent Node

COA Care Of Address

CP Control Plane

CPE Customer Premise Equipment


192

CPN Costumer Premises Networks

CSA Composite SA

CTD Cell Transfer Delay

DHCP Dynamic Host Configuration Protocol

DiffServ Differentiated Services

DLB Dual Leaky Bucket

DNS Domain Name System

DS Differentiated Services

DSCP DS Code Point

DtH Direct to Home

DtO Direct to Office

DVB Digital Video Broadcasting

EDF Earliest Deadline First

EF Expedited Forwarding

EPD Early Packet Discard

ETSI European Telecommunications Standard Institute

FA Foreign Agent

FDMA Frequency Division Multiple Access

FEC Forward Error Correction

FF Fixed Filter

FIFO First In First Out

FTP File Transfer Protocol

FTP File Transfer Protocol

GAN Generic Access Network

GEO Geo-stationary Earth Orbit

GFR Guaranteed Frame Rate

GMM Global Multimedia Mobility

GRAN Generic Radio Access Network

GS Guaranteed Service

GTW Gateway

HA Home Agent


193

HTTP Hyper Text Transfer Protocol

IAP Internet Access Point

ICI Interface Control Information

ICMP Internet Control Management Protocol

IDU Interface Data Unit

IETF Internet Engineering Task Force

IF-L Interface Layer

IGMP Internet Group Management Protocol

IN Intelligent Network

IntServ Integrated Services

IP Internet Protocol

ISP Internet Service Provider

IW Inter-Working

LAN Local Area Network

LEO Low Earth Orbit

LLC Link Layer Control

MAC Medium Access Control

MBS Maximum Burst Size

MPE Multi-Protocol Encapsulation

MPEG Motion Picture Expert Group

MPLS Multi Protocol Label Switching

MUX/DEMUX Multiplexer/Demultiplexer

NAS Network Acces

NCC Network Control Centre

ND Neighbour Discovery

OBP On Board Processing

PCR Peak Cell Rate

PDU Protocol Data Unit

PEP Performance Enhancement Proxy

PHB Per Hop Behaviour

PHY Physical


194

POP Point Of Presence

PPD Partial Packet Discard

QoS Quality of Service

RED Random Early Drop

RSpec Reserve Specification

RSVP ReSerVation Protocol

RTD Radio Technology Dependent

RTD Radio Technology Dependent

RTI Radio Technology Independent

RTP Reliable Transfer Protocol

SA Security Association

SAD Security Association Database

SAP Service Access Point

SAR Segmentation And Reassembly

S-ATM Satellite ATM

SCR Sustainable Cell Rate

SDU Service Data Unit

SE Shared Explicit

SIGN Signalling

SLA Service Level Agreement

SOHO Small Office Home Office

SSL Secure Socket Layer

TCA Traffic Contract Agreement

TCP Transfer Control Protocol

TDMA Time Division Multiple Access

TOS Type Of Service

TSpec Traffic Specification

TTL Time To Live

UBR Unspecified Bit Rate

UDP User Datagram Protocol

UIE User IP Equipment


195

UMTS Universal Mobile Telecommunication System

UNI User to Network Interface

UP User Plane

UT User Terminal

VBR Variable Bit Rate

VC Virtual Channel

VHE Virtual Home Environment

VoIP Voice over IP

VP Virtual Path

WB Web Browsing

WF Wildcard Filter

WFQ Weighted Fair Queuing


196

13 REFERENCES & STANDARDS

1 Tanenbaum, A. “Computer Networks”. Third Edition. Prentice-Hall, 1996.

2 WLANA (The Wireless LAN Alliance) “Introduction to wireless LAN”,

http://www.wlana.com

3 Pekka Sahi “Standards Related to Wireless LANs (survey and comparison)”, 1999

Department of Computer Sciences Helsinki University of Technology [email protected]

4 Stefano Cazzani “Lo standard 802.11 per le LAN senza fili”, Elettronica oggi, gennaio

1998.

5 Zhengping Zuo “In-building Wireless LANs”, http://www.cis.ohio-state.edu/~jain/cis788-

99/wireless_lans/index.html

6 IEEE P802.11a/D5.0, "Wireless LAN Medium Access Control (MAC) and Physical Layer

(PHY) specification: Higher speed Physical Layer (PHY) extension in the 5 GHz band",

1999

7 IEEE P802.11b/D5.0, "Wireless LAN Medium Access Control (MAC) and Physical Layer

(PHY) specification: Higher speed Physical Layer (PHY) extension in the 2.4 GHz band",

1999

8 Lucent Technologies, "IEEE selects Lucent/Harris proposal for new high-speed wireless

LAN", http://www.lucent.com/press/0798/980713.nsb.html

9 C.Andren, "Modulation Techniques for High Speed WLAN Systems", 1998.

http://news.wirelessdesignonline.com/content/news/article.asp

10 M. Speth, "OFDM Receivers for Broadband-Transmission",

http://www.ert.rwth-aachen.de/Projekte/Theo/OFDM/www_ofdm.html

11 ETSI, "High Performance Radio Local Area Network (HIPERLAN) Type 1; Functional

specification", http://webapp.etsi.org/pda/home.asp

12 L. Taylor, "HIPERLAN Type 1-Technology Overview", Hiperlan Alliance White

Paper,1999. http://www.hiperlan.com/hiper_white.pdf

13 M. Johnsson, "HiperLAN/2-The Broadband Radio Transmission Technology Operating in

the 5 GHz Frequency Band", 21 pages,

http://www.hiperlan2.com/site/specific/whitepaper.exe


197

14 Bluetooth SIG, “Specification of the Bluetooth System” Version 1.0 B, Specification

Volume 1 & 2, December 1999.

15 The Bluetooth Web Site, http://www.bluetooth.com

16 W. R. Stevens, ”TCP/IP Illustrated, Volume 1: The Protocols”, Addison Wesley, 1994.

17 R. Braden, “Requirements for Internet Hosts – Communication Layers” RFC 1122,

October 1989.

18 ETSI TR 101 683, “Broadband Radio Access Networks (BRAN); HIPERLAN Type 2;

System Overview” February 2000.

19 IEEE 802.2, “IEEE Standards for Local Area Networks: Logical Link Control”, 1985.

20 S. Deering and R. Hinden, “Internet protocol version 6 (IPv6) specification” RFC 2460,

December 1998.

21 C. Perkins, editor, “IP mobility support”, RFC 2002, October 1996.

22 D. Johnson, C. Perkins, “Mobility Support in IPv6”, February 2000.

23 L.Georgiadis, R.Guérin, V.Peris, K.N.Sivarajan, “Efficient network QoS provisioning

based on per node traffic shaping”, 1997

24 J. Wroclawski, “Specification of the Controlled-load Network Element Service”, RFC

2211, September 1997

25 S. Shenker, C. Partridge and R. Guerin, “Specification of Guaranteed Quality of Service”,

RFC 2212, September 1997

26 IETF “Integrated Services” working group, http://www.ietf.org/html.charters/intserv-

charter.html and http://www.ietf.org/ids.by.wg/intserv.html

27 G. Eichler, H. Hussmann, G. Mamais, C. Prehofer and S. Salsano “Implementing

Integrated and Differentiated Services for the Internet with ATM Approach: A Paractical

Approach”, IEEE Communications Magazine, January 2000

28 IETF “Differentiated Services” working group.

http://www.ietf.org/html.charters/diffserv-charter.html

http://www.ietf.org/ids.by.wg/diffserv.html

http://www.ietf.org/internet-drafts/1id-index.txt

29 V. Jacobson, K. Nichols, K. Poduri, “An Expedited Forwarding PHB”, RFC 2598, June

1999.

30 J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, “Assured Forwarding PHB Group”, RFC

2597, June 1999.


198

31 K. Nichols, S. Blake, F. Baker, D. Black, “Definition of the Differentiated Services Field

(DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, December 1998.

32 A.Elwalid and D. Mitra, “Traffic Shaping at a Network Node: Theory, Optimum Design,

Admission control”, IEEE Infocom 97.

33 R.Guerin and V.Peris, “Quality-of-Service in Packet Networks Basic Mechanisms and

Directions”, Computer Networks, 1999

34 J. Wroclawski, “The Use of RSVP with IETF Integrated Service”, RFC 2210, September

1997

35 S. Floyd and V. Jacobson, “Link-sharing and Resource Management Models for Packets

Network”, IEEE/ACM Transactions on Networking, Vol 3, n°4, August 1995

36 MIL3, “ Modeling Concepts” Volume 1, OPNET Modeler Manual

37 Beng-Ong Lee “Wide area ATM network experiments using emulated traffic source”,

BSEE, University of Kansas, Lawrence, Kansas, 1995.

38 A. Lombardo, G. Morabito, S. Palazzo, G. Schembra “A Markof-based model of MPEG-2

audio video traffic”, Proc. of the High Speed Network Symposium of IEEE Globecom'99

39 Debra Weiss and Zhiwei Xiao “Wide area UDP traffic characterization”, 1999.

40 Vern Paxson and Sally Floyd “Wide area traffic: the failure of poisson modeling”,

IEEE/ACM Transactions on Networking, Vol. 3, No. 3, 1995.

41 Anderlind Erik and Jens Zander “A traffic model for Non-Real-Time data users in a

wireless radio network”, IEEE Comunications letters, Vol.1, N. 2, March 1997.

42 J.D. Parsons, “The mobile radio propagation channel”, New York: Halsted, 1992.

43 H. Hashemi, “The indoor radio propagation channel”, Proceedings of the IEEE, Vol. 81,

No.7, 1997.

44 Prasad, “Universal Wireless Personal Communications”, Artech House, 1998.

45 S. J. Golestani, “A self-clocked fair queuing scheme for broadband applications”,

Proceedings of INFOCOM, Toronto, Canada, 1994.

46 L. Becchetti, F. Delli Priscoli, L. Munoz, T. Inzerilli, "Enhancing IP Service Provision

over Heterogeneous Wireless Networks: a Path Towards 4G", IEEE Communications

Magazine, Special Issue on "Life after Third Generation Mobile Communications", IEEE

Communications Society (U.S.A.), Vol. 39 No. 8, August 2001, pp. 74-81.

47 A. Till, “GSM Wireless Data White Paper”, Papyrus Computer Technologies Ltd, 2001.

48 E. Anderlind, J. Zander, “A Traffic Model for Non-Real-Time Data users in a Wireless


199

Radio Network”, IEEE Communications Letter, vol.1 no.2, March 1997.

49 D. Turage, T. Chen, “Modelling of Dynamic Video Traffic”, IEEE International

Symposium Circuits and Systems, May 2000.

50 M. Garret, W. Willinger, “Analysis, Modelling and Generation of Self-Similar VBR

Video Traffic”, In proceedings of ACM/SIGCOMM, September 1994

51 Martin Johonson, “HiperLAN/2- The Broadband Radio Transmission Technology

Operating in 5 GHz Frequency Band”, HiperLAN/2 Global Forum, 1999.

52 Riku Mettala, “Bluetooth White Paper”, Doc N°1.C.120/1.0, 25/08/1999.

53 C. Lu, J.A. Stankovic, G. Tao, S.H. Son, “Design and Evaluation of a Feedback Control

EDF Scheduling”, 1999 IEEE Real-Time Systems Symposium, December 1999, pp 56-67.

54 A. Elwalid, D. Mitra, “Traffic Shaping at a Network Node: Theory, Optimum Design,

Admission Control”, IEEE Infocom, 1997.

55 L. Becchetti, F. Delli Priscoli, L. Munoz, T. Inzerilli, "QoS Provisioning in Wireless IP

Networks", submitted for publication in the Special Issue on " Mobile and Wireless

Internet: Architecture and Protocols" of IEEE Personal Communications, May 2001.

56 WINE deliverable DII.1 “State-of-the-art in Wireless IPv6”.

57 WINE deliverable DII.4 “Testbed specifications”.

58 RFC-001-UoA (Version 1.0) “Overview of HIPERLAN/2”.

59 DIII.2, “TCP/IPv4 testbed implementation”.

60 DIII.3, “TCP/IPv6 testbed implementation”.

61 RFC-025-UoA “OPNET WAL Module Interfaces”.

traffic scheduling and qos for wireless broadband networks

Documents