The QoS solution in UMTS networks is developed by the following two phases:

Elementary QoS control

Figure 1 shows the elementary QoS control solution. In this solution, static basic QoS and
subscriber definition information are stored in the HLR.
Before the Policy and Charging Control (PCC) architecture is introduced, only the BSC/RNC,
SGSN, HLR, and GGSN are used during the QoS negotiation at the network side. The QoS is
seldom updated after the Packet Data Protocol (PDP) context is activated, and the session is
provided with fixed QoS.
Figure 1 Elementary QoS control solution

Advanced QoS control

Figure 2 shows the advanced QoS control solution. On the basis of static QoS, the PCC
architecture is introduced and the PCRF is added to store policy control information.
After the PCC architecture is introduced, the QoS negotiation becomes more flexible and
various functions are available, for example, time- or location-based differentiated charging, data
volume-based bandwidth control, and content-based differentiated operation.
Figure 2 Advanced QoS control solution

Implementation Principles
Principle for Elementary QoS Control
Figure 3 shows the QoS negotiation procedure in a typical UMTS network.

Figure 3 QoS negotiation procedure in a typical UMTS network

1-4: When the user equipment (UE) of a subscriber attaches to the network, the HLR inserts the QoS
information subscribed by the subscriber into the subscriber data and delivers the subscriber data to the
SGSN.
5: The UE sends an Activate PDP Context Request message carrying the requested QoS information to
the SGSN. The UE can also set the QoS parameter to 0 but does not provide the specific QoS
requirement in the Activate PDP Context Request message. The value 0 indicates that the UE uses the
default QoS on the HLR. In this case, the UE can use only non-real-time services.
6: The SGSN checks the QoS subscribed by the subscriber to determine whether the subscriber is
allowed to apply for the relevant QoS profile.

If the subscriber has subscribed to the QoS profile on the HLR and the SGSN has sufficient
resources, the SGSN sends a Create PDP Context Request message to the GGSN.

If the bandwidth and load resources of the SGSN are insufficient, the SGSN restricts the QoS
profile and reduces the QoS or rejects the Activate PDP Context Request message.

If the subscriber has not subscribed to the QoS profile on the HLR, the SGSN performs either of
the following operations based on data configuration:

Considers the subscription information as invalid and rejects the Activate PDP Context
Request message.

Uses the SGSN's current default QoS as the subscribed QoS.

7: After the GGSN receives a Create PDP Context Request message, the GGSN adjusts the QoS based
on its own resources and includes the negotiated QoS in a Create PDP Context Response message and
sends the message to the SGSN. Then, a GPRS Tunneling Protocol (GTP) tunnel is established between
the GGSN and the SGSN.
8: The SGSN notifies the RNC of the negotiated QoS and requests the RNC to establish a radio access
bearer (RAB).
9: The UTRAN where the RNC resides performs internal access control and resource reservation.

If the UTRAN has sufficient resources, the RNC sends a successful Radio Access Bearer
Assignment Response to notify the SGSN that the RAB is established.

If the UTRAN resources are insufficient, the RNC sends a failed Radio Access Bearer
Assignment Response to notify the SGSN that the requested QoS cannot be provided. After the
SGSN receives such a response, it decreases the QoS attribute based on the result contained
in the response and applies for RAB establishment again. The number of RAB re-establishment
attempts and the QoS value for each RAB re-establishment request can be configured.
10: After the RAB is established, the SGSN includes the negotiated QoS in an Activate PDP Context
Accept message sent to the UE. The UE then determines whether to use services.

If the UE accepts the negotiated QoS, the PDP context that meets relevant QoS requirements is
established between the UE and the GGSN.

If the UE cannot accept the negotiated QoS, it initiates the PDP context deactivation procedure.

Principle for Advanced QoS Control

As the PCC architecture (as shown in Figure 4) is introduced, the PCRF is added and the negotiation
between the GGSN and the PCRF (as shown in Figure 5) is also added to the QoS negotiation
procedure. The PCRF updates PDP contexts or service QoS according to service control requirements.
The QoS parameters used over the Gx interface are different from the QoS parameters used in the typical
UMTS network. The GGSN implements the mapping between these two sets of QoS parameters.

Figure 4 PCC architecture

Figure 5 shows the QoS negotiation procedure in the PCC architecture.

Figure 5 QoS negotiation procedure in the PCC architecture

Compared with the QoS negotiation procedure in the typical UMTS network, the QoS negotiation
procedure in the PCC architecture is added with the QoS negotiation between the GGSN and the PCRF
during PDP context activation, as shown in steps 7-8 in Figure 5. The specific QoS negotiation between
the GGSN and the PCRF is as follows:
The GGSN negotiates with the PCRF on the QoS based on the value of the upgrade QoS Supported
parameter in the Create PDP Context Request message sent from the SGSN.

If the upgrade QoS Supported parameter is not carried, the GGSN does not include this
parameter in a CCR message sent to the PCRF either. The PCRF considers that the QoS
upgrade is not supported by default and includes a low-level QoS in a CCA message sent to the
GGSN. The GGSN also includes a low-level QoS in a Create PDP Context Response message
sent to the SGSN.

If the upgrade QoS Supported parameter is 1, the SGSN supports the QoS upgrade. The
GGSN includes the QoS-Upgrade attribute-value pair (AVP) with the value set to
QoS_UPGRADE_SUPPORTED in a CCR message sent to the PCRF. The PCRF includes a
high-level QoS in a CCA message sent to the GGSN. The GGSN also includes a high-level QoS
in a Create PDP Context Response message sent to the SGSN.

If the upgrade QoS Supported parameter is 0, the SGSN does not support the QoS upgrade.
The GGSN includes the QoS-Upgrade AVP with the value set to
QoS_UPGRADE_NOT_SUPPORTED in a CCR message sent to the PCRF. The PCRF
includes a low-level QoS in a CCA message sent to the GGSN. The GGSN also includes a lowlevel QoS in a Create PDP Context Response message sent to the SGSN.
The following section describes the QoS negotiation procedure in the following scenarios:

QoS establishment when a subscriber goes online (CCR-Initial)

GGSN-initiated QoS update (CCR-Update)

PCRF-initiated QoS delivery (RAR)

QoS Establishment when a Subscriber Goes Online (CCR-Initial)

NOTE:
For details about the procedure in which a subscriber goes online, see IP-CAN Session Establishment.
When a subscriber goes online, the GGSN sends a CCR-Initial message carrying the QoS-Negotiation
and QoS-Upgrade AVPs to the PCRF. The PCRF sends a CCA-Initial message, in which the QoSInformation varies depending on the settings of the QoS-Negotiation and QoS-Upgrade AVPs:

If the QoS negotiation is not supported, the PCRF delivers the QoS requested by the policy and
charging enforcement function (PCEF). For example, if the PCEF requests the QoS of 4 Mbit/s
and the QoS of 2 Mbit/s is configured on the PCRF, the PCRF delivers the QoS of 4 Mbit/s.

If the QoS upgrade is not supported, the QoS delivered by the PCRF cannot be greater than the
QoS requested by the PCEF. For example, if the PCEF requests the QoS of 2 Mbit/s and the
QoS of 4 Mbit/s is configured on the PCRF, the PCRF delivers the QoS of 2 Mbit/s.

If the QoS-Negotiation AVP is not carried in the CCR-Initial message, the QoS negotiation is supported by
default. If the QoS-Upgrade AVP is not carried in the CCR-Initial message, the QoS upgrade is not
supported by default.
The UPCC generates the authorized QoS per bearer after implementing the negotiation and upgrade of
the QoS per bearer based on the requested QoS per bearer and the configured QoS policies. Then, the
UPCC processes the parameters of the QoS per service flow based on the authorized QoS per bearer to
ensure that the QoS per service flow is not greater than the authorized QoS per bearer. As defined in the
protocol, the QoS class identifier (QCI) of the QoS per service flow must be consistent with the QCI of the
authorized QoS per bearer. The UPCC replaces the QoS per service flow with the QoS per bearer when
the QoS per service flow is greater than the QoS per bearer.
NOTE:
For details about the QoS per bearer and the QoS per service flow, see Gx-interface QoS.

The QoS per service flow cannot be greater than the authorized QoS per bearer.

GGSN-Initiated QoS Update (CCR-Update)

NOTE:
For details about the GGSN-initiated QoS update procedure, see UE-Initiated IP-CAN Session Update.
When a QoS policy needs to update, the GGSN sends a CCR-Update message carrying the QoSNegotiation and QoS-Upgrade AVPs to the PCRF. The PCRF sends a CCA-Update message, in which
the QoS-Information varies depending on the settings of the QoS-Negotiation and QoS-Upgrade AVPs:

If the QoS negotiation is not supported, the PCRF delivers the QoS requested by the PCEF. For
example, if the PCEF requests the QoS of 4 Mbit/s and the QoS of 2 Mbit/s is configured on the
PCRF, the PCRF delivers the QoS of 4 Mbit/s.

If the QoS upgrade is not supported, the QoS delivered by the PCRF cannot be greater than the
QoS requested by the PCEF. For example, if the PCEF requests the QoS of 2 Mbit/s and the
QoS of 4 Mbit/s is configured on the PCRF, the PCRF delivers the QoS of 2 Mbit/s.

If the QoS-Negotiation AVP is not carried in the CCR-Update message, the QoS negotiation is supported
by default. If the QoS-Upgrade AVP is not carried in the CCR-Update message, the PCRF performs
subsequent operations based on the value of the QoS-Upgrade AVP carried in the previous CCR
message.
NOTE:
As defined in the protocol, the value of the QoS-Negotiation AVP is valid only to the current message
whereas the value of the QoS-Upgrade AVP is inherited between messages exchanged over a bearer.
The QoS per service flow cannot be greater than the authorized QoS per bearer, but the QCIs of the two
levels of QoS must be consistent. The UPCC replaces the QoS per service flow with the QoS per bearer
when the QoS per service flow is greater than the QoS per bearer.
NOTE:
For details about the QoS per bearer and the QoS per service flow, see Gx-interface QoS.

The QoS per service flow cannot be greater than the authorized QoS per bearer.

PCRF-Initiated QoS Delivery (RAR)

NOTE:
For details about the PCRF-initiated QoS delivery procedure, see PCRF-Initiated IP-CAN Session
Update.
When the PCRF proactively delivers new QoS policies to the GGSN, it sends an RAR message. The
QoS-Information carried in the RAR message is independent of the QoS-Negotiation and QoS-Upgrade
AVPs.
The QoS per service flow cannot be greater than the authorized QoS per bearer, but the QCIs of the two
levels of QoS must be consistent. The UPCC replaces the QoS per service flow with the QoS per bearer
when the QoS per service flow is greater than the QoS per bearer.
For details about the QoS per bearer and the QoS per service flow, see Gx-interface QoS.

Reference
Mapping Between QCIs and UMTS QoS Parameters
The QoS negotiated between the GGSN and the PCRF is called authorized QoS. The QoS information
includes the QCI and data rates (MBR and GBR). For details about QoS over the Gx interface, see QoSrelated AVPs.
The QCI is calculated by using the QoS parameters over the Gn interface. The QoS parameters consist
of traffic class (TC), traffic handle priority (THP), signaling indication (SI), and source statistics descriptor
(SSD). Table 1 lists the mapping between QCIs and QoS parameters.
Table 1 Mapping between QCIs and UMTS QoS parameters
QCI

UMTS QoS Parameter

TC

THP

SI

SSD

1 Conversational

n/a

n/a

speech

1 Conversational

n/a

n/a

unknown

Table 1 Mapping between QCIs and UMTS QoS parameters

QCI

UMTS QoS Parameter

TC

THP

SI

SSD

2 Streaming

n/a

n/a

speech

2 Streaming

n/a

n/a

unknown

3 Interactive

Yes

n/a

3 Interactive

No

n/a

3 Interactive

No

n/a

3 Interactive

No

n/a

4 Background

n/a

n/a

n/a

NOTE:
The concepts mentioned in the above table are described as follows:

QCI is short for QoS class identifier. It is a QoS attribute in the evolved packet core (EPC)
network that specifies the QoS level of packet forwarding behaviors (such as packet loss rate
and delay), which is provided for service data flows (SDFs). The packet forwarding behaviors
are implemented based on QCIs that are predefined on the access network node, such as the
eNodeB.
TC is short for traffic class. There are four types of traffic in the UMTS network: conversational,
streaming, interactive, and background.
THP is short for traffic handle priority. It indicates the relative importance of all SDUs belonging
to a bearer compared with all SDUs of other bearers.
SI is short for signaling indication. It indicates whether submitted SDUs are transmitted over
signaling links.
SSD is short for source statistics descriptor. It describes the characteristic of the data source
from which SDUs are sent.
SDU is short for service data unit. It is a unit of data transmitted between neighboring layers of
the protocol stack.

Concepts
The PCRF interworks with the PCEF over the Gx interface. For details about the Gx interface, see
WHFD-601010 Policy Control over the Gx Interface Using Diameter Description.
Parent topic: QoS in UMTS Networks