Utran: Radio Subsystem Basic Package - Enhanced Congestion Control FD012220C - UMR3.5

UTRAN
Feature Description
Radio Subsystem
Basic Package - Enhanced Congestion
Control
FD012220C - UMR3.5
A50016-G5000-Z142-7-7618
ND-59083-142(E)-07
Basic Package - Enhanced Congestion Control Feature Description
FD012220C - UMR3.5 Radio Subsystem
f Important Notice on Product Safety

DANGER - RISK OF ELECTRICAL SHOCK OR DEATH - FOLLOW ALL INSTALLATION INSTRUCTIONS.
The system complies with the standard EN 60950 / IEC 60950. All equipment connected to the system must
comply with the applicable safety standards.
Hazardous voltages are present at the AC power supply lines in this electrical equipment. Some components may
also have high operating temperatures.
Failure to observe and follow all installation and safety instructions can result in serious personal injury
or property damage.
Therefore, only trained and qualified personnel may install and maintain the system.
The same text in German:

Wichtiger Hinweis zur Produktsicherheit
LEBENSGEFAHR - BEACHTEN SIE ALLE INSTALLATIONSHINWEISE.
Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Alle an das System angeschlossenen
Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.
In diesen Anlagen stehen die Netzversorgungsleitungen unter gefährlicher Spannung. Einige Komponenten
können auch eine hohe Betriebstemperatur aufweisen.
Nichtbeachtung der Installations- und Sicherheitshinweise kann zu schweren Körperverletzungen oder
Sachschäden führen.
Deshalb darf nur geschultes und qualifiziertes Personal das System installieren und warten.
Caution:
This equipment has been tested and found to comply with EN 301489. Its class of conformity is defined in table
A30808-X3247-X910-*-7618, which is shipped with each product. This class also corresponds to the limits for a
Class A digital device, pursuant to part 15 of the FCC Rules.
These limits are designed to provide reasonable protection against harmful interference when the equipment is
operated in a commercial environment.
This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accor-
dance with the relevant standards referenced in the manual “Guide to Documentation”, may cause harmful inter-
ference to radio communications.
For system installations it is strictly required to choose all installation sites according to national and local require-
ments concerning construction rules and static load capacities of buildings and roofs.
For all sites, in particular in residential areas it is mandatory to observe all respectively applicable electromagnetic
field / force (EMF) limits. Otherwise harmful personal interference is possible.
Trademarks:
All designations used in this document can be trademarks, the use of which by third parties for their own purposes
could violate the rights of their owners.
Copyright (C) Siemens AG / NEC Corporation 2004-2006.
Issued by:
Siemens AG, Communications, Hofmannstrasse 51, 81359 München, Germany and
NEC Corporation, 7-1, Shiba 5-chome, Minato-ku, Tokyo, Japan
Technical modifications possible.

Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract.
Siemens AG:A50016-G5000-Z142-7-7618
2 NEC Corporation:ND-59083-142(E)-07
Feature Description Basic Package - Enhanced Congestion Control
Radio Subsystem FD012220C - UMR3.5
Reason for Update

Summary: Description on the spreading factor updated. Document updated due to
review comments.
Details:
Chapter/Section Reason for Update
2.2.1 Description on the spreading factor updated.
2 Document updated due to review comments.
Issue History
Issue Date of issue Reason for Update
Number
1 08/2004 First issue for new release.
2 01/2005 Clarification of the mechanism.
3 08/2005 Editorial changes.
4 09/2005 Mechanism of CC stage 1 updated.
5 12/2005 Document updated due to review comments.
6 02/2006 Description on the spreading factor updated.
7 09/2006 Description on the spreading factor updated.

Document updated due to review comments.
Siemens AG: A50016-G5000-Z142-7-7618

NEC Corporation: ND-59083-142(E)-07 3
This document consists of 29 pages. All pages are issue 7.
Contents
1 Short Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 In General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Customer Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Inter-Working / Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Interactions of Congestion Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Basic Concept of Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Congestion Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1.1 Initiation of the Event-Triggered Common Measurements. . . . . . . . . . . . . . . 9
2.2.1.2 Handling of Lost Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1.3 Higher Layer Filtering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Congestion Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Interdependencies of Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Congestion Control and Emergency Calls . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 Congestion Control and Pre-Emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Congestion Control Algorithm for HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Failure Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Upgrade Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Difference to the Congestion Control Algorithm in UMR2.0. . . . . . . . . . . . . 21
2.7 Feature Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7.1 Measurement Thresholds 1 and 2 in UMR3.5 . . . . . . . . . . . . . . . . . . . . . . . 22
3 Functional Split. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Siemens AG:A50016-G5000-Z142-7-7618
1 Short Description
This chapter serves as short introduction to the Enhanced Congestion Control feature.
The chapter is subdivided into the following sections:
• In General
• Customer Benefits
• Inter-Working / Dependencies
• Prerequisites
1.1 In General
The Enhanced Congestion Control feature introduces event-triggered periodic
measurements that speed up congestion control by relieving the system of the signaling
load based solely on the previously used periodic measurements.
1.2 Customer Benefits

The Enhanced Congestion Control feature improves the system’s reaction time and
uses an improved congestion handling method based on bit rate adaptation / switching
/ dropping of bearers and thus improving the network’s QoS.
1.3 Inter-Working / Dependencies

The Enhanced Congestion Control feature is part of the basic software package for
UMR3.5. This basic software package is the first step toward the capacity driven phase
of UMTS that focuses on end-user perception. It is also the basis for using the optional
feature set to reduce expenses and generate additional revenue through value-added
services.
The optional feature set of UMR3.5 offers new services and advertisement capabilities
via SMS cell broadcast, remote modem access services via UMTS, and realtime gaming
for mobile gaming communities, as well as capacity increases using the new
macro&micro mixed cell scenarios.
1.4 Prerequisites
Not applicable.
Siemens AG: A50016-G5000-Z142-7-7618

2 Functional Description
The task of congestion control is to monitor, detect, and handle situations in which the
system reaches a near-overload or an overload situation with the users already
connected. This means that some part of the network has run out, or will soon run out
of resources. Congestion control returns the system to a stable state as smoothly as
possible. In this sense, congestion control is a reactive (closed loop) congestion control
function that reacts to a congestion situation rather than prevent an overload situation.
For more information see 3GPP TSG RAN WG3: UTRAN Overall Description,
TS 25.401.
With UMR3.5 the Congestion Control feature is enhanced by the use of event-triggered
common measurements instead of periodic common measurements. These event-
triggered common measurements indicate when the system reaches a congested state
and when this state is resolved. The Enhanced Congestion Control feature reduces the
signaling load and increases system capacity.
Furthermore, two new parameters have been added to the congestion decision. Event-
triggered common measurements of type E are used to detect congestion.
For information on congestion control and HSDPA from UMR5.0 see FD012249 -
Support of HSDPA.
2.1 Interactions of Congestion Control

Congestion control is a function of the Controlling RNC. It detects and resolves an over-
load situation in a particular cell by invoking different signaling procedures. It is triggered
by a common measurement report sent via NBAP indicating that the uplink interference
(received total wideband power) or the downlink transmitted carrier power is so high that
the system may become unstable. The CRNC decides on appropriate actions to limit the
severity, spread, and duration of the congestion.
Congestion control uses:
• Transport-channel-type switching from dedicated to common channels for
interactive or background class traffic
• Bit rate adaptation to the minimum rate for multicall CS AMR/UDI + PS I/B services
• Bearer dropping for conversational, interactive/background, streaming class traffic,
and multicall
Furthermore, congestion control indicates to the admission control that the cell is
congested. Basically, admission control rejects the setup of new bearers or
reconfiguration for the congested cell.
A congestion check is always performed upon RRC connection setup (except for NAS
related handling) and RAB setup. In other words, a congestion check is performed upon
RAB setup, even if the load does not change or an existing bearer is reconfigured to a
lower rate, for example PS 384 kbit/s -> PS Streaming + PS 8 kbit/s. For the handling of
emergency calls see Congestion Control and Emergency Calls.
An RNC-internal proprietary message is defined to trigger a forced transport-channel-
type switch within the SRNC. A forced transport-channel-type switch is the preferred
method to handle a congestion, because a transport-channel-type switch does not de-
grade the QoS contract for the given best effort data users.
Bearer dropping is invoked by the RNSAP radio link failure procedure on the Iur inter-
face. Fig. 2.1 shows the interactions of congestion control.
Siemens AG:A50016-G5000-Z142-7-7618
If the UE has a real-time (that is CS AMR/UDI) and a non-real-time (that is PS I/B) bearer
simultaneously with a PS I/B component that is not at the minimum or UL: 0 kbit/s,
DL: 0 kbit/s rate, it is reconfigured to the minimum rate.
CRNC CRNC OAM

Measure- Dynamic Database
ment Database
Database
Congestion Control
Transport
Channel
Type
Switching CRNC-SRNC proprietary message:
Bit Rate Radio Link Load Indication
Congestion
Indication Congestion Adaptation
NBAP: Common Measurement Report Congestion Handling
Decision (Protocol
Handling)
Bearer RNSAP: Radio Link Failure

Drop
Congestion Indication (to AC)
Fig. 2.1 Interactions of congestion control
2.2 Basic Concept of Congestion Control

The basic steps for congestion control are:
1. Congestion decision
Detects a congestion if the received total wideband power or the transmitted carrier
power exceeds a certain level.
2. Congestion handling
Selects ongoing bearers that have to be bit-rate adapted, switched, or dropped in
order to lower the cell load.
The congestion handling has two stages:
– Stage 1: PS BE rate decrease via channel-type switching and bit rate adaptation
– Stage 2: Bearer dropping and/or bit rate adaptation and/or channel-type
switching from DCH to FACH state
Siemens AG: A50016-G5000-Z142-7-7618

2.2.1 Congestion Decision

Event-triggered common measurement reporting for event E is used as followed, see
Fig. 2.2:
• Detecting a congestion
A congestion is detected as soon as the received total wideband power/transmitted
carrier power is equal to or exceeds a congestion detection threshold (threshold 1)
and stays there for the measurement hysteresis time (internal parameter).
The Node B initiates the common measurement reporting procedure and sends a
common measurement report to the RNC via an NBAP: COMMON MEASURE-
MENT REPORT message. The Node B continues to send a report to the RNC with
a certain periodicity as long as the condition for this report is fulfilled.
Upon reception of the message, the RNC compares the value of the received total
wideband power/transmitted carrier power in the message with threshold 1, recog-
nizes report A, and detects congestion.
• Resolving a congestion
A congestion is resolved as soon as the received total wideband power/transmitted
carrier power is equal to or falls below a congestion resolution threshold
(threshold 2) and stays there for the measurement hysteresis time (internal param-
eter).
The Node B sends common measurement reports to the RNC via an NBAP:
COMMON MEASUREMENT REPORT message. Upon reception of the messages,
the RNC compares the value of the received total wideband power/transmitted
carrier power in the message with threshold 2, recognizes report B, and detects that
the congestion is resolved.
RTWP/TCP RB reconfiguration
drop of users Congestion
resolved
Measurement
threshold 1
Congestion
Measurement hysteresis
threshold 2
Congestion
detected Measurement hysteresis time
Report periodicity Time
Common measurement report A report B

reporting procedure (sent if congestion is resolved in UL or DL)
Fig. 2.2 Basic concept for congestion control
Siemens AG:A50016-G5000-Z142-7-7618
2.2.1.1 Initiation of the Event-Triggered Common Measurements

When a cell is set up, the RNC sends to the Node B an NBAP: COMMON MEASURE-
MENT INITIATION REQUEST message, which indicates the conditions for reporting
Event E. If the Node B supports event-triggered measurements for Event E, it returns
an NBAP: COMMON MEASUREMENT INITIATION RESPONSE message to the RNC.
In the event of periodic measurements, however, too long measurement periodicity
causes delay in congestion detection, and too short periodicity causes a high signaling
load to the system. The “Measurement Hysteresis Time” specifies the time that elapses
after the received wideband power is equal to or has exceeded threshold 1 or has fallen
below threshold 2 and before the Node B sends report A/B. The value of this parameter
is set to 0.1 s and cannot be changed by the operator.
After sending the first report A, the Node B keeps on reporting the measured received
total wideband power and transmitted carrier power values at intervals of the “Report
Periodicity” until it sends a report B. The “Report Periodicity” is set to 0.5 s and cannot
be changed by the operator.
The definitions of the congestion control thresholds prevent a situation in which the
UL/DL threshold is below the current values of NUL and PCOMMON in UL and DL
respectively, see Thresholds 1 and 2 (UL) and Thresholds 1 and 2 (DL).
In order to be able to receive event-triggered common measurement reports for the re-
ceived total wideband power and the transmitted carrier power, the common measure-
ment control has to be initiated with the parameters listed in Tab. 2.1. For additional
information see 3GPP TS 25.433. The mapping of the measurement quantity is speci-
fied in 3GPP TS 25.133
IE / Group name Presence Value IE type
Message Discriminator M Common

Message Type M COMMON MEASUREMENT INITIATION
Transaction ID M
Measurement ID M
Common Measurement Object M
Type
CHOICE Common M CELL
Measurement Object Type
>Cell
>>C-ID M
Common Measurement Type M Received total wideband power or
transmitted carrier power
Measurement Filter Coefficient O 0
Report Characteristics M See Tab. 2.2
SFN Reporting Indicator M FN reporting not required FN reporting
indicator
Tab. 2.1 Common measurement initiating request
Siemens AG: A50016-G5000-Z142-7-7618

IE / group name Presence Semantic description Value
CHOICE Report Characteristics

>Event E
>>Measurement Threshold 1 M See chapter Thresholds 1 and 2 Measurement threshold
(UL) and Thresholds 1 and 2 (DL)
>>Measurement Threshold 2 O See chapter Thresholds 1 and 2 Measurement threshold
(UL) and Thresholds 1 and 2 (DL)
>>Measurement Hysteresis O Pre-defined system
Time data
>>Report Periodicity O Pre-defined system
data
Tab. 2.2 Reporting characteristics for event E
Thresholds 1 and 2 (UL)

The thresholds for the received total wideband power are:
• THR1(range: -112, …, -50 dBm by step of 0.1 dB) = NUL + UL_cong_threshold
• THR2(range: -112, …, -50 dBm by step of 0.1 dB)
= MAX(THR1 - UL_cong_hyst, NUL)
The update threshold for uplink congestion control is specified by:
• Update threshold for UL CC = MIN (Update_threshold, UL_cong_threshold)
The “Uplink Congestion Threshold” relative to thermal noise is specified by the operator
and must be set to a value greater than “0”. In addition, the operator can specify the
“Uplink Congestion Hysteresis”. The “Update_threshold” is set to 0.5 dB and cannot be
changed by the operator.
Thresholds 1 and 2 (DL)

The thresholds for the transmitted carrier power are:
• THR1(range: 0, …, 1 by step of 0.01) = MAX(DL_cong_threshold, PCOMMON)
• THR2(range: 0, …, 1 by step of 0.01) = MAX(THR1 - DL_cong_hyst, PCOMMON)
Measurement Threshold 1 = median (0; 100; THR1*100) and
Measurement Threshold 2 = median (0; 100; THR2*100)
The “Downlink Congestion Threshold” and the “Downlink Congestion Hysteresis” can be
specified by the operator.
Siemens AG:A50016-G5000-Z142-7-7618
Congestion Threshold Update

Upon reception of an UL common measurement report that is for periodical reporting of
the received total wideband power, the RNC checks whether or not a UE with a DCH is
in the cell. If there is no such UE, the RNC starts the threshold update procedure.
The RNC calculates the UL congestion detection threshold (threshold 1) based on ther-
mal noise. The RNC, however, sends the UL measurement thresholds only to the Node
B if the previous signaled value of threshold 1 and the new value of threshold 1 differ by
more than the “Update Threshold for UL CC”. At the same time, the congestion resolu-
tion threshold (threshold 2) is updated accordingly.
In order to update the UL congestion thresholds threshold 1 and threshold 2 during
event-triggered measurements, the RNC terminates the event-triggered common
measurements by sending an NBAP: COMMON MEASUREMENT TERMINATION
REQUEST message. After that, the RNC notifies the Node B of the new thresholds via
an NBAP: COMMON MEASUREMENT INITIATION REQUEST message.
The DL congestion thresholds are not automatically updated. In order to update the DL
congestion thresholds, the cell needs to be re-established.
2.2.1.2 Handling of Lost Events

In the event-triggered measurement mechanism, measurement results are reported
only when a congestion situation has been detected. It may happen, however, that a
congestion detection report or a congestion resolution report is lost for example in the
event of a phase 1 restart.
To prevent failures because of lost reports A or B, the “Report Periodicity” is used in
connection with event E, see Fig. 2.3:
• Report A has been sent:
After sending the first report A, the Node B keeps on reporting the measured
received total wideband power and transmitted carrier power values at intervals of
the “Report Periodicity”. Therefore, a lost report A is recognized if periodic reports
are received.
• Report B has been sent:
The Node B stops sending periodic reports. A “Lost Event” timer is introduced in the
RNC to recognize a lost report B so that the periodic reports can be stopped. Oth-
erwise, a lost event B would not be recognized and congestion control would not be
stopped if a congestion is resolved. In this case, the cell would be emptied.
The “Lost Event” timer is equal to the “Report Periodicity” by taking into account a
Node B timing inaccuracy of 50 ms. The timer is set for UL or DL direction, that is for UL
or DL congestion. If the “Lost Event” timer expires for the first time and no periodic event
measurement is received, it is restarted for twice longer duration as the “Report
Periodicity”. If report B or the periodical measurement report is received before the timer
expires for the second time, the RNC resets the timer and congestion handling is carried
on as normal.
Upon the second expiry of the timer, the congestion handling and the “Congestion Han-
dling Period” timer are stopped if neither report B nor the periodic event measurement
report is received and there is no congestion on the other direction. The “Report Perio-
dicity” is set to 0.5 s and cannot be changed by the operator.
Siemens AG: A50016-G5000-Z142-7-7618

The following algorithm is used to handle lost events:

• When initiating the event-triggered common measurements, the “Report Periodicity”
information is sent to the Node B.
• The congestion handling is started when a report A is received for at least one
direction.
• The congestion handling is stopped when a report B is received and the other direc-
tion is not congested.
• Whenever a common measurement periodic report is received where the “Common
Measurement ID” is the same as in the initiation of the event-triggered common
measurement, the congestion handling is started if it has not already been started.
• After reception of report A, a periodic measurement report is expected every “Report
Periodicity” until the report B is received. If neither periodic measurement reports nor
report B are received, the “Lost Event” timer is started. The “Lost Event” timer is
equal to the “Report Periodicity” by taking into account a Node B timing inaccuracy
of 50 ms. If the “Lost Event” timer expires for the first time and no periodic event
measurement is received, it is restarted for twice longer duration as the “Report Pe-
riodicity”. Due to this behavior, the previous lost/missed measurement report should
be received in the subsequent measurement reporting period. Congestion handling
is not affected by this and continues as described in Congestion Handling.
• If another periodic measurement report is received where the “Common Measure-
ment ID” is the same as in the initiation of the event-triggered common measure-
ment, the “Lost Event” timer is stopped and congestion handling is continued.
• If no other periodic measurement report is received until the timer has expired and
the other direction is not congested, the congestion handling is stopped.
Siemens AG:A50016-G5000-Z142-7-7618
RTWP/TCP report A
Threshold 1
report B
Threshold 2
Time
Report periodicity
RNC handling
Case 1: Report B received
Congestion handling
stops time-out
Case 2: Report B not received
Time
Congestion ’lost event’ Congestion
handling starts Timer Start handling stops
Congestion Control Handling
RTWP/TCP
Time
Congestion handling period
Fig. 2.3 Failure handling of lost events
2.2.1.3 Higher Layer Filtering

Higher layer filtering is an important tool in order to improve the Node B measurement
accuracy and avoid unnecessary measurement reports. Higher layer filtering can be
used to average the received total wideband power (UL) and transmitted carrier power
(DL) measurement values received by event-triggered measurements. The measure-
ment filter coefficients for the received total wideband power and the transmitted carrier
power are specified by the operator. If the value of the measurement filter coefficient is
set to “0”, the RNC does not send this coefficient within NBAP COMMON MEASURE-
MENT INITIATION REQUEST message and higher layer filtering is not performed.
Siemens AG: A50016-G5000-Z142-7-7618

2.2.2 Congestion Handling

The selection of UEs to be reconfigured or dropped is done in two stages. Stage 1
maintains QoS during congestion by avoiding call dropping as much as possible while
stage 2 ensures that the congestion is solved quickly and efficiently.
It is assumed, that the traffic in DL is much higher than in UL and the system capacity is
downlink-limited. Therefore, the bearer with the lowest DL spreading factor are selected
to handle an UL or DL congestion.
For both stages the following rules applies:
• Congestion control handling handles UEs with lowest DL spreading factor first, by
considering both the primary and secondary scrambling code.
• If bearers with identical DL spreading factors are found, and if they are comprised
from primary and secondary scrambling code, then bearers from the secondary
scrambling code tree are treated first. In other words, bearers of the same DL
spreading factor from the secondary scrambling code are treated with greater prior-
ity than the same DL spreading factor bearers from the primary scrambling code.
In this section, K indicates the operator-configurable parameter “Number of Bearers
Dropped/Switched in One Step”.
Siemens AG:A50016-G5000-Z142-7-7618
UE
UEininCELL_DCH
Cell_DCH state
state
Measurement report from Node B

- Cell’ s UL received total wideband power
- Cell’s DL transmitted carrier power
Congestion detected Yes

in the last comparison?
No Comparison with Congestion resolved

congestion resolution
No congestion threshold
Comparison with
congestion detection
threshold Congestion
continues
Congestion detected
Send congestion indication

to admission control
Send congestion indication
cancellation to admission control
Select radio bearers

to be handled
Rate decrease Yes

for all bearers with
PS BE services?
No
Yes
Request SRNC to decrease rate All bearers dropped?
of target bearers and DRNC to
drop target bearers (stage 1)
No
Request SRNC/DRNC to drop

target bearers (stage 2)
End
Fig. 2.4 Congestion handling flow
The CRNC handles a congestion according to the settings of the etpchr and ebd
parameter, see Tab. 2.3. etpchr indicates whether or not the transport channel
type/physical channel type can be switched between DCH and CCH or bit rate adapta-
tion is possible in the selected cell. ebd enables bearer dropping.
Siemens AG: A50016-G5000-Z142-7-7618

etpchr ebd Congestion handling

(Enable trans- (Enable bearer
port/ dropping)
physical channel
reconfiguration)
“Enable” CTS and “Enable” bearer dropping Stage 1:

reconfiguration Channel-type switching and bit rate
adaptation
Stage 2:
Bearer dropping and bit rate
adaptation
“Enable” CTS and “Disable” bearer drop- Only stage 1:
reconfiguration ping Channel-type switching and bit rate
adaptation
“Disable” CTS and “Enable” bearer dropping Only stage 2:
reconfiguration Bearer dropping and bit rate
adaptation
“Disable” CTS and “Disable” bearer drop- New RRC connection setup, RRC
reconfiguration ping connection re-establishment,
channel-type switching (common to
dedicated), RAB establishment, and
bit rate adaptation are rejected.
Tab. 2.3 The “etpchr” and “ebd” parameters in congestion handling
Stage 1
All UEs that have a PS service, except UEs having PS streaming bearer, are ordered
by increasing DL spreading factor.
From this list, the congestion control algorithm within the CRNC selects the next K UEs
beginning with the one with the lowest DL spreading factor, and indicates the SRNC to
reduce the rate.
The SRNC
• switches UEs with a PS-background or PS-interactive only service to CELL_FACH
state by channel-type switching.
• reconfigures all UEs with PS BE + CS AMR or PS BE + CS UDI services to the
minimum rate on DCH by bit rate adaptation if the PS BE component is not at
minimum or UL: 0 kbit/s, DL 0 kbit/s rate.
In the case of DRNC, the bearer dropping is triggered by sending an RNSAP RADIO
LINK FAILURE message to the SRNC because no traffic class information is available
for the DRNC to identify whether or not the call is a single PS BE call or a PS+CS
multicall.
Siemens AG:A50016-G5000-Z142-7-7618
Select a currently connected call
Do UEs exist that

have PS services? No
Exception: UEs with
PS streaming bearer
Yes
Align the calls according to

their DL spreading factor
Included in k calls,
beginning wit the one No
Except from handling
having the lowest DL
spreading factor
Yes
No
PS BE + CS AMR/UDI Channel-type switching
combined service to common channel
Yes
Reconfigure the PS rate to

the minimum rate by
bit rate adaptation *
* If the PS BE component has a rate other then minimum or 0/0 kbit/s
Fig. 2.5 Congestion handling in stage 1
Stage 1 is repeated every congestion handling period as long as the congestion

situation persists until every UE has been treated that can be handled by step 1 and
there are at least K number UEs to be handled. Every UE is only treated once in stage 1.
If the congestion persists and less then K UEs to be handled are left, the first stage is
terminated and the second stage is started.
Siemens AG: A50016-G5000-Z142-7-7618

Stage 2
This phase begins if the congestion persists after stage 1 has been completed. In
stage 2, all UEs are selected according to their DL spreading factor starting with the
lowest, regardless of their service combination and regardless of whether or not they
have been handled in stage 1. The DL spreading factor of UEs, however, that are still
handled by procedures triggered in stage 1 when stage 2 begins are taken into account
for stage 2 after completion of this procedures.
The congestion control algorithm within the CRNC selects the next K UEs, beginning
with the one with the lowest DL spreading factor:
• K users are selected but if congestion control finds any M single PS BE call or
multicall users (M <= K, M = 0, ... K) with a PS BE rate that is higher than the mini-
mum rate:
The congestion control procedure
– releases the RRC connection of the K - M users (provided that M is not equal to
K) AND/OR
– reduces the rate of the M users by bit rate adaptation to the minimum rate for PS
BE multicall services or channel-type switching for single call PS BE services
• Otherwise, congestion control releases the RRC connection of the K users.
PS BE users with a PS BE rate that is greater than the minimum rate may exist after
congestion control stage 1 is completed because handover procedures are not failed by
congestion control: The bearers are admitted when adding a radio link in a congested
cell and after the handover procedure is completed, they are listed according to the DL
spreading factor.
In the case of DRNC, a radio link failure is signaled to the SRNC in order to release the
call.
Stage 2 is repeated every congestion handling period as long as the congestion
situation persists, until all UEs have been treated. No subsequent release requests are
generated for the same UE.
Upon receiving the report B or the expiration of the “Lost Event” timer, the congestion
handling and the “Congestion Handling Period” timer are stopped.
Siemens AG:A50016-G5000-Z142-7-7618
2.3 Interdependencies of Congestion Control

This section provides information on:
• Congestion Control and Emergency Calls
• Congestion Control and Pre-Emption
• Congestion Control Algorithm for HSDPA
2.3.1 Congestion Control and Emergency Calls

Emergency calls are identified by the setting of the RANAP allocation/retention priorities
and based on the conversational traffic class. Upon setup of an emergency call, the con-
gestion check is bypassed if indicated by the “CC for Emergency Calls” parameter.
The handling of emergency calls during congestion control Stage 2 is specified by the
“CC for Emergency Calls” parameter as follows:
• “CC for emergency calls” = “true”
The congestion check during admission control is performed for emergency calls.
• “CC for emergency calls” = “false”
The congestion check during admission control is bypassed. Furthermore,
emergency calls are not dropped by congestion control.
2.3.2 Congestion Control and Pre-Emption

The allocation/retention priorities specified for Pre-Emption are used in the congestion-
control selection algorithm:
• Stage 1
UEs with a PS BE in the RAB combination are either switched to common channels
or the rate of the PS BE is reduced to minimum rate (if channel-type-switching is not
possible).
• Stage 2
The CRNC uses the ordered list of pre-emptable radio links and selects the radio
links to be released in ascending order of priorities and increasing DL spreading
factor for radio links with the same priority. If all pre-emptable radio links of this list
are released and the congestion still persists, the CRNC selects users from non-pre-
emptable radio links with increasing DL spreading factor.
Triggering of congestion control does not prevent the execution of ongoing pre-emption
procedures. New pre-emption procedures, however, are not started during congestion
control except in the event of a soft handover.
For more information see FD012243 - Pre-Emption.
2.3.3 Congestion Control Algorithm for HSDPA

In an HSDPA-capable cell, DL congestion is caused mainly by non-HSDPA bearers.
HSDPA UEs use on the HS-DPSCH and HS-SCCH the power left from the DCH users:
HSDPA power [watt]
= maximum DL Tx power [watt] - ((NHP[dBm] + Tx carrier power margin [dB]) [watt]
where
NHP = Rel99 Traffic+ All Common Channels Power
The “Maximum DL Transmission Power” is specified by the operator. The Tx carrier
power margin is specified by system data.
Siemens AG: A50016-G5000-Z142-7-7618

The congestion decision in DL therefore does not directly depend on the usage of
HSDPA. In the Congestion Decision, the non-HSDPA transmitted carrier power is used
instead of the transmitted carrier power to detect congestion in DL for HSDPA-config-
ured cells.
UL congestion, however, is more likely to be caused by users having HSDPA services
because high UL data rates on the DCH are available in combination with HSDPA on
the DL.
The basic congestion control mechanism selects UEs according to their downlink
spreading factor no matter if the congestion is occurred in DL or UL, see Congestion
Handling. If HSDPA is used, this mechanism may lead to inappropriate handling. More-
over, HSDPA users may be dropped even though they were not the root cause of the
situation.
Therefore, the following rules apply if HSDPA is used:
• Congestion occurs in DL direction only or in UL and DL direction:
In stage 2 and in stage 1, UEs with the lowest DL spreading factor are handled first
by taking into account both primary and secondary scrambling code.
• Congestion occurs in UL direction only:
In stage 1, UEs are sorted as follows:
– At first, all UEs which have a DL spreading factor of 256 (including HSDPA users)
are listed.
– Afterward, other UEs are ordered by increasing DL spreading factor.
In stage 2 UEs with the lowest DL spreading factor are handled first by taking into
account both primary and secondary scrambling code.
If bearers with identical DL spreading factors are found and they are comprised from the
primary and the secondary scrambling code tree, bearers from the secondary scram-
bling code tree are treated first.
For single PS BE HSDPA RAB UEs, the spreading factor of their associated DPCH
channel is used, when ranking UEs.
In general, single PS BE HSDPA RABs are handled by congestion control as follows:
• Only the UL direction is congested:
Single PS BE HSDPA services are switched to FACH in stage 1 by channel-type
switching if the “Enable Transport/Physical Channel Reconfiguration” parameter
etpchr is set to “True”.
• Only the DL direction is congested or the UL and the DL direction are congested:
Single PS BE HSDPA services are handled in stage 2 as follows:
– If the etpchr parameter is set to “False” and the “Enable Bearer Dropping” param-
eter ebd is set to “True”, call drop applies for UL/DL congestion.
– If the etpchr parameter is set to “True”, channel-type switching to FACH applies to
single HSDPA UEs for DL congestion.
The default value of the “Congestion Control Hysteresis” is set to 100 ms to be able to
react on congestion situations as soon as possible.
For more information see FD012249 - Support of HSDPA.
Siemens AG:A50016-G5000-Z142-7-7618
2.4 Failure Handling

When a cell is set up, the RNC sends to the Node B an NBAP:COMMON MEASURE-
MENT INITIATION REQUEST message, which indicates the conditions for reporting
Event E. If the Node B returns an NBAP:COMMON MEASUREMENT INITIATION FAIL-
URE message, it does not support event-triggered measurements. Then the values for
the received total wideband power/transmitted carrier power obtained by periodic com-
mon measurements are used as input of congestion control. The RNC sets a flag indi-
cating per cell whether event-triggered measurements are on or off. If the initiation of
periodic common measurements fails, the RNC receives an NBAP:COMMON MEAS-
UREMENT INITIATION FAILURE message and triggers the cell deletion procedure.
If the congestion control mechanism is active, report A may be received while no UE is
in the cell due to high interference from neighbor cells. The RNC ignores this event A.
The admission control algorithm will not accept new radio bearers because the conges-
tion control mechanism is active. When interference from neighbor cells decreases, the
Node B sends a report B and normal congestion handling carries on.
If event B is received while the congestion control mechanism is deactive, the report is
discarded.
2.5 Upgrade Strategy

It may happen that the Node B does not support event-triggered common measure-
ments during the system upgrade. If the RNC receives a COMMON MEASUREMENT
INITIATION FAILURE message from the Node B with the Measurement ID specified at
the initiation of the event-triggered common measurements, the RNC discards this
message and uses the periodic common measurements as initiated for admission
control purposes. Furthermore, the congestion handling period is set to the periodicity
of the common measurements, that is the reporting period for RSSI and reporting period
for transmitted carrier power parameters. This means that the decision on the existence
of a congestion is only based on the periodic common measurements. This handling is
the same as in UMR2.0.
2.6 Difference to the Congestion Control Algorithm in UMR2.0

The difference to the congestion control algorithm implemented in UMR2.0 is the use of
event-triggered common measurements for the detection of a congestion. In UMR2.0,
periodic measurements were used instead. Therefore, the additional “Congestion
Handling Period” timer has been introduced. The “Congestion Handling Period” is the
time between the switching/dropping of K UEs, see “Congestion Handling” on page 14.
Furthermore, PS background/interactive and PS streaming services are differentiated in
UMR3.5. Additionally, the definition of the “DL Congestion Threshold” and
“DL Congestion Hysteresis” have changed, see “Man-Machine Interface” on page 25.
Siemens AG: A50016-G5000-Z142-7-7618

2.7 Feature Evolution

The FD012220C - Enhanced Congestion Control is available since UMR3.5. Enhance-
ments related to this feature that were introduced later than UMR3.5 are:
• The FD012240 - Admission Control of Prioritized Bearers, introduced with UMR4.0,
changes the Enhanced Congestion Control feature as follows:
– A congestion check is always performed upon RRC connection setup (except for
NAS related handling) and RAB setup. For the handling of emergency calls see
Congestion Control and Emergency Calls.
– Prior to UMR4.0, emergency calls are handled as NAS-related signaling bearer
and therefore the admission control threshold for NAS-related SRB are used.
From UMR4.0 onward, additional operator-configurable thresholds for emergency
calls are available.
– The definitions of the congestion control thresholds are updated to prevent a
situation in which the UL/DL threshold is below the current values of NUL and
PCOMMON in UL and DL respectively. For information on the behavior in UMR3.5
see Measurement Thresholds 1 and 2 in UMR3.5.
– In UMR3.5, the UL measurement thresholds are only changed if the previous
signaled value of threshold 1 and the new value of threshold 1 differ by more than
the “Update Threshold“. From UMR4.0 onward, the “Update Threshold for UL CC”
is used.
• The Pre-Emption feature is introduced with UMR4.0. If this optional feature is active,
step 2 of the congestion control mechanism is modified. For more information see
FD012243 - Pre-Emption.
• For the usage of HSDPA in UMR5.0, the congestion control is adapted as described
in Congestion Control Algorithm for HSDPA. For more information see FD012249 -
Support of HSDPA.
2.7.1 Measurement Thresholds 1 and 2 in UMR3.5

This section provides information on the measurement thresholds for the release when
the Enhanced Congestion Control feature was introduced.
Thresholds 1 and 2 for the total received wideband power

The uplink congestion threshold relative to thermal noise is an operator-configurable
parameter with the range 0, ..., 62 dB and a step size of 0.1 dB.
• Absolute threshold 1
The absolute threshold 1 (THR1) is the sum of the noise density (NUL) of the uplink
receiver and the uplink congestion threshold:
THR1 = MAX (NUL + UL_cong_threshold, 0)
The absolute threshold 2 (THR2) is the difference between threshold 1 and the
uplink congestion hysteresis:
THR2 = MAX (THR1 - UL_cong_hys, 0)
These thresholds have to be mapped to the values specified in 3GPP TS 25.133
according to the following formulas:
• Measurement Threshold 1 = median (0; 621; THR1*10 + 1121)
• Measurement Threshold 2 = median (0; 621; THR2*10 + 1121)
Siemens AG:A50016-G5000-Z142-7-7618
If the noise density of the uplink receiver (NUL) is already mapped to the table specified
by 3GPP TS 25.133, the following formulas apply:
• Measurement Threshold 1 = median (0; 621; NUL + UL_cong_threshold*10)
• Measurement Threshold 2 = median (0; 621; Measurement Threshold 1-
UL_cong_hyst*10)
where NUL is mapped to 0, ..., 621.
Thresholds 1 and 2 for the transmitted carrier power:

The downlink congestion threshold relative to the maximum downlink power is an
operator-configurable parameter with the range 0, ..., 1 and a step size of 0.01.
The absolute threshold 1 (THR1) is specified by the downlink congestion threshold.
THR1 = MAX (DL_cong_threshold, 0)
The absolute threshold 2 (THR2) is the difference between threshold 1 and downlink
congestion hysteresis.
THR2 = MAX (THR1 - DL_cong_hyst, 0)
These thresholds have to be mapped to the values specified in 3GPP TS 25.133 by the
following formulas:
• Measurement Threshold 1 = median (0; 100; THR1*100)
• Measurement Threshold 2 = median (0; 100; THR2*100)
Siemens AG: A50016-G5000-Z142-7-7618

3 Functional Split
Not applicable.
Siemens AG:A50016-G5000-Z142-7-7618
4 Man-Machine Interface
Name Range Default Value Description/Remarks
Uplink congestion 0, …, 62 dB 10 dB Value for the uplink congestion threshold

threshold (in steps of 0.1)
Note (UMR4.0 onward):
THR1 = NUL + UL_cong_threshold
where UL_cong_threshold > 0
Uplink congestion 0, …, 10 dB 2 dB Value for the uplink congestion
hysteresis (in steps of 0.1) hysteresis
Note (UMR4.0 onward):

THR2 = MAX(THR1 - UL_cong_hyst,
NUL)
It is recommended to set this parameter

under the following condition:
UL_cong_hyst < UL_cong_threshold
THR2 shall not be <= NUL

Downlink congestion 0, …, 1 dB 0.9 dB Value for the downlink congestion
threshold (in steps of 0.01) threshold
(0.9 corresponds to 18 Watt.)
Notes:
For an upgrade from UMR3.0 to UMR3.5
this is only a change in the range and
default value of the already existing pa-
rameter “Downlink Congestion Thresh-
old”.
UMR4.0 onward: DL_cong_threshold >=
Pcommon
Downlink congestion 0, …, 1 dB 0.15 dB Value for the downlink congestion
hysteresis (in steps of 0.01) hysteresis
(this corresponds to 0.75 lower CC
threshold and 0.8 dB CC hysteresis)
Notes:
For an upgrade from UMR3.0 to UMR3.5
this is only a change in the range and
default value of the already existing pa-
rameter “Downlink Congestion
Hysteresis”.
UMR4.0 onward: It is recommended to
set this parameter under the following
condition:
DL_cong_hyst < DL_cong_threshold
THR2= DL_cong_threshold -
DL_cong_hyst
THR2 must be > Pcommon
Tab. 4.1 Parameters that are configurable by the operator per cell at the OMC-R
Siemens AG: A50016-G5000-Z142-7-7618


Congestion handling 0, …, 10 s 0.5 s Period between congestion control
period (in steps of 0.1) actions
Reporting period for the re- 0.01 to 3600 s 10 s Reporting period for the received total
ceived total wideband 0.01 to 60 step 0.01 s wideband power
power 60 to 3600 step 60 s
Reporting period for the 0.01 to 3600 s 10 s Reporting period for the transmitted
transmitted carrier power 0.01 to 60 step 0.01 s carrier power
60 to 3600 step 60 s UMR5.0 onward: This parameter
indicates the interval in which periodic
reports of either the non-HSDPA
transmitted carrier power (if the cell is
HSDPA-capable) or the transmitted
carrier power (if the cell does not provide
HSDPA service) is issued.
Number of bearers 0, …, 10 1 Number of bearers that are
dropped/switched in one (in steps of 1) switched/dropped/bit rate adapted in
step each step
Enable bearer dropping False, True True Enables/disables bearer dropping
Enable transport/ physical False, True True Enables/disables transport/physical
channel reconfiguration channel reconfiguration
CC for emergency calls True, False False Note: Function available from UMR4.0
on. For more information see FD012240
- Admission Control of Prioritized Bear-
ers.
True: A congestion check is performed

upon the establishment of an emergency
call. In addition, emergency calls can be
handled during the stage 2 of congestion
control.
False: The Congestion check is
bypassed upon the establishment of an
emergency call. In addition, emergency
calls are not handled during the stage 2
of congestion control.
Tab. 4.1 Parameters that are configurable by the operator per cell at the OMC-R
The “Reporting period for the received total wideband power” and “Reporting period for
the Transmitted Carrier Power” parameters configure the periodicity of the common
measurements which are used for admission control or congestion control in case of
event triggered common measurement setup failure. In the database, these parameters
are under the congestion control object.
Tab. 4.2 shows measurement filter coefficient parameter for congestion control.
Siemens AG:A50016-G5000-Z142-7-7618
Measurement filter (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 Filter coefficient for RTWP measure-

coefficient for RTWP 11, 13, 15, 17, 19) ments
Measurement Filter (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 Filter coefficient for transmitted
coefficient for transmitted 11, 13, 15, 17, 19) carrier power measurements
carrier power
Tab. 4.2 Measurement filter coefficient parameter for congestion control
Siemens AG: A50016-G5000-Z142-7-7618

5 Operating the Feature

The following parameter settings apply to the Enhanced Congestion Control feature:
1. Specify parameter for congestion control. ⇒ CLI command:

cell cctl
GUI window:
Cell
Procedure:
-
Additional tasks for radio resource management control are described in detail in the
OMN:Radio Network Configuration - Procedures.
Siemens AG:A50016-G5000-Z142-7-7618
6 Abbreviations
3GPP Third Generation Partnership Project
AC Admission Control
BE Best Effort
BRA Bit Rate Adaptation
CM Configuration Management
CRNC Controlling Radio Network Controller
CS Circuit Switched
DCH Dedicated Channel
DL Downlink
DRNC Drift Radio Network Controller
FACH Forwarding Access Channel
IE Information Element
Iur Interface between RNCs
LMT Local Maintenance Terminal
NBAP Node B Application Part
OAM Operation and Maintenance
PM Performance Measurements
PS Packet Switched
QoS Quality of Service
RAB Radio Access Bearer
RACH Remote Access Channel
RAN Radio Access Network
RC Radio Commander
RLC Radio Link Control
RLS Radio Link Set
RNC Radio Network Controller
RNSAP Radio Network Subsystem Application Part
RRC Radio Resource Control
SIR Signal to Interference Ratio
SMS Short Message Service
SRNC Serving Radio Network Controller
SSD Source Statistics Descriptor
TFC Transport Format Combination
TS Technical Specification
UDI Unrestricted Digital Information
UE User Equipment
UL Uplink
UMTS Universal Mobile Telecommunications System
UTRAN UMTS Terrestrial Radio Access Network
Siemens AG: A50016-G5000-Z142-7-7618


Utran: Radio Subsystem Basic Package - Enhanced Congestion Control FD012220C - UMR3.5

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

Utran: Radio Subsystem Basic Package - Enhanced Congestion Control FD012220C - UMR3.5

Uploaded by

Copyright:

Available Formats

UTRAN

f Important Notice on Product Safety

The same text in German:

Copyright (C) Siemens AG / NEC Corporation 2004-2006.

Technical modifications possible.

Reason for Update

2.2.1 Description on the spreading factor updated.

2 Document updated due to review comments.

1 08/2004 First issue for new release.

2 01/2005 Clarification of the mechanism.

3 08/2005 Editorial changes.

4 09/2005 Mechanism of CC stage 1 updated.

5 12/2005 Document updated due to review comments.

6 02/2006 Description on the spreading factor updated.

7 09/2006 Description on the spreading factor updated.

Siemens AG: A50016-G5000-Z142-7-7618

This document consists of 29 pages. All pages are issue 7.

5 Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.2 Customer Benefits

1.3 Inter-Working / Dependencies

Siemens AG: A50016-G5000-Z142-7-7618

2.1 Interactions of Congestion Control

CRNC CRNC OAM

Bearer RNSAP: Radio Link Failure

Congestion Indication (to AC)

Fig. 2.1 Interactions of congestion control

2.2 Basic Concept of Congestion Control

Siemens AG: A50016-G5000-Z142-7-7618

2.2.1 Congestion Decision

Report periodicity Time

Common measurement report A report B

Fig. 2.2 Basic concept for congestion control

2.2.1.1 Initiation of the Event-Triggered Common Measurements

IE / Group name Presence Value IE type

Message Discriminator M Common

Tab. 2.1 Common measurement initiating request

Siemens AG: A50016-G5000-Z142-7-7618

IE / group name Presence Semantic description Value

CHOICE Report Characteristics

Tab. 2.2 Reporting characteristics for event E

Thresholds 1 and 2 (UL)

Thresholds 1 and 2 (DL)

Congestion Threshold Update

2.2.1.2 Handling of Lost Events

Siemens AG: A50016-G5000-Z142-7-7618

The following algorithm is used to handle lost events:

Congestion Control Handling

Fig. 2.3 Failure handling of lost events

2.2.1.3 Higher Layer Filtering

Siemens AG: A50016-G5000-Z142-7-7618

2.2.2 Congestion Handling

Measurement report from Node B

Congestion detected Yes

No Comparison with Congestion resolved

Send congestion indication

Select radio bearers

Rate decrease Yes

Request SRNC/DRNC to drop

Fig. 2.4 Congestion handling flow

Siemens AG: A50016-G5000-Z142-7-7618

etpchr ebd Congestion handling

“Enable” CTS and “Enable” bearer dropping Stage 1:

Tab. 2.3 The “etpchr” and “ebd” parameters in congestion handling