Beruflich Dokumente
Kultur Dokumente
Issue 01
Date 2012-11-30
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Website: http://www.huawei.com
Email: support@huawei.com
Contents
4 Parameters.....................................................................................................................................21
5 Counters........................................................................................................................................22
6 Glossary.........................................................................................................................................23
7 Reference Documents.................................................................................................................24
1.1 Scope
This document describes QoS management, including its technical principles.
l Feature change
Changes in features of a specific product version
l Editorial change
Changes in wording or addition of information that was not described in the earlier version
01 (2012-11-30)
Compared with Issue 02 (2011-12-30) of RAN13.0, 01 (2012-11-30) of RAN14.0 optimizes
some descriptions.
To ensure the end-to-end QoS, all the nodes from the transmitter to the receiver need to cooperate
with each other.
The QoS is defined during subscription, and the related information is saved on the core network
(CN). When a user sends a service request, the CN negotiates with the UTRAN and the user
equipment (UE) according to the subscribed QoS. If the negotiation is successful, a set of QoS
parameters accepted by all the nodes can be obtained. Then, each node provides the services for
this user based on these parameters. The user can be satisfied with the services only when all
the nodes meet the QoS requirements.
In the UTRAN, the QoS is determined by the QoS management strategy, as shown in Figure
2-1.
The purpose of UTRAN QoS management is to ensure the QoS and provide differentiated
services (DiffServ) to maximize the number of satisfied users.
1. The CN sends the related QoS parameters to the RNC on the Iu interface.
2. According to the QoS management strategy, the RNC maps the QoS parameters to the
parameters that can be used by the UTRAN, and then the RNC sends some of the parameters
to the NodeB.
3. Based on these parameters and the QoS management strategy, the RNC and NodeB perform
resource allocation and management, such as radio resource management (RRM) and
transmission resource management (TRM), and provide DiffServ for different users.
3 Technical Description
This section describes how the UTRAN performs QoS management. It consists of the following
sections:
To ensure the QoS of a network, bearer services with explicit attributes and functions must be
set up between the transmitter and the receiver. A bearer service involves all the aspects that are
required to ensure specific QoS. These aspects are included in control plane signaling, user plane
transmission, and QoS management. Figure 3-1 shows the UMTS QoS architecture.
As shown in Figure 3-1, the traffic from one terminal equipment (TE) to another passes different
levels of bearer services. The TE is connected to the UMTS network through a mobile terminal
(MT). The end-to-end service at the application layer is implemented through the bearer services
of the underlying networks.
The end-to-end service consists of the local bearer service, UMTS bearer service, and external
bearer service. These services ensure the QoS of the end-to-end service. They are described as
follows:
The UMTS bearer service consists of the radio access bearer (RAB) service and the core network
bearer (CNB) service.
The RAB service is implemented through the radio bearer (RB) service and Iu bearer service.
The RB service covers all the aspects of the transmission on the radio interface, and the Iu bearer
service provides the transmission between the UTRAN and the CN. For PS services, the Iu bearer
service can provide different QoS classes.
The role of the CNB is to provide a negotiated UMTS bearer service. The CN provides different
QoS classes for different backbone bearer services. A specific backbone bearer service can be
selected to meet the QoS requirement of the CN bearer service.
The RAB service involves the Uu, Iub, Iur, and Iu interfaces.
The main difference among these classes is the degree of traffic sensitivity to delay, which is
described as follows:
l The conversational class (WRFD-010501 Conversational QoS Class) is the most sensitive
to delay. It is used to carry real-time traffic. The real-time traffic requires shortest delay
and strict time sequence between data streams. Therefore, this traffic class has the highest
QoS requirement.
l The streaming class (WRFD-010502 Streaming QoS Class) is used to carry unidirectional
data streams. It does not have a high requirement for delay, but the time sequence must be
kept within a data stream and the end-to-end delay jitter of data streams must be controlled.
l The interactive class (WRFD-010503 Interactive QoS Class) is used to carry traditional
Internet services, such as Web browsing and database query. Its round trip time (RTT) is
a key parameter, and data packets need to be transmitted transparently at low bit error rates.
l The background class (WRFD-010504 Background QoS Class) is used to receive or
transmit data in background mode. Such services include email, SMS, and FTP. This class
does not have a high requirement for delay, but it requires data packets to be transmitted
transparently at low bit error rates.
Maximum bit
rate
Delivery order
Maximum SDU
size
SDU format - -
information
Residual bit
error ratio
Delivery of
erroneous SDUs
Transfer delay - -
Guaranteed bit - -
rate
Traffic handling - - -
priority
Allocation/
retention
priority
Source statistics - -
descriptor
Signaling - - -
indication
NOTE
l -: not involved
l : involved
These QoS parameters are sent by the CN to the UTRAN on the Iu interface when the service
is set up. Based on these QoS parameters, the UTRAN allocates appropriate radio resources to
users to ensure the QoS, user fairness, and DiffServ.
The parameters and their application principles on the UTRAN side are described as follows:
l Maximum bit rate (unit: kbit/s)
This parameter, also known as the MBR, specifies the maximum bit rate of an application.
It facilitates the configuration of the maximum channel bandwidth.
By modifying this parameter in the HLR, the telecom operator can limit the maximum
bandwidth allocated to one or more users, thus supporting the deployment of some charging
policies.
l Delivery order (value range: Yes, No)
This parameter specifies whether the RAB delivers service data units (SDUs) in order.
During RAB-to-RB mapping, the radio link control (RLC) layer controls the delivery order
of upper-layer SDUs. Generally, the CS RAB delivers SDUs in order. The PS RAB,
however, may or may not deliver SDUs in order. If the delivery is not in order, an upper-
layer protocol, such as the IP, reorders these SDUs when they arrive.
l Maximum SDU size (unit: octets)
This parameter specifies the maximum permissible SDU size. It limits the maximum size
of the SDUs sent by upper layers to the RLC layer.
l SDU format information (unit: bits)
This is a parameter set, which includes the parameters of a RAB subflow combination.
Based on the SDU size and/or the subflow combination rate included in the SDU format
information, the corresponding transport format combination set (TFCS) and the dynamic
part of the transport format set (TFS) of the DCH can be specified.
l SDU error ratio
This parameter specifies the fraction of SDUs lost or detected as erroneous. It determines
the setting of the RB transmission quality. That is, the actual SDU error ratio of the RB
should be smaller than the parameter value.
l Residual bit error ratio
This parameter specifies the fraction of transmitted SDUs with residual bit errors in each
subflow. Qualitative analysis shows that the CRC capability is related to the number of
check bits. The CRC capability is high when there are a large number of check bits.
Therefore, the residual bit error ratio can determine the number of check bits used on a
transport channel.
l Delivery of erroneous SDUs (value range: Yes, No, -)
This parameter specifies whether error SDUs are delivered. If the upper layer has an error
tolerance mechanism or a recovery mechanism, error SDUs can be directly delivered
without an error check.
l Transfer delay (unit: ms)
This parameter specifies the end-to-end delay of SDU transmission within the UTRAN.
This parameter, together with the SDU error ratio, determines the setting of the BLER and
the settings of the ARQ parameters in RLC AM mode in the UTRAN. The ARQ parameters
include the maximum transmission times, polling parameter, and status reporting
parameter.
l Guaranteed bit rate (unit: kbit/s)
This parameter, also known as the GBR, is used for license control and resource allocation
based on available resources. In the case that the network resources are limited, whether
the service rate of a user on the UTRAN side is higher than the GBR indicates whether the
requirement of this user for the basic rate is met.
According to 3GPP specifications, the conversational class and streaming class require the
GBR, but neither the interactive class nor the background class has this requirement.
l Traffic handling priority
This parameter needs to be set if the Traffic Class IE is set to Interactive. It specifies the
relative importance of handling the SDUs on the RAB compared with the SDUs on other
bearers. The value range is INTEGER {spare (0), highest (1) lowest (14), no priority
(15)}.
l Allocation/retention priority
This parameter, also known as the ARP, includes multiple IEs. It specifies the relative
importance of resource allocation and retention of a RAB compared with other RABs. The
ARP reflects the priority of a user.
l Source statistics descriptor (value range: speech, unknown)
This parameter needs to be set if the Traffic Class IE is set to Conversational or Streaming.
This parameter specifies the characteristics of the source of transmitted SDUs.
l Signaling Indication (value range: Yes, No)
This parameter specifies whether an interactive class carries signaling. If this parameter is
set to Yes, the UE sets the traffic handling priority (THP) to 1.
This parameter reflects the differences between this interactive class and other interactive
classes. This class may require a higher priority, shorter delay, or higher peak throughput.
For example, this parameter can be set to Yes when an interactive class carries the IMS
signaling.
The inputs of the QoS mapping are CN QoS parameters, and the outputs are radio QoS
parameters and transport QoS parameters. The mapping is implemented by the RNC.
The output of the QoS mapping is applied in the related functions of the RNC and NodeB. The
NodeB parameters are sent to the NodeB on the Iub interface.
l RAB-to-RB Mapping
l User Priority Mapping
l RAB Integrated Priority Mapping
l HSPA SPI Mapping and GBR Mapping
RAB-to-RB Mapping
The RAB setup request initiated by the CN carries the QoS parameters. These parameters
describe the requirements for the QoS. Based on these parameters, the RNC selects appropriate
RB parameters such as the bearer channel type, channel parameters, RLC mode, data
transmission parameters, and power control parameters. The RB parameters provide the basic
configuration information about the RB service. Some of the information is sent to the NodeB
on the Iub interface.
The RAB-to-RB mapping considers all the QoS parameters of the CN.
Figure 3-3 shows the RAB-to-RB mapping, where the TRB is traffic RB.
For details about the RAB-to-RB mapping, see the Radio Bearers Feature Parameter
Description.
User priorities in the UTRAN are classified into gold, silver, and copper. The mapping from
ARP values to user priorities, as listed in Table 3-2, can be configured by the telecom operator.
ARP 1 2 3 4 5 6 7 8
value
ARP 9 10 11 12 13 14 15
value
For details about how to set the user priority, see the Load Control Feature Parameter
Description.
For the configuration methods and specific applications of the RAB integrated priority, see the
Load Control Feature Parameter Description.
SRB NA NA 15
IMS Signaling NA NA 14
Conversational Gold NA 13
Silver 13
Copper 13
Streaming Gold NA 12
Silver 12
Copper 12
Interactive Gold 1 10
Gold 2 9
Gold 3 ~ 15 8
Silver 1 7
Silver 2 6
Silver 3 ~ 15 5
Copper 1 4
Copper 2 3
Copper 3 ~ 15 2
Background Gold NA 8
Silver 5
Copper 2
The CN does not set the GBRs for the interactive class and background class. To provide the
basic rates for the two classes, the RNC supports the GBR setting. The GBRs vary with user
priorities and service directions. An example is listed in Table 3-4.
Note: the GBR is configured according to User Priority, TC, THP, and bearers (R99/HSPA).
The example shows only mapping between User Priority and GBR.
The SPI mapping and the GBR mapping are performed by the RNC. Then, the mapping results
are sent to the NodeB on the Iub interface. For details about the settings of related parameters
and the impacts of these parameters on the Uu radio resources, see the HSDPA Feature
Parameter Description and the HSUPA Feature Parameter Description.
For the impacts of the SPI on the Iub transmission resources, see the Transmission Resource
Management Feature Parameter Description.
Based on the transport modes, the Iub/Iur transport QoS mapping consists of:
If the Iub transport network uses the ATM mode, the mapping from services to AAL2 QoS
classes can be configured by the telecom operator. The mapping considers the traffic class, THP
only for interactive traffic class, CN domain type, and RB type. Generally, real-time services
are mapped to high-priority queues to obtain higher QoS on the transport network.Figure 3-5
shows the service mapping over ATM.
For details about the mapping from services to AAL2 QoS classes, see the Transmission
Resource Management Feature Parameter Description.
For details about the mapping from services to IP QoS classes, see the Transmission Resource
Management Feature Parameter Description.
3.3.1 Overview
The UTRAN QoS management strategy is to try its best to ensure the QoS for each user and to
provide DiffServ for different users, thus meeting the requirements of more users.
The strategy is implemented by specific functions. From the beginning of the service setup,
functions such as the RB function, rate control, HSPA scheduling, power control, and handover
are performed for the user to ensure the QoS and service continuity. In addition, functions such
as load control, HSPA scheduling, and Iub flow control are performed among different users for
resource allocation to provide DiffServ and maximize the system capacity.
QoS guarantee for a single user involves QoS guarantee during service setup and QoS guarantee
after service setup.
throughput-sensitive service, this function ensures that the rates provided are not lower than
the GBR. For details, see the HSDPA Feature Parameter Description and the HSUPA
Feature Parameter Description.
l User experience improvement
For the voice service, the de-jitter function can be applied in IP transport. When the Iub/
Iur interface uses the IP mode, data packets may not be transmitted in sequence. In this
case, the de-jitter function can restore the data transmission order and limit the
transmission delay within an acceptable range.
For the TCP service, Huawei uses the TCP performance enhancer (TPE) and active
queue management (AQM) functions to improve the QoS. TPE aims at a service with
only one TCP connection and increases the data transmission rate at the TCP layer.
AQM aims at a service with multiple TCP connections and improves the QoS of the
TCP connections with a small amount of data. For details about the two functions, see
the TPE Feature Parameter Description and the AQM Feature Parameter
Description.
l Providing DiffServ for users with different priorities, with high-priority users being served
preferentially
l Providing DiffServ for services with different traffic classes:
A CS service has a higher priority than a PS service.
Within PS services, delay-sensitive services have higher priorities than throughput-
sensitive services.
Emergency services are provided preferentially.
l User priority: Different users have different priorities. The ARPs sent from the CN indicate
the subscribed priorities. Based on the ARPs, users are classified into 15 priorities. In the
UTRAN, users are classified into three priorities, namely gold, silver, and copper.
Therefore, the user priority mapping is based on the ARP to provide DiffServ for users in
the UTRAN.
l RAB integrated priority: This parameter is set on the basis of the RAB and with reference
to the traffic class, user priority, THP and bearer type. It is used for the provision of DiffServ
during Intelligent Access Control (IAC) and load control by RNC.
l SPI and SPI weight: The SPI is used to indicate the priority of each HSPA service. The SPI
weight is determined on the basis of the SPI and used to provide the HSPA DiffServ.
DiffServ Provision
DiffServ provision is described as follows:
HSPA scheduling and flow control determine the resource allocation among users in real time.
During resource allocation, both service-based DiffServ and user-based DiffServ can be
provided.
Services carried on the HSPA channel are classified into delay-sensitive services and
throughput-sensitive services, as listed in Table 3-5.
For different services, different QoS is provided. For example, for a delay-sensitive service,
the scheduling function limits the packet transmission delay within an acceptable range;
for a throughput-sensitive service, this function ensures that provided rates are not lower
than the GBR. Users are more sensitive to the QoS of delay-sensitive services. Therefore,
the requirement for this kind of QoS is met first during scheduling.
3GPP TS 23.107 defines only four traffic classes, which cannot fully reflect the
requirements for QoS. For example, a Web page may contain video streams in addition to
texts and pictures. All of email, video website browsing, and Bit Torrent (BT) download
may be mapped to the background class, but they have different QoS requirements. After
service setup, the RNC can further identify and classify the traffic classes and attributes
and then provide appropriate QoS to improve user experience.
l User-based DiffServ provision
User-based DiffServ is mainly aimed at throughput-sensitive services. The provision is
described as follows:
The CN does not set the GBRs for the interactive class and background class. The RNC,
however, can set the GBRs based on user priorities. The HSPA scheduling function
ensures that users with different priorities obtain different GBRs.
The RNC can also set Happy Bit Rate (HBR) which determines the throughput expected
by the user based on a study on user experience. When the rate for a user reaches the
HBR, the scheduler decreases the scheduling probability for the user.
The SPI weight is set on the basis of the SPI and user rate range, and the SPI considers
both the user priority and the traffic class. The SPI weight is always used in throughput-
sensitive services.
The user-based setting is recommended to implement user-based DiffServ. Users with
higher SPI weights have more chances to obtain required resources and satisfied user
experience.
For details about HSPA DiffServ, see the Differentiated HSPA Service Feature Parameter
Description.
For details about the Iub resource allocation among HSPA users, see the Transmission
Resource Management Feature Parameter Description.
4 Parameters
5 Counters
6 Glossary
7 Reference Documents