Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Facoltà di Ingegneria
Relatore Correlatore
Prof. Francesco Delli Priscoli Prof. Alberto Isidori
Laureando
Emiliano Pandolfi
Anno Accademico
2000/2001
Traffic Scheduling and QoS for Wireless Broadband Networks
1
Traffic Scheduling and QoS for Wireless Broadband Networks
SUMMARY
1 INTRODUZIONE ..................................................................................................6
3 WIRELESS LANS..............................................................................................37
2
Traffic Scheduling and QoS for Wireless Broadband Networks
3
Traffic Scheduling and QoS for Wireless Broadband Networks
9 CONCLUSIONS...............................................................................................183
11 FIGURE ........................................................................................................185
12 TABLE..........................................................................................................190
13 ACRONYMS.................................................................................................191
4
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
6
Traffic Scheduling and QoS for Wireless Broadband Networks
7
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
9
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
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.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
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:
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
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
Access Point
Mobile Terminal
Termin Mobile Terminal Mobile Terminal
Mobile Terminal
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:
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.
MT
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
MT
Application Application
TCP TCP
IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
Wireless subnet
Fixed network
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.
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
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.
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
IPv4 / IPv6
IP
datagram
Roughly speaking, the WINE system provides the following overviewed functionality
in a per layer basis:
26
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
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.
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.
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:
30
Traffic Scheduling and QoS for Wireless Broadband Networks
• 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.
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.
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
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.
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 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.
36
Traffic Scheduling and QoS for Wireless Broadband Networks
3 WIRELESS LANs
37
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
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.
39
Traffic Scheduling and QoS for Wireless Broadband Networks
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
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
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.
42
Traffic Scheduling and QoS for Wireless Broadband Networks
43
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
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.
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.
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.
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.
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:
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.
The standard uses Inter Frame Spaces (IFS) to provide 4 types of priorities:
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
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.
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
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
3.5.3 HIPERLAN
54
Traffic Scheduling and QoS for Wireless Broadband Networks
H ig her L ay ers
C L S AP s
P hy sic al L ay er
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:
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.
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.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.
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.
• 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”.
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:
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.
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.
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.
• 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).
• 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
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
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.
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
• 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.
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
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.
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
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
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
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.
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 police the traffic associated with a flow which was admitted with a QoS contract
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
We will consider two additional parameters, which are necessary to use a DLB in practical
cases. These are:
• 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):
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:
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.
75
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
• 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.
• 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
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.
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.
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
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
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
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.
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.
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.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)".
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 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
LLCT
Underlying network
Figure 5-1: Example of the path followed by the IP datagram relevant to a certain
connection within the 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.
module X
module Q
module Z
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.
90
Traffic Scheduling and QoS for Wireless Broadband Networks
Figure 5-2 shows a detailed WAL functional entity diagram, and we will examine what
each functional entity does:
91
Traffic Scheduling and QoS for Wireless Broadband Networks
92
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
93
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
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.
96
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
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.
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
99
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
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 )
Finally, let indicate as Nconn(i,j,t) the number of connections belonging to the association
(i,j) at time t.
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.
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.
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).
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
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
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.
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
When performing its task, the Main Scheduler has to take into account the following
issues:
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
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
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.
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
N ( t ) C ( i ,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
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 )
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 )
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
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:
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.
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
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:
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
- 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.
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
120
Traffic Scheduling and QoS for Wireless Broadband Networks
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
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
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
o the information about the IP datagrams arrived at the MT i Scheduler, i.e. the
traffic offered to the MT i Scheduler.
122
Traffic Scheduling and QoS for Wireless Broadband Networks
• 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.
123
Traffic Scheduling and QoS for Wireless Broadband Networks
Roff(i,1,th) Roff(i,C(i),th)
Roff (i,1, th ) − Rloss (i,1, th ) Admitted Traffic Roff (i, C(i),th ) − Rloss(i, C(i),th )
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
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
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 )
α (i) RLLCT
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
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)
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
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:
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
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.
α (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)
* * *
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 )
q (i,1, t h ) q (i, C (i ), t h )
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 )
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
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.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
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.
137
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
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:
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
139
Traffic Scheduling and QoS for Wireless Broadband Networks
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:
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.
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
A nalysis
142
Traffic Scheduling and QoS for Wireless Broadband Networks
Network model
Process model
Node model
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.
144
Traffic Scheduling and QoS for Wireless Broadband Networks
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.
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.
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:
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
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
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
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
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.
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
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
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
158
Traffic Scheduling and QoS for Wireless Broadband Networks
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
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.
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
R av (t) bit/sec
0 bits/sec
TOFF T ON
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
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 )
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
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
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)
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.
171
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
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
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
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
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
180
Traffic Scheduling and QoS for Wireless Broadband Networks
181
Traffic Scheduling and QoS for Wireless Broadband Networks
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
184
Traffic Scheduling and QoS for Wireless Broadband Networks
10 FIGURE
185
Traffic Scheduling and QoS for Wireless Broadband Networks
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
189
Traffic Scheduling and QoS for Wireless Broadband Networks
11 TABLE
190
Traffic Scheduling and QoS for Wireless Broadband Networks
12 ACRONYMS
191
Traffic Scheduling and QoS for Wireless Broadband Networks
192
Traffic Scheduling and QoS for Wireless Broadband Networks
193
Traffic Scheduling and QoS for Wireless Broadband Networks
194
Traffic Scheduling and QoS for Wireless Broadband Networks
195
Traffic Scheduling and QoS for Wireless Broadband Networks
196
Traffic Scheduling and QoS for Wireless Broadband Networks
197
Traffic Scheduling and QoS for Wireless Broadband Networks
198
Traffic Scheduling and QoS for Wireless Broadband Networks
199