RAN Feature Documentation

Product Version: RAN16.0

Library Version: 11
Date: 2016-12-30

For any question, please contact us.

Copyright Huawei Technologies Co., Ltd. 2016. All rights reserved.

QoS Management
Contents
3.5.8 QoS Management

WCDMA RAN
QoS Management Feature Parameter Description
Issue 01

Date 2012-11-30

HUAWEI TECHNOLOGIES CO., LTD.

 Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
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.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China

Website: http://www.huawei.com

Email: support@huawei.com

5.8 Contents
1 About This Document
1.1 Scope
1.2 Intended Audience
1.3 Change History
1.4 Differences Between Base Station Types

2 Overview of QoS Management

3 Technical Description
3.1 QoS Architecture
3.2 UTRAN QoS Mapping
3.2.1 UMTS QoS Classes
3.2.2 CN QoS Parameters
3.2.3 UTRAN QoS Mapping Mechanism
3.2.4 Uu Radio QoS Mapping
3.2.5 Iub/Iur Transport QoS Mapping
3.3 UTRAN QoS Management
3.3.1 Overview
3.3.2 QoS Guarantee for a Single User
3.3.3 DiffServ Provision for Different Users

4 Parameters

5 Counters

6 Glossary

7 Reference Documents

1 About This Document

Scope
This document describes QoS management, including its technical principles.
This document applies to the following NE types.

NE Type NE Model

RNC BSC6900, BSC6910

 NE Type NE Model

NodeB Macro 3900 series macro base stations: BTS3900, BTS3900A, BTS3900L, BTS3900AL, DBS3900, BTS3900C
3800 series macro base stations: DBS3800, BTS3812E, BTS3812AE

Micro BTS3803E, BTS3902E

LampSite DBS3900 LampSite

Intended Audience
This document is intended for personnel who:

Need to understand the features described herein

Work with Huawei products

Change History
This section provides information about the changes in different document versions. There are two types of changes, which are defined as follows:

Feature change
Changes in features of a specific product version
Editorial change
Changes in wording or addition of information that was not described in the earlier version

AN14.0 01 (2012-11-30)

Compared with Issue 02 (2011-12-30) of RAN13.0, Issue 01 (2012-11-30) of RAN14.0 optimizes some descriptions.

Differences Between Base Station Types

The features described in this document are implemented in the same way on macro, micro, and LampSite base stations.

2 Overview of QoS Management

Quality of service (QoS) is a comprehensive reflection of the service capability of a WCDMA system. It determines how satisfied the users are with the services provided
by the telecom operator. Therefore, it is an important factor to be considered in the WCDMA system.
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.
 Figure 2-1 UTRAN QoS management strategy

The purpose of UTRAN QoS management is to ensure the QoS and provide differentiated services (DiffServ) to maximize the number of satisfied users.
The basic procedure for QoS management is as follows:

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:

3.1 QoS Architecture

3.2 UTRAN QoS Mapping
3.3 UTRAN QoS Management

QoS Architecture
3GPP TS 23.107 describes the QoS concept and architecture. In addition, it provides QoS parameters based on the UMTS bearer service.
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.
 Figure 3-1 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 local bearer service is beyond the UMTS research scope.

The external bearer service is coordinated by the telecom operator with the connected networks. Between the UMTS bearer service and the external bearer
service, QoS mapping is required. Through the QoS mapping, the QoS requirement is sent to the next network element (NE).
The coordination and QoS mapping between UMTS bearer services is important for implementing the end-to-end QoS of UMTS.

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.

UTRAN QoS Mapping

3.2.1 UMTS QoS Classes

3GPP TS 23.107 defines the following four UMTS traffic classes: conversational, streaming, interactive, and background.
The main difference among these classes is the degree of traffic sensitivity to delay, which is described as follows:

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.
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.
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.
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.

3.2.2 CN QoS Parameters

Different traffic classes have different QoS requirements. Therefore, a series of QoS parameters are defined for each traffic class. Table 3-1 lists the QoS parameters to
be set for each traffic class.

Table 3-1 QoS parameters defined by the 3GPP

Traffic Class Conversational Streaming Interactive Background

Maximum bit rate

Delivery order

Maximum SDU size

SDU format information - -

SDU error ratio

Residual bit error ratio

 Traffic Class Conversational Streaming Interactive Background

Delivery of erroneous SDUs

Transfer delay - -

Guaranteed bit rate - -

Traffic handling priority - - -

Allocation/retention priority

Source statistics descriptor - -

Signaling indication - - -

NOTE:
-: not involved
: 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:

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, thereby supporting the
deployment of some charging policies.

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.

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.

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.

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.

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.

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.

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.

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.

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)}.

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.

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.
 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.

3.2.3 UTRAN QoS Mapping Mechanism

The QoS of featured services of the UTRAN is controlled by related parameters. CN QoS parameters are mapped to UTRAN QoS parameters. All these parameters
ensure the QoS of the services provided for users.
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.
Figure 3-2 shows the QoS mapping mechanism.

Figure 3-2 QoS mapping mechanism

3.2.4 Uu Radio QoS Mapping

Uu radio QoS parameters are used to manage the radio resources on the Uu interface. The Uu radio QoS mapping is implemented by the RNC, which is described in
the following sections:

RAB-to-RB Mapping
User Priority Mapping
RAB Integrated Priority Mapping
HSPA SPI Mapping and GBR Mapping

AB-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.

Figure 3-3 RAB-to-RB mapping

For details about the RAB-to-RB mapping, see the Radio Bearers Feature Parameter Description.
 er Priority Mapping

The allocation/retention priority (ARP) reflects the subscribed priority. Based on the ARP, the UTRAN can provide DiffServ for users with different priorities.
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.

Table 3-2 User priority mapping

ARP value 1 2 3 4 5 6 7 8

User priority Gold Gold Gold Gold Gold Silver Silver Silver

ARP value 9 10 11 12 13 14 15 -

User priority Silver Silver Copper Copper Copper Copper Copper -

For details about how to set the user priority, see the Load Control Feature Parameter Description.

AB Integrated Priority Mapping

The RAB integrated priority is the integrated priority of a RAB. It is used for intelligent access control (IAC) and load control by the RNC. In the case of congestion or
resource insufficiency, a service with the highest integrated priority is processed first.
For each service of a user, the mapping to the integrated priority is performed. The mapping considers these factors in the following order: traffic class, ARP, THP, and
bearer type. Here, the sequence of traffic class and ARP can be set.
Each factor has multiple values and they are also sequenced, as shown in Figure 3-4.
Figure 3-4 RAB integrated priority mapping

For the configuration methods and specific applications of the RAB integrated priority, see the Load Control Feature Parameter Description.

SPA SPI Mapping and GBR Mapping

The scheduling priority indicator (SPI) is the priority of a RAB. It is used for resource allocation during HSPA scheduling and flow control. The SPI mapping considers the
traffic class, user priority, and THP.
Based on the SPIs and user rate, the SPI weights can be determined to provide DiffServ for HSPA users. Generally, a user with the highest SPI weight obtains the
required QoS first when the resources are insufficient and has more chances of being scheduled when the resources are sufficient. In this way, user experience is
improved. Table 3-3 shows the SPI mapping.

Table 3-3 SPI mapping

Traffic Class User Priority THP SPI

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
 Traffic Class User Priority THP SPI
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.

Table 3-4 GBR mapping

Direction Gold Silver Copper

Downlink 256 kbit/s 128 kbit/s 64 kbit/s

Uplink 256 kbit/s 128 kbit/s 64 kbit/s

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.

3.2.5 Iub/Iur Transport QoS Mapping

The Iub and Iur transport networks can differentiate data packets by their priorities and then provide DiffServ. The main task of the Iub/Iur transport QoS mapping is to
map different services of different users to appropriate QoS classes so that different services on the Iub and Iur interfaces can obtain different QoS. The mapping is
performed by the RNC through the radio link (RL) setup procedure.
Based on the transport modes, the Iub/Iur transport QoS mapping consists of:

Service Mapping over ATM

Service Mapping over IP

rvice Mapping over ATM

The AAL2 QoS classes of ATM support the transport bearers with the following rates:

Constant bit rate (CBR)

Real-time variable bit rate (RTVBR)
Non-real-time variable bit rate (NRTVBR)
Unspecified bit rate (UBR)
Unspecified bit rate with the guaranteed bit rate (UBR+)

Transport bearers of different types provide different QoS.

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.
Figure 3-5 Service mapping over ATM

For details about the mapping from services to AAL2 QoS classes, see the Transmission Resource Management Feature Parameter Description.

rvice Mapping over IP

In the DiffServ model of the IP transport network, the IP QoS classes are:
 Expedited Forwarding (EF)
Assured Forwarding 1 (AF1)
Assured Forwarding 2 (AF2)
Assured Forwarding 3 (AF3)
Assured Forwarding 4 (AF4)
Best Effort (BE)

The priority of an IP queue is identified by the DiffServ code point (DSCP) in the header of an IP packet. Queues with different priorities can obtain different QoS.
If the Iub transport network uses the IP mode, the mapping from services to IP 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. Figure 3-6 shows the service mapping over IP.
Figure 3-6 Service mapping over IP

For details about the mapping from services to IP QoS classes, see the Transmission Resource Management Feature Parameter Description.

UTRAN QoS Management

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, thereby 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.
Figure 3-7 shows the UTRAN QoS management mechanism.
 Figure 3-7 UTRAN QoS management mechanism

3.3.2 QoS Guarantee for a Single User

QoS guarantee for a single user is implemented by a series of functions. One purpose is to ensure the user requirement for the basic QoS of the user by carrying the
user services on appropriate channels and setting corresponding parameters. The other purpose is to ensure the service continuity by monitoring the link quality when
the user is in movement.
QoS guarantee for a single user involves QoS guarantee during service setup and QoS guarantee after service setup.

uaranteeing QoS During Service Setup

The functions to be performed for guaranteeing QoS during service setup are channel type selection and admission control.
When a service setup request is initiated, the RB function selects an appropriate channel type such as the R99 or HSPA channel according to service attributes such as
the traffic class and MBR. The R99 channel and HSPA channel have their respective characteristics. The R99 channel can provide an MBR of 384 kbit/s, but it requires
dedicated radio resources. In comparison, the HSPA channel can provide an MBR of 28.8 Mbit/s in R7 and even higher along with the technological development. The
HSPA channel resources can be shared, and therefore the service rate may vary with the channel environment and the user's integrated priority using the resources.
Therefore, selecting an appropriate channel type based on the service attributes is an important step for QoS guarantee. In addition to the channel type, you need to
select corresponding channel control parameters and power control parameters to ensure the correct data transmission. For details about radio bearers, see the Radio
Bearers Feature Parameter Description.
After the channel type is determined, an appropriate cell needs to be selected to provide services. The admission control of each cell prevents the cell from being
overloaded due to admission of too many users. This function monitors the cell load, predicts the load increase after a new service is admitted, and determines whether
the admission will lead to overload. The admission control ensures the QoS of admitted services and the QoS of the new service after it is admitted. If a new user is
rejected because the cell is overloaded, the new user attempts to access another cell with the same coverage. For details about admission control, see the Call
Admission Control Feature Parameter Description.

oS Guarantee After Service Setup

The functions to be performed for QoS guarantee after service setup are as follows:

Power control
After service setup, power control enables the user data to be transmitted with the appropriate power. It ensures correct data reception and at the same time
avoids wastage of power resource. For details about power control, see the Power Control Feature Parameter Description.
Mobility management
When the user moves to the edge of a cell, the QoS may degrade. The handover function can direct the user to a more suitable cell in time to ensure the
service continuity. For details about handover, see the Handover Feature Parameter Description.
Rate control
If the service is set up on the DCH, the RNC can detect whether the transmit power for this user is limited in the uplink or downlink. If the transmit power is
limited, the data transmission capability may be affected and call drop may occur. To ensure the QoS in this case, the system reduces the service rate or
performs an inter-frequency or inter-RAT handover to select a more suitable cell. For details about rate control, see the DCCC Feature Parameter Description.
HSDPA resource management
If the service is set up on the HSPA channel, the HSPA scheduling function ensures that the user is able to obtain the basic QoS. For example, for a delay-
sensitive service, this function ensures that the packet transmission delay is within an acceptable range; for a 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.
 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.

3.3.3 DiffServ Provision for Different Users

The objective of DiffServ is to serve as many users as possible with limited resources and to meet the requirements of more users.

ffServ Provision Principles

The DiffServ provision principles are as follows:

Providing DiffServ for users with different priorities, with high-priority users being served preferentially
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.

The provision of DiffServ requires the mapping of the following parameters:

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.
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.
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.

ffServ Provision

DiffServ provision is described as follows:

DiffServ provision during service setup

During channel type selection, the processing is based on service attributes. Generally, CS services have stable rates and a high requirement for low delay.
Therefore, they are carried on the R99 channel to use dedicated radio resources and to obtain required bandwidths. In comparison, PS services usually have
a huge amount of data to transmit in burst mode. Therefore, they are carried on the HSPA channel to improve the resource sharing degree and to ensure the
basic QoS. For details about how to select a channel type, see the Radio Bearers Feature Parameter Description.
During admission control, the provision of DiffServ is based on traffic classes. Compared with PS services, high-priority CS services such as the AMR voice
service have lower admission limits and higher access success rates.
If the service admission fails, a service with a higher integrated priority can preempt the resources of a service with a lower integrated priority to increase the
access success rate. Whether the integrated priority considers the traffic class first or the user priority first can be determined by the telecom operator.
Generally, it is recommended that the traffic class be considered first. Therefore, CS services can have higher integrated priorities than PS services and can
preempt the resources of PS services. In this way, the access probability can be increased and the overall user satisfaction can be improved.
During admission control, emergency services are assigned the highest priority and therefore they have the highest access success rate.
For details about the DiffServ provision during service setup, see the Load Control Feature Parameter Description.
Congestion control after service setup
If the system enters the basic congestion state, there are two methods for ensuring the system stability. One is to decrease the rates of admitted users by
reserving resources for new services. The other is to reduce the cell load by performing operations such as handover. If the system enters the overload state,
it terminates the services of some users to reduce the load rapidly. Users with low integrated priorities are preferentially selected for congestion relief to
ensure the overall QoS of the cell.
Whether the integrated priority considers the traffic class first or the user priority first can be determined by the telecom operator. It is recommended that the
traffic class be considered first. Therefore, CS services can have higher priorities than PS services, and delay-sensitive services can have higher priorities
than throughput-sensitive services within PS services. In this way, the impact of congestion control on user experience can be reduced.
During congestion control, emergency services are not selected for congestion relief.
For details about congestion control, see the Load Control Feature Parameter Description.

SPA DiffServ Provision

HSPA resources are shared among multiple users. PS services are usually carried on the HSPA channel. In R8, the CS AMR voice service can also be carried on the
HSPA channel.
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.

Service-based DiffServ provision

Services carried on the HSPA channel are classified into delay-sensitive services and throughput-sensitive services, as listed in Table 3-5.

Table 3-5 Service classifications

Type Delay-sensitive service Throughput-sensitive service

QoS Low traffic volume High traffic volume

Short acceptable delay High throughput
 Service Signaling Streaming service
VoIP service Interactive service
CS AMR service Background service
IMS signaling

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.

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

There are no specific parameters associated with this feature.

5 Counters

There are no specific counters associated with this feature.

6 Glossary

For the acronyms, abbreviations, terms, and definitions, see Glossary.

7 Reference Documents

1. 3GPP TS 23.107, "Quality of Service (QoS) concept and architecture"

2. Radio Bearers Feature Parameter Description
3. Load Control Feature Parameter Description
4. Transmission Resource Management Feature Parameter Description
5. Power Control Feature Parameter Description
6. Handover Feature Parameter Description
7. DCCC Feature Parameter Description
8. HSDPA Feature Parameter Description
9. HSUPA Feature Parameter Description
10. TPE Feature Parameter Description
11. AQM Feature Parameter Description
12. Differentiated HSPA Service Feature Parameter Description