1

QoS in LTE and 802.16

Karthik R.M., Nadeem Akhtar,
CEWiT
email: [email protected], [email protected],
Jaydip Sen , Arijit Ukil,
Innovation Lab, Tata Consultancy Services Ltd.
email: [email protected] , [email protected]

I. I NTRODUCTION
Quality of Service (QoS) is a broad and loose term that refers to the “collective effect of service”, as perceived by
the user. For the purposes of this discussion, QoS more narrowly refers to meeting certain requirements typically,
throughput, packet error rate, delay, and jitter-associated with a given application. Broadband wireless networks
must support a variety of applications, such as voice, data, video, and multimedia, and each of these has different
traffic patterns and QoS requirements. In addition to the application-specific QoS requirements, networks often
need to also enforce policy-based QoS, such as giving differentiated services to users based on their subscribed
service plans. The variability in the QoS requirements across applications, services, and users makes it a challenge
to accommodate all these on a single-access network, particularly wireless networks, where bandwidth is at a
premium. From a user perspective, however, the perceived quality is based on the end-to-end performance of the
network. To be effective, therefore, QoS has to be delivered end-to-end across the network, which may include,
besides the wireless link, a variety of aggregation, switching, and routing elements between the communication end
points. IP-based networks are expected to form the bulk of the core network; hence, IP (Internet Protocol)-layer
QoS is critical to providing end-to-end service quality.
IEEE Standard 802.16 [1] defines the air interface specification for wireless metropolitan area networks (WMANs).
IEEE Standard 802.16 is designed to evolve as a set of interfaces based on a common Medium Access Control
(MAC) protocol but with physical layer specifications dependent on the spectrum of use and associated regulations.
The access and bandwidth must accommodate multiple end users. The services required by these end users are varied
in their nature and include legacy time-division multiplex (TDM) voice and data, Internet Protocol (IP) connectivity,
and packetized Voice-over-IP (VoIP). To support this variety of services, the 802.16 MAC must accommodate both
continuous and bursty traffic. Additionally, these services expect to be assigned QoS in keeping with the traffic
types.
A broad industry consortium, the Worldwide Interoperability for Microwave Access (WiMAX) Forum has begun
certifying broadband wireless products for interoperability and compliance with IEEE 802.16 standard. The WiMAX
Forum defines a limited number of system profiles and certification profiles. The system profile defines the subset
of mandatory and optional physical and MAC layer features selected by the WiMAX Forum from the IEEE 802.16
standard. A certification profile is defined as a particular instantiation of a system profile, where the operating
frequency, channel bandwidth, and duplexing mode are also specified.
Third generation Universal Mobile Telecommunications Systems (UMTS) based on Wideband Code Division
Multiple Access (WCDMA) has been deployed widely. To ensure that this system remains competitive in the
future, 3GPP (Third Generation Partnership Project) started a project to define the Long Term Evolution (LTE) of
UMTS cellular technology. The specifications related to this effort are known as evolved UMTS terrestrial radio
access (E-UTRA) but are commonly referred to by the project name, LTE. Evolved Packet System (EPS) is the
name given to the IP-based core network architecture defined in Release 8 of the 3GPP specifications. EPS is
the evolution from the General Packet Radio Service (GPRS)-based core network architecture used in UMTS/3G
networks. Compared to GPRS core network, EPS is much simpler in terms of the number of network elements
and flatter as well. In [2], integration between mobile WiMAX and 3GPP using the Policy and Charging Control
(PCC) framework has been studied and a roaming architecture for WiMAX-3GPP integration is also proposed.
In order to provide end-to-end QoS, we need to go beyond the air-interface and look at broadband wireless systems
from an end-to-end network perspective. We need to look at the overall network architecture, higher-layer protocols,
and the interaction among several network elements beyond the mobile station and the base station. Providing end-
to-end QoS requires mechanisms in both the control plane and the data plane. Control plane mechanisms are needed
to allow the users and the network to negotiate and agree on the required QoS specifications, identify which users
and applications are entitled to what type of QoS, and let the network appropriately allocate resources to each
service. Data plane mechanisms are required to enforce the agreed-on QoS requirements by controlling the amount
of network resources that each application/user can consume.
In this document, we provide a brief overview of QoS related issues in LTE and WiMAX, ,identify some
limitations in the current standards and also propose some extensions required to overcome those limitations. With
respect to LTE, we briefly discuss the bearers associated with LTE, QOS requirements in various applications, the
bearer establishment procedures, and terminal and network-initiated QoS control. For WiMAX, we describe the
QoS architecture and discuss a mapping mechanism between IP Differentiated Services (DiffServ) traffic classes
and 802.16 service classes.
The rest of the document is organized as follows. Section II discusses QoS issues in LTE. It first presents
a brief introductory concept on QoS in LTE followed by issues like EPS bearers, GBR and non-GBR bearers,
default and dedicated bearers. Various QoS requirements like user differentiation, fast session startup, and backward
compatibility issues are discussed next. The details of a bearer establishment procedure is also presented. Finally,
the section discusses procedures for network- and device-initiated QoS control in used in LTE. In Section III, we
briefly discuss the IEEE 802.16 architecture and describe the QoS classes. Section III-B overviews the WiMAX
framework for QoS, gives a brief description of the QoS functional elements and also highlights the requirements to
be met and extensions in the existing standard. In Section IV, we discuss the issues involved in ensuring end-to-end
QoS and describes the mapping between 802.16 QoS classes and the DiffServ classes. Section V concludes the
report.

II. Q O S IN LTE
A. Introduction
QoS in LTE provides access network operators and service operators with a set of tools to enable service
and subscriber differentiation. LTE core network is known as evolved packet system (EPS) for its support to
all-IP configuration. QoS in LTE is primarily network-initiated and class-based, where a service is offered to a
subscriber by the operator. The term, “service” is used as the offering an operator makes to a subscriber. Basically,
QoS mechanisms allow the access operator to enable service and subscriber differentiation, as depicted in Fig. 1.
Examples of a service include VoIP telephony based on the IP Multimedia Subsystem (IMS), Mobile Television,
Internet-Access (with various levels of user differentiation), Instant Messaging, Multimedia Broadcast Multicast
Service (MBMS) and Push-to-Talk over Cellular (PoC). We further need to distinguish between session-based
services and non-session-based services. Session-based services utilize an end-to-end session control protocol such
as SIP/SDP or RTSP/SDP. All IMS services are session-based, while Internet-Access is an example of a non session-
based service. The traffic running between a particular client application and a service can be differentiated into
separate service data flows. For example, an IMS-VoIP session can be differentiated into two service data flows, one
for the session control signaling, and one for the media. The term, Traffic Forwarding Policy (TFP) denotes a set
of pre-configured traffic handling attributes relevant within a particular user plane network element. For example, a
RAN-TFP may include several attributes, such as the link layer protocol mode (acknowledged or unacknowledged),
the power settings, and a default uplink maximum bit rate; while a Gateway TFP (GWTFP) may only include a
default downlink maximum bit rate. Each edge/bottleneck node potentially includes transport network node, which
supports a number of TFPs. Uplink (UL) and Downlink (DL) Guaranteed Bit Rates (GBRs) are not part of a TFP,
since these traffic handling attributes cannot be preconfigured for a QoS class. They must therefore, instead be
dynamically signaled. TFPs confine traffic handling attributes to those nodes where those attributes are actually
needed. TFPs are provided and configurable by the operator from the management plane, as shown in Fig. 2.
LTE supports “end-to-end” QoS, meaning that bearer characteristics are defined and controlled throughout the
duration of a session between the mobile device (UE) and the gateway (GW). QoS in LTE is characterized by an
index, QoS Class Identifier (QCI), and the parameter Allocation and Retention Priority (ARP). Bearer types belong
to two main classes with guaranteed and non-guaranteed rates, which specify in more detail the values of packet
delay and loss that can be tolerated for any given bearer.
 Fig. 1: Service and subscriber differentiation in LTE [3]

Fig. 2: Key elements for providing QoS in an access network [4]

B. EPS Bearer
EPS bearer uniquely identifies packet flows that receive a common QoS treatment between gateway and the
terminal. A bearer is the level of granularity for QoS control in EPS based LTE. One bearer exists per combination
of QoS class and IP address of the terminal. The bearer is the basic enabler for traffic separation to provide
differential treatment for traffic with differing QoS requirements. As per functionality, two types of bearers exist:
GBR and non-GBR and as per configuration, two another types of bearers exist: default and dedicated bearers.
A bearer, in general is referred to as an edge-to-edge association between the UE and the GW. Independent of
whether it is realized in a connection-oriented or a connectionless way, a bearer is defined through:
1) Network to which it connects the UE (referred to as Access Point Name in 3GPP),
2) QoS Class Identifier (QCI) via which it can be associated with a TFP defined within each user plane
edge/bottleneck node, and
3) (Optionally) the UL- and DL-GBR. Within an access network the UL-GBR and DL-GBR are only relevant
for session-based services, and only if the operators policy defined for a specific QoS class requires that
session admission control (e.g., in the RAN) be triggered when establishing service data flows associated
 with that QoS class.
The term, QCI is not associated with any semantics, e.g., related to traffic characteristics or application layer
requirements on end-to-end QoS. That is, a QCI is simply a “pointer” to a TFP. Note further that, within a specific
node, multiple QCIs may be associated with the same TFP. In order to receive a QoS level other than the default
QoS level (via the default bearer explained below), a service data flow needs to be bound which is referred to as
a QoS bearer.

C. GBR and non-GBR bearers

For GBR bearers, maximum bit rate (MBR) and GBR are defined, though in 3GPP Release 8 [5], MBR and GBR
are identical. GBR bearers are shielded from congestion related packet loss. This is realized by admission control
functions residing in different network nodes, like LTE base station and is executed at the point when a bearer
is established and modified. A GBR bearer is normally established “on demand”, because it blocks transmission
resources by reserving them in an admission control function, where as a non-GBR bearer can remain established
for long periods of time because it does not block transmission resources. GBR bearer is set up for premium
users, where preference is blocking a new service request rather than risking degrading the performance of the
already admitted service request. It is an operator’s policy decision to establish GBR bearer for a service request,
primarily based on expected traffic load versus predicted capacity. If sufficient capacity or low expected traffic load
is assumed, any service both real-time and non real-time, can be realized on non-GBR bearers.

D. Default and dedicated bearers

Default bearers are established when the user terminal is initially attached to the network. One default bearer
exists per IP address to provide basic connectivity. As the default bearer can remain established for long periods, in
LTE it is mandatory that default bearer be a non-GBR bearer. Dedicated bearers are mostly for GBR services, but
even non-GBR bearers can also be dedicated bearer depending on the policy undertaken by the operator based on
its objective function and constraints. The operator maps the packet flows onto the dedicated bearer based on the
policies provisioned into the network by Policy and Charging Resource Function (PCRF). It also evaluates the QoS
level of the dedicated bearer. Conceptual depiction of a terminal with a default and dedicated bearer established
onto the same IP address is shown in Fig. 3, where it is considered that end-to-end IP packet entering the system is
provided with a tunnel header. A tunnel header contains the bearer identifier to associate the packet with the correct
QoS parameter, which is based on subscriber differentiation (business vs. standard, post-paid vs. pre-paid, roamers,
privileged (civil administrator, police) and service differentiation (IP multimedia sub-system (IMS) voice, P2P file
sharing, real-time audio, video streaming, mobile-TV). In the transport network, the tunnel header further contains
diffserv code point (DSCP) value (Fig. 3). In network layer, a packet flow is differentiated based on five-tuple
points; namely, source and destination IP address, source and destination port numbers and protocol ID.

E. QoS Requirements in LTE

LTE QoS is evolved based on few strategic requirements to satisfy and achieve the targets like high data rate,
low latency, and higher aggregate throughput. They are:
1) Operator Controlled Service and User Differentiation
2) Minimize Terminal Involvement in QoS and Policy Control
3) QoS Support for Access Agnostic Client Applications (UE-Based + Non-UE-Based)
4) Fast Session Setup
5) Backwards Compatibility
1) Operator Controlled Service and User Differentiation: Service and user differentiation requires a limited
set of well defined QoS classes. The number of QoS classes supported within an operators network reflects the
granularity of differentiation the operator provides. Operators should be free to define the mapping of the service
data flow(s) of offered services to the QCI(s). For certain well-known services this mapping could be standardized,
or defined as part of roaming agreements. Likewise, operators should be free to define which TFP gets associated
with a QCI.
 Fig. 3: Bearer and associated QoS parameters in LTE

2) Minimize Terminal Involvement in QoS and Policy Control: Operators may regard a UE as a non-trusted
device which can be “hacked”, e.g., for the purpose of receiving higher QoS than subscribed and charged for.
Therefore, the control over a bearer’s QCI should be located within the network. In principle, there is no reason for
a UE to have knowledge of a bearer’s QCI. Another aspect of this requirement is the placement of the exception
handling control associated with bearer establishment. To ensure a consistent exception handling across terminals
from different vendors, this control should be located within the network.
3) Support for Access Agnostic Client Applications (UE-Based + Non-UE-Based): Access agnostic client appli-
cations do not use any vendor and/or access-specific QoS-API (Application Programming Interface). A QoS-API
can be used to request the establishment of a QoS bearer, and thereby create the UL binding between a service
data flow of the requesting client application and the QoS bearer. This requirement basically says that any client
application programmed towards the ubiquitous socket-API that is supported by virtually every widely deployed
operating system should be able to receive QoS. Note that the socket-API does not support requests for QoS bearers.
4) Fast Session Setup: It is widely recognized that low session setup delays are an important factor in user
perceived service quality.
5) Backwards Compatibility: It can be expected that UEs based on the 3GPP LTE QoS concept will be widely
deployed in the coming years. Also, the upgrade of network equipment can not be assumed to be carried out “over
night”. Hence, backwards compatibility with LTE based equipment needs to be ensured by an evolved 3GPP QoS
concept.
6) QoS Class Identifier (QCI): QCI is a scalar that is used within the access networks as a reference to node-
specific parameters that control packet-forwarding function, like resource allocation constraints, scheduling weights,
queue management, buffer size) and each bearer is assigned one and only one QCI and uniquely identified by it.
QCI characteristics are generally used to describe bearer type (GBR, non-GBR), priority, packet-delay budget, and
packet-error-loss-rate. In the access network, it is the responsibility of the eNodeB to ensure the necessary QoS for
a bearer over the radio interface. Each bearer has an associated QCI, and an Allocation Retention Priority (ARP).
Each QCI is characterized by priority, packet delay budget and acceptable packet loss rate. The QCI label for a
bearer determines how it is handled in the eNodeB. Only a dozen such QCIs have been standardized so that vendors
can all have the same understanding of the underlying service characteristics and thus provide the corresponding
treatment, including queue management, conditioning and policing strategy. This ensures that an LTE operator can
expect uniform traffic handling behavior throughout the network regardless of the manufacturers of the eNodeB
equipment. The set of standardized QCIs and their characteristics (from which the PCRF in an EPS can select) is
provided in Table I. The QCI table specifies values for the priority handling, acceptable delay budget and packet
error loss rate for each QCI label.
The priority and packet delay budget (and to some extent the acceptable packet loss rate) from the QCI label
 TABLE I: Standardized QoS Class Identifiers (QCIs)for LTE [5]
QCI Resource Priority Packet delay (ms) Packet loss Services
1 GBR 2 100 10−2 Conversational voice
2 GBR 4 150 10−3 Conversational voice (live streaming)
3 GBR 3 50 10−3 Real-time gaming
4 GBR 5 300 10−6 Non-conversational video (buffered streaming)
5 Non-GBR 1 100 10−3 IMS signaling
6 Non-GBR 6 300 10−6 Video (buffered streaming)
7 Non-GBR 7 100 10−3 Voice, video (live streaming), interactive streaming
8 Non-GBR 8 300 10−6 TCP-based (e.g. WWW, e-mail), FTP, P2P, etc.,
9 Non-GBR 9 300 10−6

determine the RLC mode configuration and how the scheduler in the MAC handles packets sent over the bearer
(e.g., in terms of scheduling policy, queue management policy and rate shaping policy). For example, a packet
with a higher priority can be expected to be scheduled before a packet with lower priority. For bearers with a
low acceptable loss rate, an Acknowledged Mode (AM) can be used within the RLC protocol layer to ensure that
packets are delivered successfully across the radio interface.
The ARP of a bearer is used for call admission control- i.e., to decide whether or not the requested bearer should
be established in case of radio congestion. It also governs the prioritization of the bearer for pre-emption with
respect to a new bearer establishment request. Once successfully established, a bearer’s ARP does not have any
impact on the bearer-level packet forwarding treatment should be solely determined by the other bearer level QoS
parameters such as QCI, GBR and MBR.
An EPS bearer has two cross multiple interfaces as shown in Fig. 4 the S5/S8 interface from the P-GW to S-GW,
the S1 interface from the S-GW to the eNodeB, and the radio interface (also known as the LTE-Uu interface) from
the eNodeB to the UE. Across each interface, the EPS bearer is mapped onto a lower layer bearer, each with its
own bearer identity. Each node must keep track of the binding between the bearer IDs across its different interfaces.
An S5/S8 bearer transports the packets of a EPS bearer between a S-GW and an eNodeB. A radio bearer
transports the packets of an EPS bearer between a UE and an eNodeB. An eNodeB stores a one-to-one mapping
between a radio bearer ID and an S1 bearer to create the mapping between the two.

Fig. 4: LTE/SAE bearers across different interfaces [5]

IP packets mapped to the same EPS bearer receive the same bearer-level packet forwarding treatment (e.g.,
scheduling policy, queue management policy, rate shaping policy, RLC configuration). Providing different bearer-
level QoS thus requires that a separate EPS bearer is established for each QoS flow, and the user IP packets must
be filtered into the different EPS bearers.
 Packet filtering into different bearers is based on Traffic Flow Templates (TFTs). The TFTs use IP header
information such as source and destination IP addresses and Transmission Control Protocol (TCP) port numbers
to filter packets such as VoIP from web browsing traffic so that each can be sent down the respective bearers with
appropriate QoS. An uplink TFT (UL TFT) associated with each bearer in the UE filters IP packets to the EPS
bearers in the uplink direction. A downlink TFT (DL TFT) in the P-GW is a similar set of downlink packet filters.
As a part of the procedure by which a UE attaches to the network, the UE is assigned an IP address by the
P-GW and at least one bearer is established. This is called the default bearer, and it remains established throughout
the lifetime of the PDN connection in order to provide the UE with always-on IP connectivity to that PDN. The
initial bearer-level QoS parameter values of the default bearer are assigned by the MME, based on the subscription
data retrieved from the HSS. The PCEF may change these values in interaction with the PCRF or according to
local configuration. Additional bearers called dedicated bearers can also be established at any time during or after
completion of the attach procedure. A dedicated bearer can be either a GBR or a non-GBR bearer, (the default
bearer always has to be a non-GBR bearer since it is permanently established). The distinction between default
and dedicated bearers should be transparent to the access network (e.g. E-UTRAN). Each bearer has an associated
QoS, and if more than one bearer is established for a given UE, then each bearer must also be associated with
appropriate TFTs. These dedicated bearers could be established by the network, based for example, on a trigger
from the IMS domain, or they could be requested by the UE. The dedicated bearer for a UE may be provided
by one or more P-GWs. The bearer-level QoS parameter values for dedicated bearers are received by the P-GW
from the PCRF and forwarded to the S-GW. The MME only transparently forwards those values received from the
S-GW over the S11 reference point to the E-UTRAN.

F. Bearer Establishment Procedure

This section describes an example of the end-to-end bearer establishment procedure across the network nodes
using the functionality described in the previous sections.
A typical bearer establishment flow is shown in Fig. 5. Each of the messages is described below.
When a bearer is established, the bearers across each of the interfaces discussed above are established. The PCRF
sends a ‘PCC (policy Control Changing) Decision Provision’ message indicating the required QoS for the bearer
to the P-GW. The P-GW uses this QoS policy to assign the bearer-level QoS parameters. The P-GW then sends
a Create Dedicated Bearer Request message including the QoS and UL TFT to be used in the UE to the S-GW.
The S-GW forwards the ‘Create Dedicated Bearer Request’ message (including QoS, UL TFT and S1-bearer ID)
to the MME (message 3 in Fig. 5). The MME then builds a set of session management configuration information
including the UL TFT and EPS bearer identity, and includes it is the ’Bearer Setup Request’ message which it
sends to the eNodeB (message 4 in Fig. 5). The session management configuration in NAS information and is
therefore sent transparently by the eNodeB to the UE.
The Bearer Setup Request also provides the QoS of the bearer to the eNodeB; this information is used by the
eNodeB for call admission control and also to ensure the necessary QoS by appropriate scheduling of the user’s
IP packets. The eNodeB maps the EPs bearer QoS to the radio bearer QoS. It then signals a ‘RRC Connection
Reconfiguration’ message (including the radio bearer QoS, session management configuration and EPs radio bearer
identity) to the UE to set up the radio bearer (message 5 in Fig. 5). The RRC Connection Reconfiguration message
contains all the configuration parameters for the radio interface. This is mainly for the configuration of the layer 2
(the PDPC, RLC and MAC parameters), but the Layer 1 parameters required for the UE to initialize the protocol
stack. Message 6 to 10 are the corresponding messages to confirm that the bearers have been set up correctly.

G. Network and Terminal-Initiated QoS Control

In the earlier development stage of 3GPP LTE, only terminal-initiated QoS control mechanism is proposed and
accepted. The philosophy behind terminal-initiated QoS control is based on the assumption that the information
about the requested service (e.g., application-layer QoS requirements) is only present in the UE, and that this
information must be provided to the network from the requesting client application. This is depicted in Fig. 6. This
has led to a number of important consequences which are perceived as limitations:
1) QoS bearer can only be initiated from the UE.
2) The uplink and downlink binding states are controlled from the UE.
 Fig. 5: A message flow diagram for LTE/SAE bearer establishment [5]

3) The QCI is represented as a record of attributes.

One limitation resulting from UE-initiated establishment of QoS bearers is that it leaves the exception handling
to the UE’s local policy. For example, this policy could be to retry setting up the QoS bearer with the same or
different Requested QoS, or perhaps to simply give up trying to set up the call. This is in conflict with requirement
2. Furthermore, the absence of the possibility to initiate the establishment of a QoS bearer from the network (using
a bearer handling procedure) precludes the possibility to pre-activate QoS bearers based on operator policy. This
is in conflict with requirement 4. This leads to the development of procedures for network-initiated QoS control.
In network-initiated QoS control, the network initiates the signal to set up a dedicated bearer with a specific QoS
toward the terminal or UE and the RAN, which generally consists of base stations and gateways. The signal is
triggered by an application function (AF) and deep-packet inspection (DPI) function. Using this paradigm, the
client application is left with “QoS unaware”, which is shown in Fig. 7. The main motivation for specifying the
network-initiated QoS control is that most of the IP related services (Internet access, IP-TV, IMS voice) are typically
provided by the access network operator through some third-party peering agreement. The advantage of network-
initiated QoS control is that it minimizes the terminal involvement in QoS and policy control which can be used
to provide QoS to access-agnostic client applications, such as applications that can be downloaded and installed
by the subscriber without any terminal vendor specific QoS-API. Another advantage is that client applications can
reside in a node (like laptop, set top box) that is physically separated from the actual terminal to implement the
concept of “split-terminal”.
In this section, we discussed about QoS in LTE, defined the various bearers, specified the QoS requirements in
LTE, gave the standardized QCI values and also described the bearer-establishment procedure. We also highlighted
the limitations of UE-initiated establishment of QoS bearers and the advantages of network-initiated QoS control.
In the next section, we discuss the QoS in 802.16 and describe the WiMAX QoS framework and identify extensions
 Application Service

Service
info Initiate QoS bearer (Requested QoS+DL binding)

UE Network
RAN
Initiate QoS bearer
(Negotiated QoS)

Fig. 6: Terminal-initiated QoS control [4]

Fig. 7: Terminal-initiated (top) and network-initiated (bottom) QoS control [3]

required in the existing standard.

III. Q O S IN 802.16
A. QoS classes in 802.16
The basic IEEE 802.16 architecture consists of one Base Station (BS) and one (or more) Subscriber Station (SS).
BS acts as a central entity to transfer all the data from SSs in a Point to multipoint (PMP) mode. Transmissions take
place through two independent channels: Downlink Channel (from BS to SS) and Uplink Channel (from SS to BS).
Uplink Channel is shared between all SSs while Downlink Channel is used only by BS. WiMAX Network Working
Group (NWG) Release 1.0.0 specification [6] supports the Time Division Duplexing (TDD) mode of operations.
The IEEE 802.16 is connection oriented. Each packet has to be associated with a connection at MAC level. This
provides a way for bandwidth request, association of QoS and other traffic parameters and data transfer related
actions.
 Scheduling services represent the data handling mechanisms supported by the MAC scheduler for data transport
on a connection. Each connection is associated with a single scheduling service. A scheduling service is determined
by a set of QoS parameters that quantify aspects of its behaviour. These parameters are managed using MAC dialog
messages. There are 5 types of scheduling service on the uplink namely, Unsolicited Grant Service (UGS), extended
real-time polling service (ertPS), real-time polling service (rtPS), Non-real-time Polling service (nrtPs) and best
effort (BE) service. Each service is associated with a set of QoS parameters that quantify aspects of its behaviour.
A detailed description of each of the services is given in [1].
The parameters associated with each of the services are given in Table II.

TABLE II: Parameters of Scheduling services and typical applications

Class of Service Parameters Application
UGS Maximum Sustained Traffic Rate, Maximum Latency and Tolerated Jitter E1/T1
ertPS Minimum Reserved Traffic Rate, Maximum Sustained Traffic Rate, Maximum Latency Silent suppressed VoIP
rtPS Minimum Reserved Traffic Rate, Maximum Sustained Traffic Rate, Maximum Latency MPEG video
nrtPS Minimum Reserved Traffic Rate, Maximum Sustained Traffic Rate, Maximum Latency FTP
BE No minimum service level requirement e-mail

B. WiMAX Forum QoS Architecture

The WiMAX Forum’s NWG is responsible for developing the end-to-end network requirements, architecture, and
protocols for WiMAX. The WiMAX NWG has developed a network reference model (NRM) based on an IP service
model to serve as an architecture framework for WiMAX deployments for supporting fixed, nomadic, and mobile
deployments and to ensure interoperability among various WiMAX equipment and operators. The NRM defines
a number of functional entities and interfaces between those entities. The interfaces are referred to as reference
points. The overall network can be divided into three parts:
1) mobile stations used by the end user to access the network
2) the access service network (ASN), which comprises one or more base stations and one or more ASN gateways
that form the radio access network at the edge, and
3) the connectivity services network (CSN), which provides IP connectivity and the IP core network functions.
The QoS architecture framework [6] extends the IEEE 802.16 QoS model by defining the various QoS-related
functional entities in the WiMAX network and the mechanisms for provisioning and managing the various service
flows and their associated policies. The WiMAX QoS framework supports simultaneous use of a diverse set of
IP services, such as differentiated levels of QoS on a per user and per service flow basis, admission control, and
bandwidth management and calls for the use of standard Internet Engineering Task Force (IETF) mechanisms for
managing policy decisions and policy enforcement between operators. The NWG Release 1.0.0 specification [6]
defines the following procedures for QoS provisioning:
1) Pre-provisioned service flow creation, modification, and deletion.
2) Initial Service Flow creation, modification and deletion.
3) QoS policy provisioning between AAA(Authentication, Authorization and Accounting) and SFA (Service
Flow Authorization).
The IEEE 802.16 specification [1] defines a QoS framework for the air interface. It consists of the following
elements:
• Connection-oriented service.
• 5 data delivery services namely UGS, ertPS, rtPS, nrtPS, and BE.
• Provisioned QoS parameters for each subscriber.
• A policy requirement for admitting new service flow requests.
Under the IEEE 802.16 specification, a subscription can be associated with a number of service flows characterised
by QoS parameters. This information is provisioned in a subscriber management system, namely, AAA or policy
server. There are two types of service models, namely, static service model and dynamic service model. In the
static service model, the subscriber station is not allowed to change the parameters of provisioned service flows
or create service flows dynamically. A dynamic service flow request is triggered by mechanisms not specified in
802.16 specification and they are evaluated to decide whether the service flow request can be authorized. IEEE
802.16 specification defines the following procedure for dynamic service flow creation:
• Permitted service flows and their associated QoS parameters provisioned via the management plane.
• Service flow request evaluated against the provisioned information and created if permissible.
• Service flow created transitions to an admitted state and finally to an active state. Transition to admitted state-
invocation of admission control in BS and soft resource reservation. Transition to active state- actual resource
assignment for the service flow. item Service flow can also transition in the reverse direction.
• A dynamically created service flow MAY be modified or deleted.
1) QoS Functional elements: Based on the IEEE 802.16 [1] and the WiMAX reference model [6], the QoS
functional elements and their functions can be enumerated as follows:
1) MS (Mobile Station) and ASN (Access Service Network). WiMAX network may support ASN-initiated
service flow creation.
2) The home Policy Function (PF) and its associated policy rules belong into the H-NSP (Home Network Service
Provider). Maintained information include general policy rules and application specific policy rules. AAA
provisions the PF’s database with user’s QoS profile and associated policies.
3) AAA holds the users’ QoS profile and associated policy rules. They may be downloaded into the SFA (Service
Flow Authorization) at network entry or into the PF.
4) Service Flow Management (SFM): is a logical entity in the ASN for creation, admission, activation, modifica-
tion and deletion of 802.16 service flows. It consists of Admission Control (AC) and associated local resource
information. SFM always located in the BS. Admission Control is the ability to admit or ability to control
admission of a user to a network based on users service profile and network performance parameters (for
example, load and average delay). If a user requests access to network services but the incremental resources
required to provide the grade of service specified in the users service profile are not available, the Admission
Control function rejects the users access request. Admission Control is implemented to ensure service quality
and is different from authentication and authorization, which are also used to admit or deny network access.
5) SFA: There are two SFA-s, namely Anchor SFA and Serving SFA. Anchor SFA is assigned to each MS for the
duration of the Device Authentication Procedure. Serving SFA directly communicates with the SFM. Both the
SFAs know the identities of each other. SFA MAY perform ASN-level policy enforcement using local policy
database and associated local policy function and admission control. Resource reservation request messages
are sent from the anchor SFA to the serving SFA and finally to the SFM. The result of the reservation is sent
from the SFM to the serving SFA and finally back to the anchor SFA.
6) A network management system for administratively provisioning service flows.
7) Pre-provisioned service flow: Set of service flows can be created, admitted and activated after an SS registers
with the WiMAX network.
The MS initiates a call setup procedure. The QoS profile and policies are stored in the PF or SFA by the AAA.
They evaluate the Service Flow Trigger requests and send the result of the evaluation back to the triggering element
which can be MS or the ASN itself.
The QoS functional elements [6] together with the procedure to setup a call are shown in Fig. 8.
2) Extensions to the standard: The limitations of the existing Release 1 Version 1.2 [6] standard and the
extensions required can be enumerated as follows:
1) The scope of the QoS in [6] is limited to the WiMAX radio link connection. QoS specific treatment in the
fixed part of core and access networks not specified. There are many possibilities for enforcing QoS in the
access and core networks, and operators may require specific interfaces in ASN elements to use for mapping
IP traffic onto these networks. Therefore, the QoS section in [6] makes no guarantees on end-to-end QoS.
Operators require specific L2 and L3 interfaces in ASN network elements for mapping IP traffic on to these
networks.
2) In the specification [6], only preprovisioned service flows are defined. There is no scope for dynamic service
flow creation. Dynamic service flows are triggered by the MS or AF. The AF issues service flow triggers to
the PF. The provision, admission and activation of dynamic service flows require interaction between PF and
SFA. Hence, PF-SFA interaction not specified.
3) For a given ASN/NAP (Network Access Provider) there exists an anchor SFA assigned to each MS. The
 Home or Visited NSP
Service request

Admit or reject AF External

BS networks
ASN−GW Result Service
SFM Service of Flow
Admission Serving SFA evaluation trigger
Flow Trigger
Control
Service
PF
Request Result of
MS evaluation
Admit
or reject Anchor SFA

Local resource AAA

ASN
Service Flow Trigger Evaluation
Store QoS profile and
done using policies in PF or SFA policies in PF or SFA

Fig. 8: QoS functional elements and Call Setup

anchor SFA does not change for the duration of the Device Authentication session. Optionally, there may be
one or more additional SFA entities that relay QoS related primitives and apply QoS policy for that MS. The
relay SFA that directly communicates with the SFM is called the serving SFA. Both the anchor and serving
SFA know the identities of each other. The anchor and/or serving SFA may also perform ASN-level policy
enforcement using a local policy database and an associated local policy function (LPF). The LPF can also
be used to enforce admission control based on available resources. A serving SFA MAY be in the bearer path
towards the SS, but only the signalling interactions for SFA are in the scope of [6]. Data path interactions
between PF and SFA are not defined.
4) Handoff capability from 3GPP to WiMAX is usually referred to as scenario 4 or inter-system handover.
Seamless inter-system handover or scenario 5 provides greater service continuity than that perceived in intra
3GPP handovers. However, both inter-system handover and seamless-inter-system handover are not addressed
in WiMAX Release 1.0.
5) Maintaining a specific level of QoS consistently across the WiMAX and 3GPP access technologies involves
several considerations such as QoS mappings and semantics on the two access networks as well as appropriate
resource allocations. WiMAX provides a powerful and flexible QoS handling using the QoS mechanisms from
802.16 which is transparent to Direct IP access, However, QoS-enabled IP-based access networks cannot be
fully utilized within WiMAX-3GPP IP access.
3) Requirements: [1], [6], [7] have specified the general requirements of the Network Systems Architecture as
well as specific requirements from the QoS architectural framework. A summary of the general requirements is as
follows:
1) Architecture should support simultaneous set of diverse IP services including DiffServ and Integrated Services
(IntServ), admission control and bandwidth management.
2) Policy enforcement per user based on the Service Level Agreements (SLAs) and also synchronisation between
operators based on SLA-s accommodating for the fact that not all operators implement the same policies.
SLA-based resource management for subscribers should also be supported.
3) The architecture should be capable of supporting voice, multimedia services and other mandated regulatory
services such as emergency services and lawful interception and should be agnostic to a variety of independent
Application Service Provider (ASP) networks.
4) Architecture should support interworking with existing wireless network using protocols based on IETF and
 IEEE suite of protocols.
5) The architecture does not preclude inter-technology handovers- e.g., to Wi-Fi, 3GPP- when such capability
is enabled in multi-mode MS
6) It should support roaming between NSP-s. The architecture should allow a single NAP to serve multiple
MSs using different private and public IP domains owned by different NSPs (except where solutions become
technically infeasible). The NSP MAY be one operator or a group of operators. Seamless handover between
different vehicular speeds have to be addressed.
7) Interfacing with various interworking and media gateways for delivering services over IP to WiMAX access
networks should be supported.
8) Global roaming across WiMAX operators with credential reuse, use of AAA for accounting and charging,
and consolidated/common billing and settlement.
9) Specifications should specify the rules in situations in which pre-provisioned service flows cannot be created
or activated in the ASN. QoS framework should allow the communication of an attempt to pre-provision a
service flow from the ASN to the CSN. The procedure is dependent on the policies within the ASN and the
agreement between NAP and NSP.

IV. E ND - TO -E ND Q O S
In this section, we deal with application and connection level QoS and briefly describe the issues in providing
end-to-end QoS. We also briefly describe the DiffServ mechanism for providing QoS in WiMAX networks.

A. Application level QoS and connection level QoS

In general, QoS in wireless networks is considered at two levels, i.e., at the application level and connection
level. Application level QoS is related to the perceived quality at the user end. A set of parameters, such as
delay/delay jitter, error/loss and throughput, etc., are used to describe application level QoS. Efficient packet access
and packet scheduling schemes play key roles in solving these QoS problems. Connection-level QoS is related to
connection establishment and management. It measures the connectivity and continuity of service in a wireless
network, mostly by two parameters: the new-call-blocking probability, which measures service connectivity, and
the handoff-dropping probability, which measures service continuity during handoff. For a mobile user, dropping an
ongoing call is generally more unacceptable than blocking a new call request. Therefore, minimizing the handoff-
dropping probability is usually a main objective in the wireless system design. On the other hand, the goal of a
network service provider is to maximize the revenue by improving network resource utilization, which is usually
associated with minimizing the new-call-blocking probability while keeping the handoff dropping below a certain
threshold.
Connection level QoS is influenced by call admission control (CAC). In cellular wireless networks the utilization
of system resources by new calls is often kept below a threshold level to accommodate handoff connections because
service providers are obligated to provide a minimum QoS to subscribers even as they aim to maximize bandwidth
utilization. Thus, when a mobile SS engaged in a call is handed off to a new cell, it may receive a higher priority for
channel allocation by the new BS than new calls originating in the cell. Even with resource reservation, connections
can still be dropped due to fluctuations in the received SINRs at the mobile SSs, especially for those located near
the edges of cells. To handle a multiservice WiMAX access network, it is very important to employ the CAC
mechanism. First, CAC is a crucial step for the provision of QoS guaranteed service, because it can prevent the
system capacity from being overused. Second, CAC can help WiMAX access network to provide different types of
traffic load with different priorities by manipulating their blocking probabilities. To carry out the admission control
for each subscribers local network, a CAC manager can be placed in a WiMAX base station. The CAC manager
knows the uplink/downlink bandwidth capacity of any subscriber k from other modules in the same base station.
When an application in subscriber k ’s local network initiates a connection to the Internet, it sends connection request
to the CAC manager with upstream bandwidth requirement bU and downstream bandwidth requirement bD . Then
the CAC manager commits admission control check on both uplink and downlink. In this respect, the call admission
control in WiMAX access network is a two-dimensional CAC problem. The two-dimensional CAC problem can
be decomposed into two independent one-dimensional problems namely uplink CAC policy and downlink CAC
policy to make admission tests on both the uplink and downlink separately, and only the connection request passing
both admission tests is admitted finally. In general, uplink traffic is only a fraction of the downlink traffic in
most applications. Hence, downlink admission control plays a more important rule than uplink admission control.
Depending on whether minimizing new-call-blocking probability or minimizing handoff-dropping probability is the
objective, we can design CAC algorithms to achieve the desired objective.

B. Issues in providing end-to-end QoS

The links between intermediate nodes of an end-to-end call may use a variety of layer 2 technologies, such
as ATM, frame relay, and Ethernet, each of which may have its own methods to provide QoS. Since WiMAX is
envisioned to provide end-to-end IP services and will likely be deployed using an IP core network, IP QoS and its
interaction with the wireless link layer are what is most relevant to WiMAX network performance.
Resource limitations in the network is what makes providing assurances a challenge. Although typically, the
most-constrained resource is the wireless link, the other intermediate nodes and links that have to be traversed for
an end-to-end service also have resource limitations. 1 Each link has its own bandwidth-capacity limits, and each
node has limited memory for Over-building the network to provide higher bandwidth capacity and larger buffers
is an expensive and inefficient way to provide quality, particularly when the quality requirements are very high.
Therefore, more clever methods for providing QoS must be devised and these methods must take into account
the particular needs of the application or service and optimize the resources used. Different applications require a
different mix of resources. For example, latency-intolerant applications require faster access to bandwidth resources
and not memory, whereas latency-tolerant applications can use memory resources to avoid packets being dropped,
while waiting for access to bandwidth resources. This fact may be exploited to deliver QoS efficiently. In short, a
QoS-enabled network should provide guarantees appropriate for various application and service types while making
efficient use of network resources.
Ensuring end-to-end QoS requires mechanisms in both the control plane and the data plane [7]. Control plane
mechanisms are required to allow the users and the network to negotiate and agree on the required QoS, identify
which users and applications are entitled to what type of QoS, and let the network allocate the resources accordingly,
to each service. Data plane mechanisms are required to enforce the agreed-on QoS requirements by controlling the
amount of network resources that each application/user can consume.
The WiMAX network bearer consists of a wireless bearer and an IP transmission bearer. The former provides
a wireless access service by the IEEE 802.16 mechanism, and the IP bearer deploys DiffServ and MPLS (Multi-
Protocol Label Switching) and so on, to guarantee QoS. Traditional IP networks were designed for best-effort data
and did not include any provision for QoS. Some form of QoS can be provided by relying on different end-to-end
transport protocols that run over IP. For example, TCP ensures that data packets are delivered end-to-end reliably.
For ensuring end-to-end latency and throughput, QoS mechanisms need to be in place in the network layer, and
traditional IP did not have any. One mechanism for ensuring IP QoS is via Diff Serv (Differentiated Services)
architecture.

C. DiffServ and 802.16 service mapping

Diffserv is an IP layer QoS mechanism, whereby IP packets are marked with diffserv code points at the network
point of entry and network elements enforce relative priority of packets based on their code points. The diffserv
methodology allows network resources to be reserved for classes of traffic, rather than for individual flows. DiffServ
defines a number of service classes and QoS mechanisms that are applied to packets in those service classes (called
Per Hop behaviour or PHB). The DiffServ Code Point (DSCP) is located in the IP packet header and is used to
determine the PHB. The standard PHB-s each have a unique DSCP associated with them. The DSCP is used to
determine the respective DiffServ behaviour the packet is to receive. Different types of applications have different
traffic characteristics and require different QoS behaviours to be applied to them. The different DiffServ classes
are Expedited Forwarding (EF) Class, Assured Forwarding (AF) Class, Class Selector (CS) and Default DiffServ
Class.
Mapping between between DiffServ and UMTS network should take place when the IP network and UMTS
networks are interconnected. A similar method for mapping between DiffServ and WiMAX should also be devel-
oped. Mapping to DiffServ classes: UGS class requires a fixed amount of service. ertPS and rtPS can be mapped
to Expedited Forwarding (EF) DiffServ. nrtPS can be mapped to Assured Forwarding (AF) while best effort can
be either mapped to the AF or default DiffServ behaviour.
In the context of the WiMAX air link, IP diffserv mechanism can be used to enforce priorities for packets within
a service flow, or to establish service flows based on diffserv classes for a given subscriber. As an example, a single
pre-provisioned service flow for a subscriber can be used to carry multiple types of traffic, with relative precedence
established based on diffserv code points. On the other hand, service flows MAY be established dynamically to
carry different diffserv traffic classes. An example of this is the establishment of a UGS service flow dynamically
to carry a voice call, where the voice traffic is marked with diffserv EF class. In the first case above, the diffserv
code points are used to prioritize and schedule packet transmission within a service flow. The manner in which
this is done is a matter of local implementation in the BS and the SS, subject to the prioritization rules of diffserv.
In the second case, the diffserv code point is used to classify packets onto separate service flows. This scenario
occurs when packets entering the BS or the MS are already marked with diffserv code points by an application or
some prior network entity.
ertPS and rtPS services can be mapped to the EF DiffServ Class. nrtPS can be mapped to the AF based on the
emission priority, discard priorities and their minimum requirements. BE can be mapped to either the AF class
or the Default DiffServ Class. A similar procedure is used in [8] to perform the mapping between UMTS service
classes and DiffServ traffic classes.

V. C ONCLUSION
We provided a brief description of QoS in LTE and the 802.16 traffic classes and the extension of IEEE 802.16
QoS framework to WiMAX QoS architecture. In LTE the EPS provides UEs with IP connectivity to the packet data
network. The EPS supports multiple data flows with different QoS per UE for applications that need guaranteed delay
and bit rate such as VoIP as well as best effort web browsing. The EPS network architecture, EPS bearers, together
with their associated QoS attributes provide a powerful framework for the provision of a variety of simultaneous
services to the end user. From the perspective of the network operator, the LTE systems is also breaking new ground
in terms of its degree of support for self-optimization and self-organization of the network via the X2, S1 and Uu
interfaces, to facilitate deployment. In LTE, each logical channel has a corresponding QoS description which should
influence the behavior of the eNodeB resource scheduling algorithm. Based on the evolution of the radio and traffic
conditions, this QoS description could potentially be updated for each service in a long-term fashion. It is likely
that the mapping between the QoS descriptions of different services and the resource scheduling algorithm in the
eNodeB will be a key differentiating factor between radio network equipment manufactures. In a heterogeneous
networking environment, guaranteeing end-to-end QoS will invite special challenges. It includes among other issues,
mapping of the QoS attributes of the access and core networks to the QoS class identifier values of the applications,
and design of suitable inter-working and inter-operating (I&I) elements in the gateways
WiMAX NWG Release 1.0.0 specification supports only a static QoS model based on the concept of preprovi-
sioned service model. Extensions are required in the Release 1.0.0 to support dynamic creation, modification and
deletion of service flows. New system profile features are needed to enable advanced services such as location-based
services and multicast-broadcast services. In addition, MAC layer efficiency has to be improved by reducing the
MAC layer overhead. The next generation of mobile WiMAX is expected to provide flexible deployment solutions
such as multi-hop relay, femtocell, and multicarrier support as well as optimized coexistence and interworking with
other access technologies such as WiFi and 3G systems. In addition, flexible spectrum deployment is desirable.
MAC layer efficiency has to be improved by lowering the MAC overhead especially for applications such as VoIP
traffic.
There are many issues with ensuring end-to-end QoS. QoS needs to be considered at different levels, namely the
application level and connection level. Mechanisms are required to ensure that the QoS is met at the different levels.
In addition, the links between intermediate nodes of an end-to-end call may use a variety of layer 2 technologies
and proper mapping mechanisms between the QoS of the different layer needs to be developed. Ensuring end-to-end
QoS also requires mechanisms in both the control and user plane. One method of ensuring IP QoS is via Diff-Serv.

R EFERENCES
[1] IEEE 802.16: IEEE Standard for Air Interface for Broadband Wireless Systems, June 2008.
[2] P. Taaghol, A. K. Salkintzis, and J. Iyer, “Seamless integration of mobile WiMAX in 3GPP networks,” IEEE Communications Magazine,
vol. 46, no. 10, pp. 74–85, October 2008.
[3] H. Ekstrom, “QoS control in the 3GPP evolved packet systems,” IEEE Communications Magazine, vol. 47, no. 2, pp. 76–83, February
2009.
[4] R. Ludwig, H. Ekstrom, P. Willars, and N. Lundian, “An evolved 3GPP QoS concept,” in IEEE Vehicular Technology Conference, vol. 1,
May 2006, pp. 388–392.
[5] 3GPP TS 23.203 V8.3.1, Technical Specification, Policy and charging control architecture (Release 8).
[6] WiMAX Forum Network Architecture, Stage 2: Architecture Tenets, Reference Models and Reference Points, January 2008.
[7] J. G. Andrews, A. Ghosh, and R. Muhamed, Fundamentals of WiMAX, Understanding Broadband Wireless Networking. Prentice Hall,
2007.
[8] S.Maniatis, E. Nikolouzou1, I. Venieris, and E. Dimopoulos, “Diffserv-based traffic handling mechanisms for the umts core network,”
in IST Mobile and Wireless Telecommunications Summit, June 2002.