ZTE UMTS Congestion Control Feature Guide - V1 10

Congestion Control
Feature Guide
Congestion Control
Congestion Control
Version Date Author Reviewer Notes
Wu
V1.00 2014/06/28 Ma Yongchao First edition
ZeXian
Add notes: UGloAc.tTrueQ and

Wu
V1.10 2015/05/20 UGloAc.tTrueQForced must be less than
ZeXian
or equal to the RAB waiting timer of CN.
© 2015 ZTE Corporation. All rights reserved.

ZTE CONFIDENTIAL: This document contains proprietary information of ZTE and is not to be disclosed or used
without the prior written permission of ZTE.
Due to update and improvement of ZTE products and technologies, information in this document is subjected to
change without notice.
ZTE Confidential Proprietary 1

Congestion Control
TABLE OF CONTENTS
1 Feature Attribute ............................................................................................... 5
2 Overview ............................................................................................................ 5
2.1 Feature Introduction ............................................................................................. 5
2.1.1 ZWF21-04-010 Congestion Control ..................................................................... 5
2.1.2 ZWF21-05-001 Emergency Call ........................................................................... 6
2.1.3 ZWF21-05-005 Service Pre-emption .................................................................... 7
2.1.4 ZWF21-05-023 RAB Queuing .............................................................................. 7
2.2 License Control .................................................................................................... 8
2.3 Correlation With Other Features .......................................................................... 8
3 Technical Description ....................................................................................... 9

3.1 ZWF21-04-010 Congestion Control ..................................................................... 9
3.1.1 Service Pre-emption .......................................................................................... 12
3.1.2 RAB Queuing ..................................................................................................... 12
3.1.3 DCH Downgrade ................................................................................................ 12
3.1.4 Resource Pre-emption at lur Interface................................................................ 18
3.1.5 Node B Common Measurement ......................................................................... 19
3.2 ZWF21-05-005 Service Pre-emption .................................................................. 19
3.3 ZWF21-05-023 RAB Queuing ............................................................................ 25
3.4 ZWF21-05-001 Emergency Call ......................................................................... 26
3.5 Handling Strategy in Case of Threshold-Crossing Bandwidth Utilization ............ 27
4 Parameters....................................................................................................... 27
4.1 Common Parameters ......................................................................................... 27
4.2 ZWF21-04-010 Congestion Control Parameters ................................................ 29
4.3 ZWF21-05-023 Parameters Related to RAB Queuing ........................................ 31
4.4 Parameters Related to Bandwidth Handling Strategy......................................... 33
5 Related Counters and Alarms ........................................................................ 34

5.1 Related Counters ............................................................................................... 34
5.2 Related Alarms .................................................................................................. 36
6 Engineering Guide .......................................................................................... 36

6.1 Application Scenario .......................................................................................... 36
6.2 Feature Activation Procedure ............................................................................. 36
6.2.1 ZWF21-04-010 Congestion Control ................................................................... 36
6.2.2 ZWF21-05-001 Emergency Call ......................................................................... 40
6.2.3 ZWF21-05-005 Service Pre-emption .................................................................. 40
6.2.4 ZWF21-05-023 RAB Queuing ............................................................................ 40

Congestion Control
6.3 Feature Validation Procedure ............................................................................ 41

6.3.4 ZWF21-05-023 RAB Queuing ............................................................................ 43
6.4 Feature Deactivation Procedure......................................................................... 44
6.4.4 ZWF21-05-023 RAB Queuing ............................................................................ 44
6.5 Impact on the Network ....................................................................................... 44
7 Abbreviation .................................................................................................... 45
8 Reference Document....................................................................................... 46

Congestion Control
FIGURES
Figure 3-1 Resource Pre-emption Flow .............................................................................11

Figure 4-1 Parameter List 1 ...............................................................................................27
Figure 6-1 Parameter Configuration 1 ................................................................................37
TABLES
Table 2-1 License Control List ............................................................................................ 8

Table 3-1 Definition of RAB Pre-emption Capability in 3GPP Protocols .............................20
Table 5-1 Counter List .......................................................................................................34
Table 6-1 Feature Validation Procedure – Congestion Control ..........................................41
Table 6-2 Feature Validation Procedure – Emergency Call ................................................42
Table 6-3 Feature Validation Procedure – Service Pre-emption .........................................42
Table 6-4 Feature Validation Procedure – RAB Queuing ...................................................43

Congestion Control
1 Feature Attribute
RNC Version: [ZXWR RNC V3.13.10.15/ZXUR 9000 V4.13.10.15]
Node B Version: [ZXSDR V4.13.10.20]
Attribute: [Optional]
Involved NEs:
NE Name Related or Not Special Requirement
UE √ None
Node B √ None
RNC √ None
MSC - None
MGW - None
SGSN - None
GGSN - None
HLR - None
“√”: Involved
“-”: Not involved
2 Overview
2.1 Feature Introduction
2.1.1 ZWF21-04-010 Congestion Control
Congestion occurs if uplink or downlink load reaches or exceeds the admission threshold
and new service requests fail due to insufficient resources. In this case, congestion
control is required. During congestion, the system should decrease the system load and
release some resources by forcible release and rate reduction according to the
requirement of the service delay and priority instead of rejecting service requests directly.

Congestion Control
The congestion control increases the access success rate so that system capacity is fully
used.
If congestion occurs in the system, ZTE RAN can trigger resource preemption to ensure
the services of high-priority subscribers and improve the access success rate. The
following two congestion control strategies are used:
 Service pre-emption: High-priority services pre-empt with lower-priority

services.
 Rate downgrade: This strategy is used to improve the access success rate by
decreasing the data traffic rate of some online subscribers.
If congestion occurs, ZTE RAN queues the service requests that support congestion
queuing. After the load is decreased, the system schedules services in the congestion
queue according to the service priorities so that high-priority subscribers can obtain
preferential resources.
ZTE RAN can trigger congestion control in the target cell of a handover if admission
failure occurs during the handover, which improves the handover success rate.
ZTE RAN supports congestion control process on the Iur interface. The SRNC can
process congestion control messages (as defined in the 3GPP RNSAP) received from
the DRNC.
Note:
The congestion control feature described in this guide is only applicable to R99 cells. For
congestion control related to HSDPA, HSUPA, DC-HSDPA, and DC-HSUPA, refer to
ZTE UMTS HSDPA Introduction Feature Guide, ZTE UMTS HSUPA Introduction
Feature Guide, ZTE UMTS DC-HSDPA Feature Guide, and ZTE UMTS DC-HSUPA
Feature Guide.
2.1.2 ZWF21-05-001 Emergency Call
In general, an emergency call is identified by a UE. If a user dials an emergency service

number, the UE identifies the calling reason as Emergency Call in the RRC connection
setup request message or the initial UE message.

Congestion Control
If a user in roaming state dials a local emergency service number but the UE fails to
identify this number, the call is not identified as Emergency Call. In this situation, the CN
needs to actively monitor the called number. If a local emergency service number is
detected, the CN can configure a special priority for the service during RAB
establishment. The ZTE RAN equipment can map the special priority to the highest
priority to ensure the QoS of the emergency call service.
The ZTE RAN equipment provides preferential services for emergency calls so that
sufficient resources can be allocated to the emergency calls in different scenarios, such
as access admission, congestion, and overload.
2.1.3 ZWF21-05-005 Service Pre-emption
Service pre-emption refers to a process where the system with insufficient resources
releases the resources allocated to a lower-priority service so that a new
preemption-capable higher-priority service can access the system. The CN determines
whether a service is pre-emption capable and whether a service can be pre-empted and
notifies the RNC of the pre-emption configuration through an RAB assignment request
message. In general, RT services can pre-empt NRT services and higher-priority
services can pre-empt lower-priority services.
The ZTE RAN equipment can identify the pre-emption capability parameters configured
for RAB services by the CN and reallocates resources to services with different priorities
in case of congestion. During the resource reallocation, congestion control priorities are
also considered. The service pre-emption feature ensures that high-priority users and
services can obtain more system resources and better QoS.
2.1.4 ZWF21-05-023 RAB Queuing
During RAB establishment for a new service, if the system load is too heavy with
insufficient resources and the corresponding QoS parameter indicates that this service
supports RAB queuing, the RAB is queued, waiting for resources. The system can
quickly allocate resources to the RAB if some resources are released within a certain
period of time. If no resource is available until the allowed queuing period expires, the
RAB establishment fails.

Congestion Control
In case of heavy load, this feature can queue service requests and attempt to establish
RABs for these services again at appropriate moments, rather than reject the service
requests directly. This feature increases the access success rate. Meanwhile, the
increased RAB establishment delay due to service queuing relieves the impact on the
system load caused by repeated access attempts.
The ZTE RAN equipment supports RAB queuing during RAB establishment and
incoming relocation. Whether a service is queued depends on the corresponding QoS
parameters configured for the service and the user by the CN and the system load.
If multiple services are queued, the ZTE RAN equipment provides preferential services to
higher-priority users.
2.2 License Control
Table 2-1 License Control List
License Configured
Feature ID Feature Name Unit
Control Item NE
ZWF21-04-010 Congestion Control N/A N/A N/A

ZWF21-05-001 Emergency Call N/A N/A N/A
ZWF21-05-005 Service Pre-emption N/A N/A N/A
ZWF21-05-023 RAB Queuing N/A N/A N/A
2.3 Correlation With Other Features
1. Required Features
ZWF21-04-001 Admission Control
2. Mutually Exclusive Features

None
3. Affected Features
None

Congestion Control
3 Technical Description
3.1 ZWF21-04-010 Congestion Control
Congestion control is a resource pre-emption process where several admission and

scheduling strategies are used, including service pre-emption, DCH downgrade, and
RAB queuing. If congestion occurs in the system, resource pre-emption can be triggered
to ensure the services of higher–priority subscribers and improve the call success ratio.
The following describes the main strategies used in congestion control:
 Service pre-emption: Higher-priority services can pre-empt lower-priority services.

By pre-empting the resources of lower-priority subscribers, higher-priority
subscribers can access the system quickly. This feature reflects service
differentiation between subscribers.
 RAB queuing: A service supporting RAB queuing can be queued to wait for being
scheduled again when the service request is rejected. This feature increases the
access success rate.
 Downgrade: This feature is used to release resources by decreasing the data traffic
rate of online subscribers so that the call success ratio is increased.
The following provides the definitions of different priorities that are used in the congestion
control strategies.
 Basic Priority of RNC-BP
The Basic Priority (BP) is determined by two factors: ARP (Allocation/Retention

Priority) and Traffic Class. ARP is mapped and transferred to the RNC by the core
network QoS. Traffic Class indicates the type of the originated service. The ZTE
RNC extends the traffic classes defined in the protocol. For example, the special
Traffic Handling Priority (THP) of interactive service is also regarded as a value of
Traffic Class for the BP mapping.
 Application Priority of RNC-AP

Congestion Control
The Application Priority (AP) is determined by the BP, the radio bearer type (DCH,
HSPA, or MBMS), and the rate of existing subscribers. In the event of congestion or
overload, Application Priority of RNC-AP is used to select subscribers/services for
decreasing the load. The bearer type and rate are also considered because
different bearer types require different priorities and the rate is a key factor used to
control of the system load and relieve traffic congestion. For example, the system
load can be decreased quickly if a high rate service is selected for downgrade.
 Scheduling Priority of RNC-SP
The Scheduling Priority (SP) used in the RRM strategy of the RNC is determined by
the BP and the radio bearer type. The SP is used to select subscribers during
service pre-emption and admission of queued subscribers. Refer to the ZTE UMTS
QOS Guarantee Feature Guide for detailed information about mapping relations,
configuration methods, and examples of the priorities mentioned above.
The following describes the resource pre-emption process:
If a service fails to be admitted (excluding failure caused by an online rate upgrade

request) due to congestion caused by insufficient hard resources, and the service is
pre-emption capable, service pre-emption is performed. If the service pre-emption fails
and the service supports queuing, the service is queued and a downgrade procedure is
triggered to decrease the rate of online subscribers according to the configured rate
levels. If the service does not support queuing, a downgrade procedure is immediately
triggered to decrease the rate of online subscribers once. If the service is not
pre-emption capable, or the service fails to be admitted due to congestion caused by
insufficient soft resources, the system checks whether the service support queuing. If the
service supports queuing, the service is queued and a downgrade procedure is triggered.
If the service does not support queuing, a downgrade procedure is triggered
immediately.
If the admission failure is caused by an online rate increase request, the service is
queued directly. For the subsequent actions, refer to the related sections in this guide.
The following figure shows an overall resource pre-emption flow during RAB assignment
for a UE for better understanding of the sequence of pre-emption and downgrade
actions.

Congestion Control
Figure 3-1 Resource Pre-emption Flow
RAB Assignment Request

(UE -A)
Yes UE-A accesses the

Is CAC successful?
network successfully.
No
Is the RAB pre- Yes Service pre-emption is

emption capable? performed.
No
No No
Does the RAB Is pre-emption
support queuing? successful？
Yes Yes
Downgrade is triggered The RAB of UE-A is

to decrease the rate of UE-A accesses the
queued. network successfully.
online UEs.
The RAB establishment
of UE-A fails.
Downgrade is triggered
to decrease the rate of
online Ues.
The RAB is scheduled

when the next
scheduling time is
reached and UE-A
attempts to access the
network again.
Note:
1. The downgrade procedure in the flow is applied to DCHs.
2. The scheduling time mentioned in the flow is described in Section 3.3

ZWF21-05-023 RAB Queuing.
3. Hard resources include downlink code resources and Node B CEs (uplink and
downlink). Soft resources include downlink TCP and uplink RTWP.

Congestion Control
3.1.1 Service Pre-emption
For the details, refer to Section 3.2 ZWF21-05-005 Service Pre-emption.
3.1.2 RAB Queuing
For the details, refer to Section 3.3 ZWF21-05-023 RAB Queuing.
3.1.3 DCH Downgrade
If the switch (ULdCtrl.decRateSw) that determines rate downgrade in advance of

preemption is enabled, the DCH downgrade is triggered by a failure of an RRC setup
request, the first RAB setup request, or an incoming relocation request due to congestion
caused by lack of code resources and/or CE resources. The maximum number of
lower-priority services that are selected for downgrade at a time is determined by
ULdCtrl.maxNumUeOfDecRat + 3. If the request still fails after the downgrade, the
subsequent procedures are performed, including service pre-emption, RAB queuing, and
DCH downgrade.
If a rejected subscriber has no preemption capability or fails to pre-empt other online

subscribers, and the subscriber does not support queuing, a downgrade procedure is
triggered directly to decrease the rates of online services. If the rejected subscriber
supports queuing, the subscriber is queued and a downgrade procedure is triggered to
release some resources for the services in the queue or the services to be admitted.
Note: All the following principles are applicable in both the uplink and downlink.
The congestion causes that can trigger downgrade include:
 Downlink: lack of code resources (hard resources), lack of Node B’s CE resources
(hard resources), and lack of power resources (soft resources).
 Uplink: lack of Node B’s CE resources (hard resources), and uplink interference
(soft resources).
According to the above congestion causes, the following procedures may trigger
downgrade: RRC setup, RAB setup, RAB modification or RB reconfiguration, R99 DCH
rate upgrade, incoming SRNC relocation, Iur RL setup, intra-RNC soft or hard handover,

Congestion Control
incoming Inter-RAT handover (ISHO), incoming Inter-Frequency handover (IFHO),

incoming HS-DSCH serving cell change, inter-RNC soft or hard handover (SHO/HHO),
and the second RAB setup for the same user.
Different policies are used to trigger downgrade because the queue contains new
services and ongoing services requesting a rate increase.
The new services include services in the first RAB assignment, services in non-first RAB
assignment for emergency calls, CS services initiated in case of existing PS services,
and services in relocation.
A service in non-first RAB assignment has no pre-emption capability and cannot be

queued. However, the service can trigger downgrade in case of access failure.
If an RRC connection establishment request is rejected in a cell due to congestion and

the congestion cause is not a large amount of users, a DCH downgrade process is
triggered in the cell.
Common services and services in handover, for which queuing is not allowed, are not
placed in the queue. These services can trigger downgrade in the cell where they are
rejected, using the same downgrade policy as new services. Services in handover
include those in intra-RNC soft and hard handovers, incoming inter-RAT handovers,
incoming inter-frequency handovers, and inter-RNC soft and hard handovers.
The purpose of downgrade triggered by access failure of a service without queuing

capacity is to ensure successful access of the subscriber in a later attempt or direct
access of other subscribers even if the cell is not overloaded.
After a downgrade process is triggered by a service without queuing capacity, the timer
used to prohibit congestion control is started. The value of this timer is 10 seconds.
Before this timer expires, no rate increase request from an ongoing service is processed.
The purpose of this timer is to avoid ping-pong rate adjustments of ongoing services.
Note 1: Transport resources at the lub interface and lu interface are allocated
dynamically. In case of congestion due to insufficient transport resources, the bandwidth
is allocated to voice services at the Maximum Bit Rate (MaxBR), allocated to streaming
services at the Guaranteed Bit Rate (GBR), and allocated to I/B services at the minimum
bit rate. When sufficient transport resources are available, the assigned bandwidth

Congestion Control
(MaxBR) can be allocated to each service. In this case, the allocation of transport
resources are subjected to dynamic adjustment based on resource occupation,
regardless of bandwidth allocation notifications among individual network elements.
Downgrade is not implemented in congestion due to insufficient transport resources at
the Iub interface and Iu interface. The characteristics and priorities of services are
considered during dynamic allocation of transport resources at the lub interface and lu
interface. For the mutual influence between the RT service rates and NRT service rates
based on transport resources, refer to the ZTE UMTS RNC ATM Transmission Feature
Guide (v3) and ZTE UMTS RNC ATM Transmission Feature Guide (v4).
3.1.3.1 Downgrade Triggered by New Services
Downgrade triggered by a new service is specific to individual RABs. If a subscriber has

multiple concurrent RABs, these RABs are independent of each other without a coupling
relationship when they are selected for downgrade.
 Time for triggering downgrade

For a new service without queuing support, downgrade is triggered once upon
rejection of the service. RRC establishment and handover services are regarded as
new services without queuing support. For a service with queuing support,
downgrade is triggered when the service is queued and triggered again when a
common measurement is reported. Downgrade is triggered multiple times as long
as the queue contains a service limited by only hard resources. If the queue
contains services with limited soft resources, downgrade can be triggered only
when a common measurement is reported.
 The principles for selecting online services to be downgraded are as follows:

The online RABs are sorted according to their Application Priorities (APs). The
system selects RABs for downgrade in ascending order of the APs.
ULdCtrl.maxNumUeOfDecRat determines the maximum number of RABs that can be
selected during a downgrade procedure, meaning that multiple online RABs may be
downgraded when a new subscriber accesses the network. If multiple RABs have
the same AP, one or more of these RABs may be selected for downgrade
randomly.

Congestion Control
During a downgrade procedure triggered by a new service or a service handover,

the AP corresponding to the service that triggers the downgrade and the APs
corresponding to the online services to be downgraded are not compared in order
to guarantee the call success ratio or reduce the call drop rate during handover.
The Application Priority (AP) of a service reflects the Basic Priority (BP), current
rate, and bearer type of the service. For the mapping methods and configuration
examples of APs, refer to the ZTE UMTS QOS Guarantee Feature Guide. CS AMR,
PS RT, and PS NRT services can be the downgrade targets.
 After an online service is selected for RAB downgrade, the following method is used
to determine the target rate level:
The rate of a PS service can be decreased by several DRBC rate levels each time.
The maximum number of DRBC rate levels is determined by ULdCtrl.ulMaxDecStg
in the uplink and ULdCtrl.dlMaxDecStg in the downlink. The rate of an interactive or
background (I/B) service can only be decreased to the minimum DRBC rate level.
The rate of a streaming (S) service can only be decreased to the Guaranteed Bit
Rate (GBR). If Iu-up mode version 2 is used, a CS AMR service is downgraded
according to the type of rate assigned to the lu interface. If Iu-up mode version 1 is
used, a CS AMR service is downgraded according to the rate levels allowed by the
RNC. Different DRBC rate levels are defined in the uplink and downlink. For
detailed definitions of the uplink and downlink DRBC rate levels, refer to the ZTE
UMTS DRBC Algorithm Feature Guide. For the application of available rate levels
corresponding to AMR Iu-up mode version 1 and Iu-up mode version 2, refer to the
ZTE UMTS WB-AMR Rate Control Feature Guide and ZTE UMTS NB-AMR Rate
Control Feature Guide.
3.1.3.2 Downgrade Triggered by Rate Increase Requests From Online Services
Downgrade triggered by a rate increase request from an online service is specific to

individual RABs. If a subscriber has multiple concurrent RABs, these RABs are
independent of each other without a coupling relationship when they are selected for
downgrade.
The time of triggering downgrade is the same as that described in the “Downgrade
Triggered by New Services" section.

Congestion Control
To ensure fairness between subscribers and prevent ping-pong adjustment, the following
two factors are considered for each online service during downgrade triggered by a rate
increase request from an online service: the comparison result between the current rate
and the Nominal Bit Rate (NBR) and the Application Priority (AP) to which the actual rate
assigned to the service is mapped. The downgrade principles are as follows:
1. All online services (CS, PS RT and PS NRT) in a cell are divided into three sets (set
1, set 2, and set 3) according to the comparison results between the current service
rate and the NBR. Set 1 contains the services at a current rate lower than the NBR.
Set 2 contains the services at a current rate equal to the NBR. Set 3 contains the
services at a current rate higher than the NBR.
2. The relationship among the priorities of set 1, set 2, and set 3 is: set 1 > set 2 > set
3. A rate increase request from a service in set 1 can trigger a downgrade of
services in set 2 and set 3. A rate increase request from a service in set 2 can
trigger a downgrade of services in set 3. In addition, downgrade is allowed only if
the set that the service whose rate is increased belongs to has a lower priority than
the set that the service whose rate is decreased belongs to. For example, if service
A in set 1 falls into set 2 after its rate is increased to the target rate and service B in
set 2 falls into set 1 after its rate is decreased, service A is not allowed to trigger the
downgrade of service B. This principle prevents ping-pong rate adjustments.
3. If the service requesting rate increase and the service available for downgrade
belong to the same set, the former must have a higher AP than the latter, and the
former with its rate increased must have an AP same as or lower than the latter with
its rate downgraded.
The uplink NBR (UBasPri.ulNormBitRate) and downlink NBR (UBasPri.DlNormBitRate)

are configured separately, which are obtained according to the Basic Priority (BP) of a
UE.
After an online service is selected for RAB downgrade, the following method is used to
determine the target rate level: The rate of the online service is decreased by one level at
a time based on the DRBC rate levels. If the online service is an I/B service, the lowest
target rate is the rate at the lowest DRBC rate level. If the online service is a C/S service,
the lowest target rate is the Guaranteed Bit Rate (GBR). Different DRBC rate levels are

Congestion Control
defined in the uplink and downlink. For detailed definitions of the uplink and downlink
DRBC rate levels, refer to the ZTE UMTS DRBC Algorithm Feature Guide.
The target rate of the online service requesting a rate increase is at a higher DRBC rate
level than the current rate of the service. For details, refer to the ZTE UMTS DRBC
Algorithm Feature Guide.
3.1.3.3 Execution of Rate Increase and Decrease Actions
The lub interface increases or decreases service rates through radio link reconfiguration.
The Uu interface increases or decreases service rates through RB reconfiguration. If a
UE is in macro diversity state, the lub interface reconfigures multiple links at the same
time.
If congestion occurs in a cell corresponding to any link of a UE in macro diversity state,

this UE is selected as the downgrade target and all links of this UE are downgraded. The
reason is that an R99 UE supports only one transport format and one transport format
set. Different links of the UE must have the same transport format and transport format
set. In case of macro diversity, all links of the UE may be managed by the SRNC or the
DRNC, or some links are managed by the SRNC and the others are managed by the
DRNC.
3.1.3.4 Forbidding of AMR Downgrade
Due to the impact of AMR downgrade on user experience, an RNC-level switch

(URncInfo.conForbAmrSwit) is defined to control whether AMR downgrade is allowed.
If the switch is set to “1: forbidden”, AMR services cannot be selected as downgrade
targets.
If the switch is set to “0: not forbidden”, AMR services can be selected as downgrade
targets. The downgrade principles are the same as those described in Section 3.1.3.1
Downgrade Triggered by New Services and Section 3.1.3.2 Downgrade Triggered by
Rate Increase Requests From Online Services.

Congestion Control
3.1.3.5 Congestion Control in Case of CE Resource Sharing Among Cells in

Different PLMNs
For the details, refer to the ZTE UMTS RAN Sharing Feature Guide.
3.1.4 Resource Pre-emption at lur Interface
Congestion control is determined by a CRNC to trigger a load decrease. If the CRNC of a

UE is a DRNC, the CRNC cannot perform downgrade and RAB release for this UE. The
CRNC must notify the SRNC of available UEs that can be degraded through the Iur
interface
In case of congestion, the CRNC treats UEs whose radio links are set up through the lur
interface the same as UEs of this RNC (SRNC) when selecting targets for load decrease.
If a UE whose radio link is set up through the lur interface is selected, only downgrade
can be triggered. Service pre-emption cannot be triggered.
For a UE whose radio link is set up through the Iur interface, the BP of RNC used by the
DRNC is obtained from the Frame Handling Priority (FHP) in the RL setup request. The
Frame Handling Priority, being obtained by the SRNC from the BP mapping table,
reflects the information about ARP and Traffic Class. Because the lur interface cannot
carry the Traffic Handling Priority, the FHP is used during downgrade.
If the SRNC is not a ZTE RNC, the ZTE DRNC can use the Frame Handling Priority
directly as the BP because the FHP also reflects the data processing priority of an RAB
and can be regarded as equivalent to the service priority.
According to the previously described downgrade policies, the following describes the
handover scenarios that can trigger downgrade:
1. In an intra-RNC SHO, if congestion occurs in a non-best cell of a UE, the access of

a new service in the non-best cell may trigger downgrade of the UE.
2. In an intra-RNC SHO, if congestion occurs in the best cell of a UE, the access of a
new service in the best cell may trigger downgrade of the UE.
3. In an inter-RNC SHO, if congestion occurs in a cell of the DRNC to which a UE is

connected, the access of a new service in the cell may trigger downgrade of the UE.

Congestion Control
4. In an inter-RNC SHO, if congestion occurs in the SRNC to which a UE is connected,

the access of a new service in the cell may trigger downgrade of the UE (including
all links of the UE).
5. In an inter-RNC SHO, if a UE fails to add a link in a cell of the DRNC, the cell may
trigger downgrade of other UEs in the cell.
3.1.5 Node B Common Measurement
3.1.5.1 Uplink Interference Measurement
The uplink interference is estimated by the Received Total Wideband Power (RTWP)
measured on the Iub interface. The Node B reports the measurement result to the RNC
through the Iub interface periodically. For Node B common measurement, refer to the
ZTE UMTS Node B Management Feature Guide.
3.1.5.2 Downlink Power Measurement
The downlink power is estimated by the downlink Transmitted Carrier Power (TCP) on
the Iub interface. The Node B reports the measurement result to the RNC through the Iub
interface periodically. For Node B common measurement, refer to the ZTE UMTS Node
B Management Feature Guide.
3.2 ZWF21-05-005 Service Pre-emption
The purpose of service pre-emption is to ensure immediate access of subscribers with

higher priorities during congestion.
The following describes the entire service pre-emption process, including the application
of interface information, application scenarios, selection of subscribers for service
pre-emption, and service pre-emption in case of multiple RABs.
Note: All the principles involved in the following process are applicable in both the uplink
and downlink.

Congestion Control
 IE Information Application During Service Pre-emption:

If a service request is originated during congestion, the system can release an
existing RAB forcibly according to the priority and pre-emption capability of the new
service. As specified in 3GPP protocols, the pre-emption capability is determined by
the CN through the Allocation/Retention Priority (ARP) IE in the RAB assignment
message or relocation request message during service setup or in the RL setup
message during handover over the Iur interface. The following table describes the
IEs that determine the pre-emption capability of an RAB.
Table 3-1 Definition of RAB Pre-emption Capability in 3GPP Protocols
IE Value Meaning
Pre-emption may trigger pre-emption The RAB has the service pre-emption
Capability capability.
shall not trigger The RAB does not have the service
pre-emption pre-emption capability.
Pre-emption pre-emptable The RAB can be released by other RABs

Vulnerability forcibly.
not pre-emptable The RAB cannot be released by other

RABs forcibly.
Priority no priority The RAB does not have the service

Level pre-emption capability and cannot be
released by other RABs forcibly.
1-14 The resource allocation priority of the

RAB. The value "1" stands for the highest
priority level.
If the RAB assignment message, relocation request message, or RL setup

message contains the ARP IE, Priority Level, Pre-emption Capability, and
Pre-emption Vulnerability in this IE determine whether the RAB has the pre-emption
capability and whether the RAB is pre-emptable.
If the RAB assignment message, relocation request message, or RL setup

message does not contain the ARP IE, the RAB has no preemption capability but
can be released forcibly during service pre-emption due to its lowest priority. The
ARP IE is optional in the RAB assignment message and relocation request
message. If the RAB assignment or relocation request message does not contain

Congestion Control
this IE, the RNC needs to map the RAB to a priority for completing the entire
process. In the ZTE RNC, the Basic Priority (BP) of an RAB without ARP
information is set to 0, which is the lowest priority. As specified in 3GPP TS 25.413,
if the RAB assignment message carries no ARP information, this RAB is regarded
as incapable of pre-emption and subjected to service pre-emption by default.
 Application Scenarios of Service Pre-emption

Service pre-emption can be triggered only by RRC connection establishment for an
emergency call, the first RAB assignment (for an RT or NRT service), non-first RAB
assignment for an emergency call, relocation due to 2G-to-3G handover or 3G
RNC-to-RNC relocation, or a CS service initiated after a PS service in the case of
lack of hard resources.
If congestion occurs due to a lack of hard resources in the RRC signaling phase
and the RRC connection establishment cause is not an emergency call, the UE
attempts to access the FACH instead of triggering service pre-emption.
If congestion occurs due to a lack of hard resources in the RRC signaling phase
and the RRC connection establishment cause is an emergency call, service
pre-emption is triggered. If service pre-emption fails, the UE attempts to access the
FACH again. If congestion occurs due to a lack of hard resources in the RAB
assignment phase for an emergency call, service pre-emption can be triggered
again.
If congestion occurs due to a lack of resources in case of high-speed RRC signaling,

low-speed signaling is used for the access attempt. If the service is not permitted
again, a congestion control process is triggered by the low-speed RRC
establishment. If congestion occurs due to lack of hard resources, a service
pre-emption process is determined depending on whether the service is an
emergency call.
For the detailed information about congestion control in case of concurrent PS and
CS services, refer to the “Congestion Control in Case of PS and CS Services” part
in this section.
 RAB Selection Mechanism During Service Pre-emption

If an RAB with pre-emption capability triggers a service pre-emption process, only

Congestion Control
RABs with Scheduling Priorities (SPs) lower than the SP of this RAB and
Pre-emption Vulnerability Indicators (PVIs) set to “pre-emptable” can be selected as
the pre-emption targets.
If an RAB meets the service pre-emption conditions above, the RAB can be forcibly
released only when the calculation result shows that the cell resources after this
RAB is released can meet the resource requirement of the RAB triggering this
service pre-emption process. Otherwise, this RAB cannot be selected as the
pre-emption target because the release of this RAB cannot ensure successful
access of the originator of the service pre-emption. For example, if an originator of
the service pre-emption needs a code with SF 64, but the minimum SF after the
release of the ongoing RAB with the lowest priority is 128, the RABs, even with the
lowest SP, cannot be released forcibly.
Moreover, the number of RABs that can be released forcibly by an originator of the
service pre-emption is limited to avoid drops of ongoing services. If only one type of
hard resource is insufficient for the originator, only one RAB can be forcibly
released for this originator. If more than one type of hard resources is insufficient,
two RABs can be released forcibly for this originator.
A target RAB for service pre-emption can be an RAB used for an RT or NRT
service.
 Principles of Combining Pre-emption Capability and Scheduling Priority in Case of

Multiple RABs
If the originator of the service pre-emption has multiple RABs, the pre emption
capabilities of these RABs are combined first. As long as one of these RABs has
the pre-emption capability, the originator is deemed as capable of pre-emption. The
highest SP of these RABs is compared with the SP of the subscriber to be released
forcibly.
If multiple RABs belong to the subscriber to be released forcibly, the highest RAB
SP. In addition, service pre-emption is allowed only when all these RABs are
pre-emptable, meaning that their PVIs are set to “pre-emptable”.
 Execution of Service Pre-emption

After the originator determines a target subscriber for service pre-emption, the

Congestion Control
following service pre-emption actions are executed: deleting macro diversity links in
the congested cell and releasing RABs. If this subscriber has multiple links and the
congested cell is not the best cell, the links of the congested cell are deleted. If this
subscriber has only one link in the congested cell or the congested cell is the best
cell of this subscriber, all RABs belonging to this subscriber are released. The RAB
release can ensure quick access of the originator because the RAB release can be
completed with a high success ratio in a shorter time than downgrade and FACH
conversion, which prevents the originator from waiting for a long time during the
access process. In the network, a minority of subscribers with the highest priority
has the pre-emption capability and a minority of subscribers with the lowest priority
is pre-emptable. The service pre-emption ensures the access of subscribers with
the highest priority within the acceptable delay by dropping online subscribers with
the lowest priority.
 Handling of Failed Service Pre-emption

A service pre-emption process fails if the originator fails to select a target subscriber
for service pre-emption due to a cause, for example, all online subscribers have
higher scheduling priorities than the originator; all online subscribers are not
pre-emptable, or the resources of the online subscribers cannot meet the
requirement of the originator. If the originator is allowed for queuing, the originator is
placed in the queue, waiting for being scheduled. At the same time, a downgrade
process is triggered. If the originator is not allowed for queuing, a downgrade
process is triggered once even if the cell is not overloaded, so that the access of the
originator can be permitted upon a later request or the access of other subscribers
can be directly permitted. or other subscribers
 Directed Retry of AMR Subscribers

During admission control for an AMR subscriber, if congestion occurs due to a lack
of resources and the AMR subscriber has no pre-emption capability or the queuing
of the subscriber is not allowed, a directed retry to 2G is triggered. If the subscriber
has pre-emption capability or the queuing is allowed, the previously-described
service pre-emption and queuing actions are executed. A directed retry to 2G is
triggered if the service pre-emption or queuing fails.

Congestion Control
 Preemption Policy for Handover Subscribers

The access failure of a handed over subscriber triggers a downgrade process
instead of a service pre-emption or queuing process,
 Congestion Control in Case of Concurrent PS and CS Services

If a subscriber has an ongoing PS service on an RRC in CELL_FACH or
CELL_DCH state and a CS service is initiated, the minimum DRBC rate is
re-allocated to the PS service and an access attempt to the DCH is made for the PS
and CS services. If the access fails, the rate 0/0kbps is re-allocated to the PS
service and an access attempt to the DCH is made for the PS and CS services. If
the access fails again, only the CS service is considered for congestion control.
If the Pre-emption Capability IE of the CS service is set to ”may trigger pre-emption”,

a pre-emption procedure is triggered. If the pre-emption procedure fails or the
Pre-emption Capability IE of the CS service is set to ”shall not trigger pre-emption:
but the queuing is allowed for the CS service, a downgrade procedure is triggered.
If the queuing of the CS service is not allowed, the downgrade procedure is
triggered only once.
If the subscriber belongs to the DRNC, the parameter

UIurLink.RNCFEATSWITCHBIT18 is used to indicate whether the DRNC supports
PS (0/0kbps). If PS (0/0kbps) is supported, the service pre-emption process is the
same as that for the SRNC, meaning that the rate 0/0kbps is re-allocated to the PS
service and an access attempt to the DCH for the PS and CS services is made. If
PS (0/0 kbps) is not supported, the service access fails and a DCH downgrade
process is triggered.
If the CS service is an emergency call, the default value of Pre-emption Capability

is ”may trigger pre-emption” and the default value of Pre-emption Vulnerability
is ”not pre-emptable”.
 Congestion Control in Case of CE Resource Sharing Among Cells in Different

PLMNs
For the details, refer to the ZTE UMTS RAN Sharing Feature Guide.

Congestion Control
3.3 ZWF21-05-023 RAB Queuing
If RAB queuing is allowed, a service can be queued after being rejected due to
congestion in the cell. An access attempt can be made again for the queued service
when idle resources are available in the cell. The RAB queuing feature improves the
access success ratio and ensures differentiated QoS.
The Queuing Allowed IE in the RAB ASSIGNMENT REQUEST or RELOCATION

REQUREST message determines whether an RAB can be queued. The queuing is
allowed when the value of Queuing Allowed is TRUE. Otherwise, the queuing is not
allowed. For a service request from the DRNC, if the RADIO SETUP REQUEST
message over the Iur interface contains the Allowed Queuing Time IE, the queuing is
allowed. Otherwise, the queuing is not allowed.
If congestion occurs in a cell, new service requests and rate upgrade requests are
scheduled according to the Scheduling Priorities (SPs) of the queued services. The
services with higher SPs are scheduled first, meaning that the resources released by
congestion control are assigned to services with higher SPs.
To improve the call success ratio during admission control for the queued services, new
service requests are scheduled before rate upgrade requests. As long as there is a new
service request in the queue, no rate upgrade request is scheduled. The new service
requests include RAB assignment requests and relocation requests.
New service requests are scheduled according to their scheduling priorities. A new
service request with a higher SP is scheduled prior to another with a lower SP. For the
SP mapping policies, refer to the ZTE UMTS QOS Guarantee Feature Guide. When
the rate upgrade requests from ongoing services are sorted, the current rates allocated
to these services are considered to ensure the fairness and priorities of the services. The
services with current rates lower than the NBR are put into set 1, the services with
current rates equal to the NBR are put into set 2, and the services with current rates
higher than the NBR are put into set 3. The services in each set are sorted in descending
order of SPs. Services with higher SPs are scheduled first.
The uplink and downlink NBRs are configured separately: UBasPri.ulNormBitRate and
UBasPri.DlNormBitRate.

Congestion Control
The following describes the time for scheduling the queued services. If the service with
the highest SP is queued due to lack of soft resources, the service cannot be scheduled
for admission control until a common measurement is reported, because whether
sufficient soft resources are available is determined on the basis of the common
measurement report. If the service with the highest SP is queued due to lack of only hard
resources, this service is scheduled for admission control upon release or downgrade of
any other ongoing services. The service can also be rescheduled when a common
measurement is reported. Therefore, services queued due to lack of hard resources
more chances of being scheduled for admission control.
Note 1: The OMC parameter UGloAc.qLength determines the queue length. The OMC
parameter UGloAc.tTrueQ determines the time that a service queued during RAB
establishment can wait for being scheduled The OMC parameter UGloAc.tTrueQReloc
determines the time that a service queued during relocation can wait for being
scheduled.
Note 2: For an AMR or CS 64K service, if the RAB assignment message or the SRNC
relocation request carries no queue information or indicates that queuing is not allowed
for the RAB, it depends on the forcible queuing switch whether the RAB can be queued.
The forcible queuing switch for AMR services is UGloAc.forcQueSwiAMR, the forcible
queuing switch for CS 64K services is UGloAc.forcQueSwiCS64, and the maximum
queuing time is determined by the parameter UGloAc.tTrueQForced. If the RAB
assignment message or the SRNC relocation request indicates that the RAB can be
queued, the RAB is not restricted by the forcible queuing switch.
Note 3: UGloAc.tTrueQ and UGloAc.tTrueQForced must be less than or equal to the

RAB waiting timer of CN.
3.4 ZWF21-05-001 Emergency Call
For an emergency call, the default value of Pre-emption Capability is “may trigger
pre-emption” and the default value of Pre-emption Vulnerability is ”not pre-emptable”.
During the admission process of an emergency call, the system only determines whether
sufficient hard resources (code resources and Node B CE resources) are available. If
congestion occurs due to lack of hard resources, the emergency call can trigger forcible

Congestion Control
release of other non-emergency calls in the cell. Ongoing emergency calls cannot be
forcibly released.
3.5 Handling Strategy in Case of Threshold-Crossing

Bandwidth Utilization
If the transport bandwidth utilization exceeds the specified threshold and the bandwidth
release switches are enabled, the RNC releases the maximum number of UEs
(URncFunction.bwOvldRelUeNum) at a time in ascending order of basic priority until the
bandwidth utilization decreases to a value lower than the threshold. For how to determine
whether the bandwidth utilization exceeds the threshold, refer to the ZTE UMTS
Transport CAC Feature Guide. The bandwidth release switches on the Iub, Iu-CS, Iu-PS,
Iur, Iur-g interfaces are UIubLink.bandRelSwitch, UIucsLink.bandRelSwitch ,
UIupsLink.bandRelSwitch , UIurLink.bandRelSwitch, and UIurgLink.bandRelSwitch
respectively.
4 Parameters
4.1 Common Parameters
Figure 4-1 Parameter List 1
Reco
Paramete Value Defaul mmen
GUI Name Parameter Description Unit
r Name Range t Value ded
Value
This parameter indicates

[8,8,8, [8,8,8,
the Nominal Bit Rate
8,8,16, 8,8,16,
DCH (NBR) of downlink (0..384)
UBasPri.dl 16,16, 16,16,
Downlink interactive/background kbps
NormBitR kbps 16,16, 16,16,
Nominal Bit services on a DCH. It is step 1
ate 16,64, 16,64,
Rate mapped from the Basic kbps
64,64, 64,64,
Priority. Traffic with a
64,64] 64,64]
higher basic priority has a

Congestion Control
Reco
Value
higher NBR. DRBC queue
scheduling needs to
sequence online services.
The services with a
current rate lower than the
NBR are put into the
foremost set (set1), the
services with a current
rate equal to the NBR are
put into set2, and the
rate higher than the NBR
are put into the last set
(set3). Then the services
in each set are sequenced
according to their
Scheduling Priorities
(SPs). The service ranking
foremost is scheduled
first.

the nominal bit rate of
uplink
interactive/background
services on DCH, which is
related to the Basic [8,8,8, [8,8,8,
Priority. The higher the 8,8,16, 8,8,16,
(0..384)
UBasPri.ul DCH Uplink basic priority, the higher 16,16, 16,16,
kbps,
NormBitR Nominal Bit the nominal bit rate of the kbps 16,16, 16,16,
step 1
ate Rate service. In the DRBC 16,64, 16,64,
kbps
scheduling, online 64,64, 64,64,
services need to be 64,64] 64,64]
sorted. The services with
a current rate smaller than
the NBR are put into the
foremost set (set1), the

Congestion Control
Reco
Value
rate equal to the NBR are
put into set2, and the
rate larger than the NBR
are put into the last set
(set3). The services in
each set are sorted
according to their
scheduling priorities (SP).
The foremost service is
scheduled first.
4.2 ZWF21-04-010 Congestion Control Parameters
Reco
Value

whether to take the rate
downgrade measure
Switch of
before preemption in case
Rate
of congestion. If this
ULdCtrl.de Downgrade 0: Off
function is enabled, rate N/A Off 1: On
cRateSw ahead of 1: On
downgrade will be
Preemption in
executed before
Congestion
preemption. If this function
is disabled, preemption
will be executed directly.
Switch of This parameter the 0:

is not
URncInfo. 0: not 0: not
Forbidding switch of forbidding AMR forbidden
conForbA N/A forbidd forbidd
AMR deceleration triggered by 1:
mrSwit en en
Deceleration congestion control. When forbidden

Congestion Control
Reco
Value
Triggered by the switch is on, AMR
Congestion speed is forbidden even
Control resource is congested.

Maximum
the maximum number of
Number of
ULdCtrl.dl degraded DRBC steps for
Degraded
MaxDecSt decreasing the data rate 1..8 N/A 1 1
Downlink
g of the selected service
Load Steps
when downlink overload
Every Time
occurs.
Maximum This parameter indicates

Number of the maximum number of
ULdCtrl.ul
Degraded degraded DRBC steps for
MaxDecSt 1..8 N/A 1 1
Uplink Load decreasing the data rate
g
Steps Every for the selected user when
Time uplink overload occurs.
Maximum
Number of
ULdCtrl.m the maximum number of
UE
axNumUe UEs whose rates are 1..100 N/A 3 3
Decreasing
OfDecRat decreased each time
Rate When
when congestion occurs.
Congestion
0: Not
Support
This parameter indicates PS(0
1: 1:
UIurLink.R Whether the adjacent RNC feature kbps /0
Suppor Suppor
NCFEATS Support PS switch, 0 means not kbps)
N/A t PS(0 t PS(0
WITCHBI (0kbps/0kbps support PS (0 kbps /0 1:
kbps /0 kbps /0
T18 ) kbps) and 1 means Support
kbps) kbps)
support. PS(0
kbps /0
kbps)

Congestion Control
4.3 ZWF21-05-023 Parameters Related to RAB Queuing
Reco
Value
0..32, 0
means
queuing
UGloAc.q True Queue the maximum number of
function N/A 16 16
Length Length the congested calls in the
is not
true queue.
supporte
d

Time of True
the maximum wait time in
Queue for
the true queue after the
UGloAc.tT Congested (1..60)s,
call setup request is s 10s 10s
rueQ Service in step 1s
refused by the Call
RAB Setup
Admission Control (CAC)
Process
algorithm.

the maximum wait time in
the true queue for an
Time of True
incoming relocation after
Queue for
the relocation request is
UGloAc.tT Congested (0..60)s,
refused by the Call s 4s 4s
rueQReloc Service step 1s
Admission Control (CAC)
Relocating
algorithm.
into UTRAN
“0” means no queue
process is executed for an
incoming relocation.

the forced queue switch
Forced
UGloAc.fo for AMR services. In the
Queue Switch 0: Off
rcQueSwi condition that there is no N/A 1: On 1: On
for AMR 1: On
AMR queue information or the
Service
assigned RAB has no
queue ability in the AMR

Congestion Control
Reco
Value
RAB assignment
information, if the forced
queue switch is set to
"On", this AMR service
has the queue ability. If
the forced queue switch is
set to “Off”, this AMR
service has not the queue
ability.

the forced queue switch
for CS 64 kbps service. In
the condition that there is
Forced no queue information or
UGloAc.fo Queue Switch the RAB be assigned has
0: Off
rcQueSwi for CS no queue ability in the CS N/A 1: On 1: On
1: On
CS64 64kbps 64 kbps service RAB
service assignment information, if
the forced queue switch is
"On", then this CS 64 kbps
service has the queue
ability.

the maximum time in the
true queue when a service
is forced into a queue. In
Maximum the condition that there is
Time in the no queue information or
UGloAc.tT
True Queue the assigned RAB has no (1..60)s,
rueQForce s 6s 6s
when Service queue ability in the RAB step 1s
d
be Forced assignment information, if
into Queue the forced queue switch is
set to “On”, this RAB has
the queue ability, and this
parameter indicates the
maximum time in the true

Congestion Control
Reco
Value
queue.
4.4 Parameters Related to Bandwidth Handling

Strategy
Recom
Parameter Value Default mende
Name Range Value d
Value
Transport
UIubLink.b BandWidth
the Transport BandWidth 0: Off
andRelSwit Release N/A 0: Off 1: On
Release Switch based on 1: On
ch Switch based
Overload for Iub interface
on Overload
Transport This parameter indicates

UIucsLink. BandWidth the Transport BandWidth
0: Off
bandRelS Release Release Switch based on N/A 0: Off 1: On
1: On
witch Switch based Overload for Iu-cs
on Overload interface
Transport This parameter indicates

UIupsLink. BandWidth the Transport BandWidth
0: Off
bandRelS Release Release Switch based on N/A 0: Off 1: On
1: On
witch Switch based Overload for Iu-ps
on Overload interface
Transport
UIurLink.b BandWidth
andRelSwit Release N/A 0: Off 1: On
ch Switch based
Overload for Iur interface
on Overload

Congestion Control
Recom
Parameter Value Default mende
Name Range Value d
Value
Transport
UIurgLink. BandWidth
bandRelS Release N/A 0: Off 1: On
witch Switch based
Overload for Iur-g interface
on Overload
0-255,
255
means
resource
release is
not
the Release the maximum number of
URncFunct limited by
UE Number UE in a cell whose
ion.bwOvld UE N/A 5 5
when Band transport resource will be
RelUeNum number
Exceeds Limit released while transport
when
path is overload.
band
limitation
is
exceeded
.
5 Related Counters and Alarms
5.1 Related Counters
Table 5-1 Counter List
Counter ID Name
C311775697 Number of rate decreased by congest control, Conversation
Number of rate decreased by congest control, Interactive

C311775698
class

Congestion Control
Number of rate decreased by congest control, Background

C311775699
class
Number of rate decreased by congest control, Streaming

C311775700
class
C311774805 Number of PS Downgrade due to UL CE Congestion
C311774806 Number of PS Downgrade due to DL CE Congestion
C311774807 Number of PS Downgrade due to Code Congestion
C311774808 Number of PS Downgrade due to DL Power Congestion
C311774809 Number of PS Downgrade due to UL Power Congestion
Number of PS Downgrade due to Uplink interference

C311775713
limit(RTWP)
Number of PS Downgrade due to equivalent AMR user

C311776963
number limited.
Number of UE that is forced to hard handover caused by

C311772462
congestion control
Number of UE that is forced to remove soft radiolink caused

C311772463
by congestion control
Number of UE that is forced to transform to FACH state

C311772464
caused by congestion control
Number of UE that is forced to call drop caused by

C311772465
congestion control
Number of call drop RAB caused by congestion control,

C311775717
Downlink DCH no code

C311775718
Uplink NodeB CE limit

C311775719
Downlink NodeB CE limit
C311776585 Duration of congest in cell
C311776586 Duration of congest by TCP in cell
C311776587 Duration of congest by RTWP in cell
C311776588 Duration of congest by UL CE in cell
C311776589 Duration of congest by DL CE in cell
C311776590 Duration of congest by code resource in cell

Congestion Control
5.2 Related Alarms
This feature has no related alarm.
6 Engineering Guide
6.1 Application Scenario
If a service access request fails due to insufficient resources, this feature allows the
system to reduce the load and release some resources through service pre-emption,
RAB queuing, and downgrade according to the pre-emption capability, delay requirement,
and priority of this service, instead of directly rejecting the service. This feature improves
the access success ratio and makes full use of the system capacity.
The congestion control actions (such as service release and downgrade) affect online
subscribers and degrade user experience of the online subscribers.
Appropriate thresholds must be configured for admission control to avoid system

overload and frequent congestion control.
6.2 Feature Activation Procedure
This procedure describes how to locate the parameters related to this feature in the GUI.
The parameter values on the screenshots in the procedure are for reference only. Refer
to Chapter 4 for the recommended values of the recommended values of the related
parameters.
1. In the configuration resource tree, select Modify Area > Managed Element -
UMTS Logical Function Configuration > Service Configuration > QOS
Function, double-click Qos Basic Configuration, and set the parameters DCH
Downlink Nominal Bit Rate and DCH Uplink Nominal Bit Rate, see Figure 6-1

Congestion Control
Figure 6-1 Parameter Configuration 1
2. In the configuration resource tree, select Modify Area > Managed Element >
UMTS Logical Function Configuration > UTRAN Cell, double-click Load Control
Information, and set the parameters Maximum Number of UE Decreasing Rate
When Congestion, Switch of Rate Downgrade ahead of Preemption in
Congestion, Maximum Number of Degraded Downlink Load Steps Every Time,
and Maximum Number of Degraded Uplink Load Steps Every Time, see Figure
6-2

Congestion Control

Congestion Control
UMTS Logical Function Configuration, double-click Extended Info of RNC, and
set the parameter Switch of Forbidding AMR Deceleration Triggered by
Congestion Control, see Figure 6-3
UMTS Logical Function Configuration > Link Configuration, double-click Iur
Link, and set the parameter Whether Support PS (0kbps/0kbps), see Figure 6-4

Congestion Control
This feature is activated by default. No procedure is required to activate this feature.
This feature is activated by default. No procedure is required to activate this feature
This procedure describes how to locate the parameters related to this feature in the GUI.
The parameter values on the screenshots in the procedure are for reference only. Refer
to Chapter 4 for the recommended values of the recommended values of the related
parameters.
In the configuration resource tree, select Modify Area > Managed Element > UMTS
Logical Function Configuration > Service Configuration, double-click Global
Access Control Information, and set the parameters True Queue Length, Time of
True Queue for Congested Service in RAB Setup Process, Time of True Queue for
Congested Service Relocating into UTRAN, Maximum Time in the True Queue
when Service be Forced into Queue, Forced Queue Switch for AMR Service, and
Forced Queue Switch for CS 64kbps service, see Figure 6-5

Congestion Control
6.3 Feature Validation Procedure
Table 6-1 Feature Validation Procedure – Congestion Control
Test Item Congestion Control
1. The WCDMA system is ready.
2. Cell1 supports HSUPA, HSDPA and DCH.
3. The code resources of Cell1 are properly configured so that only one SF8 and
one SF256 code are available.

Prerequisit
4. UE1 and UE2 camp on Cell1 in Idle mode.
es
5. UE1 supports R99 and subscribes to an interactive or background service.
The UL and DL MBRs of UE1 are set to 2 Mbps. The queuing of UE1 is
allowed, but pre-emption is not allowed.
6. The queuing of UE2 is allowed but UE2 cannot trigger pre-emption.

Congestion Control
Test Item Congestion Control
1. UE1 initiates a PS service in Cell1 and starts downloading through FTP. The
DL data rate of UE1 reaches 384 kbps after a while.
2. UE2 makes a voice call to another UE or PSTN but is not permitted for the
first attempt due to a shortage of DL codes, UE2 is placed in the queue and
Step DL congestion control is triggered. The DL data rate of UE1 is downgraded.
The voice call of the UE2 is permitted for the next attempt.
3. End the voice call. After that, the DL data rate of UE1 increases to 384 kbps
again.
4. Deactivate the PDP of UE1.
Expected 1. In Step2, the voice call of UE2 is permitted. The DL data rate of UE1 is
result downgraded.
Table 6-2 Feature Validation Procedure – Emergency Call
Test Item Emergency Call

Prerequisit
es
3. UE1 camps on Cell1 in Idle mode.
1. UE1 makes an emergency call in Cell1.
Step 2. Maintain the emergency call for 2 minutes.
3. End the emergency call.
Expected 1. The emergency call is established successfully.

result 2. The voice quality is good without obvious delay.
Table 6-3 Feature Validation Procedure – Service Pre-emption
Test Item Service Pre-emption

Congestion Control
Test Item Service Pre-emption
3. Only one SF8 code and one SF256 code are available in Cell1.
4. UE1 and UE2 camp on Cell1 in Idle mode.

Prerequisit
5. UE1 supports R99 and subscribes to a background service. The UL and DL
es
MBRs are set to 2 Mbps. UE 1 is pre-emptable, with ARP1.
6. UE2 supports R99 and subscribes to a background service The UL and DL
MBRs are set to 2 Mbps. UE2 may trigger pre-emption, with ARP2.
7. The priority of ARP1 is lower than that of ARP2.
1. UE1 initiates a PS service in Cell1 and starts downloading through FTP.
2. UE2 initiates another PS service. The PS service of UE1 is released due to

Step
the shortage of code resources and the PS service of UE2 is permitted.
3. Deactivate the PDP of UE2.
Expected 1. In Step2, the PS service of UE2 is permitted after the PS service of UE1 is
result released.
Table 6-4 Feature Validation Procedure – RAB Queuing
Test Item RAB Queuing
Prerequisit 3. Only one SF256 code is available in Cell1.

es 4. UE1 and UE2 camp on Cell1 in Idle mode.
5. The queuing of UE1 and UE2 is allowed. UE1 and UE2 have no pre-emption
capability.
1. UE1 makes a voice call in Cell1, but the voice call is not permitted for the first
attempt due to the shortage of DL codes. The UE1 is placed in the queue
Step
and DL congestion control is triggered.
2. Deactivate the CS call.

Congestion Control
Test Item RAB Queuing
Expected
1. In Step1, the voice call of UE1 cannot be permitted.
result
6.4 Feature Deactivation Procedure
None
None
None
None
6.5 Impact on the Network
1. Impact on Equipment Performance

None
2. Impact on Network KPIs

The advantages of this feature:
 If access is not permitted due to congestion, this feature allows the system to
release some resources for the new service. This feature can increase the

Congestion Control
service access ratio, improve user experience of new subscribers, and make
full use of the system capacity.
 The congestion control feature can reduce the system load and maintain the
system stability.
The disadvantage of this feature is:
 User experience of subscribers with lower priorities degrades due to forcible

release or rate downgrade in case of congestion.
7 Abbreviation
Abbreviation Full Name
DCH Dedicated Channel
RAN Radio Access Network
QoS Quality of Service
PS Packet Switched
CS Circuit Switched
R99 Release 1999
GBR Guaranteed Bit Rate
NBR Nominal Bit Rate
UE User Equipment
RTWP Received Total Wideband Power
TCP Transmitted Carrier Power
RNC Radio Network Controller
RACH Random Access Channel
FACH Forward Access Channel
AMR Adaptive Multi-Rate
DRBC Dynamic Radio Bearer Control
ARP Allocation/Retention Priority
THP Traffic Handling Priority
BP Basic Priority
AP Application Priority

Congestion Control
SP Scheduling Priority
RL Radio Link
RAB Radio Access Bearer
RT Real-Time
NRT Non-realtime
SF Spreading Factor
DRNC Drift RNC
CRNC Control RNC
CE Channel Element
8 Reference Document
[1] ZXUR 9000 UMTS (V4.13.10.15) Radio Network Controller Radio Parameter
Reference
[2] ZXWR RNC (V3.13.10.15) Radio Network Controller Radio Parameter Reference
[3] ZXUR 9000 UMTS (V4.13.10.15) Radio Network Controller Performance Counter
Reference
[4] ZXWR RNC (V3.13.10.15) Radio Network Controller Performance Counter Reference
[5] ZTE UMTS Admission Control Feature Guide
[6] ZTE UMTS QoS Feature Guide
[7] ZTE UMTS DRBC Algorithm Feature Guide
[8] ZTE UMTS NB-AMR Rate Control Feature Guide
[9] ZTE UMTS WB-AMR Rate Control Feature Guide
[10] ZTE UMTS RAN Transmission Overview Feature Guide
[11] ZTE UMTS Transport CAC Feature Guide

ZTE UMTS Congestion Control Feature Guide - V1 10

Uploaded by

Copyright:

Available Formats

ZTE UMTS Congestion Control Feature Guide - V1 10

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ZTE UMTS Congestion Control Feature Guide - V1 10

Uploaded by

Copyright:

Available Formats

Congestion Control

Add notes: UGloAc.tTrueQ and

© 2015 ZTE Corporation. All rights reserved.

ZTE Confidential Proprietary 1

1 Feature Attribute ............................................................................................... 5

3 Technical Description ....................................................................................... 9

5 Related Counters and Alarms ........................................................................ 34

6 Engineering Guide .......................................................................................... 36

ZTE Confidential Proprietary 2

6.3 Feature Validation Procedure ............................................................................ 41

ZTE Confidential Proprietary 3

Figure 3-1 Resource Pre-emption Flow .............................................................................11

Table 2-1 License Control List ............................................................................................ 8

ZTE Confidential Proprietary 4

Node B Version: [ZXSDR V4.13.10.20]

2.1 Feature Introduction

2.1.1 ZWF21-04-010 Congestion Control

ZTE Confidential Proprietary 5

 Service pre-emption: High-priority services pre-empt with lower-priority

2.1.2 ZWF21-05-001 Emergency Call

In general, an emergency call is identified by a UE. If a user dials an emergency service

ZTE Confidential Proprietary 6

2.1.3 ZWF21-05-005 Service Pre-emption

2.1.4 ZWF21-05-023 RAB Queuing

ZTE Confidential Proprietary 7

2.2 License Control

Table 2-1 License Control List

ZWF21-04-010 Congestion Control N/A N/A N/A

2.3 Correlation With Other Features

2. Mutually Exclusive Features

ZTE Confidential Proprietary 8

3.1 ZWF21-04-010 Congestion Control

Congestion control is a resource pre-emption process where several admission and

 Service pre-emption: Higher-priority services can pre-empt lower-priority services.

 Basic Priority of RNC-BP

The Basic Priority (BP) is determined by two factors: ARP (Allocation/Retention

 Application Priority of RNC-AP

ZTE Confidential Proprietary 9

 Scheduling Priority of RNC-SP

The following describes the resource pre-emption process:

If a service fails to be admitted (excluding failure caused by an online rate upgrade

ZTE Confidential Proprietary 10

Figure 3-1 Resource Pre-emption Flow

RAB Assignment Request

Yes UE-A accesses the

Is the RAB pre- Yes Service pre-emption is

Downgrade is triggered The RAB of UE-A is

The RAB is scheduled

1. The downgrade procedure in the flow is applied to DCHs.

2. The scheduling time mentioned in the flow is described in Section 3.3

ZTE Confidential Proprietary 11

3.1.1 Service Pre-emption

For the details, refer to Section 3.2 ZWF21-05-005 Service Pre-emption.

3.1.2 RAB Queuing

For the details, refer to Section 3.3 ZWF21-05-023 RAB Queuing.

3.1.3 DCH Downgrade

If the switch (ULdCtrl.decRateSw) that determines rate downgrade in advance of

If a rejected subscriber has no preemption capability or fails to pre-empt other online

The congestion causes that can trigger downgrade include: