FOR OVERLOAD IN BSC

- ALLIP;

Check the Alarm list carefully for any abnormal Alarms, such as link failures, congestions, APZ alarms etc.
Act on the alarms following OPI if possible. Note that there could be critical alarms hiding low down the
alarm list if they have been defined with low alarm classes. A good example of this could be the “Radio
Control Administration TRH Load Threshold Exceeded”.

- PLLDP;

During processor load limitation it is obvious that some calls will be rejected. Which kind of calls are
rejected can be easy identified by comparing the values for offered and fetched traffic from the PLLDP;
printout.

The sum of all fetched values should be in a reasonable level. You might suspect a software fault in case
that all (not only one) fetched values drop almost to zero, but keep in mind that the capacity for
rejection of calls is not reflected in these fetched values. It should also be noted that there could be
situations where the PLOAD value is very low and yet the BSC is not handling all the offered traffic. One
reason is that the pre-seize blocks have reached their capacity limit and are rejecting calls even before
asking LOAS for capacity. The other reason is that the connected MSC is overloaded. Check the
Processor Load in the MSC for the second instance.

- Check Signaling towards the MSC

It should be noted that signaling links (SLC) could be active but effectively not carrying any traffic related
messages if the MTP3 Routing and the SCCP definitions are not done.

See if the signaling links are working normal.

C7LTP:LS=all;

See if the MTP Routing is defined and active

C7RSP:DEST=all;

See if the SCCP layer is working (Allowed).

C7NCP:SP=all, SSN=all;

- Check for any Transmission Related Problems

The DIP Quality Supervision Alarms in the alarm List are a good indication if there are any transmission
problems on the A-interface or the Abis-interface.

- Check for Software Congestions

Alarm “Size Alteration of Data Files Size Change Required” indicates congestion of software.
Check the DBS table for the congested SAE:

DBTSP: TAB=SAACTIONS;

Sometimes congestion occurs but neither the alarm is raised nor entry is put into SAACTIONS. Use TEST
SYSTEM to find congestion in this case:

TEST SYSTEM;

ON IN DO: FOR 10 TIMES, P MS, P SWD,;

ON IN SAFCO CONGREPORT;

INIT;

Data word 1 in the signal CONGREPORT contains the sending block reference and data word 2 contains
the SAE number.

- Check that the Transceiver Handlers are not congested

Print the events issued in the latest interval in the event log.

RAHEP:NOINT=1;

If there are TRH’s that are running low on capacity and are rejecting calls, order an immediate
rearrangement.

RAHII;

- Check the number of call attempts from STS output.

Compare the number of call attempts to previous values, to see how much traffic is being received and
handled by the BSC.

- Check the MSC-BSC route occupancy

Knowing how many devices in the MSC-BSC route are occupied will give a rough indication of how much
traffic is being handled by the BSC. This Check will have to be done in the MSC.

STRSP: R=bsc route;

3.2 FOR OVERLOAD IN MSC

- ALLIP;

Check the Alarm list carefully for any abnormal Alarms such as link failures, congestions, APZ alarms etc.
Act on the alarms following OPI if possible.

- PLLDP;
During processor load limitation it is obvious that some calls will be rejected. Which kinds of calls are
rejected can be easy identified by comparing the values for offered and fetched traffic from the PLLDP
printout.

The sum of all fetched values should be in a reasonable level. You might suspect a software fault in case
that all (not only one) fetched values drop almost to zero, but keep in mind that the capacity for
rejection of calls is not reflected in these fetched values.

- MGSVP;

Is it possible that the number of active subscribers may cause such high traffic? Compare the value of
active subscribers in VLR with values from previous days.

- Check history of the exchange

Find out the normal traffic load at this hour, recent DT changes, extensions or software upgrades etc.

Discuss with the operation & maintenance (O&M) engineers of the particular node if hardware
extension, DT changes, recent software updates, moving of cells, and the normal average traffic at this
hour. Please keep in mind that the traffic could increase tremendously in some special day such as the
lottery draw day.

- Check C7 signalling network

It is important here to consider possible C7 signalling failures causing higher load because the
destination cannot be reached and alternatives don’t exists or are not properly defined. In theory the
alarm list can often accurately indicate the problem area if there is some thing wrong in C7 network,
provided that various C7 supervisions are defined and activated properly. However those alarms could
be easily ignored if the alarm list is too long.
Firstly, you can check the status of all signalling links by:

C7LTP: LS=ALL;

Note that normally there should be alarm of “CCITT7 Signalling Link Failure” if some signalling link fails.

Then to see if the MTP routing is defined and active you can use:

C7RSP: DEST=ALL;

Normally alarm “CCITT7 Destination Inaccessible” would be generated if the C7 signalling link towards
certain destination is not reachable.

Check if the SCCP layer is working fine by:

C7NCP: SP=ALL, SSN=ALL: Make sure the SCCP status of others nodes are “Allowed”.

Check C7 event report by:

C7ERP: ENUM=ALL or EREPP: ENUM=ALL; (R9.1)

C7 Event Report is a comprehensive monitoring of all layers of C7 signalling network. If those relevant C7
Event Reports have been initiated properly, we can gain a clear picture of how the C7 network is
working by analyzing the contents of those Event Reports. Please be noted that in MSC R9.1 a couple of
new commands were introduced for C7 Event Report handling. They are all started with ER***, such as
EREPP and etc.

- Devices on BSC routes

Look at this may give you a rough indication of how many “on going” calls between BSC and MSC.

If all (or almost all) devices are busy towards the BSC this indicates under dimensioning of this route and
means that some Terminating calls fail in the MSC at a very late stage (or are diverted to voicemail). We
assume that for every failed call there are at least 2 or 3 reattempts and this will cause higher processor
load in the MSC.
Some Mobile Originating calls will be rejected in the BSC because there is no free device towards the
MSC available. Reattempts of these rejected originating calls will increase the load in the BSC also (check
PLLDP; in the BSC).

On the other hand if the number of devices in state busy is very low (compared to average figures) or
almost zero a software fault or DT fault might be suspected.

- Devices on routes towards PSTN and TR exchange

In a high traffic or overload situation you expect to see a high number of the devices in state busy or
incoming.

When all (or almost all) devices are busy towards the PSTN/TR this indicates under dimensioning of this
route and means that some mobile originating calls will fail at a very late stage in MSC/VLR.

Some Mobile Terminating traffic will fail due to the fact that no device is available. In this case we
should remember that the GMSC needs a roaming number before the call can be terminated to the
MSC/VLR. Consequently, every failed mobile terminating call uses some capacity in MSC/VLR as well as
in the GMSC and HLR.

A very low number of devices in state busy (compared to average figures) indicates a software fault or
DT fault might be suspected.

- Check IN traffic by C’ARLDP

Compare the number of IN sessions being handled by system to the history values. This is very helpful to
know what the system is working on if you consider that an IN call consumes much more system
resources, in particular C7 signalling resources, than an ordinary GSM call.

- Check the load in the other surrounding nodes. HLR, GMSC, FNR etc. This can give you an idea what
kind of traffic might cause the high load in your node.

- Check restart data by: SYRIP: SURVEY; and SYRIP: LOG;

Application Errors or Forlopp events shortly before or during the overload situation are good sources of
information.
- Check SAE congestion by DBTSP: TAB=SAACTIONS;

Sometimes congestion occurs but neither the alarm is raised nor entry is put into SAACTIONS. Use TEST
SYSTEM to find congestion in this case:

Telmi: Load=95, Ti=5;

On In Safco Congreport;

On Do: for 5 times, P swd,;

Init;

Data word 1 in the signal CONGREPORT contains the sending block reference and data word 2 contains
the SAE number.

4 MEASURES IN BSC

Many measures can be taken in the BSC to restrict traffic in order to temporarily reduce the load the CP.
However, all measure more or less have negative side effects on the system’s traffic carrying ability.
Following are the measures that can be taken into consideration:

1. Limit number of channel required messages from the MSs (RMHBI):

It is a very efficient method to decrease sudden CP loads attributed by high traffic generated by unusual
end-user behaviour.

TEST SYSTEM;

R8:

PRINT VAR RMHBI 128;

SET VAR RMHBI 128=x;

R9.1:

PRINT VAR RMHBI 132;

SET VAR RMHBI 132=x;

END TEST;

Note: x should at the start be set to half of the printed value. This value depends on the APZ type and
are by default:
APZ 21211: 45

APZ 21225: 90

APZ 21220: 150

APZ 21230: 150

The original (default) value MUST be set back using the same procedure when the CP load is back to
normal.

System impacts:

A number of Channel Required sent from MSs will be discarded before demanding CP capacity in the
BSC. The value is the maximum number of accepted Channel Required messages per 100 milliseconds.

Discarded Channel Required messages will affect the number of calls that can be setup in the system.
Since MSs will not get access to the system, they will start to repeat the access requests, so this
procedure will increase the number of access requests to the system. A negative effect of this procedure
can be that it is causing a backlog of requests for Location Update. Note this will NOT affect that
emergency call setup.

2. When a MS is rejected it will have to wait up to 20 seconds before attempting to send the next
CHANNEL REQUIRED message (timer T3122).

The MS can be rejected for two reasons

• The limit of the number of accepted CHANNEL REQUIRED per 100 ms is reached, this happens before
the capacity is requested from LOAS. (Pre-seize capacity limit reached).

• Pre-seize function accepts the request but processor capacity is not granted by LOAS.

Increase the timer before MS can do random access again after Immediate Assignment Reject has been
sent to it (RMSCS parameters WAITINDICATIONA and WAITINDICATIONB):

TEST SYSTEM;

R8:

PRINT VAR RMSCS 41; ! MS TIMER AFTER IMM ASS REJ !

PRINT VAR RMSCS 42; ! MS TIMER AFTER LOAS REJECT !

SET VAR RMSCS 41=x;

SET VAR RMSCS 42=y;

R9.1:
PRINT VAR RMSCS 42; ! MS TIMER AFTER IMM ASS REJ !

PRINT VAR RMSCS 43; ! MS TIMER AFTER LOAS REJECT!

SET VAR RMSCS 42=x;

SET VAR RMSCS 43=y;

END TEST;

Note: x should to start with be set to 20, and y should to start with be set to 30.

These values are by default:

CWAITINDICA: 10 (seconds)

CWAITINDICB: 20 (seconds)

The original (default) value MUST be set back using the same procedure when the CP load is back to
normal.

System impacts:

The time between when an MS get Immediate Assignment Reject before the MS tries to setup a call
again is increased. This timer (T3122) is used by the MS and is received in the mobile from the
Immediate Assignment Reject message. This will avoid unnecessarily high CP load from extensive retries
from MSs trying to setup a call when for example all SDCCH’s are currently busy or when the CP load is
high for other reasons. This procedure should just have a small impact on traffic seen from an end-user
during a high traffic situation, since it is likely that the MS will still be denied, but later in the call setup
execution chain.

3. Cell Barring:

Cell Barring prevents mobile access to the resources in the cell thus preventing traffic to be generated in
the cell towards the BSC. In case some cells should be cell barred:

RLSBC: CELL=cell1,CB=YES;

RLSBC: CELL=cell2,CB=YES;

In case all cells shall be cell barred:

RLSBC: CELL=ALL,CB=YES;

Preferred procedure to take away Cell Barring:

RLSBC: CELL=ALL,CB=NO,SLOW;

A cell every 2or 3 seconds will be unbarred.

System impacts:

No MSs can/will setup calls in this cell(s). Handover to this cell(s) is however still possible. All MSs in idle
mode that are currently camping (listening to) the cell(s) will do a cell reselection to find another cell to
camp to. If this cell is within another Location Area, then the MSs performs a Location Update
procedure. Extensive Location Update procedures will affect the MSC/VLR load and the signalling load
on the A-interface. Since SDCCHs are used for Location Updates, congestion on SDCCHs can be seen
which will lead to increased CP load in the BSC during a period of time. Also, when barring all cells in one
BSC, other BSC(s) will take over the MSs that have signal strength from the other BSC. This could
increase the CP load of adjacent BSC(s) especially when barring all cells in one BSC. Bad signal strength
for MSs in idle mode and at call setup is obvious since other cell than the best must be used for MSs that
had to do a cell reselection. Since mobile terminating calls are restricted paging are re-sent from the
MSC and lots of mobile terminating calls will end up (after paging attempts) with announcement. All
types of calls are restricted, also emergency calls.

4. Restrict MS Access Classes:

Very efficient to decrease CP load generated from traffic. Does not increase the MSC/VLR load due to
many Location Updates from MSs. It could be better than Cell Barring, especially when the MS Access
Classes are evenly distributed to the end-user SIM cards. Even if only the same MS Access Class is used
for all end-users it is efficient to limit this MS Access Class, but in a number of cells at the time.

In case some cells shall be restricted:

RLSBC: CELL=cell1, ACC=x&y&z;

RLSBC: CELL=cell2, ACC=x&y&z;

In case all cells shall be restricted:

RLSBC: CELL=ALL, ACC=x&y&z;

Bar access classes 0-9 to only allow emergency calls. THIS SHOULD ONLY BE DONE FOR

EXTREAME OVERLOAD CONDITIONS (This can cause paging load in the MSC).

If subscribers are spread evenly over the access classes, bar in steps of 10% waiting a

few minutes between classes while observing processor load levels.

RLSBC: CELL=ALL, ACC=0; ! BAR 10% !

RLSBC: CELL=ALL, ACC=0&1; ! BAR 20% !

RLSBC: CELL=ALL, ACC=0&&2; ! BAR 30% !

RLSBC: CELL=ALL, ACC=0&&3; ! BAR 40% !

RLSBC: CELL=ALL, ACC=0&&4; ! BAR 50% !

RLSBC: CELL=ALL, ACC=0&&5; ! BAR 60% !

RLSBC: CELL=ALL, ACC=0&&6; ! BAR 70% !

RLSBC: CELL=ALL, ACC=0&&7; ! BAR 80% !

RLSBC: CELL=ALL, ACC=0&&8; ! BAR 90% !

RLSBC: CELL=ALL, ACC=0&&9; ! BAR 100% !

If subscribers are not evenly spread over access classes, bar subscribers for access classes 0-9 using the
following command:

RLSBC CELL=cell, ACC=0&&9; ! BAR 100% !

Preferred procedure to take away Limited Access Classes:

RLSBC: CELL=ALL, ACC=CLEAR, SLOW;

A cell every 2 or 3 seconds will be unrestricted. It is also possible to just unrestrict a few access classes
and then either use 'fast' or 'slow' update.

Example:

When a severe overload in the GSM network occur, it is possible to inhibit traffic and slowly restart it
again with 2 commands:

RLSBC: CELL=ALL, ACC=0&&9;

RLSBC: CELL=ALL, ACC=CLEAR, SLOW;

This will stop all MSs to take contact with the radio network within 30 seconds and then slowly allow all
MSs to take contact again. (For 150 cells all MSs are allowed after 5-6 minutes.)

It is also possible to just restrict a percentage of the MSs by not restricting all the classes 0 to 9, but
instead e.g. 0 to 4 (50%). However, to be able to predict a percentage of barred MSs requires that the
operator has spread the access classes randomly of the subscribers as recommended by the GSM specs.
If this is not done, for example if all MSs have the same access class then all MSs within a cell must be
barred to get the effect. Note that in the 'worst case' the method still works, it is just harder to 'fine
tune'.

Access class definitions in GSM 02.11:

0-9 Normal users, Randomly spread

10 Emergency calls (normal users or without SIM)

11 For PLMN use

12 Security services

13 Public utilities (e.g. water/gas suppliers)

14 Emergency services

15 PLMN staff

System impacts:

MSs with the restricted Access Classes on their SIM card are not allowed to access the network. These
MSs can not make mobile originating calls in this cell(s) and also mobile terminating calls into this cell(s)
will not succeed, since the MSs are not allowed to answer on paging. The MSs do not automatically do a
cell reselection to another cell, thus avoiding extensive Location Updates. So, the signal strength and the
network connection are kept and the end-user will not notice anything unless it tries to make a call. This
could differ from cell barring where the MSs are not allowed to stay in this cell if cell barred, and if the
MSs do not find another cell it can camp on it will get ‘No network’ in the handset display. Even though
the MS Access Class is restricted handovers into this cell(s) are still allowed. Emergency calls are allowed,
as long as MS Access Class 10 is not restricted.

Note: There is chance that customer prefer to use one method over the other (item 3 or 4) because of
the do not want to restrict the call which may effect their VIP , it is recommended to check with the
customer before doing any of these .

5. Increase TALLOC timer:

Useful to decrease CP load generated from traffic. Decreases the number of handover attempts and
assignment attempts to other cell at congestion (for example TCH, TRA and/or SRS), within a certain
time period, which will decrease CP load. Also, TRH load will decrease by increasing this parameter.

RLLBC: TALLOC=x;

Note: x is recommended to be set to 12 during high CP load. This will lead to no retry during call setup
(assignment) and inter BSC handover in case of congestion.

System impacts:

Bad signal strength or quality can be experienced by end-user since repetitive handover and assignment
attempts are delayed or skipped when increasing the TALLOC value. However, this should only be
experienced (worsened) for MSs with already bad signal strength or bad quality. In case no congestion is
present in the system no repetition is needed and so this timer is not used.
6. Increase T3212 (BSC) and BTDM (MSC) and GTDM timers (MSC):

Useful to decrease CP load generated from periodic Location Updates. Decreases the number of
Location Updates in general which will decrease CP load.

RLSBC: CELL=cell, T3212=x;

Note: x is recommended to 20 (2 hours) during normal operation. There should be no need to increase it
beyond 20 during a high CP load situation.

Current value can be printed by command:

RLSBP: CELL=ALL;

At the same time the MSC/VLR parameters BTDM and GTDM used by the function Implicit Detach
Supervision MUST be changed.

MGIDI: BTDM=x, GTDM=y;

Note: The total time of these two parameters (x+y) must be greater than the longest T3212 value of the
connected BSCs. x is recommended to be set to 120 and y to 6 during normal operation. There should be
no need to increase x and y beyond these values during a high CP load situation.

Current values can be printed by command:

MGIDP;

System impacts:

By increasing the timer T3212 the number of registered MSs in the location register database will
increase. Also, longer delivery time of SMS messages can be experienced.

7. Stop STS collections:

By stopping the periodic collection of STS counters the CP load can be decreased. Also SP (IOG) load shall
decrease as a result of this.

IMLIT:SPG=0;

SDDCE;

END;

System impacts:

STS counter regular collection is stopped and it is not possible to get data from the situation that could
be useful for trouble shooting in afterward.

8. Reduce number of retransmissions per MS per random access (MAXRET).

Efficient to decrease CP load generated from traffic at high traffic (congestion) situations. Efficient to
decrease signalling load at random access problems, since the number of retries from the MS at
rejection at call setup is decreased. This procedure is most efficient when the problem is not the number
of SDCCH, but earlier in the call setup chain. Or to reduce the number of retransmissions when the CP
and/or LAPD load is very high so that there are long delays on for example Immediate Assignment Reject
sent from the BSC. If that is delayed the MS will retry to access the system MAXRET number of times.

RLSBC: CELL=ALL, MAXRET= maxret;

MAXRET has a default value of 4. During an emergency situation it is recommended to decrease this to
2.

System impacts:

In case of problems for MS to access the system, it will retransmit its random access. This might be
necessary at small temporary radio disturbances. If MAXRET is decreased the number of successful call
setups might decrease. However, this is quite unlikely and will most likely not give any worse traffic
performance than from the already existing high CP load situation.

9. Decrease CP load from GPRS On Demand traffic

In general GPRS traffic does not affect the CP load much since most of the execution is done in the PCU
implemented in the RPP. However, some CP load is generated from GPRS On Demand (OD) traffic. When
the PILTIMER expires the ODPDCH is returned to the CS domain. This consumes CP load. Extending the
value of parameter PILTIMER can decrease the CP load:

RAEPC: PROP=PILTIMER-X;

X is recommended to be double the old value in an emergency situation. Default value is 20 seconds.

Also, when a new (set of) ODPDCH is requested from CS it consumes CP load. Increasing the number of
users (TBF) per ODPDCH will reduce the CP load impact from this. This will lead to that less number of
requests for ODPDCHs, and thus need for less TCHs, are received in the CS domain hence using less CP
execution. This is controlled by the parameters TBFDLLIMIT and TBFULLIMIT.

RAEPC: PROP=TBFDLLIMIT-X;

RAEPC: PROP=TBFULLIMIT-Y;

X and Y are recommended to be increased to at least double the old value in an emergency situation.
Default value is 2.
System impacts:

By increasing the TBFDLLIMIT and TBFULLIMIT more GPRS users will have to share the same radio
resource (ODPDCH). This will give a lower bit rate per user on the radio interface. The GPRS user as a
slower connection with the system might notice this. It is probably better to have a faster connection
downlink than uplink, so by just adjusting TBFULLIMIT in the first step will most likely not be noticed by
the GPRS user. Increasing PILTIMER will not affect the end-user at all. However, if PILTIMER is increased
and the GPRS traffic is very low, but the CS traffic is high it will lead to an increased number of pre-
emptions of ODPDCHs to normal CS traffic.

9. Limit the number of pagings that reach the TRHs (PAGLIMIT)

There is a possibility to limit the number of pagings that are sent to the TRHs per second from the CP.
This will most likely not have a big affect on the CP load, but more on the TRH load and the LAPD
signalling load. The CP load can be indirectly affected since if pages do not reach the MS, then there will
be less random access in the BSC.

Check the TRH Event Log for indications of overloaded TRHs or LAPD links due to pagings.

RAHEP;

If pagings are discarded this indicates an overloaded TRH and/or overloaded LAPD links. This is the way
for the system to protect itself against TRH restarts and blocking of LAPD links. This is not an emergency
situation, however, if this is not enough and BTSs are starting to reconfigure (OFFMPL high in PLLDP),
then there is an emergency situation and you should proceed.

The TRH load can be decreased by limit the number of pages per second to the TRHs. Also limiting the
number of pages can decrease the LAPD signalling load on the Abis interface. Overloaded LAPD links or
TRHs can lead to BTS reconfigurations, which will increase the CP load from O&M jobs up to 95%. So, by
limiting the number of pagings it can prevent sudden high CP load due to BTS reconfiguration.

RAEPC: PROP=PAGLIMIT-X;
X depends on the TRH and LAPD configuration. In an emergency situation, where BTS’s are
reconfiguring, it is recommended to set it to half the current paging rate. The current paging rate can be
seen from OFFDI in the PLLDP printout. It should not be necessary to go below 50 pagings per second at
any occasion.

System impacts:

If the number of pagings are limited with this parameter, that otherwise would have been successful the
number of successful mobile terminating call setups will decrease. The number of repeated pagings
from the MSC/VLR will increase that will increase the pressure on the BSC. Note that a high number of
pagings to mobiles in one small area (cell) will increase the paging load in the whole MSC/VLR area
(global paging) or at least Location area (local paging). It may also help to stop the repeat paging in the
MSC, thus reducing the total number of paging messages towards the BSC. Change the parameters
PAGREP1LA and PAGREPGLOB from the AXEPARS db table (SETNAME GSMMMSC). It is recommended to
set these parameters to 0 (no repeat paging in one LA and no global repeat paging).

5 MEASURES IN MSC

Considering traffic blocking, measures in MSC might not be as effective as those in BSC. Because MSC is
mainly functioning as switching and before a call reaches MSC it has gone through a long way in system.

Followings are means can be taken into consideration to bring down the processor load during an
overload situation in MSC:

5.1 LIGHT MEASURES

- Switch off Authentication

DBTRI;

DBTSC: TAB=AXEPARS, SETNAME=GSMMMSC, NAME= AUTHENTICATE, VALUE=0;

DBTRE: COM;

Comment: This can be used to gain some temporary CP load. Selective Authentication also can be
considered if the overload situation is not that severe but the security issue is of much concern.

- Switch off all Equipment Identity checks (if active) in MSC/VLR using following exchange properties
(Check the parameters before change their values):

MGEPC: PROP=IMEICONTROLCLLS- 0;

MGEPC: PROP=IMEICHKWITHIMSI-0;

MGEPC: PROP=IMEICONTROLEMR-0;

MGEPC: PROP=IMEICONTROLSMS-0;

MGEPC: PROP=IMEICONTROLLU-0;

MGEPC: PROP=IMEICONTROLSS-0;

Comment: This can be used to gain some temporary CP load. - Switch off TMSI

- You can gain a few percent of capacity by switching off the TMSI function. The parameter TMSIPAR
indicates if TMSI allocation is performed in the MSC/VLR.

DBTRI;

DBTSC: TAB=AXEPARS, NAME=TMSIPAR, SETNAME=GSMMMSC, VALUE=1;

DBTRE: COM;

5.2 SERIOUS MEASURES

- Passive Forlopp function

The Forlopp function uses 3 to 4% processor capacity (in operation mode), if no forlopp release is in
progress. To gain this capacity short term is tempting and might work. Switching off Forlopp increases
risk having a restart instead of any Forlopp release. However, you might consider this option together
after you verified carefully that you don’t have forlopp releases (see previous chapter on how to check).

- Switch off STS and other measuring programs

IMLCT: SPG=0;

SDDCE;

END;

Comment: This measure is also to gain temporary CP load. Dependant on how many counters are used
by the operator the gain of processor capacity can be in the range of 2-5%. However, the negative
impact is that there might be lack of information for analyzing how the system was running during the
overload time.

- Restrict IN traffic from XSS to SSF subsystem

ARLDP: APCLNK=ALL;

ARLDC:APCLNK=apclink,SMAX=xxxx;

Comments: This measure can be applied to restricts the number of IN traffic sessions towards SCP to a
certain level. IN traffic will be blocked before they access SSF subsystem. Considering that a IN call costs
a lot more resource than a ordinary GSM call, this measure can reduce the MSC CP load considerably.
On the other hand, since the call has gone thought all call processes in BSC before they are blocked, the
measure will not reduce any CP load in BSC. Contratrily it could generate more CP load in BSC as far as
the call reattempts from end-user after failure calls are concerned.

Please be noted that in MSC R9.1 the definition of APC link is slightly different. In R8 APC links are
defined in pairs, one from XSS to SSF and the other one from SSF to XSS. However, in R9.1 APC can be
used for two-way connection. Which means traffic from XSS to SSF and from SSF to XSS will run over the
same APC link. Therefore the number of sessions in the APC link will usually double.

- Restrict incoming traffic in BSC by measures mentioned above.

In case one of the main problems for the overload situation is that the BSC’s are serving too much traffic
to the MSC you may want to restrict the amount of traffic in the BSC. Please refer to the chapter of
measures in BSC. In addition if the traffic from certain route is too high to protect MSC you can block
some devices in this route to limit the traffic as well.