Thực hiện chất lượng dịch vụ trong các mạng IP (P5)

5
Mapping Service
Requirements to
Network Resources
The ability to properly map services to network resources in a
multi-service network is highly important both for making the
initial configuration of a network domain, and also as a basis for
performing network configuration optimization. The basic task in
both cases is the same, although in the latter case there is an initial
configuration to start with, as well as potentially a larger number
of existing boundary conditions for the new configuration.
Resource allocation is an optimization problem where the avail-
able network resources, SLAs for different parties, and require-
ments of service types are examples of boundary conditions. The
SLA interfaces relevant to resource allocation are illustrated with
an example configuration in Figure 5.1. The responsibility of end-
to-end service quality can be thought to be by default with service
providers, who use SLAs towards network transport providers to
implement the service quality. Alternatively, an access network
operator may provide a set of services from outsourced Applica-
tion Service Providers (ASPs), such that the access network oper-
ator is responsible for end-to-end service quality.
There may be more than one service provider involved, for
example, in using IP telephony services in such a way that the
Implementing Service Quality in IP Networks Vilho R
¨
ais
¨
anen
 2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X
134 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES

SLA
SLA
SLA
SLA
SLA
SLA
Service
subscriber
Service
operator
Transport
operator
Service
operator
Transport
operator
Service
subscriber
Figure 5.1 SLA reference model for the present chapter
caller and callee use different IP telephony service providers. In
the general case, there may be also transit operators involved.
As to services, both external service operator/transport operator
and operator-internal service/transport interfaces are illustrated
in Figure 5.1. In general, there is no need to have a one-to-one
relationship between service and transport operators.
Available network resources are the most limiting factor when
service mapping in multi-service access networks is considered.
This is true not only when the network infrastructure already
exists, but also when a new network is being built. In backbone
networks, on the other hand, more conservative network dimen-

sioning is typically possible due to higher flow aggregation levels.
The generic traffic engineering process described in the last chap-
ter can be used to optimize the use of the available resources in
both access and backbone networks, but the starting point for this
optimization is the initial resource allocation. When traffic engi-
neering process can be applied, requirements for the accuracy of
the initial configuration become smaller. When the traffic volumes
transported in the network domain are anticipated to grow with
time, dimensioning of a new network infrastructure usually takes
into account future growth in traffic volumes. Also in this case,
the initial configuration is not as critical as for a fully loaded
multi-service access network. The goal should nevertheless be as
precise as possible a resource allocation, starting from the antici-
pated shares of traffic types.
SLAs for direct end user customers can provide flexibility for
resource allocation, if SLAs include traffic types that can be
used for this purpose. The SLAs for different customer segments
and services may be different with respect to degree of details
of service quality support provided. As discussed in Chapter 2,
for services with stringent quality support requirements such as
5.1 SCOPE OF THIS CHAPTER 135
multimedia conferencing, absolute guarantees may be necessary.
On the other hand, for data type services, statistical guarantees
may be sufficient. A change of admission control policy to demand
service quality types is a tool that can be used to control the
resource allocation in access networks when the service quality
invocation procedures allow for this.
Towards the service and network providers, the SLAs are typi-
cally more static. The resource allocation optimization and applica-
tion of the traffic engineering process may result in a need to mod-

ify the SLAs, but this typically takes place at longer timescales than
one associated with resource management for the operator’s own
end user services. Thus, it could be said that the traffic engineer-
ing process should also yield an indication of its means becoming
exhausted, being indicative of a need to modify SLAs or by other
means restore the operational efficiency of traffic engineering.
5.1 SCOPE OF THIS CHAPTER
Chapter 2 described the intrinsic requirements of services and
their characterization. Chapters 3 and 4 described mechanisms for
providing service quality support in the network. This chapter
deals with the link between service requirements and IP network
service quality support. The concepts in this chapter are used in
discussing service management in the next chapter. Let us next
define the reference model for this chapter.
For the purposes of the present chapter, the end-to-end delivery
path for service instances is assumed to consist of multiple trans-
port operators, each capable of providing support for service quality
for a set of services, either statistically on the level of behavioural
aggregates or per flow (cf. Figure 5.1). It is further assumed that
each transport operator is capable of providing multi-service sup-
port. Each transport operator is assumed to be using a per-domain
service quality support mechanisms independently of each other.
The actual mechanisms can be circuit-switched guaranteed QoS
for telephony, over-dimensioning, or DiffServ, to name but a few
alternatives. The resource allocation discussion in this chapter per-
tains to a multi-service DiffServ domain specifically, and thus is
most directly related to access networks.
Services are assumed to be managed by service operators by
having Service Level Agreements (SLAs) with end users, with
136 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES

transport operators and between each other, as necessary. A
transport operator may also be a service operator, in which
case the service operator/transport operator interface is an
operator-internal one. Referring back to the client/server and
connectivity/service paradigms used in Chapter 2, the model
of Figure 5.1 is of latter type, allowing for signalled inter-
operation of service providers for a single service instance. The
client/server application of Figure 5.1 could only involve single
service subscriber, single service operator, and one or more
transport operators.
For the service provider, service quality provision is at best
related to the intrinsic quality requirements of individual service
event types. Depending on the SLA type, the service provider may
also need to understand service quality support mechanisms of the
transport operators. For the transport operator, on the other hand,
one part of the optimization problem is allocation of services to
proper service quality support classes. This is a part that the ser-
vice provider may need to understand, unless the SLA between
the service provider and transport operator is sufficiently detailed
for the service operator not to need worry about technical details
of the service quality support details.
A second aspect of the transport operator optimization relates
to using resources effectively to implement multi-service SLAs for
different parties involved. Efficient resource usage includes select-
ing an optimal set of supported service quality aggregates, and
using network resources to implement SLAs using the aggregates.
Here, it is assumed that the service provider and the transport
provider are able to negotiate the behavioural aggregate used for
service quality support.
In the discussion below, the SLAs for service providers are con-

ceptually seen as boundary conditions for the resource allocation
of the transport operators’ own end user services, the basic process
and target of resource allocation being the same for both types of
traffic aggregates. For operators’ own services, there is no need to
take into account an external negotiation interface towards differ-
ent business party, which is why they are used for simplicity in
the discussion below.
Next we shall review service quality support-related resource
allocation models from ETSI EP TIPHON, Third Generation
Partnership Project (3GPP), and QoS Forum. Two further DiffServ-
related examples are provided due to their relation to policing, one
5.2 ETSI EP TIPHON REFERENCE MODEL 137
of them being draft ITU-T model. After that, the concept of utility-
based resource allocation is reviewed. The TIPHON reference
model is relevant to IP telephony, that of 3GPP to mobile services,
while the QoS Forum and ITU-T models and utility-based resource
allocation reference models are generic in nature. The concepts
from these models are used in formulating a generic framework
for resource allocation for multi-service IP network.
5.2 ETSI EP TIPHON REFERENCE MODEL
The European Telecommunications Standardization (ETSI) is an
organization making international telecommunications standards.
The best-known ETSI standards are probably GSM and UMTS.
During the latter half of the 1990’s, ETSI founded the IP telephony
project TIPHON, which has devised a reference models for IP
telephony, in which service providers can be separated from trans-
port operators [TIPHON-3]. The model pertains to IP telephony
specifically, but is sufficiently generic to be used here. While some-
what abstract, it illustrates the logically necessary functions and
interfaces of a separated service/transport paradigm. Particularly

valuable for the present purposes, the ETSI TIPHON reference
model also includes a QoS reference model.
5.2.1 Architecture
The reference model consists of separated service and transport
layers, and is illustrated in Figure 5.2. The two-tier model allows
for telephony providers, using Session Initiation Protocol (SIP),
for example, to operate without having to build own transport
networks.
When a VoIP call is set up between the communicating parties,
the IP telephony service provider for the calling party sets up
the call by communicating with the service provider of the called
party, as necessary. The respective service operators at each end
set up necessary transport resources. As a result of the resource
set-up, the communicating hosts may be provided with a QoS
tokens to authorize the access to appropriate transport resources
[TIPHON-3].
138 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES
TRM TRMTRM
Telephone
Telephone
Transport
operator 1
Transport
operator 2
Transport
operator 3
Service
provider 2
Service
provider 1

Figure 5.2 ETSI EP TIPHON reference model
Note
: Solid lines denote the transport layer, dotted lines the service layer,
and dashed lines the link between service and transport layers
The reference model has been targeted to be “agnostic” with
respect to QoS mechanism used on the transport layer, and should
therefore work with ATM, IP QoS mechanisms including Diff-
serv and IntServ, and over-provisioning, for example. End-to-end
QoS requirements of services are dealt with by using QoS budgets,
so that the end-to-end service quality requirements are known,
broken down into per-service provider allocations and further to
transport level allocations. For example, the service provider 1 in
Figure 5.2 is supposed to be able to calculate how much delay and
packet loss is allowable in transport operator 1’s domain. Service
provider 1 would then communicate this requirement to Transport
Resource Manager (TRM) within transport operator 1’s domain to
check whether the necessary service quality support can be imple-
mented by the transport operator. The per-domain allocation does
not have to be statically allocated for a particular path, but can
also be dynamically negotiated. The QoS resource allocation may
be iterative and affect call routing. As has been seen in previous
chapters, the properties of the terminals potentially affect end-to-
end service quality. In the TIPHON work, this has been taken into
account by classifying the terminals according to their impact to
end-to-end service quality.
There is no need to have one-to-one correspondence between
service and transport operators in TIPHON’s model. In Figure 5.2,
Service Provider 2 has service quality support signalling interface
to two transport operators along the end-to-end path. In fact, there
need not be QoS interface from a service operator to each transport

operator at all, but service quality support signalling can take place
between transport operators. The QoS reference model [TIPHON-
3] also contains exemplary signalling charts for different inter-
working scenarios. One signalling mode shown therein performs
5.2 ETSI EP TIPHON REFERENCE MODEL 139
Table 5.1 Functional elements of the TIPHON QoS control model
Element Layer Description
QoS Service Manager
(QoSM)
Service layer Mediates requests for
end-to-end QoS based on
policies stored in QoSPEs,
communicating with other
QoSMs and TRMs.
QoS Policy Element
(QoSPE)
Service layer Manages service QoS policies
and authorization.
Transport Resource
Manager (TRM)
Transport layer Applies set of policies and
mechanisms to transport
resources to provide QoS
guarantees across the
domain controlled by the
TRM.
Transport Policy Entity
(TPE)
Transport layer Functional entity maintaining
the policies of a transport

domain.
Transport Function (TF) Transport layer Logical entity representing
the transport resources in
the domain.
Interconnect Function
(ICF)
Transport layer Entity for interconnecting
transport domains;
typically AD boundary
with optional flow
authorization policies.
the end-to-end resource allocation set-up signalling entirely on the
transport layer, initiated by communication endpoints (terminals).
All told, TIPHON’s QoS model includes the elements listed
in Table 5.1. QoS Service Managers handle the end-to-end service
quality including QoS budget negotiations and interfacing to the
transport layer, based on service layer policies. Instantiation of ser-
vice quality on transport layer is controlled by Transport Resource
Manager, which can operate on aggregate level or flow level. When
IntServ is used end-to-end, service quality signalling takes place
between TRMs and terminals.
In TIPHON’s QoS control model, the service and transport lay-
ers are logically separated from each other. Due to this, they have
sets of policies that operate on different conceptual levels. The
140 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES
policies of the service domain relate to authorization of service
instantiations, whereas the policies of transport domain pertain to
authorization of flows to classes of resources.
The TIPHON QoS reference model lists three ways of allocating
QoS budgets across transport domains:

• Dynamic signalling of transport QoS parameters during call
set-up.
• Static SLAs between service domains.
• Aggregation of transport domain resources and caching infor-
mation of QoS resource availability.
Per-call signalling is akin to per-flow RSVP reservations, and has
similar kinds of scalability concerns associated with it. Particularly
in IP telephony, the delay due to resource set-up is also important.
Static SLAs between different parties is the simplest model. An
elaboration of this allowing for more flexibility is the third model,
in which admission control is performed to available resources
between operators.
5.2.2 QoS model
The TIPHON QoS model is illustrated in Figure 5.3, consisting
of QoS characterizations on the user layer, application layer, and
TIPHON Voice QoS Class
USER
Codec, Frames per Packet, Frame Size, Jitter Buffer Delay,
FEC (Redundancy), Overall One-Way Delay,
Packet Loss
APPLICATION
TRANSPORT
Packet Loss, Mean Delay, Delay Variation
Figure 5.3 QoS characterization of user, application, and transport levels
in the TIPHON reference model
Source
:From[TIPHON-3]
5.2 ETSI EP TIPHON REFERENCE MODEL 141
transport layer. QoS characterization on user layer consists of the
TIPHON voice QoS class, having five possible values: wideband,

narrowband high, narrowband medium, narrowband acceptable,
and best effort. Subscribers can choose between these classes based
on associated pricing and quality attributes. The voice QoS class
can also be a part of the subscription profile.
Mapping of user layer QoS characterization to application layer
characterization is performed by interpreting the voice QoS class
in technical terms. The actual parameters involved depend on the
outcome of end-to-end codec negotiation. In SIP, this is performed
using the Session Description Protocol (SDP) during call set-up.
For example, the negotiated parameters could include the codec
to be used (for example, AMR, GSM FR, G.723.1, G.711) and the
bit rate for the codec (ranging from 4.75 to 12 kbit/s for AMR).
QoS characterization on the transport layer, that is, the service
quality support that a transport operator needs to be able to pro-
vide, are derived from two sources:
1. Application quality characterization.
2. End-to-end QoS budget.
The two are not independent, as the end-to-end QoS budget may
be used in negotiating the application parameters (codec). The
choice of codec and audio sample size affect the end-to-end delay.
The relation between end-to-end delay and end user experience
used by TIPHON is shown in Figure 5.8 in Section 5.7.4.
5.2.3 Summary
In ETSI TIPHON IP telephony reference model, the end-to-end
negotiation is performed under control of service layer operators,
and involves one or more transport operators. The service operator
performs the mapping from service quality to transport resource
requirements. The TIPHON QoS model consists of a subscription,
codec, and transport levels, addressing the different abstraction
levels that can be used in telephony. The transport operator uses a

logical transport resource management element to perform admis-
sion control to available resources.
The weakness of the original TIPHON QoS model is the amount
of per-flow signalling associated in admission control of a new
142 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES
flow: at least one of the service operators was supposed to signal
to one or more transport operators to ensure appropriate service
quality support for the flow. When more than one service provider
is involved in the end-to-end set-up, handling all scenarios arising
from each operator using service quality support signalling with
the transport operator or operators, call set-up delay can quickly
become prohibitively large in such cases. The concept of perform-
ing admission control to traffic aggregates was incorporated into
the TIPHON model as a further mode, having better scalability
properties. We shall return to the topic of admission control to
aggregates in Chapter 8.
5.3 QBONE
Internet2 project is a partnership to develop inter-domain ser-
vice quality support for the Internet, led by US universities and
participated in by a number of corporations and other organi-
zations [THD + 99]. Distance learning, remote instrument access
and control, advanced scientific visualization and networked col-
laboration are listed as potential uses for service quality support
in the future Internet. Internet2 addresses the following areas:
applications, middleware, advanced networks, engineering, and
partnerships. QBone is the QoS testbed of Internet2 to address
the needs such as those listed above, and has been attended to
by a number of network service providers. To quote the Internet2
website ():
The goal of the QBone is to provide an inter-domain test bed

for differentiated services (DiffServ), where the engineering,
behaviour, and policy consequences of new IP services can
be explored.
The goal of QBone is to use IETF standards to implement inter-
domain architecture. More precisely, each QBone node is required
to support Virtual Leased Line (VLL) emulation using Expedited
Forwarding (EF). This service support mode is called QBone
Premium Service (QPS), and will be described in Section 5.3.1.
Network elements are required to support the configuration that
makes VLL service possible.
Inter-domain interworking for DiffServ in QBone paradigm can
be implemented by SLAs and Service Level Specifications (SLSs),
5.3 QBONE 143
the latter being the technical part of the SLAs. The inter-relation
of SLAs and SLSs will be discussed in more depth in the next
chapter, and for present purposes it is sufficient to know that since
SLAs/SLSs exist at the boundaries of the domains, they can at
their simplest be based on bilateral agreements between network
operators. The QBone architecture aims to provide added value
to end-to-end DiffServ + SLA/SLS architecture with enhanced
support for dynamic inter-domain operations. The goal is to
specify a common set of operational practices and procedures
to be followed by network operators. Bandwidth Brokers (BBs)
are viewed as tools for making automated admission control
decisions, network device configurations, and dynamic inter-
domain SLAs. Bandwidth brokers will be discussed further in
Chapter 8.
For present purposes it is sufficient to know that static SLAs
can be viewed as a special case of dynamic bandwidth broker
paradigm, and that neither SLA negotiation between domains

nor admission control towards end system necessarily have to be
automatic. Thus, the bandwidth broker – at most general – is a
conceptual device in discussing resource management.
A further requirement is an integrated measurement infrastruc-
ture with hooks provided for supporting end-to-end debugging
and auditing by users, network operators, and implementers.
Both active and passive measurement data may be collected for
this purpose and preferably shared openly among participants.
5.3.1 Service support models
Within the QBone, each participating network is a DiffServ
Domain that inter-operates with other QBone networks to provide
the end-to-end QBone services. Two separate “service models”
have been devised, the first of which must be supported by all
QBone domains. Within the terminology of the present book, the
two models would be better termed service support models.
1. QBone Premium Service (QPS): QPS is a low-delay, low-jitter, and
low-loss service based on the DiffServ EF model. Token bucket
profiler on the network edge configured with token bucket
parameters including peak rate, and bucket depth of MTU
bytes. The following definition is from the Internet2 website:
144 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES
QPS is based on reservations for token bucket parameters in
DiffServ network. A QPS reservation makes a simplex, peak-
limited bandwidth assurance. The extent of a QPS reserva-
tion may be entirely within a QBone domain, from one edge
of a QBone domain to another edge of the same domain, or
through multiple QBone domains and is defined by a service
source and service destination, each of which is, in general,
defined by a network prefix.
A QBone reservation consists of the following data [THD + 99]:

source, destination, route, starting time, ending time, peak rate,
MTU, and jitter. Requirements for QBone SLS are listed, includ-
ing SLS components such as the Traffic Conditioning Specifica-
tion (TCS).
2. Alternative Best Effort (ABE): ABE provides a low bounded queu-
eing delay service in the Internet, while still being best-effort,
and requiring no additional charging or usage control. To quote
the Internet2 website,
[G]oal [of ABE] is to help applications with stringent real
time constraints, such as interactive audio. With ABE, it is not
required to police how much traffic uses the low delay capa-
bility, the service being designed to operate equally well in
all traffic scenarios. Applications choose between receiving a
lower end-to-end delay and receiving more overall through-
put. Every best effort packet is tagged as either “green” or
“blue”. “Green” packets receive a low, bounded queueing de-
lay. To ensure [that] “blue” packets do not suffer as a result,
“green” flows receive less throughput [than blue flows] dur-
ing bouts of congestion.
Green versus blue marking differentiates between traffic
types, which are affected by per-packet latency values and
those, affected only by the overall throughput. Examples
of applications using the green and blue markings are IP
telephony and web browsing, respectively. The two service
types of ABE do not map directly to standardized AF or EF
Per-Hop Behaviours.
5.3.2 Summary
The QBone reference model is an end-to-end model for transport
network service quality support means for single-domain as well
5.4 3GPP QOS MODEL 145

as multi-domain case. The model addresses network service qual-
ity support modes and mechanisms, and service mapping is not
addressed, apart from the service quality support models pro-
vided. Two such service models are provided: obligatory QPS,
and tentative ABE.
QPS provides low-delay, low-jitter, and low-loss service quality
support. QPS requires policing, and is based on one-way reser-
vations of capacity using the token bucket paradigm within one
or more domains. QPS can be implemented with the EF PHB
of DiffServ.
ABE provides the possibility of trading overall throughput for
low delay service. ABE does not require policing at the network
edge. ABE does not map directly to standard DiffServ PHBs.
In its simplest form, the end-to-end QBone model can be imple-
mented with DiffServ within each domain with bilateral SLA/SLS
agreements between operators. QBone is studying bandwidth bro-
kers as a tool for admission control to network resources, as well
as for dynamic inter-domain SLAs.
5.4 3GPP QOS MODEL
General Packet Radio Service (GPRS) was designed to make ac-
cessing of packet-oriented services better integrated with the cel-
lular network than is the case in circuit data of GSM. The first
GPRS standard version (release 97) supports circuit-switched (CS)
telephony, CS data as well as packet-switched (PS) data traffic.
The communication between a GPRS terminal and another IP-
addressable device (another mobile terminal or an Internet server,
for example) takes place using a Packet Data Protocol (PDP) con-
text, having QoS parameters associated with it. From the point
of view of end user IP communication, GPRS Gateway Support
Node (GGSN) at the edge is the access router used by the mobile

terminal, and PDP context hides most mobility-related functions
from endpoints of end user IP communication.
The GPRS R 97 QoS profile defines the following requirements
for the service: delay, service precedence, reliability, mean
throughput, and peak throughput [KP01]. Of these parameters,
delay means end-to-end delay, service precedence means roughly
drop precedence, and reliability defines which degree of loss the
service can tolerate. The QoS parameters are used in the GPRS
146 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES
radio interface to select a the radio priority, and in the GPRS core
network to select adequate core network QoS parameters.
The Universal Mobile Telephone System (UMTS) specification of
ETSI’s Third Generation Partnership Program (3GPP) is an exten-
sion of the GPRS paradigm to support Wideband Code Division
Multiple Access (WCDMA) radio interface, including a more ad-
vanced QoS model. The 3GPP QoS model provides support for
service quality differentiation for generic real-time and interactive
services, in addition to voice and data. This is accomplished by
defining UMTS bearers for radio access and core network, which
support not only the specification of priority and bandwidth type
of parameters, but provide for a richer set of service quality sup-
port requirement specifications. PDP context is the unifying link
for QoS across different bearers. In the terminal, a sufficient Appli-
cation Program Interface (API) between applications and the oper-
ating system is assumed to exist to request service quality support.
A simplified overview of protocol stacks of 3GPP architecture is
shown in Figure 5.4. Note that radio access bearer and IP bearer
provide service quality support for user layer traffic (end user
IP flows) “from below”, whereas service quality interworking to-
wards external Internet takes logically place on user layer.

5.4.1 QoS model
The interested reader can find a longer account of 3GPP QoS
model in [KP01], only a short description being given here. Net-
work architecture for UMTS is shown in Figure 5.4. As with GPRS,
each user flow is mapped in to a PDP context.Oneoftheproper-
ties of the PDP context is traffic class, being one of the following
four types:
Radio tunnelling
RAB
Link
GTP
ATM
Link
GTP
ATM
Link
GTP
IP
Link
Terminal
Application
Radio tunnelling
RAB
Link
User IP layer
Base transceiver station
& radio network
controller
Serving GPRS support
node

Gateway GPRS support
node
Link
GTP
IP
Link
User IP layer User IP layer
Figure 5.4 Release 99 UMTS architecture protocol stacks
Note
: The protocol architecture has been simplified
5.4 3GPP QOS MODEL 147
1. Conversational class. This service class has been designed for
interactive real-time communications such as voice or multime-
dia telephony, which has strict limits for end-to-end delay.
2. Streaming class. This service class is suitable for non-urgent
real-time services that can tolerate longer delay than conversa-
tional class applications.
3. Interactive class is suitable for interactive data-type services
such as browsing the Internet. Interactive class traffic is typ-
ically prioritized with respect to background class.
4. Background class.
In addition to the traffic class, the QoS profile associated with a
PDP context includes the parameters listed below in Table 5.2. Not
all of them are applicable to all traffic classes.
The QoS profile parameters of the PDP context are used in map-
ping to bearers. The Radio Bearer (RB) is used in the radio inter-
face, and the bearer between mobile and SGSN is called upwards is
called Radio Access Bearer (RAB). In the transport network, user
layer traffic is transported by GPRS Tunnelling Protocol (GTP)
tunnelling using either ATM or IP transport. The corresponding

bearer is called core network (CN) bearer. Protocol stacks relating
to different bearers are illustrated in Figure 5.4. While the proto-
col stacks in the radio access and transport networks seem a bit
complicated, they provide the end user flows with the abstrac-
tion layer of bearer to implement the PDP context service quality
requirements and hide mobility from communication endpoints.
Table 5.2 QoS profile para-
meters in 3GPP framework
Maximum bit rate
Guaranteed bit rate
Maximum service data unit
SDU size
SDU format information
SDU error ratio
Residual bit error ratio
Delivery of erroneous SDU
Delivery order
Transfer delay
Traffic handling priority
Admission/retention
Priority
148 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES
The QoS requirements of the PDP context are signalled end-to-
end inside the mobile network and mapped to appropriate bearer
parameters. The desired QoS properties are then implemented
using appropriate bearer mechanisms in radio and mobile net-
work domains. The full 3GPP QoS architecture involves multiple
levels of bearers which are omitted here.
For Interactive class, Traffic Handing Priority (THP) provides
finer granularity, having three possible values. The significance

of this parameter is as follows: as measured end-to-end, an inter-
active traffic class flow with THP1 receives, on average, lower
end-to-end delay than interactive traffic class flow with THP2. A
similar relation exists between THP2 and THP3. Traffic handling
priorities can be thought of as roughly corresponding to delay
classes in the GPRS QoS model.
5.4.2 Summary
The 3GPP architecture is designed to support telephony
and packet-based services for wide-area cellular access. The
architecture uses IP transport in packet core between mobility
servers, and service quality interworking on the Internet can be
implemented by SLA-type mapping from CN bearer to external
mechanism at the edge of the mobile network.
The 3GPP QoS model encompasses four traffic classes, providing
quality support for basic service categories, including telephony,
streaming, browsing, and background data transfer.
An extension of basic 3GPP architecture is reviewed briefly
above, Chapter 9 will use IP-based RAN as a case study to apply
the conceptual framework developed in this book.
5.5 OTHER MODELS
The authors of [MNV02] consider a DiffServ-based architecture
with the following service quality support classes: premium
constant bit rate, premium variable bit rate, premium multimedia,
premium mission critical, and best effort. The first two for the
service quality support classes are meant for UDP, and the next
two for TCP. The service quality support classes have been
designed with interoperability of 3GPP traffic classes in mind,
5.6 UTILITY-BASED ALLOCATION OF RESOURCES 149
and the authors present an example mapping between the two
service quality support models. According to the authors, the

service model can be implemented with a combination of priority
queueing (PQ) and WFQ, with tail-drop, RED and WRED as
possible mechanisms for buffer management. Token bucket is used
for peak rate policing in premium constant bit rate model, and in
premium variable bit rate model, two token buckets are used for
policing both sustainable and peak rate. For TCP traffic, policing
is done with a single token bucket with “downgraded” DSCP
marking for out-of-profile traffic.
In ITU-T’s draft specification [Y.1221], three service quality sup-
port models called IP transfer capabilities are defined.
• Dedicated bandwidth transfer capability (DBW) is suitable for
services with stringent delay requirements. Parameters to be
controlled are peak rate, token bucket size, and maximum
allowed packet size. Out-of-profile packets may be discarded.
• Statistical bandwidth transfer capability (SBW) is intended for
applications with no stringent delay requirements. Control
parameters are peak rate, peak rate bucket size, sustainable rate,
sustainable rate bucket size, and maximum allowed packet size.
Traffic above sustainable bit rate but within peak bucket traffic
will be delivered.
• Best Effort transfer capability (BE): no guarantees provided.
In [Y.1221], congestion and overloading control are performed
with packet discarding control as well as potentially using Explicit
Congestion Notification (ECN).
5.6 UTILITY-BASED ALLOCATION OF RESOURCES
The previously reviewed schemes for provisioning of service
quality support with network resources have stemmed mainly
from a service quality requirement viewpoint, without directly
taking into account the operator’s business objectives. Next, we
shall discuss the concept of resource allocation performed based

on utility, where such objectives can be expressed by interpreting
utility as revenue.
For the purposes of this topic, let us assume a network
transport/service provider with a selection of supported services
provided for customers, as well as SLAs for other operators. This
150 MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES
scenario is suitable for illustrating the benefit of utility-based
allocation. The subject matter of this chapter, however, is also
useful for pure network transport operators, especially when
dynamic SLA mechanisms are used. Dynamic SLAs will be
discussed further in Chapter 8.
A generic formulation of utility-based allocation of resources
is as follows: maximize utility of service resource allocation sub-
ject to service quality requirements and total amount of resources
available in the network (see, for example, [PB01]). The variables
to adjust are the set of supported service types, {S
i
}, and the allo-
cated resources for each service type, {R
i
}. An oft-used example
for evaluating utilities of individual services is the utility curve,
assumed to be available for each service type. The utility curve
is often shown for bandwidth, whereby the curves for CBR VoIP
and WWW browsing – for example – could look like the example
in Figure 5.5. Utility for CBR VoIP deteriorates quickly below a
critical bandwidth limit, whereas the utility for browsing in the-
ory is a smoother function of the available bandwidth. From the
curve, one can immediately see that it is no use to provide a band-
width below the “step” threshold for a VoIP stream. The utility of

a browsing session, on the other hand, behaves more smoothly as
a function of the bandwidth.
The utility for a particular service type of Figure 5.5 is a function
of bandwidth, i.e.:
U = U (b), (5.1)
1 / Bandwidth
Utility
Figure 5.5 Utility curves for VoIP (dotted line) and WWW browsing
(dashed line)