Sei sulla pagina 1di 200

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
Traffic Scheduling and QoS for Wireless Broadband Networks

Alla mia famiglia che mi


ha sempre sostenuto

A mia moglie Antonella che mi


è sempre stata vicina

1
Traffic Scheduling and QoS for Wireless Broadband Networks

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

2
Traffic Scheduling and QoS for Wireless Broadband Networks

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

3
Traffic Scheduling and QoS for Wireless Broadband Networks

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

4
Traffic Scheduling and QoS for Wireless Broadband Networks

Traffic Scheduling and QoS for


Wireless Broadband Networks

5
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

6
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

7
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

8
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

9
Traffic Scheduling and QoS for Wireless Broadband Networks

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;

10
Traffic Scheduling and QoS for Wireless Broadband Networks

 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.

11
Traffic Scheduling and QoS for Wireless Broadband Networks

PART ONE
The WINE project and Wireless
Network

12
Traffic Scheduling and QoS for Wireless Broadband Networks

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

13
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

14
Traffic Scheduling and QoS for Wireless Broadband Networks

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

15
Traffic Scheduling and QoS for Wireless Broadband Networks

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

16
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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.

17
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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

18
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

19
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

BPN

IEEE 802.11

HIPERLAND 2
BLUETOOTH

DPN

1 Mbps 10 Mbps 25 Mbps

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

20
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

Router

Internet

Fixed Host Router


Access Point
Switch
Fixed Host Switch
Access Point

Access Point

Mobile Terminal
Termin Mobile Terminal Mobile Terminal
Mobile 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.

21
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

Radio access network

MT

Application Wireless WINE system Fixed network


entities WINE system Radio Radio for AP subnetworking TCP/
domain
for MT system subsystem unit UDP

WINE access network Internet

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.

22
Traffic Scheduling and QoS for Wireless Broadband Networks

2.4 WINE SYSTEM MODEL

MT

Application Application
TCP TCP
IPv4 IPv6 IPv4 IPv6 IPv4 IPv6

WINE system WINE system

Wireless I/F Wireless I/F

Wireless subnet
Fixed network

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

23
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

Router

Internet
Fixed Host
Default Router
Switch
Switch

Access Point Access Point


Access Point

Mobile Terminal Mobile Terminal


Mobile Terminal

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

24
Traffic Scheduling and QoS for Wireless Broadband Networks

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

25
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

Applications
Application
Data

TCP UDP RTP

IPv4 / IPv6
IP
datagram

Wireless Adaptation Layer

Link Layer Modules


Wireless
802.11 BLUETOOTH HIPERLAN2 MIB
LLC LLC LLC

802.11 BLUETOOTH HIPERLAN2


MAC MAC MAC

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.

26
Traffic Scheduling and QoS for Wireless Broadband Networks

◊ 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-

27
Traffic Scheduling and QoS for Wireless Broadband Networks

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

28
Traffic Scheduling and QoS for Wireless Broadband Networks

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

29
Traffic Scheduling and QoS for Wireless Broadband Networks

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

30
Traffic Scheduling and QoS for Wireless Broadband Networks

◊ 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

31
Traffic Scheduling and QoS for Wireless Broadband Networks

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

32
Traffic Scheduling and QoS for Wireless Broadband Networks

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

33
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

34
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

35
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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.

36
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

37
Traffic Scheduling and QoS for Wireless Broadband Networks

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 WLANS

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.

38
Traffic Scheduling and QoS for Wireless Broadband Networks

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

39
Traffic Scheduling and QoS for Wireless Broadband Networks

3.3 HOW WIRELESS LANS 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.

40
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

41
Traffic Scheduling and QoS for Wireless Broadband Networks

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

42
Traffic Scheduling and QoS for Wireless Broadband Networks

3.4 WIRELESS LANS 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.

43
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

44
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

45
Traffic Scheduling and QoS for Wireless Broadband Networks

 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

46
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

47
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

48
Traffic Scheduling and QoS for Wireless Broadband Networks

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

49
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

50
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

51
Traffic Scheduling and QoS for Wireless Broadband Networks

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

52
Traffic Scheduling and QoS for Wireless Broadband Networks

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)

Bluetooth
2.4GHz Buetooth
link
Bluetooth link HOST
controller
Radio controller
& I/O

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 M M
S/M

S S S S S S S
S S S

a b c
Figure 3-13: Examples of Bluetooth piconets

53
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

54
Traffic Scheduling and QoS for Wireless Broadband Networks

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

C ontro l P lane U s er P lane

H ig her L ay ers
C L S AP s

O ne ins tanc e per D LC


C o nverg ence L aye r U s er C on nec tion,
identified by D U C ID
D LC C ontro l S AP D LC U ser S AP (M A C ID + D LC C ID )
R a d io Link C o ntro l S ub -laye r D a ta Link C o ntro l -
R ad io DLC
B a sic D ata Tra nsp o rt F unc tio n
O n e ins tanc e per M T Association
R esou rce C on n ec tion
C on trol
C on trol C on trol S co p e o f
H IP E R L AN /2
E rror C ontro l
stand ard s
R LC
O ne ins tanc e per A P

M e dium A ccess C ontrol

P hy sic al L ay er

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

55
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

56
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

57
Traffic Scheduling and QoS for Wireless Broadband Networks

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 WLANS

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.

58
Traffic Scheduling and QoS for Wireless Broadband Networks

PART TWO
Scheduling Policies and QoS in WINE

59
Traffic Scheduling and QoS for Wireless Broadband Networks

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;

60
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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).

61
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

62
Traffic Scheduling and QoS for Wireless Broadband Networks

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

63
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

64
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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.

65
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

66
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

67
Traffic Scheduling and QoS for Wireless Broadband Networks

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

68
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

69
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

70
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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.

71
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

72
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

73
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

r bytes/s

p bytes/s
b bytes

Offered Admitted
traffic traffic

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

74
Traffic Scheduling and QoS for Wireless Broadband Networks

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

75
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

76
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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

77
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

78
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

w1 w2 w3 wN
s

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

wi
si = N
⋅s
(i = 1,...,N).
∑wj
j=1

79
Traffic Scheduling and QoS for Wireless Broadband Networks

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

 wi
 ⋅ si ∈ B(t)
ri (t) =  ∑ w j
 j∈B(t)
0 otherwise

Flow
with no
backlog of

w1 w2 w3 wN

s1 s2 s3 sN

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)

80
Traffic Scheduling and QoS for Wireless Broadband Networks

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:
Wi (t1 , t 2 ) W j (t1 , t 2 )
=
wi wj

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

bi ( H − 1) M i H LhMAX
Di =
ˆ + +∑ h
Ri Ri h =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

81
Traffic Scheduling and QoS for Wireless Broadband Networks

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

82
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

83
Traffic Scheduling and QoS for Wireless Broadband Networks

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

84
Traffic Scheduling and QoS for Wireless Broadband Networks

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).

85
Traffic Scheduling and QoS for Wireless Broadband Networks

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

86
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

87
Traffic Scheduling and QoS for Wireless Broadband Networks

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).

88
Traffic Scheduling and QoS for Wireless Broadband Networks

IP layer

WAL Coordinator

WAL module WAL module QoS module


1 2

LLCT

Underlying network

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

89
Traffic Scheduling and QoS for Wireless Broadband Networks

medium specific link layer. This layer is termed the Wireless Adaptation Layer (WAL). The
WAL will run both in access points and wireless terminals.

Transport Layer (Mobile Terminal Only)


[ TCP, UDP, RTP ]

Wireless SNMP Agent


IPv4, IPv6
Routing, Mobility

Wireless Adaptation Layer

module X
module Q
module Z

Wireless Interface Driver


Interface
Specific LLC + MAC
PHY

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

90
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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.

91
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

92
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

93
Traffic Scheduling and QoS for Wireless Broadband Networks

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()

94
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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

95
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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 Should not be used with video or voice delay sensitive streams.
interaction
Lower For channels with high packet loss.
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

96
Traffic Scheduling and QoS for Wireless Broadband Networks

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 Works with longer duration streams, TCP or UDP
interaction
Lower For lower bandwidth or overused channels.
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

97
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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 Useful with TCP or UDP.
interaction
Lower Useful on links with frequent link outages (temporary)
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.

98
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

99
Traffic Scheduling and QoS for Wireless Broadband Networks

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

100
Traffic Scheduling and QoS for Wireless Broadband Networks

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

101
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

N (t )

Eq. 5.1 Atot (t ) = ∑ C (i, t )


i =1

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:

102
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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

103
Traffic Scheduling and QoS for Wireless Broadband Networks

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

104
Traffic Scheduling and QoS for Wireless Broadband Networks

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).

105
Traffic Scheduling and QoS for Wireless Broadband Networks

F ro m th e W A L c o o r d in a to r

I P d a ta g r a m s

C la s sif ie r

(1 ,1 ) (1 ,N (1 ,t)) (m ,1 ) (m ,N (m ,t)) (M (t),1 )


... ... ... (M (t),N (M (t),t))

M T1 ... MT m ... M T M ( t)
S c h e d u le r S c h e d u le r S c h e d u le r

M a in S c h e d u le r M a in S c h e d u le r
a lg o r ith m MUX

T o th e L L C T

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

106
Traffic Scheduling and QoS for Wireless Broadband Networks

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 ∫ α (i, t ) R(t )dt


0

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

107
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

108
Traffic Scheduling and QoS for Wireless Broadband Networks

t N max

Eq. 5.3 Bt arg et (i, t start , t ) = ∫ α (i, t ) ∑ Bemitted (i, t start , t )dt (I=1..Nmax)
tstart i =1

N max

where ∑B
i =1
emitted (i, tstart , t ) 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.:

C (i ,t ) C (i ,t )

∑ Rsus (i, j, t )
j =1
∑N
j =1
conn (i, j , t ) Rsus − conn (i, j )
Eq. 5.4 α (i, t ) = N (t ) C (i ,t )
= N (t ) C (i ,t ) (i=1..Nmax)
∑ ∑R
i =1 j =1
sus (i, j , t ) ∑ ∑N
i =1 j =1
conn (i, j , t ) Rsus − conn (i, j )

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) :

109
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

110
Traffic Scheduling and QoS for Wireless Broadband Networks

Note that the CAC Module will definitely assure that:

N ( t ) C ( i ,t )

Eq. 5.7 Rair −int erface (t ) > ∑ ∑R


i =1 j =1
sus (i, j , t )

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:

N (t )

∑R trans (i, t )
Eq. 5.8 Θ(t ) = i =1

Rair −int erface (t )

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:

N ( t ) C ( i ,t )

Eq. 5.9 RLLCT (t ) > ∑ ∑R


i =1 j =1
sus (i, j , t )

111
Traffic Scheduling and QoS for Wireless Broadband Networks

Morever, in this ideal case, taking into account Eq. 5.8, the Throughput Θ(t) is equal to:

N (t )

∑R emitted (i, t )
Eq. 5.10 Θ(t ) = i =1

RLLCT (t )

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,
C ( i ,t )
i.e. Rno min al (i ) = ∑N
j =1
conn (i, j , t ) Rsus −conn ( j )

(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

112
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

113
Traffic Scheduling and QoS for Wireless Broadband Networks

PART THREE
MT SCHEDULER:
The Single Controller Algorithm

114
Traffic Scheduling and QoS for Wireless Broadband Networks

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 C (i )

∑∑N
i =1 j =1
Conn
(i, j )

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

115
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

Loff (i, j , th − Tmonit , th)


Roff (i, j , th) =
Eq. 6.1 Tmonit

Llost (i, j , th − Tmonit , th)


Rloss (i, j , t , h) =
Eq. 6.2 Tmonit

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

116
Traffic Scheduling and QoS for Wireless Broadband Networks

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-

117
Traffic Scheduling and QoS for Wireless Broadband Networks

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):
Ttotal N C ( i )
Eq. 6.6 J (0, Ttotal ) = ∫ ∑∑ w( j ) R
0 i =0 j =1
loss (i, j , th)dth

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].

118
Traffic Scheduling and QoS for Wireless Broadband Networks

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:
N
Eq. 6.7 ∑ α (i) = 1
i =1

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.

119
Traffic Scheduling and QoS for Wireless Broadband Networks

- 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:

C (i )
Eq. 6.8 ∑ δ (i, j, t ) R
j =1
h LLCT ≤ α (i ) RLLCT

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.

120
Traffic Scheduling and QoS for Wireless Broadband Networks

From the WAL Coordinator

IP datagrams

Classifier

(1,1)
… (1,C ) 1
(1,1)
… (2,C ) 2 …
(N,1) (N,C(N))

MT 1 MT 2 … .. MT N
Scheduler Scheduler Scheduler
IP datagrams selected for being transmitted towards the LLCT

Decisions about the MT


Scheduler entitled to transmit
an IP datagram towards the
LLCT
IP datagrams selected for being
Main Scheduler transmitted towards the LLCT

algorithm To the LLCT

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

121
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

h + N ( i , j , h ) −1 h+ N ( i , j ,h )
Eq. 6.10 ∑ Tshortδ (i, j, tl ) RLLCT < q(i, j, th) ≤
l =h
∑T
l =h
shortδ (i, j , tl ) RLLCT

Eq. 6.11 D (i, j , th) = N (i, j , h)Tshort

• 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

122
Traffic Scheduling and QoS for Wireless Broadband Networks

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).

123
Traffic Scheduling and QoS for Wireless Broadband Networks

IP datagrams relevant IP datagrams relevant to


to the associations (i,1) the associations (i,C(i))

Roff(i,1,th) Roff(i,C(i),th)

Rloss (i,1, t h ) Rloss (i, C (i ), t h )


Admittance
Admittance Admittance
Admittance
Discarded traffic Handler (i,1) Handler(i,C(i))
(i,C(i)) Discarded traffic
Handler (i,1) Handler

Roff (i,1, th ) − Rloss (i,1, th ) Admitted Traffic Roff (i, C(i),th ) − Rloss(i, C(i),th )

FIFO Buffer (i,1) whose FIFO Buffer (i,C(i)) whose


occupancy is q(i,1,th) bits occupancy is q(i,C(i),th) bits

Commands regulating
the admittance of the IP
datagrams in the FIFO Decisions about the FIFO
Buffers buffer entitled to transmit an IP δ ( i ,1, t ) R
δ (i, C(i),t )R h LLCT
h LLCT
datagrams towards the LLCT

MTiiBuffer
MT Buffer
Controller
Controller
IP datagrams selected for being
transmitted towards the LLCT
Decisions about the MT Scheduler
entitled to transmit an IP datagram
towards the LLCT

From the Main Scheduler algorithm

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.

124
Traffic Scheduling and QoS for Wireless Broadband Networks

From the Classifier


Roff (i,1, t h ) Roff (i, C (i ), t h )

Rloss (i,1, t h )
+
- +
Rloss (i, C (i ), t h ) - -
-
MTiiBuffer
MT Buffer
Controller
Controller
δ (i,1, t h ) RLLCT

δ (i, C (i ), t h ) RLLCT
q (i,1, t h +1 ) − q(i,1, th )

q(i, C (i), th +1 ) − q(i, C (i), th )

α (i) RLLCT

From the Main


Scheduler algorithm
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.

125
Traffic Scheduling and QoS for Wireless Broadband Networks

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)).

126
Traffic Scheduling and QoS for Wireless Broadband Networks

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 0 = Rt*k −off (i, j ) − Rt*k −loss (i, j ) − δ t*k (i, j ) RLLCT j=1..C(i)

Eq. 6.13 q t*k (i, j ) = D max( j )δ t*k (i, j ) RLLCT 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:
C (i ) C (i )
Eq. 6.15 ∑ δ t* (i, j) RLLCT = ∑ ( Rt* (i, j ) − Rt*
j =1
k
j =1
k − off k − loss
(i, j )) = (1 − ε )α (i ) RLLCT

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:

127
Traffic Scheduling and QoS for Wireless Broadband Networks

[ ]
C (i )
Rleft (i ) = (1 − ε )α (i ) RLLCT − ∑ Rt*k − off (i, j ) − Rt*k − loss (i, j )
j =1

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) Rt*k −loss (i, j1) is set to max( Rt*k −off (i. j1) − Rmin ( j1) − Rleft (i ),0) 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, δ t*k (i, j ) and q t*k (i, j ) 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 δ t*k (i, j ) and q t*k (i, j ) 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:

I t+h = ((i, j ) : q (i, j , th) − q t*k (i, j ) ≥ 0)

I t−h = ((i, j ) : q (i, j , th) − q t*k (i, j ) < 0)

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:

128
Traffic Scheduling and QoS for Wireless Broadband Networks

I t+h (i ) = ( j : q (i, j , th) − q t*k (i, j ) ≥ 0) i=1..N

I t−h (i ) = ( j : q (i, j , th) − q t*k (i, j ) < 0) i=1..N

The cardinality of the subsets I t+h (i ) will be denoted as M + (i ) .

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 t h ∈ [t k , t k +1 ) , 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 Rloss (i, j , th) = max( Rt*k −loss (i, j ) + Roff (i, j , th) − Rt*k −off (i, j ),0)

Eq. 6.17 δ (i, j , th) = δ t* (i, j ) + K t* (i, j , th)[q(i, j , th) − qt* (i, j )]
k k k

* *
where Rtk-loss(i,j), q t*k (i, j ) , δ t*k (i, j ) are computed as described above and Ktk (i,j,th) (j = 1,...C)
are positive constants to be determined as follows:

εα (i )
K t*k (i, j , th) = if (i, j ) ∈ I t+h
Eq. 6.18 +
[
M (i ) q (i, j , th) − q (i, j )
*
tk ]
δ t* (i, j ) 1
Eq. 6.19 K t*k (i, j , th) = min(− k
, ) if (i, j ) ∈ I t−h
q (i, j , th) − q (i, j ) TshortRLLCT
*
tk

*
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

129
Traffic Scheduling and QoS for Wireless Broadband Networks

δ(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.

Roff (i,1, t k ) Roff (i, C (i ), t k )

α (i) RLLCT
Centralized computationofofRR* *tk-loss(i,j)
Centralizedcomputation (i,j)according
accordingtotothe
thethree
three
tk-loss
step algorithm.
step algorithm. *
Rloss (i,1, t h ) Rloss (i, C (i ), t h )
RRloss (i,j,t)=max(R
(i,j,t
loss
h
h)=max(R
* tk-loss (i,j)+Roff(i,j,th)-Rtk-off(i,j),0)
tk-loss(i,j)+Roff(i,j,th)-Rtk-off
(i,j),0)

Rt*k −loss (i,1) Rt*k −loss (i, C (i ))

* * *
Roff (i,1, t k ) qq* tk(i,1) and δ * tk(i,1)
tk(i,1) and δ tk(i,1) qq* tk(i,C(i)) and
tk(i,C(i)) and
computation
computation
*
k
computation Roff (i, C (i ), t k )
(i,C(i))computation
δδ*tkt(i,C(i))
according to eq. 5.12, according to eq. 5.12,
according to eq. 5.12, according to eq. 5.12,
eq.5.13,
eq. 5.13,eq.
eq.5.14
5.14 eq.5.13,
eq. 5.13,eq.
eq.5.14
5.14
qtk (i,1), δ tk (i,1)
* *
qtk (i, C (i )), δ t*k (i, C (i ))
*

K* k(i,1,th) K* k(i,C(i),th)
K*tkt(i,1,t h) K*tkt(i,C(i),t h)
computation
computation computation
computation
accordingtoto
according accordingtoto
according
eq. 5.18, eq. 5.19 eq. 5.18, eq. 5.19
eq. 5.18, eq. 5.19 eq. 5.18, eq. 5.19
K t*k (i,1, t h ) K t*k (i,1, t h )

δ(i,1,t)h)computation
δ(i,1,t computation δ(i,C(i),t)h)computation
δ(i,C(i),t computation
h h
according totoeq.
according eq.5.17
5.17 according totoeq.
according eq.5.17
5.17

δ (i,1, t h ) δ (i, C (i ), t h )

Roff (i,1, t h ) q(i,1,th+1) )computation


computation q(i,C(i),th+1) )computation
computation Roff (i, C (i ), t h )
q(i,1,t h+1 q(i,C(i),th+1
according totoeq.
according eq.5.9
5.9 according totoeq.
according eq.5.9
5.9

q (i,1, t h ) q (i, C (i ), t h )

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

130
Traffic Scheduling and QoS for Wireless Broadband Networks

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 t h ∈ [t k , t k +1 )

( [ ] )
q(i, j , th + 1) − q(i, j, th) = Roff (i, j, th) − Rloss (i, j , th ) − δ t*k (i, j ) RLLCT − K t*k (i, j , th ) q(i, j, th) − qt*k (i, j ) RLLCT Tshort

Then, by taking Eq. 6.12 and Eq. 6.16 into account, we obtain at a time t h ∈ [t k , t k +1 ) :

[ ]
q (i, j , th + 1) − q (i, j , th) = − K t*k (i, j , th) q (i, j , th) − qt*k (i, j ) R LLCT Tshort

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 t h ∈ [t k , t k +1 )

Eq. 6.20 e(i, j , th) = q (i, j , th) − qt*k (i, j )

we get at a time t h ∈ [t k , t k +1 ) :

e(i, j , th + 1) − e(i, j , th) = − K t*k (i, j , th) R LLCT Tshort e(i, j , th)
i.e.
Eq. 6.21 ( )
e(i, j , th + 1) = 1 − K t*k (i, j , th) R LLCT Tshort e(i, j , th)

Taking into account Eq. 6.19 and Eq. 6.21, the trends by which e(i, j , th) 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 e(i, j , th) is positive (i.e. if, at time th, the association (i,j) belongs to I t+h ), than, in
virtue of Eq. 6.18, the Eq. 6.21 becomes

RLLCT Tshort εα (i )
e(i, j , th + 1) = e(i, j , th) −
M + (i )

131
Traffic Scheduling and QoS for Wireless Broadband Networks

i.e., at each discrete time instant (i.e. every Tshort seconds), the error reduces by an
εα (i )
amount A equal to R LLCT Tshort (see Fig. 4.2a); note that as, due to these reductions,
M + (i )
e(i, j , th) becomes negative, then the error follows the trends herafter explained.
When e(i, j , th) 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 e(i, j , th) 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 e(i, j , th) is negative (i.e. if, at time th, the association (i,j) belongs to I t−h ) the
following two trends are possible:

δ t* (i, j ) 1
i) if k
≥ , than, in virtue of Eq. 6.19, the Eq. 6.21
q (i, j , th ) − q (i, j )
*
tk Tshort RLLCT

becomes e(i, j , t h +1 ) = 0 , i.e. the error converges to zero in just one discrete time
instant, i.e. in Tshort seconds (see Figure 6-6);

δ t* (i, j ) 1
ii) if − k
< , in virtue of Eq. 6.19, the Eq. 6.21 becomes
q (i, j , t h ) − q (i, j )
*
tk Tshort RLLCT

e(i, j , t h +1 ) = e(i, j , t h ) + RLLCT Tshort δ t*k (i, j ) , i.e., at each discrete time instant (i.e.
every Tshort seconds), the module of the error reduces by an amount A equal to
RLLCT Tshort δ t*k (i, j ) ; in this case the trend ia as in Figure 6-5, but specular with
respect to the time axis.

132
Traffic Scheduling and QoS for Wireless Broadband Networks

e (i,j,t h)
A
A
A
tk t
Tsh o rt tk+1 h
Tlo n g

Figure 6-5: Trend of the error e(i,j,th) for th>=tk if e(i,j,tk) is positive

e(i,j,th)
Tlong

tk th
Tshort tk+1
e(i,j,tk )

Figure 6-6: Trend of the error e(i,j,th) for t ∈ [tk,tk+1] if e(i,j,tk) is negative and
δ t* (i, j ) 1
− k

q (i, j , th) − q (i, j )
*
tk Tshort RLLCT

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 K t*k (i, j , th) q (i, j , th) − qt*k (i, j ) ]
is negative for any j ∈ I t−h (i ) , we have for any i ∈ [1, N]:

133
Traffic Scheduling and QoS for Wireless Broadband Networks

∑ δ (i, j, t h ) = ∑ δ t* (i, j ) + ∑ K t* (i, j, t h )[q(i, j, t h ) − qt* (i, j )] =


C (i ) C (i ) C (i )

k k k
j =1 j =1 j =1

[ ] ∑K [ ]
C (i )

∑δ *
tk (i, j ) + ∑K *
tk (i, j , t h ) q(i, j , t h ) − qt*k (i, j ) + *
tk (i, j , t h ) q(i, j , t h ) − qt*k (i, j ) ≤
j =1 j∈I t+h ( i ) j∈I t−h ( i )

εα (i )
(1 − ε )α (i ) + ∑ M + (i )
= (1 − ε )α (i ) + eα (i ) = α (i )
j∈I t+h ( i )

134
Traffic Scheduling and QoS for Wireless Broadband Networks

PART FOUR
Simulation and Performance

135
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

136
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

137
Traffic Scheduling and QoS for Wireless Broadband Networks

 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.

138
Traffic Scheduling and QoS for Wireless Broadband Networks

 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.

139
Traffic Scheduling and QoS for Wireless Broadband Networks

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

140
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

141
Traffic Scheduling and QoS for Wireless Broadband Networks

R e-specification

D ata collection and


Initial specification
simulation

A nalysis

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:

142
Traffic Scheduling and QoS for Wireless Broadband Networks

Network model
Process model

Node model

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

143
Traffic Scheduling and QoS for Wireless Broadband Networks

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

144
Traffic Scheduling and QoS for Wireless Broadband Networks

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

145
Traffic Scheduling and QoS for Wireless Broadband Networks

 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

146
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

147
Traffic Scheduling and QoS for Wireless Broadband Networks

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)

148
Traffic Scheduling and QoS for Wireless Broadband Networks

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

149
Traffic Scheduling and QoS for Wireless Broadband Networks

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

150
Traffic Scheduling and QoS for Wireless Broadband Networks

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
40kbit
to compute Tshort as Tshort = , verifying that the delay constraints are
δ(i,j,th) RLLCT
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

151
Traffic Scheduling and QoS for Wireless Broadband Networks

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 Parameter Assumed Values Assumed Assumed Values Assumed Values


Symbol Meaning in the Service Values in in the Service in the Service Class j
Class j = 1 the Service Class j = 3 =4
Class j = 2
J Service Class Id 1 2 3 4
Typical Voice1 FTP Web Video
Application
Average Bit 29.2 Kbps 200 Kbps 40 Kbps 1,132 Mbps B Frames
RAV Rate per (GSM) (Computed (Computed during 1.481 Mbps P Frames
connection during the the download 2.143 Mbps I Frames4
(Nominal download periods3)
Value) periods2)
BAV Average IP 580 Bits 20000 Bits 12000 Bits 12000 Bits
datagrams length (GSM)
Statistical CONSTANT UNIFORM UNIFORM UNIFORM
Distribution of at the value In the interval in the interval in the interval [320,
the random specified in the [320, 39680] [320, 23680] Bits 23680] Bits
variable line above Bits
Bsegment(j)
Average
Interarrival Time
TAV between 20 ms 100 ms 300 ms 7.57 ms
consecutive IP
datagrams
(nominal value)
Statistical CONSTANT UNIFORM UNIFORM GAUSSIAN
Distribution of the at the value in the interval in the interval with the following
random variable specified in the [0.05, 0.15] [0.05, 0.55] secs average
representing the line above secs 10.6 ms (B Frame)
Tinterarrival(j)
Between
8.1 ms (P Frame)
consecutive IP 5.6 ms (I Frame)
datagrams of a
certain connection

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.

152
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

153
Traffic Scheduling and QoS for Wireless Broadband Networks

Ttotal N C ( i )
J (0, Ttotal ) = ∫ ∑∑R
0 i = 0 j =1
loss (i, j , th)dth = Bloss

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.:

N C (i )

∑∑B
i =1 j =1
emitted (i, j )
η LINK =
R LLCT Ttotal

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

154
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

155
Traffic Scheduling and QoS for Wireless Broadband Networks

• 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 Bloss −tot

which are key parameters in order to assess the efficiency of the designed Traffic
Control Module.

156
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

157
Traffic Scheduling and QoS for Wireless Broadband Networks

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)

158
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

159
Traffic Scheduling and QoS for Wireless Broadband Networks

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

160
Traffic Scheduling and QoS for Wireless Broadband Networks

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:

161
Traffic Scheduling and QoS for Wireless Broadband Networks

 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).

162
Traffic Scheduling and QoS for Wireless Broadband Networks

The web and FTP sources are on-off type:

R av (t) bit/sec

0 bits/sec

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.

163
Traffic Scheduling and QoS for Wireless Broadband Networks

8.4 SIMULATIONS RESULTS

8.4.1 Compliant Campaign

95
Link Efficiency (%)

90
85 FIFO Queue option
80 Open-Loop option
75 Closed-Loop option
70
65
11 12 13 14 15
Number of MTs (N )

Figure 8-8:Link Efficiency ηlink as a function of the number of MTs N, up to Nlimit.

50
45
40
Bloss (Mbit)

35 FIFO Option
30
25 Closed-loop option
20
15 Open-loop option
10
5
0
11 12 13 14 15

Number of MTs (N )

Figure 8-9:Overall number of discarded bits Bloss as a function of the number of MTs N, up to
Nlimit.

164
Traffic Scheduling and QoS for Wireless Broadband Networks

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

165
Traffic Scheduling and QoS for Wireless Broadband Networks

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]

166
Traffic Scheduling and QoS for Wireless Broadband Networks

Figure 8-12:Delay D(i,3,th) experienced by the IP datagrams relevant to the associations (i,3)
(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]

Figure 8-13:Delay D(i,4,th) experienced by the IP datagrams relevant to the associations (i,4)
(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
Traffic Scheduling and QoS for Wireless Broadband Networks

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)

Figure 8-15: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 (Closed-Loop option; N = Nlimit = 15) ) for a
single MT (Rmin(2)=200 kbps during the download period, see note 2)

168
Traffic Scheduling and QoS for Wireless Broadband Networks

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)

Figure 8-17:Bit rate of the admitted traffic Roff(i,4,th) − Rloss(i,4,th) relevant to the associations
(i,4) (Video) during the Simulation Time Period (Closed-Loop option; N = Nlimit = 15) ) for a
single MT (Rmin(4)=1350 kbps)

169
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

0.97

0.87
LINK Efficiency

Open Loop Option


0.77
Reference Option
0.67 Closed Loop Option

0.57

0.47
1 2 3
K (Number of Associations)

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 .

170
Traffic Scheduling and QoS for Wireless Broadband Networks

2000
1800
1600
1400
Bloss (Mbit)

1200 Open Loop Option


1000 Reference Option
800
Closed Loop Option
600
400
200
0
1 2 3
K (Number of Associations)

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

171
Traffic Scheduling and QoS for Wireless Broadband Networks

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

172
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

Figure 8-22: 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 =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

173
Traffic Scheduling and QoS for Wireless Broadband Networks

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

174
Traffic Scheduling and QoS for Wireless Broadband Networks

Figure 8-26: 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 =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

175
Traffic Scheduling and QoS for Wireless Broadband Networks

8.4.2.3 Analysis of Web traffic handling by the scheduler for k=3

Figure 8-28: 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 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

176
Traffic Scheduling and QoS for Wireless Broadband Networks

Figure 8-30: Delay D(i,3,th) experienced by the IP datagrams relevant to the associations (i,3)
(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

177
Traffic Scheduling and QoS for Wireless Broadband Networks

8.4.2.4 Analysis of Video traffic handling by the scheduler for k=3

Figure 8-32: Bit rate of the admitted traffic Roff(i,4,th) − Rloss(i,4 ,th) relevant to the
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

178
Traffic Scheduling and QoS for Wireless Broadband Networks

Figure 8-34: Delay D(i,4,th) experienced by the IP datagrams relevant to the associations (i,4)
(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

179
Traffic Scheduling and QoS for Wireless Broadband Networks

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

180
Traffic Scheduling and QoS for Wireless Broadband Networks

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

181
Traffic Scheduling and QoS for Wireless Broadband Networks

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

182
Traffic Scheduling and QoS for Wireless Broadband Networks

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

183
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

184
Traffic Scheduling and QoS for Wireless Broadband Networks

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

185
Traffic Scheduling and QoS for Wireless Broadband Networks

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
δ t* (i, j ) 1
− k
≥ .................................................................................133
q (i, j , th) − q (i, j )
*
tk Tshort RLLCT
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

186
Traffic Scheduling and QoS for Wireless Broadband Networks

Figure 8-9:Overall number of discarded bits Bloss as a function of the number of MTs N, up to
Nlimit.................................................................................................................................164
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] ..............................................166
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] ..............................................166
Figure 8-12:Delay D(i,3,th) experienced by the IP datagrams relevant to the associations (i,3)
(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
Figure 8-13:Delay D(i,4,th) experienced by the IP datagrams relevant to the associations (i,4)
(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
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) ....................................................................................168
Figure 8-15: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 (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
Figure 8-17:Bit rate of the admitted traffic Roff(i,4,th) − Rloss(i,4,th) relevant to the associations
(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

187
Traffic Scheduling and QoS for Wireless Broadband Networks

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
Figure 8-22: 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 =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
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) ...........................................174
Figure 8-25: Time Average of Bit Rate of input FTP traffic and output FTP traffic.............174
Figure 8-26: 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 =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
Figure 8-28: 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 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
Figure 8-30: Delay D(i,3,th) experienced by the IP datagrams relevant to the associations (i,3)
(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
Figure 8-32: Bit rate of the admitted traffic Roff(i,4,th) − Rloss(i,4 ,th) relevant to the
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
Figure 8-34: Delay D(i,4,th) experienced by the IP datagrams relevant to the associations (i,4)
(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

188
Traffic Scheduling and QoS for Wireless Broadband Networks

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

189
Traffic Scheduling and QoS for Wireless Broadband Networks

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

190
Traffic Scheduling and QoS for Wireless Broadband Networks

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

191
Traffic Scheduling and QoS for Wireless Broadband Networks

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

192
Traffic Scheduling and QoS for Wireless Broadband Networks

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

193
Traffic Scheduling and QoS for Wireless Broadband Networks

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

194
Traffic Scheduling and QoS for Wireless Broadband Networks

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

195
Traffic Scheduling and QoS for Wireless Broadband Networks

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 pekka.sahi@hut.fi
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

196
Traffic Scheduling and QoS for Wireless Broadband Networks

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.

197
Traffic Scheduling and QoS for Wireless Broadband Networks

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

198
Traffic Scheduling and QoS for Wireless Broadband Networks

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”.

199

Potrebbero piacerti anche