You are on page 1of 10

Advanced Congestion Relief

Central Optimization Team

1 / 10

Advanced Congestion Relief


DESCRIPTION..................................................................................................................3
REASON FOR ACTIVATION........................................................................................3
IMPACT ON GSM NETWORK......................................................................................3
TYPES OF BTS SUPPORTED BY FEATURE..............................................................3
TYPE OF BSC SUPPORTED BY THIS FEATURE.....................................................3
DATABASE PARAMETERS INVOLVED...................................................................4
1) ENABLING THE INTELLIGENT CONGESTION RELIEF FEATURE .....................................4
2) BASIC HANDOVER ON CONGESTION FUNCTIONALITY.................................................4
3) NON-IMPERATIVE HANDOVER REJECTION....................................................................5
4) CONGESTION RELIEF HANDOVER RETRY......................................................................6
5) INCOMING HANDOVER REQUESTS................................................................................6
6) HANDOVER RETRY.......................................................................................................8
7) ASSOCIATED DATABASE PARAMETERS........................................................................8
8) FIGURE 1: DESCRIPTION OF ADVANCED CONGESTION RELIEF....................................9

2 / 10

Advanced Congestion Relief

Description
The Advanced Congestion Relief procedure feature is an enhancement to Motorola's optional Handover
on Congestion feature.
Handover on congestion offers a higher quality solution compared with the use of ETSI defined
directed retry procedures, since it allows the operator to shed traffic from heavily loaded cells prior to
reaching a fully congested state. Once a cell reaches its operator defined congestion threshold, existing
traffic is optimally handed over to non-congested cells, thereby relieving the condition and clearing
capacity for new calls or originations. By way of comparison, directed retry forces originations in
congested cells to be directed immediately to other cells which many times can result in poor cell
assignments and poor call quality.

Reason for activation


Deployment of this feature results in better overall system quality as the best handover candidate is chosen
instead of a random candidate. Probability of traffic channel blocking is reduced thus contributing to
increased capacity and quality of service. The feature helps maintain highest call quality while enhancing
the network's traffic handling capacity.

Impact on GSM network


This feature improves network quality and capacity during high traffic periods.
Based on field experience and analysis of new multiband scenarios, Motorola has identified several
improvements that enhance the quality and effectiveness of handover on congestion. These new
procedures deliver the following advantages:
Faster congestion relief by preventing handovers to non-ideal targets

Reduced signaling traffic through fewer handover attempts


Less congestion and fewer congestion relief triggers by intelligently preventing handovers that leads to
congestion in other cells
Efficient congestion control in the preferred band of a multiband network.

Types of BTS supported by feature


All

Type of BSC supported by this feature


All

3 / 10

Database Parameters involved


1) Enabling the Intelligent Congestion Relief feature
ENHANCED_RELIEF = 1 (Already 1 on all cells)
The enhanced_relief parameter enables or disables the Intelligent Congestion Relief feature.
chg_element enhanced_relief <value> <location> cell=<cell_desc>
Value (valid range):
0

Disabled

Enabled

2) Basic Handover on Congestion Functionality


HO_EXIST_CONG = 2 (Already 2 on all cells)
This parameter determines if attempts to handover existing calls on a TCH will be initiated in the case of an
MS needing a TCH when there are none available in that cell. The maximum number of handovers initiated
by this parameter is one of the following:

The number of queued requests in the congested cell.

The number of calls meeting the congestion handover criteria in the congested cell. This selection may
provide more effective congestion relief for cells that experience frequent congestion.

When the cell becomes congested, TCH requests are queued regardless of whether queuing is enabled in
the cell in order to give the congestion procedure a chance to work before failing the requests. Handovers
are initiated only for established calls if neighbors are available meeting the specified congestion handover
criteria (PBGT (n) Congest_ho_margin > 0). This is a reduced HO margin that MS must meet in order
to be handed over.
chg_element ho_exist_congest <value> <location> cell=<cell_desc>
Value (valid range):
0

Disabled

Attempt to handover as many calls as the number of queued assignment requests

attempt to handover as many calls as meet the congestion handover criteria

VALID_CANDIDATE_PERIOD = 4000 (Already 4000 on all cells)


This parameter is a timer that controls the duration that candidates for handovers due to congestion are
valid before querying for new ones.

4 / 10

chg_element valid_candidate_period <value> <location> cell=<cell_desc>


Value (valid range): 1 to 1000000 (ms)
Default:

4000 ms

(See Figure 1 for further explanation of above-mentioned functionality. Application scenario in cell A)

3) Non-imperative handover rejection


TCH_CONGEST_PREVENT_THRES = 90 (To be made 90 on the desired
cells)
This parameter specifies the level of overall TCH utilization by any MS in a given cell, at which the
Congestion Relief procedure is initiated. The parameter is expressed as a percentage and sets the
Tch_congest_prevent_thres as compared with percentage of busy TCH. If the TCH allocation brings the
percentage of busy TCH above this threshold, the Congestion Relief procedure is initiated.
chg_element tch_congest_prevent_thres <value> <location>cell=<cell_desc>
Value (valid range):
0

Disabled

1 to 100

Congestion Relief process starts when specified threshold is reached.

101

Congestion Relief process starts when all available TCH are in use, and at least one more
TCH is requested.

The BSS rejects an incoming non-imperative handover if it will cause congestion relief procedures to be
triggered. The BSS does not allow an incoming handover if the reason for that handover is congestion relief
(or other non-imperatives) and the handover itself will lead to the invocation of congestion relief
procedures (tch_congest_prevent_thres is exceeded). Should such a handover be allowed, then the net
result would simply be the movement of a congestion problem from one cell to another. Excessive
handovers are therefore eliminated.
Non-imperative handovers are:

Congestion Relief

Power Budget

Band Handovers

Band Reassignments

5 / 10

(See Figure 1 for further explanation of above-mentioned functionality. Application scenario in cell A)

The command may be rejected if the value of mb_tch_congest_thres is set more then this parameter.
So mb_tch_congest_thres will have to be set < = tch_congst_prev_thres.

4) Congestion relief handover retry


RTRY_CAND_PRD = 4000 (Already Set)
EXT_RTRY_CAND_PRD = 4000 (Already Set)
The source cell will not attempt a non-imperative handover, for a period of time, to a target cell, which had
rejected a previous handover attempt, both imperative and non-imperative. Two new timer elements,
rtry_cand_prd and ext_rtry_cand_prd (external cell) are used to control this period of time. This protects
the system from experiencing excessive handover attempts, as well as resulting in a reduction in signaling.
This timer only affects non-imperative types of handovers, such as Congestion Relief, Band Reassignment,
Band Handovers, and Power Budget Handovers. It does not, however, affect any imperative handover
retries. These handovers are allowed to take place regardless of such timers, as they are needed in order to
keep the call active.
If a target cell receives an incoming HO due to Congestion Relief (cause value Traffic on external
handovers), this timer prevents the target cell from triggering a CR handover back to the source cell.
Chg_element rtry_cand_prd <timer length> <location> cell=<cell_desc>
Value (valid range): 1 to 1000000 (ms)
Default:

4000 ms

chg_element ext_rtry_cand_prd <timer length> <location> cell=<cell_desc>


Value (valid range): 1 to 1000000 (ms)
Default:

4000 ms

(See Figure 1 for further explanation of above-mentioned functionality. Application scenario in cell B)

5) Incoming handover requests


If a BSS target cell rejects an incoming handover, because that handover would trigger congestion relief
procedures, the target cell will inform the source cell of its future, intra-BSS only, accessibility status. If the
target cell is configured to optionally invoke congestion relief procedures after rejecting the handover
request, then it may be capable of handling the necessary handovers.

6 / 10

CONGEST_AT_TARGET = 1 (Already Set)


This element controls the behavior of the target cell should it reject a handover request, either imperative or
congestion relief.
chg_element congest_at_target <value> <location> cell=<cell_desc>
Value (valid range):
0

No action if the Cell rejects a handover request

The system will invoke Congestion Relief procedures if this cell rejects a handover request
and the source cell will be informed that CR procedures have begun

(See Figure 1 for further explanation of above-mentioned functionality. Application scenario in cell C)

7 / 10

6) Handover retry
CONGEST_AT_SOURCE = 1 (Already set)
This element enables the source cell to optionally retry an imperative, intra-BSS only, handover to target
cells, which rejected the initial handover request (were unable to service it) and indicated (to source cell)
that they had initiated a congestion relief procedure following the initial rejection.

chg_element congest_at_source <value> <location> cell=<cell_desc>


Value (valid range):
0

No actions if a given candidate rejects a handover

If an imperative handover is needed, the source cell retries candidates which were
previously unable to serve the handover request

(See Figure 1 for further explanation of above mentioned functionality. Application scenario in cell B)

7) Associated database parameters


The following database parameter is not directly related to this feature, however it has an effect on its
functionality. Therefore, it is strongly recommended that to be set to the value specified, as follows:

HANDOVER_REQUIRED_REJECT_SWITCH = 1 (0 RIGHT NOW)


This parameter shall be set to 1. This will ensure that the MSC sends a handover required reject message to
the source BSC in the event that a target cannot be found for a requested handover. This message is needed
so that the external cell will be properly marked when it gets rejected.

8 / 10

8) Figure 1: Description of Advanced Congestion Relief

Figure 1. Description of Advanced Congestion Relief procedures and functionality

Prerequisites for the features to work:


CELL A

HO_EXIST_CONGEST = 1 or 2 (recommended 2 for Mobilink)


TCH_CONG_PREVENT_THRES <> 0 (recommended 90)

CELL B

HO_EXIST_CONGEST = 1 or 2 (recommended 2)
TCH_CONG_PREVENT_THRES <> 0 (recommended 90)
CONGEST_AT_SOURCE = 1

CELL C

HO_EXIST_CONGEST = 1 or 2 (recommended 2)
TCH_CONG_PREVENT_THRES <> 0 (recommended 90)

9 / 10

CONGEST_AT_TARGET = 1
ALL CELLS A, B, C HANDOVER_REQUIRED_REJECT_SWITCH = 1, ENHANCED_RELIEF = 1

10 / 10

You might also like