GSM flow control procedures

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■
■

BSS initiated flow control function

GSM flow control reduces the number of access bursts sent to a site according to the traffic
loading. Flow control takes place in the following channels:
• Traffic channels (TCHs).
• Random access control channels (RACCHs).
• Signaling state machine (SSM).
The flow control features are not optional, but can be restricted if required.

TCH flow control

TCH flow control is necessary to avoid overload conditions on the RACH, CRM or SSM.
CRM overload control is enabled by the change_element command tch_flow_control.
It is further controlled by the two parameters: tch_busy_critical_threshold and
tch_busy_norm_threshold.
When the CRM allocates a TCH it checks both thresholds.
If the tch_busy_norm_threshold is exceeded, the CRM randomly bars one access class (0–9)
after which two timers T1 and T2 are started (flow_control_t1, flow_control_t2). These timers
control the rate at which access classes are barred and unbarred.
When an overload condition is initiated by the MSC in a situation of high TCH usage, the CRM
subsystem in the BTS starts the timer flow_control_t1. This timer is used in conjunction with
timer flow_control_t2 to control the barring and unbarring of access classes.
This prevents a class of user MSs from making calls on the network and hence reduces the load
on the MSC. This mobile access class information is carried to the mobile subscriber in the
SYSTEM INFORMATION message specified in GSM recommendations.
The BTS (CRM) timer flow_control_t1 specifies the interval that must elapse before new
overload messages of a particular access class are considered by the flow control mechanism.

BSS flow control operation

As soon as an overload condition is initiated by the MSC, CRM bars an access class and
generates the flow control procedure has started barring normal calls from access
classes 0-9 alarm. CRM starts timers flow_control_t1 and flow_control_t2. While
flow_control_t1 is running, CRM ignores all further overload messages.
If, after expiry of flow_control_t1 with flow_control_t2 still running, another overload message
is received, another access class is barred and both timers are restarted.
• If, however, timer flow_control_t2 expires without any further overload messages having
been received, an access class is unbarred and only flow_control_t2 is restarted. This
continues as long as no further overload messages are received until all classes are
unbarred, at which time, the flow control procedure has started barring normal calls
from access classes 0-9 alarm is cleared. Of course, if during this process another
overload message is received, another access class is barred and both timers are restarted.
• Figure 5-9 shows the operation of the two timers. The example assumes that
flow_control_t1 is set to less than flow_control_t2 and uses access classes 8 and 9.
If tch_busy_critical_threshold is exceeded, the CRM bars any remaining unbarred
classes, two at a time, each time the threshold is exceeded. flow_control_t1 with
flow_control_t2 still take an active part in barring and unbarring classes.

RACH flow control

The parameters rach_load_period and ccch_load_period work in conjunction with a
change_element command, rach_load_threshold, to provide traffic flow control by allowing
the RSS to monitor the number of channel requests received in a given period. If this number
exceeds the rach_load_threshold then the RSS transmits a load indication message to call
processing.
On receipt of this message, call processing bars one random access class (0–9). Simultaneously,
CP starts timers T1 and T2 (flow_control_t1 and flow_control_t2). See Figure 5-9 for the
process of barring and unbarring.
Both the rach_load_period and ccch_load_period are in multiples of 235.5 ms (1 x 51 frame).
The rach_load_period determines the period over which the RACH load is monitored. The
ccch_load_period is in operation only when an overload condition has been triggered in the
previous period (RACH or CCCH).
The rach_load_threshold parameter is calculated as follows:

Where:
The numerator is the number of SDCCH sub-slots and TCHs configured for the cell.
The denominator is the number of available RACH slots in 4 x 51 multiframes. This changes
depending on the value of ccch_conf.
The resulting percentage is the rach_load_threshold, with a granularity of 0.01%.

SSM flow control

This feature is implemented to help reduce the loading on an instance of SSM. The
triggers are that either ssm_normal_overload_threshold (one access class barred) or
ssm_critical_overload_threshold (two access classes barred) have been met or exceeded.
These thresholds are calculated as follows:
Where: Is:
400 the maximum number of calls that can be supported using a GPROC 1.
800 the maximum number of calls that can be supported using a GPROC 2 or GPROC 3
The normal threshold must be less than the critical threshold.
The CRM is informed of the threshold met or exceeded and carries out the same procedure as
TFC or RACH flow control.

MSC initiated flow control

The MSC overload control feature adds to the BSS functionality flow control functions specified
within GSM recommendations to support!the OVERLOAD message from the MSC on the
A-interface.
The MSC overload control feature extends the flow control mechanism in the BSS to temporarily
reduce the flow of traffic between the MSC and the BSS. This mechanism allows the MSC to
notify the BSS that it is becoming overloaded and to reduce the amount of information being
sent to the MSC from the BSS.
On becoming overloaded, the MSC sends an OVERLOAD message to the BSS. The BSS receives
this message and immediately starts to reduce the traffic loading on the MSC, by barring mobile
access classes within cells in the BSS.
Multiple OVERLOAD messages can be sent from the MSC to the BSS. There is a danger that
access classes will be barred too rapidly, resulting in all access classes being restricted
throughout the BSS. To guard against this a timer is started on reception of an OVERLOAD
message. This timer is called T17. The BSS ignores all subsequent OVERLOAD messages
received after the first instance until T17 expires. When T17 has expired the next OVERLOAD
message received by the BSS will result in the next access class being barred and T17 is
restarted. Timer T17 duration is set by the flow_control_t1 parameter.
There is no message sent from the MSC to the BSS notifying the BSS that the MSC processor
overload condition has cleared. The unbarring of the access classes to increase the traffic to
the MSC is controlled by a timer. This timer is called T18. This timer is also started when the
first OVERLOAD message is received. If no subsequent OVERLOAD message has been received
when the T18 timer expires then the BSS will unbar an access class. The T18 timer will then
be restarted, unless all of the access classes are now unbarred. Timer T18 duration is set
by the flow_control_t2 parameter.
The reception of an OVERLOAD message after the expiry of T17, but before the expiry of T18,
will result in the barring of a mobile access class and both timers T17 and T18 are restarted.
Example 1
Figure 5-10 shows a single OVERLOAD message received. A single access class is barred and
then unbarred after expiry of the controlling timer.
Figure 5-10 Single overload message received
Example 2
Figure 5-11 shows two OVERLOAD messages received. Only a single access class is barred
and then unbarred. This is because the second OVERLOAD message is received before T17
has expired.
Figure 5-11 Two overload messages received

Example 3
Figure 5-12 shows three OVERLOAD messages received. Two access classes are barred and
then unbarred. This is because the second OVERLOAD message is received before T17 has
expired and is ignored. The third OVERLOAD message is received after the expiry of T17 and
results in the barring of a second access class.
Figure 5-12 Three overload messages received
The current BSS initiated flow control mechanisms cause a flow control alarm to be raised in
each affected cell for the duration of the flow control. The MSC initiated flow control will not
cause this cell alarm to be raised for the following reasons:
• The flow control is not the result of a BSS problem.
• Many of alarms could result from a single MSC overload message.
• It is assumed that the MSC will report!an alarm detailing the cause of the problem.
As already described, there are three BSS initiated flow control mechanisms:
• SCCP state machine overload based on the call information blocks.
• Cell resource overload based on the utilization of traffic channels.
• Radio subsystem overload based on overloading of the AGCH, RACH channels.
The effect of the existing T1 timer in preventing additional flow control from the BSS applies
equally to MSC initiated flow control. Similarly, the effect of the T17 timer on preventing
additional MSC flow control also applies to BSS flow control requests. However, if the cell flow
control alarm has not been raised then it is raised on reception of a BSS flow control request at
the cell, regardless of what timers are active.
The cell flow control alarm will only be cleared when all flow control, however
initiated, is cleared.
If the system has SPI or a reset in progress any messages from the MSC relating to an overload
condition are ignored.
The BSS retains statistics to allow the user to trace the effect of the OVERLOAD message
on the BSS.
AGCH flow control management
{31565}
AGCH flow control feature allows the user to manually enable or disable Access Grant Channel
(AGCH) flow control. The users can enable AGCH flow control on the required cells and disable
the AGCH flow control on other cells based on different network situations.
It provides the users with the option to avoid frequent triggering of AGCH overload due to
the trigger of Immediate Assign Reject (IAR). It also adds additional counter array statistic
IA_IAR_MSGS_PER_AGCH to monitor the number of Immediate Assign (IA) or IAR messages
sent over CCCH or discarded when AGCH overload respectively.
The BSS supports a per cell element _cell_data, 20 which indicates whether the functionality of
the AGCH flow control is enabled or disabled. It also specifies the triggers associated with IA
or IAR that can trigger the AGCH overload.
When the functionality of AGCH flow control is disabled, the overall flow control works by
appropriately configuring other parameters that affect RACH/TCH/SSM flow control.
To make the overall functionality of flow control efficiently on system level work, it is
recommended that at least one flow control must be enabled and work well.

Related commands and parameters

Refer to Technical Descrip!ion: BSS Command Reference (68P02901W23) manual for a full
descrip!ion of commands and parameters.
The following parameters can be used to specify GSM flow control:
• tch_flow_control - Enables or disables the TCH flow control option.
• tch_busy_critical_threshold - Sets the threshold for initiating the flow control procedure
barring two of the access classes 0 through 9 from making calls due to TCH congestion.
• - Sets the threshold for initiating the flow control procedure to
bar a single access class 0 through 9 from making a call due to TCH congestion.
• ccch_load_period - Indicates the number of TDMA multiframes between successive
calculations of the RACH load during overload conditions.
• rach_load_period - Indicates the number of TDMA multiframes between successive
calculations of the RACH load during non-overload conditions.
• rach_load_threshold - Specifies the threshold level for RACH load.
• ccch_conf - Defines the organization of the CCCHs on the BCCH.
• ssm_normal_overload_threshold - Indicates the usage of call information blocks, as a
ratio of active calls to the maximum calls that the SSM can handle, before an access
class is barred.
• ssm_critical_overload_threshold - Indicates the usage of call information blocks, as
a ratio of active calls to the maximum calls that the SSM can handle, before no MS
originated calls are allowed.
• bss_msc_overload_allowed - Controls whether the BSS acts upon OVERLOAD messages
received from the MSC.
• flow_control_t1 - Specifies the interval that must elapse before new OVERLOAD message
of a particular access class are considered by the flow control mechanism.
This is the internal overload message which can originate from either the MSC
or BSS.
• flow_control_t2-Specifies the interval that must elapse before an access class, on which a
bar on new OVERLOAD messages has previously been set, can be brought back into service.
This is the internal overload message which can originate from either the MSC
or BSS.
Related statistic
The MSC_OVLD_MSGS_RX statistic records the number of OVERLOAD messages received
from the MSC.
System impact
For all control methods, MS access classes can be barred to reduce cell loading.
When the ssm_critical_overload_threshold parameter is exceeded, no MS originated calls
are allowed.
When a cell is deleted from an INS site, the flow control cell alarm is cleared. The OMC
reports the wrong cell ID.

BSS alarms relate to overload

21.BSS: Trunk major threshold exceeded

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■
■

Clearing Type: FMIC

Severity Level: Major
Category: Communication
Descrip!ion
This alarm indicates that the percentage of trunk capacity has exceeded the user-specified value
of the trunk_major_threshold database parameter.
For further information, refer to the BSS statistics chapter in the manual, Technical Descrip!ion:
BSS Command Reference (68P02901W23).
Additional information eld
There is no additional information in the output for this alarm.
Possible causes
The following are the Possible causes for this alarm:
• The percentage of utilized trunks is greater than the value of trunk_major_threshold
database parameter.
• The value of the trunk_major_threshold database parameter is set too low.
Ignore any additional bytes displayed.
Procedure
Perform the following procedure to resolve the alarm.
Procedure 6-20 Trunk major threshold exceeded
1 Review the Alarms window to identify the current CIC and RCI
alarms.
2 Initiate fault isolation and fault resolution procedures to restore
the failed circuits.

22.BSS: Trunk critical threshold exceeded

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■
■

Clearing Type: FMIC

Severity Level: Critical
Category: Communication
Descrip!ion
This alarm indicates that the percentage of trunk capacity has exceeded the user-specified value
of the trunk_critical_threshold database parameter.
For further information, refer to the BSS statistics chapter in the manual, Technical Descrip!ion:
BSS Command Reference (68P02901W23).
Additional information eld
There is no additional information in the output for this alarm.
Possible causes
The following are the Possible causes for this alarm:
• The percentage of utilized trunks is greater than the value of trunk_critical_threshold
database parameter.
• The value of the trunk_critical_threshold database parameter is set too low.
Ignore any additional bytes displayed.
Procedure
Perform the following procedure to resolve the alarm.
Procedure 6-21 Trunk critical threshold exceeded
1 Review the Alarms window to identify the current CIC and RCI
alarms.
2 Initiate fault isolation and fault resolution procedures to restore the
failed circuits.
3. MTL: Link trafc too high
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■
■

Clearing Type: Intermittent

Severity Level: Investigate
Category: Communication
Descrip!ion
Congestion is detected at either the local or remote end of the MTL affecting the flow of the
signaling traffic across MTP Layer 2.
This is potentially a service-affecting fault.
This alarm does not necessarily indicate that there is a physical problem with the MTLs.
A network congestion problem is probably causing the MTL links to experience signaling
congestion.
System action
After the alarm is reported, flow control procedures are started at the MTP Layer 2 level to
handle congestion. These procedures ensure that user messages are stored in an MTP Layer
2 buffer for transmission when the signaling traffic subsides and returns to a normal level of
activity. When MTP Layer 2 has used all of its buffer space, user messages are discarded.
Additional information eld
There is no additional information in the output for this alarm.
Possible causes
High traffic levels on the MTL do not allow enough time for the device driver to process frames.
Procedure
Perform the following procedure to resolve the alarm.
Procedure 31-6 Link trafc too high
1 Determine if any MTL devices are OOS.
If all MTL devices... Then...
are OOS Go to step 2.
are not OOS Go to step 3.
2 Reset each OOS MTL device.
If all MTL devices... Then...
return to service The fault condition no longer
exists. Clear the alarm.
do not return to service Resolve the Signaling Link Failure
(MTL 0) alarm for the MTL
device(s) that do not return to
service and then clear this alarm.
3 Clear the alarm.
The alarm is due to congestion. The capacity of the current MTL
links is insufficient to handle the signaling traffic. If this alarm
recurs, capacity must be increased by the addition of MTL links.
12. MTL: SL congestion indications - PM
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■
■

Clearing Type: Intermittent

Severity Level: Warning
Category: Communication
Descrip!ion
The SL_CONGESTION statistic threshold has been reached.
This statistic counts the number of times that a Signaling Link (SL) is congested with a high
volume of calls.
For further information, refer to the MTL statistics chapter in the manual, Maintenance
Information: GSM Statistics Application (68P02901W56).
Additional information eld
There is no additional information in the output for this alarm.
Possible causes
The number of MTLs allotted for the BSS is insufficient to handle the volume of calls.
Procedure
Perform the following procedure to resolve the alarm.
Procedure 31-16 SL congestion indications - PM
1 Clear the alarm.
2 The alarm is due to congestion. The capacity of the current MTL links is
insufficient to handle the signaling traffic. If this alarm recurs, capacity
must be increased by the addition of MTL links.

52. BSP: BSP CPU Safe Overload

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■
■

{23306}
Clearing Type: FMIC
Severity Level: Warning
Category: Service Quality
Descrip!ion
The BSS supports this alarm to indicate that the active BSP CPU is working in safe-overload
status and its utilization is over safe-overload threshold (BSP CPU utilization is 70%).
Additional information eld
The Additional information field contains 11 bytes in the additional alarm codes.
Byte Denition
One, two The total CPU utilization of BSP
when the overload is detected.
Three, four and five The ids of the top three
processes which have the
highest CPU utilization.
Six, seven, eight, nine, ten
and eleven
The CPU utilization value of
these three processes.
Possible causes
The following are the Possible causes for this alarm:
• The CPU resources are exhausted due to processing of a large number of service requests
for handover and call setup or release.
• Large number of alarms are generated in BSS.
• A software fault in some BSP process causes high CPU utilization.
• Hardware fault.
• This alarm is raised and cleared whenever there is a DB update.
Procedure
Procedure 5-19 BSP CPU safe overload
Identify one of the causes for BSP CPU safe overload by using the
content of additional codes.
If... Then...
the highest CPU utilization is
on Allocation Manager (AM)
and Switch Manager (SM)
processes
check the reason for large number
of service requests and review
their network plan.
For other causes, further troubleshooting is required to
identify the underlying cause.
53. BSP: BSP CPU critical overload
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■
■

{23306}
Clearing Type: FMIC
Severity Level: Critical
Category: Service Quality
Descrip!ion
The BSS supports this alarm to indicate that the active BSP CPU is working in critical-overload
status and its utilization is over critical-overload threshold (95% of BSP CPU is utilized).
Additional information eld
The Additional information field contains 11 bytes in the additional alarm codes.
Byte Denition
One, two The total CPU utilization of BSP
when the overload is detected.
Three, four and five The ids of the top three
processes which have the
highest CPU utilization.
Six, seven, eight, nine, ten
and eleven
The CPU utilization value of
these three processes.
Possible causes
The following are the Possible causes for this alarm:
• The CPU resources are exhausted due to processing of a large number of service requests
for handover and call setup or release.
• Large number of alarms are generated in BSS.
• A software fault in some BSP process with priority higher than SM and AM causes high
CPU utilization.
• Hardware fault.
• This alarm is raised and cleared whenever there is a DB update.
Procedure
Procedure 5-20 BSP CPU critical overload
Identify one of the causes for a BSP CPU critical overload by using
the content of additional codes.
If... Then...
the highest CPU utilization are
on Allocation Manager (AM)
and Switch Manager (SM)
processes
the overload control works and
the alarm is cleared when the BSP
quits the critical-overload state.

19. GPROC: RSL links congestion

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■
■

Clearing Type: FMIC

Severity Level: Investigate
Category: Communication
Descrip!ion
The flow of messages exceeds the transmissibility of RSL links. Links congestion was detected
on one or more RSLs on this GPROC.
Some paging messages may be discarded when this alarm is present. Hence, the
associated services are not provided. For example, some new calls may not be
established. Select retry or wait a while to avoid peak usage of the system.
Additional information eld
There is no additional information in the output for this alarm.
Possible causes
• Huge number of paging messages coming from the MSC.
• The transmissibility of RSL is too low.
Procedure
Perform the following procedure to resolve the alarm.
Procedure 23-4 RSL links congestion
1 Determine whether or not it is necessary to expand network capability.
Isolate occurrences of the alarm to specific BTS Sites or LCF processors to
determine if expansion or re-configuration is required.
2 Take appropriate action and clear the alarm.