Introduction

The aim of the overload control mechanism is to preserve the traffic-handling capabilities of the mobile base station system (BSS) under adverse conditions.With the term overload it is meant that part of the total load offered in excess of the traffic processing capacity of the BSS.The overload control mechanism is implemented in the BSC and consists of traffic detection mechanism and defensive action makers.Traffic detection mechanism consists of ‘overload messages’ coming either from the various parts of the network (BTS and/or MSC) of from the BSC itself (overload detection).Defensive actions aimed at reducing both mobile originating (MOC) and/or mobile terminating (MTC) calls (overload handler); the strategy is here presented and follows the GSM recommendation 08.08.GSM rec 08.08 gives the following definition of the general overload handling strategy: „The overload causing traffic is reduced in several timer guarded steps until the overload is prevented. Otherwise, if for some time no overload is indicated, the traffic is increased again in timing steps until full load has been resumed“.The time-out values of the timers, number of steps, amount and type of traffic reduced in each step, overload recognition and threshold parameters are all considered implementation dependent and have not been specified.Essentially there are two methods to reduce overload: reducing the mobile terminating traffic by discarding paging messages, reducing the mobile originating traffic by barring the access to specific cells.Access barring is done using the access classes specified by GSM (refer to GSM 08.08). There are 10 access classes (0...9) related to normal subscribers. The access class to which a subscriber belongs is derived from his IMSI. Furthermore, there are 5 classes (11...15) assigned to special high priority subscribers (e.g. police, PLMN operator, ...). The bit 10 (EC) indicates whether emergency calls are allowed in the cell for all subscribers or only the special ones.To reduce overload in moderate way, incoming traffic is not completely rejected, but reduced by several steps of escalation controlled by two timers.

Timer Control of Overload Reduction

When getting informed on an overload situation in a BTS, in the MSC or in the BSC itself, the BSC performs the first step for traffic reduction and starts two timers T17 and T18 with T18 > T17.During run time of T17 all overload messages with the same cause as the initializing message are ignored in order not to reduce the traffic too rapidly.If the overload situation is still present after expiry of T17, but during runtime of T18, the next step of traffic reduction is initiated and T17 and T18 are started again. This step by step reduction of traffic is maintained until the maximum reduction is obtained arriving at the last step.If time T18 expires (i.e. no overload message is received), the BSC increases the traffic by one step (i.e. stops the traffic reduction measure of the last step) and restarts timer T18. This increment will continue until full load has been resumed.

T18

2. step of loadreduction

1. step of loadreduction

restart T18increase trafficby one step

increase trafficto full load

restart timers

start timers

BSC MSC

overloadT17

overload (ignored)

overload

overload (ignored)

Fig. 1

The two timer T17, T18 are administered in the object BSC, package BSCT:Name range Unit Meaning

T17 <unit>-0...<unit> 254Default: 20 half sec.

half secondsfive seconds

started when an overload message is detected, during runtime of T17 overload messages are ignored.

T18 <unit>-0...<unit> 254Default: 60 half sec.

half secondsfive seconds

Started in case of overload, defines the observation time for overload.

Fig. 2

1 Overload Detection and Counter Measures

BTS Overload Handling

no TCH available call rejected (in future release: queuing and directed retry, i.e. serving the call by a suitable neighbor cell)

no SDCCH available

rejection by immediate assignment reject message, new access is barred for a certain time (timer T3122)

AGCH overload (i.e. BS is not able to forward immediate assignment or immediate assignment reject messages). 1st step: BSC barrs the first half of access classes of that cell 2nd step: BSC barrs the second half of access classes of that cell

PCH overload: PCH overload is detected when the free buffer space in the BTS for paging messages is zero or below a threshold (given by the parameter (CCCH_LOAD_THRESH)). Then the BSC is periodically (period given by parameter CCCH_LOAD_IND_PERIOD) informed on the current load on the PCH. The reaction of the BSC is pagings for the concerned BTS are discarded and the MSC is notified.

BSC Overload Handling

BSC overload is detected when the Tx buffers of the CCS7 links are congested the percentage of busy (level 3) registers to handle incoming call requests is

above a threshold (90%) The real time processor load of the telephony processor TDPC is above a certain

threshold set by the O&M parameter OVLSTTHR. Sending of overload messages is stopped when the load is below a second parameter OVLENTHR with OVLENTHR < OVLSTTHR.

When BSC overload is detected, the following steps for traffic reduction are performed 1st step: the BSC barrs the first half of access classes in a group of cells

2nd step: the BSC barrs all access classes in that group of cells3rd step: BSC performs step 1 and 2 for the next group of cells4th step: ... (and so on till the overload situation disappears)

Within the traffic reduction algorithm, a round robin mechanism is used. This means if for counteracting one overload situation, cells 1 to 4 had been barred and the overload ends, the 4 cells are unbarred. If an overload situation occurs again, the overload handler starts barring from the 5th cell and not from the first one.

MSC Overload Handling

MSC overload is detected by the MSC itself. The BSC is informed by an overload indication messages with cause „processor overload“. The MSC reduces paging load by its own and therefore the BSC reduces only mobile originating traffic by means of barring access classes (in the same way as for BSC overload).

Parameters for Overload Handling:

Specification Name

Object/ Packag

e

DB Name Range Meaning

T3122 BSC/ BSCB

T3122 0...255 sec

Timer to barr a new access for a certain time after unsuccessful access (e.g. no SDCCH available)

EN_BSC_OVL _HAND

BSC/ BSCB

BSCOVLH TRUE, FALSE

flag to enable/disable BSC overload handling

EN_MSC_OVL __HAND

BSC/ BSCB

MSCOVLH

TRUE, FALSE

flag to enable/disable MSC overload handling

EN_BTS_OVL __HAND

BSC/ BSCB

BTSOVLH TRUE, FALSE

flag to enable/disable BTS overload handling

OVL_START _THRESH

BSC/ BSCB

OVLSTTHR

7000... 10000

threshold for TDPC processor (in BSC) overload detection: 10000 = 100 %

OVL_END _THRESH

BSC/ BSCB

OVLENTHR

7000... 10000

threshold for TDPC processor (in BSC) below which the sending of overload messages is stopped: 10000 = 100 %

CCCH_LOAD _IND_PERIOD

BTS/ BTSB

LDPERIOD

0...255 sec

period for sending the CCCH load indication message from BTS to BSC

CCCH_LOAD _THRESH

BTS/ BTSB

LDTHRESH

0...100%

CCCH load threshold, if this threshold is exceeded the BTS informs the BSC using the CCCH load indication message

Fig. 3