Overload Handling
description
Transcript of Overload Handling
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