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.

BSC start timers 1. step of load reduction restart timers 2. step of load reduction T18 T17 overload overload (ignored) overload overload (ignored)

MSC

restart T18 increase traffic by one step

increase traffic to full load

Fig. 1

The two timer T17, T18 are administered in the object BSC, package BSCT: Name range Unit Meaning T17 <unit>-0... half seconds started when an overload message is <unit> 254 five seconds detected, during runtime of T17 Default: 20 half overload messages are ignored. sec. T18 <unit>-0... half seconds Started in case of overload, defines <unit> 254 five seconds the observation time for overload. Default: 60 half sec.
Fig. 2

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) rejection by immediate assignment reject message, new no SDCCH access is barred for a certain time (timer T3122) available 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 cells 3rd step: BSC performs step 1 and 2 for the next group of cells 4th 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:

Specificatio n Name T3122 EN_BSC_OV L _HAND EN_MSC_OV L __HAND EN_BTS_OV L __HAND OVL_START _THRESH OVL_END _THRESH

CCCH_LOAD _IND_PERIO D CCCH_LOAD BTS/ _THRESH BTSB

Object/ DB Name Range Meaning Packag e BSC/ T3122 0...255 Timer to barr a new access for a BSCB sec certain time after unsuccessful access (e.g. no SDCCH available) BSC/ BSCOVLH TRUE, flag to enable/disable BSC overload BSCB FALSE handling BSC/ MSCOVL TRUE, flag to enable/disable MSC overload BSCB H FALSE handling BSC/ BTSOVLH TRUE, flag to enable/disable BTS overload BSCB FALSE handling BSC/ OVLSTTH 7000... threshold for TDPC processor (in BSCB R 10000 BSC) overload detection: 10000 = 100 % BSC/ OVLENTH 7000... threshold for TDPC processor (in BSCB R 10000 BSC) below which the sending of overload messages is stopped: 10000 = 100 % BTS/ LDPERIO 0...255 period for sending the CCCH load BTSB D sec indication message from BTS to BSC LDTHRES 0...100 H % CCCH load threshold, if this threshold is exceeded the BTS informs the BSC using the CCCH load indication message

Fig. 3