40803906 sdcch

D-3.3 Traffic Load Scenario and Decision Making Page 1
Copyright  2001 CAUTION Consortium 13/10/2001
CAUTION IST-2000-25352
D-3.3
Resource Management Application Scenarios
Traffic Load Scenarios and Decision-Making
Contractual Date of Delivery to the CEC: 30 September 2001
Actual Date of Delivery to the CEC: 15 October 2001
Author(s): Massimo Barbera1
, Cristina Barbero1
, Paola Dal Zovo1
, Fernanda Farinaccio1
, Ivan Mura1
,
Stefano Pestrin1
, Gianluca Previti1
,
Sofoklis Kyriazakos2
, Evangelos Gkroustiotis2
, Charis Kechagias2
, Chris Karambalis2
,
Z. Lioupas2
, B. Petropoulos2
,
Kostas Vlahodimitropoulos3
, Achilleas Chatzikonstantinou3
, Filippos Kyriazidis3
Participant(s): MOTOROLA1
, ICCS/NTUA2
, VTT, COSMOTE3
, TELIA
Workpackage: WP3
Est. person months: 8
Security: Pub.
Nature: R
Version: 8.0
Total number of pages: 84
Abstract:
This document contains the design of the CAUTION Resource Management Unit (RMU), the component
in charge of performing the decision making process that ultimately results in the triggering of the
adequate congestion treatment techniques. The RMU receives the information on congestion situations in
form of a list of alarmed cells, and executes a matching algorithm to identify the Traffic Load Scenario
that best suits the current situations. The RMU contains most of the intelligence of the CAUTION system.
Starting from a human included basic knowledge about the possible Traffic Load Scenarios and suitable
Resource Management Techniques, the RMU builds over time a database of observed congestion cases
and applied techniques, and improves its performances by learning from past experiences through a Case
Based Reasoning approach. Searching the database of historical cases allows finding similar situations
that occurred in the past and to immediately identify the most successful strategy to deal with the current
congestion event. Once a technique has been selected to deal with a congestion event, the parameters
necessary to instantiate the technique can be either obtained by similar application cases stored in the
database, or can be computed with a fine-tuning model-based approach, which optimizes the Resource
Management Technique to meet the network operator goals for the current scenario. The knowledge
gained through experience is stored in the RMU database, and will be reused to enhance future decision-
making. Moreover, the database information will also be processed to obtain hints on the quality of the
basic knowledge provided by the operator, and suggestions for possible modifications and updates.
Keyword list: Traffic Load Scenarios, Resource Management Techniques, Decision Making, Case-Based
Reasoning, Model-Based Optimization.

DOCUMENT HISTORY
Date Version Status Comments
25-07-2001 001 int Initial version (ToC) for partners’ comments
10-08-2001 002 int First draft high level design
31-08-2001 003 int Included partners’ contribution
4-09-2001 004 int Overall revision
21-09-2001 005 int Added Motorola input, as per Espoo meeting
21-09-2001 006 int Added ICCS input
5-10-2001 007 apr MTCI overall revision
12-10-2001 008 apr Final document

TABLE OF CONTENTS
1 EXECUTIVE SUMMARY.......................................................................................................................... 6
2 INTRODUCTION........................................................................................................................................ 7
2.1 PURPOSE................................................................................................................................................. 7
2.2 SCOPE..................................................................................................................................................... 7
2.3 OVERVIEW ............................................................................................................................................. 7
3 CAUTION HIGH LEVEL ARCHITECTURE ......................................................................................... 8
4 TRAFFIC LOAD SCENARIOS ............................................................................................................... 11
4.1 ITMU INPUT TO RESOURCE MANAGEMENT........................................................................................... 11
4.2 TRAFFIC LOAD SCENARIO CHARACTERIZATION .................................................................................... 15
4.2.1 Busy hours....................................................................................................................................... 19
4.2.2 Tourist periods ................................................................................................................................ 21
4.2.3 Bank holidays.................................................................................................................................. 22
4.2.4 Sport events..................................................................................................................................... 23
4.2.5 Traveling services strikes................................................................................................................ 24
4.2.6 Religious/cultural events................................................................................................................. 25
4.2.7 Demonstrations ............................................................................................................................... 26
4.2.8 Department stores........................................................................................................................... 27
4.2.9 Planned outages.............................................................................................................................. 28
4.2.10 BTS shortcoming......................................................................................................................... 29
4.2.11 BSC shortcoming ........................................................................................................................ 30
4.2.12 Catastrophes............................................................................................................................... 31
4.2.13 Accidents..................................................................................................................................... 32
4.2.14 Massive congestion scenario ...................................................................................................... 33
4.2.15 Conclusions................................................................................................................................. 35
5 RMU DESIGN............................................................................................................................................ 36
5.1 INTRODUCTION..................................................................................................................................... 36
5.2 RMU LOGICAL FUNCTIONALITIES ........................................................................................................ 36
5.3 RMU HIGH-LEVEL STATE DIAGRAMS ................................................................................................... 37
5.4 TRAFFIC LOAD SCENARIO RECOGNIZER ................................................................................................ 40
5.4.1 TLSR sub modules........................................................................................................................... 40
5.4.2 Inputs............................................................................................................................................... 41
5.4.3 Processing....................................................................................................................................... 42
5.4.4 Outputs............................................................................................................................................ 48
5.5 STRATEGY SELECTOR ........................................................................................................................... 51
5.5.1 Inputs............................................................................................................................................... 51
5.5.2 Processing....................................................................................................................................... 54
5.5.3 Outputs............................................................................................................................................ 58
5.6 STRATEGY ACTUATOR ......................................................................................................................... 62
5.6.1 Inputs............................................................................................................................................... 62
5.6.2 Processing....................................................................................................................................... 63
5.6.3 Output.............................................................................................................................................. 65
5.7 KNOWLEDGE BASE MANAGER ............................................................................................................. 67
5.7.1 Inputs............................................................................................................................................... 67
5.7.2 Processing....................................................................................................................................... 68
5.7.3 Outputs............................................................................................................................................ 75
5.8 SPECIFICATION OF RMU INTERNAL INTERFACES.................................................................................. 77
5.9 DETAILED DESCRIPTION OF EXTERNAL INTERFACES ........................................................................... 77
5.9.1 Communication protocols ............................................................................................................... 77
5.9.2 Messages exchanged ....................................................................................................................... 78
6 CONCLUSIONS......................................................................................................................................... 83
REFERENCES.................................................................................................................................................... 84

TERMS AND ACRONYMS
AGCH Access Grant Channel
ALT Alarm Threshold
BR Blocking Rate
CBR Case-Based Reasoning
CLC CLear Code alarm
COM Component Object Model
CSSR Call Setup Success Rate
DB Database
DS Default Scenario
ECS Emergency Call Server
GoD Grade of Service
IP Internet Protocol
ITMU Interface Traffic Monitoring Unit
KBM Knowledge Base Manager
MML Man Machine Language
OMC Operations & Maintenance Center
PCH Paging Channel
PCS Priority Call Server
RACH Random Access Channel
RM Resource Management
RMT Resource Management Technique
RMU Resource Management Unit
RTT Real Time Traffic
RXT Relax Threshold
SA Strategy Actuator
SACCH Slow Associated Control Channel
SCCH Signaling Control Channel
SDCCH Stand-alone Dedicated Control Channel
SMS Short Message Service
SS Strategy Selector
TCH Traffic Channel

TCP Transmission Control Protocol
TLS Traffic Load Scenario
TLSR Traffic Load Scenario Recognizer
UTLS Undefined Traffic Load Scenario
XML eXtended Markup Language

1 EXECUTIVE SUMMARY
This document describes the applications scenarios for the CAUTION systems and specifies the way each
application scenario will be mapped into the most adequate resource management technique. A subtitle was
added to this deliverable, in order to make the document more specific. In CAUTION system, RMU is the
element that should be seen as the core of the “system-thinking”. Therefore, in addition to the high- and low-
level system design, the deliverable describes the whole concept of decision-making implemented by the RMU.
The management techniques will be described in-detail in D-3.1, carefully explaining the parameters and the
syntax that will be used for execution. Therefore, this deliverable focuses on the intelligence of the RMU
element and the decisions making scheme. This architecture will be transparent to the management techniques,
enabling a scalable system, to which the operator can anytime add new management techniques.
The RMU is the component in charge of performing the decision making process that ultimately results in the
triggering of the adequate congestion treatment techniques. The RMU contains most of the intelligence of the
CAUTION system. Starting from a human included basic knowledge about the possible Traffic Load Scenarios
and suitable Resource Management Techniques, the RMU builds over time a database of observed congestion
cases and applied techniques, and improves its performances by learning from past experiences through a Case
Based Reasoning approach.
The RMU receives the information on congestion situations in form of a list of alarmed cells form the
CAUTION ITMU component, and executes a matching algorithm to identify the Traffic Load Scenario that best
suits the current situations. To this goal, the RMU stores a list of pre-defined Traffic Load Scenarios that are
included in an RMU database by a human operator. Also, the RMU stores a calendar of predicted events, which
will be checked first to ascertain whether some congestion had been foreseen for the current time. The Traffic
Load Scenarios are an extrapolation of the possible congestion situations the cellular network may incur in. The
matching results in a first decision, which assigns the current congestion situation to one Traffic Load Scenario.
For each Traffic Load Scenario, the RMU database stores a list of Resource Management Techniques, which are
deemed suitable for alleviating the congestion that is usually observed in that specific Traffic Load Scenario.
Therefore, once the RMU has classified one congestion situation, a potential list of choices is still available for
dealing with the current scenario. The selection of which Resource Management Technique to apply is
determined by a Case-Based Reasoning approach, by which the RMU learns from its past experiences. For each
congestion situation, a search is performed on the RMU database, looking for similar events that occurred in the
past. If similar cases are found, then the Resource Management Technique that had been applied in that case will
be applied for the current situation as well.
Applying one Resource Management Technique does not guarantee that the congestion situation gets solved.
Since the matching between the current situation and the list of Traffic Load Scenarios may be not perfect, a
misclassification might occur. Therefore, in case one Resource Management Technique does not achieve the
desired effects, the RMU will switch to the next one, and this resection process repeats till one successful
Resource Management Technique is selected or there are no more Resource Management Techniques to apply.
For every selection of a Resource Management Technique, one case will be stored in the RMU database, keeping
track of all the RMU attempts. This way, the RMU will be able to reapply successful choices without being stuck
by any predefined order of the Resource Management Techniques list.
Moreover, the database information will also be processed to obtain hints on the quality of the basic knowledge
provided by the operator, and suggestions for possible modifications and updates. For instance, it is quite easy to
evaluate aggregate statistics on the success rate of a specific Resource Management Technique, to ask the human
operator of removing some very ineffective Resource Management Technique. Also, the average duration of
congested events can be computed from the historical database of the RMU. Therefore, the RMU will be a self-
learning component, able to adapt its behavior to the changing situation, and also able to identify possibly wrong
choices that have been made by a human operator.

2 INTRODUCTION
2.1 Purpose
Deliverable D-3.3, Resource Management Application Scenarios, Traffic Load Scenarios and Decision-Making,
contains the presentation of the work done in WP3 task 3.2 of the CAUTION project and follows the
requirement analysis phase presented in Deliverable [1]. D-3.3 is a design document with the purpose of
providing the basis for the development of the RMU, which is the core element of the CAUTION system, by
which resource management techniques are decided and executed (by means of the OMC network element) after
a detection of the network congestion scenario. This deliverable is required in order to allow the developers to
follow a well-structured guideline that describes the architecture of the RMU in a hierarchical way: from a high
level design of the whole system deep into a low level design of each module and sub-module composing the
system (Detailed Design). In this design document decisions for the architecture, task structure, inter-task
communication, synchronization etc. are taken and documented.
2.2 Scope
The CAUTION system is conceived with the intention to recognize and to react to network congestion
situations, thus solving congestion in overloaded sectors of cellular networks. Such features are mainly provided
by two CAUTION specific network elements, namely the ITMU and the RMU. The first one is responsible for
collecting data as well as for congestion situation recognition, while the second one is responsible for deciding
and actuating the reaction.
This document describes only the RMU component, whose functionalities can be mainly divided in four parts,
namely Traffic Load Scenarios recognition, Strategy Selection, Strategy Actuation and Knowledge Management.
For better understanding the role of the RMU, this deliverable initially presents the CAUTION system
architecture in order to give a general idea of where the RMU is placed, the way the RMU behaves and what his
interactions with the other elements are; in particular, this document describes how the input exchanged between
the ITMU and the RMU can be mapped into traffic load scenarios. The subsequent part of the deliverable
analyzes the RMU from a high-level logical architecture point of view, giving the description of every module
composing the RMU in terms of inputs, processing and outputs. The last part of the document studies in depth
the modules composing the RMU, describing a detailed design of each module from a low-level design point of
view.
2.3 Overview
The rest of this deliverable is structured as follows:
• Chapter 3 provides a high-level description of the CAUTION system architecture. First an overview of
the elements composing the system is shown; then the behaviors of the ITMU (the detector of the
congestion) and the RMU (the responsible of the reaction to the congestion) are briefly described;
• Chapter 4 gives a description of traffic load scenarios; this section shall help the RMU designer in
specifying how the input exchanged from the ITMU to the RMU can be mapped in traffic load
scenarios and their associated RMTs;
• Chapter 5 describes the design of the architecture of the RMU. First a logical outline of the architecture
of the RMU is given; then the RMU high-level state diagram is shown; last a description of the role of
each module composing the RMU is provided, along with module input/output data, local data,
interrupts and signals, logic flow, algorithms, error handling and shared data.

3 CAUTION HIGH LEVEL ARCHITECTURE
Traffic congestion is a situation in cellular networks that is hardly managed in cellular networks. Traffic
overload arises every day during rush hours and quite often in non-predictable events, and cellular networks are
not built with a redundancy similar to the one of fixed networks; therefore, they are more sensitive to congestion
situations than fixed network. The need of high-speed data technologies, in combination with the development of
several data services, results in network shortcomings. CAUTION tackles the problem of traffic congestion in
cellular networks and the main objectives of the project can be summarized as follows:
• Monitor cellular networks
• Predict and/or detect congestion situations
• Apply management techniques to avoid traffic overload
• Ensure stable transition from the congested state to the normal one
For the above-mentioned objectives a suitable architecture should be designed. A very important network
element is the one, responsible for real-time system monitoring. Unfortunately, real-time monitoring is a very
difficult task in existing networks. Monitoring tools, cannot respond in real-time and additionally they cannot
automatically enable mechanisms to overcome congestion problems. The idea of ITMU is to exploit all available
reporting mechanisms and collect those that can give an idea of the traffic overload. In this way redundant
procedures will be avoided, and with no additional overhead the system can be monitored in terms of utilization
and channel blocking. Therefore, ITMU will guarantee the accurate detection of problems and will manage the
reporting to the Resource Management Unit (RMU). On the other hand and despite the implementation
difficulties of the distributed monitoring solution, ITMU will not have knowledge management mechanisms
implemented, in order to ensure safe system rollout. The system element, which has to be very carefully
designed, following intelligent algorithms and knowledge-based management, is the RMU. The reported alarms,
originated from ITMU, will have to be mapped and processed in a way to match the appropriate traffic-load
scenario. In a further stage, a management technique should be selected and applied after adjusting several
parameters. This is also related with on-the-fly adjustments that will lead to the wanted result.
In this section the high level CAUTION system architecture is presented. The main reason is to show where each
network element is placed and how it interacts with the rest of the elements. Since RMU is an element that has a
focal position in the CAUTION system all elements communicating with RMU should be discussed.
CAUTION system is composed by four new elements interconnected by means of dedicated wired lines or IP
backbone network as illustrated in Figure 1. The new CAUTION network elements are the following ones:
• ITMU (Interface Traffic Monitoring Unit)
• RMU (Resource Management Unit)
• Emergency Call Server
• Priority Call Server
The concentrator is an already existing element in GSM cellular networks and generally it is vendor-dependent.
It is used to collect MSC reports that are then delivered toward the ITMU through the A’ interface.
The ITMU will collect, from several concentrators, information about the radio resource utilization in each cell.
It will also construct a matrix for all BTSs with the purpose of compacting several data coming from several
concentrators. Each column will contain the BTS’ identifier and information about the utilization of all the
logical channels of a given cell. A sliding window will aggregate and average the data, estimating the real-time
resource utilization. The ITMU will internally store the matrixes and when congestion is detected in the radio
interface of a given cell, the ITMU will forward alarm messages (through the I- Interface) to the RMU.
The RMU is the core element of the CAUTION system by which resource management techniques are decided
as well as executed (through the OMC) after a detection of network congestion. The RMU is a centralized
element. It will manage the alarms generated by several ITMUs and depending on the type of data, the RMU will
react properly by sending messages to the OMC (through the N interface). The messages will contain radio
resource management information used to change the radio resource allocation of the overloaded cells. In some
cases the RMU can respond to an ITMU message with a request for additional information about traffic-load in
adjacent cells, in order to execute the most appropriate RMT. For example if a RMT has an effect on the alarmed

cell as well as on its adjacent cells, the RMU may decide to control the status of the radio resources of the
adjacent cells in order to verify that the candidate RMT will not influence negatively the neighboring cells. The
RMU may also decide to apply a RMT even before alarms are generated by the ITMUs, when some predicted
congestion event is going to happen. In this case the RMU knows beforehand that a particular traffic condition
will occur at a given time and at specific cells, and it can decide to prevent the probable cell overload by
applying, in advance, the proper RMT. After a radio resource modification, the RMU monitors the radio
resource utilization in order to check if the applied RMT has gained the desiderate effects.
Concentrator
RMU
ITMU_02 ITMU_n
...
OMC
ITMU_01
Emergency
call server
Emergency
call server
Emergency
call server
Priority
call server
MSC_n
BSC
Concentrator Concentrator
MSC_01
BSC
MSC_02
BSC
C
A'
U
O' N
I
T
IP
IP
Figure 1: High-level CAUTION architecture
In addition, a PCS and an ECS are connected to the RMU and ITMU elements. Priority call server will be an
additional element of the CAUTION architecture that will enable the prioritized assignment of bandwidth,
according to the user’s class. ETSI and 3GPP have specified user’s prioritization classes for priority calls,
preemption and queuing. In CAUTION project, it will be important to avoid prioritization of users according to
their contract with the cellular operator, since several legal issues should be considered. The priority call server
will be an element that can be “on the fly” reconfigured in such a way to assign priorities according to the traffic-
load situations. The users will be classified to several classes, such as:
• Ambulances
• Authorities
• Police
• Fire department

In this way after the monitoring of the system, that will take place in ITMU, the priority server will provide the
RMU information related to the priority classes of the subscribers.
The emergency call center will be a CAUTION element that should guarantee a full-time availability of the
network, especially in emergency situations. In GSM networks, these elements already exist but they are not
operational in extreme congestion situations. Emergency call centers will be attached to each ITMU in the
CAUTION architecture. Their functionality is to monitor the traffic load in all cells and alarm reporting from
ITMU. The emergency call centers will be distributed to each ITMU and also connected to the centralized RMU.
Whenever ITMU reports congestion alarms to the emergency call center, the emergency call center will take the
decision about the required bandwidth needed. This would be adjustable and re-configurable from external
places, in a way to require on-demand bandwidth or QoS. For instance, if a catastrophe has taken place the QoS
grade will be definitely increased in such a way that all emergency calls will be served, even if they are
performed from the operator. For the optimal usage of the emergency call centers, operators should in the future
monitor the reserved resources. The connection with the RMU, might change the selected management
technique, therefore, it will be the dominant element in cases of emergency, that in spite of the RMU decisions,
might require the execution of a mechanism, which will enable the handling of emergency calls.
The identified interfaces as shown in Figure 1 are named as follows:
• C : MSC - Concentrator
• A’ : Concentrator – ITMU
• U : ITMU – emergency call server
• T : Emergency call server – RMU
• I : ITMU – RMU
• O’ : RMU- priority call server
• N : RMU – OMC.
The connections among the CAUTION elements are the following ones:
• Connection with Priority call server (dedicated 2-way communication)
• Connection with Emergency call server (2-way communication)
• Connection with one or more ITMUs (dedicated 2 way-communication, or through an IP based
network backbone)
• Connection with the OMC (dedicated 2 way-communication, or through an IP based network
backbone) for executing the proper resource management techniques.

4 TRAFFIC LOAD SCENARIOS
This section gives information about how the parameters provided by the ITMU to the RMU can be associated to
traffic load scenarios. The traffic load scenario identification gives to the RMU a high level vision about the
mobile network congestion as well as it allows to take the correct decisions for capacity management techniques.
Each of the traffic load scenarios will be characterized by a set of parameters, concerning logical channels
utilization and congestion characteristics.
In Section 4.1, the parameters collected by ITMU are described in detail. Then, we explain the rationale behind
the traffic load scenario characterization and recognition in Section 4.2: In the subsequent Sections (from 4.2.1 to
4.2.13), each traffic load scenario is characterized in terms of channels subject to congestion, duration of
congestion and types of traffic.
4.1 ITMU input to resource management
The ITMU performs a real-time monitoring on the network, by collecting information about the radio resource
utilization. It receives from the concentrator several different data (see [1]) that are appropriately processed to
generate the network congestion parameters of interest in CAUTION. In Figure 2, the logical architecture of
ITMU is shown. The concentrator listens to the reports generated in the MSC and forwards them to an ITMU,
which constructs a matrix for all BTSs. For each BTS, the ITMU matrix contains information about all logical
channels. A sliding window aggregates and averages the data, estimating the real-time resource utilization,
blocking rate as well as an indication about the percentage of not-normal clear-codes and emergency calls.
Bridge
RMU
BTS1
BTS2
BTS3
BTS4
BTSn
. . .
SDCCH: 30%
TCH: 67%
RACH: 20%
AGCH: 10%
PCH: 4%
...
t0
Concentrator
RTT, CDR, etc.
Figure 2: ITMU logical architecture
After the completion of a call (successful or not), the reporting system sends a report, indicating the reason of the
connection release. In case the subscriber completed the call normally, the report that is sent to the MSC is
‘0000’ (normal clear). If another value is received, the call was not cleared normally. Some of the not-normal
clear codes are reported if the other party does not respond. Obviously these clear codes are not considered for
generating an alarm, since they are not combined with a network shortcoming. Therefore, if at a certain cell there
is a large amount of not-normal-cleared calls, this should also be reported to the RMU. Therefore, in the ITMU
matrix this indicator should be counted and stored.
The main reason for reporting not-normal-cleared calls is that they can give a better view of the network
shortcoming. If for example, the TCH utilization in a specific cell is around 15%, there are two possible reasons
that explain this:
• The cell is not congested and there are no additional problems

• The traffic congestion is enormous and the lack of signaling channels result in a very low TCH
utilization.
In the second case, it is obvious that the combination of the channel utilization with the not-normal-cleared calls
would have diagnosed the congestion, something that would not have been noticed from the sole utilization
value. In case the number of not-normal-cleared calls is higher than a threshold, a CLC (CLear Code) report is
sent to RMU. The ITMU estimated parameters for each cell are indicated in the following:
• TCH utilization
• SDCCH utilization
• RACH utilization
• SACCH utilization
• AGCH utilization
• PCH utilization
• TCH Blocking rate (BR)
• SDCCH Blocking rate (BR)
• Percentage of not-normal clear-codes
• Percentage of emergency call attempts
The ITMU will compare each of these parameters with a set of threshold values it stores, to verify whether the
threshold value is reached or not. A positive match with the threshold values will result in one alarm to be
propagated to the RMU, indicating the necessity of starting a congestion management procedure. Three
threshold values are defined for ITMU:
• Alarm threshold (ALT), which specifies a threshold value that when reached triggers some overload
management RMU actions. ALT is always set.
• Relax threshold (RXT), which specifies a threshold value that when reached stops the alarm to be
issued by the ITMU. It represents the termination of the congestion situation. A value of RXT
consistently less than that of ALT shall be considered, to limit the occurrence of oscillatory phenomena.
• Alarm based on the number of not-normal clear codes (CLC). This alarm is generated when the number
of not-normal clear codes is above a pre-defined threshold.
The plot shown in Figure 3 explains the way the ITMU employs the various thresholds in case of a congestion
event. As the resource utilization grows to overcome the ALT value, the ITMU will send an alarm to the RMU.
The treatment of overload will continue till the resource utilization factor has decreased below the RXT value.
After that, the normal resource management is resumed by RMU.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1 2 3 4 5 6 7 8 9 10 11
RXT
ALT
time
Channel utilization
Alarm from
ITMU
Stop overload
treatment
Figure 3: ITMU threshold utilization

0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1 2 3 4 5 6 7 8 9 10 11
RXT
ALT
time
Channel utilization
Stop overload
treatment
CLC alarm
Figure 4: Creation of a CLC alarm
Figure 4 shows how a CLC alarm is generated. In the above example, although the TCH utilization was not
higher than the pre-defined threshold, an abnormally high number of not-normal clear codes lead to the
conclusion that the network is suffering from some kind of congestion, and generates a CLC alarm.
The ITMU will exploit available reports and will calculate cell overload indicators. In every loop the system will
check if the values are under or above their threshold values, as described above. If one of the above parameters
has reached a threshold, the alarm mechanism is triggered. This alarm will be reported to the RMU.
Subsequently, RMU will identify the traffic-load scenario and decide for a management technique. To take into
consideration the time necessary for the RMT deployment and impact on resource utilization, after execution of
the technique, additional alarms for the same cells should be not be forward from the ITMU to the RMU for a
given period of time. The duration of this period between two different alarms (∆t) will be a variable in the
system, but is expected to be around 1 minute, in any case not less. In the following flow chart, a simple
mechanism to filter redundant alarms is shown. It is important to notice that the ITMU will keep calculating the
indicators as normal, though they are not submitted, unless the specific time has passed.
Detect alarm for
cell_i
cell_i timer=0 cell_i timer= ∆t
Set filtering-timer
for cell_i = 0
Increase timer
Fwd alarm to
RMU
yes yes
no no
Monitor
system
Increase timer
Figure 5: Filtering of alarm in the ITMU

An important issue that should be mentioned is how utilization and blocking rate are calculated. In order to
calculate the utilization, it is important to store locally in the ITMU the resource allocation configuration of each
cell. By constructing the ITMU matrix, it is possible to come to conclusions about the occupation of the
signaling and traffic channels. Subsequently the Erlang-B table is used, in order to calculate resource utilization,
considering the GoS (Grade of Service), since network operators always consider this value. To estimate the
blocking rate (BR), the number of blocked clear codes should be divided by the total number of clear codes.
The threshold values are manually set, configurable, and are stored both in the ITMU and the RMU database
(see following sections). The RMU, which is also accessible from outside can change the ITMU thresholds if
congestion is predicted. The ITMU shall read the threshold values at initialization time. When the ITMU issues
an alarm to the RMU, it forwards all the data it has on the congested BTS, thus providing the RMU with a
snapshot of the overall congestion situation. The alarm is continuously sent (on a periodic basis) till it gets
deactivated, i.e. all parameters go below their RXT thresholds. If not-normal-cleared calls are detected, a CLC
report is sent.
The communication between ITMU and RMU will be a two-way communication. This is important in order to
allow the exchange of additional information when required. The RMU receives the alarm messages, which are
submitted asynchronously from the ITMU, for the decisions making. The RMU might not be able to detect the
scenario or before executing the appropriate command, it is recommended to have a better view of the system
traffic. Therefore, the RMU will request the data of the neighbor cells, in order to decide about the area that is
affected from the traffic overload. In that case, ITMU sends messages to the RMU, indicated with NCI and
containing information about the neighbor cell that was requested. The NCI type of message is only used by
ITMU to send to the ITMU data for a certain cell that are requested by the RMU itself.
The ITMU alarm will have a concrete syntax. The specification of the alarm grammar will be described in detail
in D-3.2. The main factors that should definitely be included in the alarm message are:
Table 1: Output to RMU from ITMU
Input to RMU from ITMU Name
Identifiers of the overloaded cell Cell_id
Message type ALT, RTX, CLC, NCI
Time indicator TIME
Date indicator DATE
TCH utilization TCH_UT
SDCCH utilization SDCCH_UT
SACCH utilization SECCH_UT
PCH utilization PCH_UT
AGCH utilization AGCH_UT
RACH utilization RACH_UT
TCH blocking rate TCH_BR
SDCCH blocking rate SDCCH_BR
Emergency calls Ec_no
Number of not-normal clear codes clc_no

4.2 Traffic load scenario characterization
Before any attempt is made to characterize the traffic load scenarios, based on a piece of predictable information,
such as occurrence time, congestion localization, duration of the event, and amount of traffic observed during the
congestion, it must be clear how the information from ITMU should be interpreted according to the statistical
analysis performed in [1]. Therefore, utilization and blocking of certain channels in addition to normal and not-
normal clear codes, reported by the ITMU element, should be corresponded to performance indicators such as
Blocking Rate, Success Rate and Throughput of the respective channels.
A quantitative correspondence of the above mentioned indicators is a difficult task with doubtful results, that
would produce additional overhead to the whole process. Thus, a qualitative relation is attempted instead. For
that reason, two new charts are generated, depicting the network’s reaction in congestion situations for the
utilization of the channels, based on the chart generated by the statistical analysis for the performance indicators
examined in [1]. The basic idea of the chart is explained in Figure 6.
Y-Axis
X-Axis
SDCCH
BLOCKING
TCH
BLOCKING
HANDOVER
FAILURES
0
LOW
CONGESTION
MEDIUM
CONGESTION
HIGH
CONGESTION
TRAFFIC
THROUGHPUT
Figure 6: Network's behavior in congestion situations for performance indicators
Low congestion means that only few BSCs are affected and probably is geographically limited, medium
congestion means that a respective percent of BSCs participate in the crisis and high congestion means that
almost the entire network is affected. The above classification of situations is also based on the results on
network level.
At first, traffic can also be considered as the throughput of the network. As seen in the diagram, it increases
beyond the threshold of the low congestion situation, but reaches a limit beyond the threshold of the medium
congestion conditions. This limit represents exactly how much traffic the network can handle (or the maximum
throughput the network can achieve). After the threshold of the high congestion, traffic is slightly degrading, as
the conditions worsen and the resources responsible for a service establishment (SDCCH mostly) dramatically
diminish.
As far as the SDCCH Blocking is concerned, it is clearly marked on the diagram that it is increasing
proportionally to the augmentation of the congestion level. This is normal, because the demand for establishment
resources increases, while resources are static and limited. In that way, blocking is increased proportionally to
the demand. The importance of the SDCCH Blocking in the whole study is that all procedures are SDCCH-
dependant.

TCH Blocking also increases as traffic (or demand) increases, beyond the low congestion threshold, and reaches
a peak at medium congestion, accordingly to the traffic. As high congestion situations approach, TCH Blocking
clearly reduces its figures. This is also SDCCH-dependant and it happens because the network has run out of
establishment resources (SDCCH mostly), traffic is reduced and there are TCHs available. It must be noted that,
in cellular networks, TCHs outnumber SDCCHs in every single TRX.
Finally, Handover failure rate (the same applies for Call Setup failure rate, which is 1-CSSR) follows the curve
of TCH Blocking. It is also SDCCH-dependant, reaches its peak when TCH Blocking is at its highest point and
diminishes at high congestion conditions, because services cannot be established at this point.
According to the above facts, the utilization diagrams follow in the same layout. It is very important, in this
exact point of the analysis, to clarify that the following charts slightly precede the one above in terms of time and
network monitoring. In other words, monitoring a channel, one will firstly perceive a change in utilization,
followed by a change in blocking/success rates. An explanation of the next diagram is shown in Figure 7.
UTILIZATION%
0
LOW
CONGESTION
MEDIUM
CONGESTION
HIGH
CONGESTION
TCH
100
50
SDCCH
Figure 7: Network's reaction in congestion situations for utilization of SDCCH, TCH
As shown above, TCH suffers the first from the congestion situation, followed by the SDCCH. The utilization of
the two channels is similar in both low and medium congestion situations. When SDCCH gets highly congested,
TCH utilization degrades, as there cannot be any more TCH assignments (lack of setup resources). If the traffic
load is even bigger, the situation worsens, RACH and PCH overcome the highest level of utilization and SDCCH
utilization starts to degrade also, as call setup attempts are now not perceived at all by the network.
In Figure 8, the behavior of RACH, PCH and AGCH utilization is depicted. These channels follow a smoother
increase of their utilization, as there are usually enough resources to handle the attempts made. Especially,
AGCH rarely encounters problems in blocking and utilization. The most common phenomenon, though, as far as
RACH/PCH are concerned, is that problems are encountered in the Abis interface (air interface’s resources are
usually adequate to handle most situations), causing congestion situations. Usually, all three channels (PCH,
RACH, AGCH) remain in medium or low congestion utilization factor.
Combining the information from the three aforementioned charts with the experience of the operator on similar
situations and radio coverage, it is feasible to relate utilization and blocking reported by the ITMU to congestion

and, therefore, to characterize the scenarios. Utilization is the key indicator that will characterize a congestive
scenario, as it is more representative of what is really happening and more independent from the situation itself
than blocking. On the other side, blocking will provide additional information and, thus, extra help in the
characterization of the scenario. Blocking rate depends on certain network parameters, such as radio coverage of
the selected area, overlapping of the cells and the use of directed retry. This “drawback” can be used in favor of
the method, as it will offer extra characteristics to the situation. For instance, in a congestion situation where
utilization reaches high values, it is very possible for blocking to remain in low level because of good cell
overlapping and proper use of the directed retry feature. Another possibility is that, while utilization decreases to
very low values giving the impression that everything works fine, blocking rate reaches very high values, raising
in that way the alarm that channels are not used because of congestion. The use of utilization in combination
with blocking will be obvious in the construction of the characterization rule for each scenario, a procedure that
follows.
UTILIZATION%
0
LOW
CONGESTION
MEDIUM
CONGESTION
HIGH
CONGESTION
100
50
RACH / PCH
AGCH
Figure 8: Network's reaction in congestion situations for utilization of RACH, PCH, AGCH
Furthermore, a significant point of this analysis is that most of the events are scaling events, meaning that the
increase will pass through all the congestion levels, on the road to the highest peak and that must be taken into
consideration on the selection of the appropriate scenario.
An important role will also be played by the information gathered off the clear codes, which will be combined
with the utilization and blocking information for best performance of the matching of the scenarios. It is possible
for few selected scenarios to be triggered based only on abnormal behavior of clear codes (e.g. dramatic increase
of non-normal clear codes).
Finally, because the production of each scenario rule demands certain values for each parameter used, the code
of interpretation of numbers to levels (Low, Medium, High) follows. The encoding uses the statistical analysis
and the operator’s experience in order to transform numbers to levels.

Priority
As far as priority is concerned, there will be three different levels of it, depending mostly on the percentage of
emergency calls attempted in each scenario/situation.
• Level 0, which will be the default level for normal situations.
• Level 1, which will be the level for critical situations from the network’s aspect
• Level 2, which will be the level for emergency situations.
Dimension
• Low: up to 10 cells
• Medium: 10 cells to 50 cells
• High: over 50 cells
SDCCH, TCH, PCH, RACH Utilization
• Low: 60% to 70%
• Medium: 70% to 80%
• High: over 80%
AGCH Utilization
• Low: 70% to 80%
• High: over 90%
SDCCH, PCH, RACH, AGCH Blocking Rate
• Low: 0% to 1%
• High: over 5%
TCH Blocking Rate
• Low: 0% to 1%
• High: over 10%
CLC percentage
• Low: 0% to 1%
• High: over 10%
Emergency call percentage
• Low: 0% to 5%
• High: over 10%
The CAUTION strategy to traffic load scenario characterization is based on the concept of “characterization
rule”. A characterization rule for traffic load scenario X is an extrapolation from a set of observed events, which
defines the properties a specific network congestion event has to satisfy for the event to be classified as a traffic
load scenario X. The definition of characterization rules is based on an induction process, which moves from a
set of the observed and already recognized events, and produces a general rule.
The construction of the characterization rule demands the maximum set of parameters and information to be
included. In a realistic point of view, though, during the implementation of the process for instance, only some of
these data may be present, in order to avoid unnecessary complexity and overload.

The basic ingredient for this inductive process is represented by the characterization of each traffic load scenario.
Such characterization immediately provides the conditions that network traffic parameters exhibit when an
occurrence of the traffic load scenario arises. A traffic load scenario will be characterized based on a piece of
predictable information, such as that on occurrence time, congestion localization, duration of the event, and
amount of traffic observed during congestion. Most traffic load scenarios show some predictable features that are
usefully employed to define a characterization rule.
It is worthwhile observing that the characterization rules represent in fact the first knowledge base of the
CAUTION system. Such knowledge will be manually added to the RMU knowledge base, and could be
subsequently modified according to further experiences gained by the system during operation.
Each rule will be given in an abstract form, as a logical predicate that can be easily transformed into the code
performing the recognition. The following BNF context-free grammar (symbols enclosed within <> denote non-
terminals) precisely defines the syntax of rules.
<RULE>::= (<Dimension Rule>)
(<SDCCH Rule>)
(<TCH Rule>)
(<AGCH Rule>)
(<PCH Rule>)
(<...Other channels... Rule>)
(<Emergency calls Rule>)
(<Clear Code Rule>)
EXTRA INFO
(<Priority>)
(<Expected Duration>)
(<...Everything else might be useful...>)
This grammar distinguishes two types of info in the rule. Everything that comes before the EXTRA INFO
delimiter will be used by the TLSR in the matching process. This implies that all the fields before EXTRA INFO
will be measurable according to the HIGH/MEDIUM/LOW scale. Everything that follows the EXTRA INFO
will be used by other RMU processes, e.g. the expected duration will be useful for the SS to know the length of
the monitoring.
Utilization and blocking will be provided by the ITMU in the format presented in the aforementioned grammar
(real in [0, 1]), but they will be encoded to levels, according to the scheme presented in the paragraph above, in
order to be included in the characterization rule.
The grammar shown above specifies the type of knowledge that must be provided to the CAUTION system to
start a recognition algorithm that classifies congestion events. According to the grammar transformations, only
some of these data may be present. Obviously, the more the amount of included information, the better the
reliability of the TLS recognition and treatment processes.
In the following, we will denote with the phrasing “Undefined Traffic Load Scenario” (UTLS), the completely
unspecified traffic load scenario, i.e. the one for which the characterization rule does not specifies any condition.
We shall assume that each congestion event, when compared with the UTLS, results in a perfect match. In the
following, we will perform the extrapolation process to produce the characterization rule for each of the relevant
traffic load scenarios identified in [1].
4.2.1 Busy hours
In a telecommunications system what we call “Busy Hour” is the sliding 60-minute period during which the
maximum total traffic load in a given 24-hour period occurs. For example, this is a situation that occurs in
business days more or less in the same way throughout the whole network, but it is better perceived in urban
areas.

The diagram in Figure 9 shows the typical trend of the total BSC workload (in Erlang) during the day. As it can
be observed from Figure 9, two different peaks are reached during the day, with peak traffic values much higher
than the average ones.
96.91
57.75
34.58
21.78
15.0011.3712.52
25.86
62.18
117.74
178.18
229.16
256.43254.67
228.66
189.38
174.58
210.43
254.73
266.59
260.52
235.65
190.97
142.43
0
50
100
150
200
250
300
0:00
2:00
4:00
6:00
8:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
Erlang
Average Value: 146 Erlang
Figure 9: Channel utilization during the Busy Hours
Since busy hour’s congestion is a periodical situation, the time occurrence, traffic overload and location of the
event are predictable with a good confidence degree. In particular, the following parameters can be estimated
based on the statistical analysis of the observed events.
The start time of the congestion event, as well as its duration, are statistically predictable. Depending on the area
and time of the year, three different busy hours can be defined. Firstly, in a metropolitan area, during wintertime,
busy hour occurs in the [12 AM, 1 PM] time window. In the rest of a country, during wintertime, busy hour
occurs in the [8 PM, 9 PM] time window. Finally, during summer time, busy hour occurs in the [8 PM, 9 PM]
time window almost everywhere. The last case applies mostly to the next scenario of tourist periods.
The channels subject to congestion are mainly the TCH and the SDCCH. TCH utilization can overcome 80%
during the Busy Hour, while SDCCH utilization reaches values up to 70 %. The channel that first gets congested
is the TCH, then the SDCCH. It should be noted that in certain cells of a metropolitan area utilization reaches
100%. As far as the other channels are concerned, all three (PCH, RACH, AGCH) remain in low congestion
utilization factor. Blocking rates in this scenario remain in [1%, 10%] percentage window for the TCH and in the
[1%, 5%] percentage window for the other channels. Of course, as mentioned before, blocking depends highly
on the area, radio coverage and other network parameters and these values are averaged estimations, in order to
help the identification process.
The cells involved in the Busy Hours congestion events are also predictable. A list of such cells can be provided,
depending on the specific geographic area involved in the Busy Hours. As mentioned above, the cells mostly
affected are the ones serving urban areas, especially if they are highly populated. This fact means that only few
cells in the entire network encounter high congestion on busy hour.
The following table provides a characterization of the traffic typologies associated with the Busy Hours events.
The results are extracted from the statistical analysis performed in [1].
Table 2: Traffic breakdown during Busy Hours
Voice LocUpd SMS Other (Emergency etc.)
Relative traffic % 35% 40% 20% 5%
Combining the data provided above, we can produce the following characterization rule to capture the Busy
Hours occurring during Business Days.

START RULE: Busy Hours
(Dimension = High)
(SDCCH Util.= Medium OR High)
(TCH Util. = High)
(PCH Util. = Low)
(RACH Util. = Low)
(AGCH Util. = Low)
(SDCCH BR= Medium)
(TCH BR = Medium)
(Em. call = Low)
(CLC = Low)
EXTRA INFO
(Priority = 0)
(Predicted duration = 1 h; Predicted Start Time = 12AM OR 8PM)
END RULE
4.2.2 Tourist periods
We consider tourist periods those long vacation periods in which a considerable amount of people uses to leave
for holidays resorts (seasides, mountains, lakes, islands, et cetera). Even if the number of tourists in a given
location can vary over the years in a rather unpredictable way, the traffic overload can be estimated to fairly well
on the basis of the statistical analysis of the data collected in previous years.
In very simple words, what can be expected during the tourist period in a specific location is a “scaling” effect,
which multiples the time-dependent utilization factor of the network resources proportionally to the amount of
users in the area affected by the tourist flow. Thus, area in which the local Busy Hours does not generate any
network congestion during non-tourist periods, may be daily affected by an excessive degradation of network
performances in those periods, during which the number of wireless users in the area is multiplied by a factor of
two, five, and even ten.
Congestion characteristics of an event belonging to the Tourist Period traffic load scenario should be quite
similar to that of the Busy Hour explained above. Slight differences are observed in the utilization factors of
certain channels (that are slightly increased), in the starting times of the traffic peaks and the scenario’s predicted
duration. The cells mostly affected in this scenario are the ones serving tourist destinations and are easily
located.
The channels subject to congestion are mainly the TCH and the SDCCH. Both TCH and SDCCH utilization can
overcome 80% during the Busy Hour. The channel that first gets congested is the TCH, then the SDCCH. As far
as the other channels are concerned, both PCH and RACH climb on the medium congestion utilization factor,
while AGCH rests at the lowest level of congestion. Blocking rates in this scenario remain in [1%, 10%]
percentage window for the TCH and in the [1%, 5%] percentage window for the other channels. Of course, as
mentioned before, blocking depends highly on the area, radio coverage and other network parameters and these
values are averaged estimations, in order to help the identification process.
The start time of the congestion event, as well as its duration, are statistically predictable. Regardless of which
day of the week is considered or the area affected, the traffic peak is reached during the time window [8 PM, 9
PM] in the evening, as people tend to move their acting hours later than usual.
The cells involved in the Tourist Period TLS congestion events are predictable. A list of such cells can be
provided, depending on the specific geographic area involved in the tourist movements. The following table

provides a characterization of the traffic typologies associated with the Tourist Period Peak events. The relative
traffic is similar to the one observed in busy hour.
Table 3: Traffic breakdown during Tourist Period Peak events
Combining the data provided above, we can produce the following characterization rule to capture the Tourist
Period Peak scenario.
START RULE: tourist period
(Dimension = High)
(Observed Locations ⊆ {Cell1, Cell2,…})
(SDCCH Util. = High)
(TCH Util. = High)
(PCH Util. = Medium)
(RACH Util. = Medium)
(AGCH Util. = Low)
(SDCCH BR= Medium)
(TCH BR = Medium)
(Em. call = Low)
(CLC = Low)
Extra info
(Priority = 0)
(Predicted duration = 1 h; Predicted Start Time = 8PM)
END RULE
4.2.3 Bank holidays
We consider bank holidays those public holidays such as New Year first day, Easter and Christmas. In these
particular days of the year people use to give best wishes to relatives and friends causing a huge growth of the
traffic load in a relatively short period of time. The traffic overload and particularly overloaded traffic times (e.g.
the minutes around midnight in New Year’s Eve) are predictable with a nearly good precision from previous
statistical data. The following observable parameters are described in the paragraphs below: channels subject to
congestion, duration of congestion and types of traffic.
All channels are affected in such a scenario. All channels, but AGCH that reaches the medium utilization factor,
increase to the highest level of utilization. TCH receives the first congestion situation, followed by the SDCCH.
When SDCCH gets highly congested, TCH utilization degrades, as there cannot be any more TCH assignments
(lack of setup resources). If the traffic load is even bigger, the situation worsens, RACH and PCH overcome the
highest level of utilization and the user has practically no cell phone. TCH blocking rate usually overcomes the
10% threshold, while SDCCH, RACH and PCH reach also high values, way over the 5% threshold. Only AGCH
remains in medium blocking.

The start time of the congestion event, as well as its duration, are statistically predictable. As observed during the
statistical analysis, the event takes place in the [11 PM, 1 AM] time window. The most important aspect of this
scenario is that the date is also predictable. Yet, the most predictable case is causing the greatest problem to the
network.
The cells involved in the Bank holidays congestion events are predictable. Usually, this scenario applies to the
whole network’s topology. The event is expected to affect on network level and only a small number of cells will
behave well. The following table provides a characterization of the traffic typologies associated with the Bank
holidays scenario. The results are extracted from the statistical analysis performed in D-2.1.
Table 4: Traffic breakdown during Bank Holidays
Combining the data provided above, we can produce the following characterization rule to capture the Bank
holidays scenario.
START RULE: Bank holidays
(Dimension = High)
(Observed Locations ⊆ {Cell1, Cell2,…})
(TCH Util. = High)
(PCH Util. = High)
(RACH Util. = High)
(AGCH Util. = Medium)
(SDCCH BR= High)
(TCH BR = High)
(Em. call = Low)
(CLC = Low)
Extra info
(Priority = 1)
(Predicted duration = 2 h; Predicted Start Time = 11PM)
END RULE
4.2.4 Sport events
During sport events a large/medium number of persons are concentrated in a delimited location. The interested
cells pass from the average concentration of users to a much higher amount of users that can become call
attempting users for a period of about 2-3 hours, depending on the duration of the sport event. The time and
location of the event are known in advance, the traffic overload can be estimated on the basis of data previously
collected in similar events. The following observable parameters are described in the paragraphs below: channels
subject to congestion, duration of congestion and types of traffic.

(lack of setup resources). TCH blocking rate usually overcomes the 10% threshold, while SDCCH, RACH and
PCH reach also high values, way over the 5% threshold. Only AGCH remains in medium blocking. If the traffic
load is even bigger, the situation worsens, RACH and PCH overcome the highest level of utilization and the user
has practically no cell phone. The last part usually happens in certain periods of the event, such as “dead”
periods (half time of a match etc.) or extremely “active” points (scoring of a goal, gaining a victory etc.).
The start time and date of the congestion event, as well as its duration, are known in advance, but for each event
in particular. In that way there cannot be defined any time window, but will be easily statistically predicted and
identified, based on previous statistical data.
The cells involved in the Sport events’ congestion scenario are predictable. Usually, this scenario applies to very
few cells serving the location of the sport event and its surrounding area. At first, the congestion appears to the
surrounding cells, as the crowd is coming to the stadium. Then congestion moves to the cells serving inside the
stadium and, finally, is redirected to the surrounding cells, as the crowd is leaving. The following table provides
a characterization of the traffic typologies associated with the Sport events. The results are extracted from the
statistical analysis performed in D-2.1.
Table 5: Traffic breakdown during Sport events
Combining the data provided above, we can produce the following characterization rule to capture the Sport
events scenario.
START RULE: Sport events
(Dimension = Low)
(TCH Util. = High)
(PCH Util. = High)
(RACH Util. = High)
(SDCCH BR= High)
(CLC = Low)
(TCH BR = High)
(Em. call = Low)
Extra info
(Priority = 1)
END RULE
4.2.5 Traveling services strikes
The traveling services strikes can cause the growth of users concentration in places like railway stations or
airports. Typically all those people whose planned travel has been cancelled or suspended will use the phone in
order to inform persons waiting for them that they aren’t arriving on time, and to find a solution like backup
travel services. The time and location of the event are known in advance, the traffic overload is predictable to a
certain extent if data has been collected in similar events. The following observable parameters are described in
the paragraphs below: channels subject to congestion, duration of congestion and types of traffic.

Both TCH and SDCCH reach the highest level of utilization, but the other channels remain in low utilization
factor. TCH receives the first congestion situation, followed by the SDCCH. When SDCCH gets highly
congested, TCH utilization degrades, as there cannot be any more TCH assignments (lack of setup resources). As
far as blocking is concerned, TCH BR overcomes the 10% threshold, SDCCH BR overcomes the 5% threshold,
while the other channels remain below the 1% threshold.
The cells involved in the Traveling services strikes congestion scenario are predictable. Usually, this scenario
applies to very few cells (possibly only one) serving the location of the strike event, such as airports, railway
stations, bus stations or ports. The following table provides a characterization of the traffic typologies associated
with the Traveling services strikes. The results are extracted from the statistical analysis performed in D-2.1.
Table 6: Traffic breakdown during Traveling services strikes
Combining the data provided above, we can produce the following characterization rule to capture the Traveling
services strikes scenario.
START RULE: Traveling services strikes
(Dimension = Low)
(TCH Util. = High)
(PCH Util. = Low)
(RACH Util. = Low)
(AGCH Util. = Low)
(SDCCH BR= High)
(CLC = Low)
(TCH BR = High)
(Em. call = Low)
Extra info
(Priority = 1)
END RULE
4.2.6 Religious/cultural events
Cultural events like theatre performances, movies, concerts, discos, and religious events cause a concentration of
people in specific locations. In those occasions a medium/large amount of people use mobile phones mostly to
call friends and relatives. The time and location of the event are known in advance, the traffic overload is quite
predictable on the basis of data previously collected in similar events. The following observable parameters are
described in the paragraphs below: channels subject to congestion, duration of congestion and types of traffic.
Usually, the Dimension of this event is slightly lower than the one of a sport event, as far as channel utilization is
concerned. Both TCH and SDCCH reach the highest level of utilization, but the other channels remain in
medium utilization factor. TCH receives the first congestion situation, followed by the SDCCH. When SDCCH

gets highly congested, TCH utilization degrades, as there cannot be any more TCH assignments (lack of setup
resources). TCH BR varies in the [1%, 10%] percentage window, while SDCCH BR is controlled in the [1%,
5%] window. The other channels are in low level blocking rates.
The cells involved in the religious/cultural events’ congestion scenario are predictable. Usually, this scenario
applies to very few cells serving the location of the event and its surrounding area. At first, the congestion
appears to the surrounding cells, as the crowd is coming to the location of the event. Then congestion moves to
the cells serving inside the theatre, cinema or church and, finally, is redirected to the surrounding cells, as the
crowd is leaving. The following table provides a characterization of the traffic typologies associated with the
Religious/cultural events. The results are extracted from the statistical analysis performed in D-2.1.
Table 7: Traffic breakdown during Religious/cultural events
Combining the data provided above, we can produce the following characterization rule to capture the
Religious/cultural events’ scenario.
START RULE: Religious/cultural events
(Dimension = Low)
(TCH Util. = High)
(SDCCH BR= Medium)
(TCH BR = Medium)
(Em. call = Low)
(CLC = Low)
Extra info
(Priority = 0)
END RULE
4.2.7 Demonstrations
Demonstrations for political, social, trade union reasons are potential congestion situations. The traffic overload
depends mostly on the concentration of users and also partially on the participants need to communicate and
exchange information about the demonstration progress. The time and location of the event are known in
advance, the traffic overload is predictable to a certain extent if data has been collected in similar events. The
following observable parameters are described in the paragraphs below: channels subject to congestion, duration
of congestion and types of traffic.

(lack of setup resources). If the traffic load is even bigger, the situation worsens, RACH and PCH overcome the
highest level of utilization and the user has practically no cell phone. Blocking during demonstrations increases
to high values for the TCH and SDCCH, but remains low for RACH, PCH and AGCH respectively. Of course,
this depends on the area, radio coverage and other network parameters.
The cells involved in the Demonstrations congestion scenario are predictable. Usually, this scenario applies to
few cells serving the location of the demonstration and its surrounding area. At first, the congestion appears to
the meeting point of the demonstrators, but then moves along with the direction of the demonstration, affecting
the cells serving the area. The following table provides a characterization of the traffic typologies associated with
the Demonstrations events. The results are extracted from the statistical analysis performed in D-2.1.
Table 8: Traffic breakdown during Demonstrations
Demonstrations scenario.
START RULE: Demonstrations
(Dimension = Medium OR Low)
(TCH Util. = High)
(PCH Util. = High)
(RACH Util. = High)
(SDCCH BR= High)
(CLC = Low)
(TCH BR = High)
(Em. call = Low)
Extra info
(Priority = 1)
END RULE
4.2.8 Department stores
Department stores grouping shops of different kinds attract all over the year a high concentration of people. In
these situations, due to the huge number of people restricted in a delimited area, a traffic congestion can be
observed, both incoming and outgoing calls. The overload problem can occur during the Busy hours, when
traffic is by default increased. The traffic overload is quite predictable, by using the daily measurements
collected by the cell(s) the department store is situated in. From these data, specific busy hours can also be
individuated. The following observable parameters are described in the paragraphs below: channels subject to

The channels subject to congestion are mainly the TCH and the SDCCH. TCH utilization can overcome 80%
during the Busy Hour, while SDCCH utilization reaches values up to 70 %. The channel that first gets congested
is the TCH, then the SDCCH. As far as the other channels are concerned, all three (PCH, RACH, AGCH) remain
in low congestion utilization factor. Blocking is usually in medium level for all the channels, except AGCH,
which remains in the lowest values.
The start time of the congestion event, as well as its duration, are statistically predictable. During business days,
the Department stores scenario can be predicted to occur during the [12 AM, 1 PM] time window in the morning,
and during the time window [8 PM, 9 PM] in the evening. The hours indicated above are, of course, a rough
estimation that can be modified from country to country, from area to area etc. It will be included, though, in the
characterization rule, as an indication.
The cells involved in the Department stores congestion scenario are also predictable. It is most likely only one
cell affected, the one serving the department store, with the possibility that a few neighboring cells “feel” the
phenomenon.
The following table provides a characterization of the traffic typologies associated with the Department stores
scenario. The results are extracted from the statistical analysis performed in D-2.1.
Table 9: Traffic brekdown during Department stores event
Department stores scenario.
START RULE: Department stores
(Dimension = Low)
(SDCCH Util. = Medium)
(TCH Util. = Medium OR High)
(PCH Util. = Low)
(RACH Util. = Low)
(AGCH Util. = Low)
(SDCCH BR= Medium)
(TCH BR = Medium)
(Em. call = Low)
(CLC = Low)
Extra info
(Priority = 0)
(Predicted Start Time = 12AM OR 8 PM)
END RULE
4.2.9 Planned outages
In case of a planned outage for repairing the network, the service in the corresponding cell(s) is either
unavailable or limited. The traffic trend is the usual one, but because of the outage a certain number of users are
redirected in the adjacent cells, causing a traffic overload in those areas. The location and duration of the outage
are known in advance. The number of users that are redirected in the adjacent cells can usually be estimated on

the basis of statistical data. The following observable parameters are described in the paragraphs below: channels
subject to congestion, duration of congestion and types of traffic.
The channel that is mostly affected in this scenario is the SDCCH, especially if LocUpd is demanded for the
users directed to the neighboring cells. Thus, it reaches the highest values of utilization. TCH can vary its
utilization between medium and high utilization factor, while the other channels remain in medium
(RACH/PCH) or low (AGCH) congestion situations. Blocking is assumed to be high in such a situation for all
channels, except the AGCH, which reaches medium values. High blocking is mainly caused by the redirection of
users to the neighboring cells, but highly depends on the characteristics of the area of the outage.
The cells involved in the Planned outages congestion scenario are known in advance. This scenario applies to
few cells serving the surrounding area of the location of the outage. When the planned elements go down, all the
traffic is redirected to the neighboring cells. The following table provides a characterization of the traffic
typologies associated with the Planned outages events. The results are extracted from the statistical analysis
performed in D-2.1.
Table 10: Traffic breakdown during Planned outages
Combining the data provided above, we can produce the following characterization rule to capture the Planned
outages scenario.
START RULE: Planned outages
(Dimension = Low)
(TCH Util. = Medium)
(AGCH Util. = Low)
(SDCCH BR= High)
(TCH BR = High)
(Em. call = Low)
(CLC = Low)
Extra info
(Priority = 0)
(1AM < Event Duration < 5AM)
END RULE
4.2.10 BTS shortcoming
In case of BTS or BTS link shortcoming, users are redirected to the nearest BTSs, where the traffic overload
situation takes place consequently. The location, time and duration of the shortcoming is not known in advance.
The traffic overload can be estimated to a certain extent on the basis of the average number of users of the cell

corresponding to the damaged BTS. The following observable parameters are described in the paragraphs below:
channels subject to congestion, duration of congestion and types of traffic.
users directed to the neighboring cells. Thus, it reaches the highest values of utilization. TCH can vary its
utilization between medium and high utilization factor, while the other channels remain in medium
(RACH/PCH) or low (AGCH) congestion situations. Blocking is assumed to be high in such a situation for all
channels, except the AGCH, which reaches medium values. High blocking is mainly caused by the redirection of
users to the neighboring cells, but highly depends on the characteristics of the area of the shortcoming.
The start time and date of the congestion event, as well as its duration, are unpredictable. In that way there
cannot be defined any time window and can only roughly be estimated based on previous statistical data.
The cells involved in the BTS Shortcoming congestion scenario are known in advance. This scenario applies to
few cells serving the surrounding area of the BTS out of order. When the respective BTS goes down, all the
traffic is redirected to the neighboring cells. The following table provides a characterization of the traffic
typologies associated with the BTS Shortcoming events. The results are extracted from the statistical analysis
performed in D-2.1.
Table 11: Traffic breakdown during BTS Shortcoming
Combining the data provided above, we can produce the following characterization rule to capture the BTS
Shortcoming scenario.
START RULE: BTS Shortcoming
(Dimension = Low)
(AGCH Util. = Low)
(SDCCH BR= High)
(TCH BR = High)
(Em. call = Low)
(CLC = Low)
Extra info
(Priority = 1)
END RULE
4.2.11 BSC shortcoming
In case of a BSC or a BSC link shortcoming, some areas inside the BSC coverage could remain isolated. In a
BSC having a star topology, users located at the edges of the BSC coverage area are redirected to the nearest
BSCs; otherwise their calls are not satisfied. The location, time and duration of the shortcoming is not known in
advance. The traffic overload can be estimated to a certain extent on the basis of the average number of users at

the edges of the area related to the damaged BSC. The following observable parameters are described in the
paragraphs below: channels subject to congestion, duration of congestion and types of traffic.
users directed to the neighboring cells. In case of a BSC that coincides with the LA borders, the load on SDCCH
due to LocUpd is sure to overcome the highest expectations. It should be mentioned that LocUpd will be
performed twice, once when the BSC goes down and once when it becomes operational again. Thus, SDCCH
reaches the highest values of utilization. TCH can vary its utilization between medium and high utilization
factor, while the other channels remain in medium (RACH/PCH) or low (AGCH) congestion situations.
Blocking is assumed to be high in such a situation for all channels, except the AGCH, which reaches medium
values. High blocking is mainly caused by the redirection of users to the neighboring cells, but highly depends
on the characteristics of the area of the shortcoming.
The start time and date of the congestion event, as well as its duration, are unpredictable. In that way there
cannot be defined any time window and can be only roughly estimated based on previous statistical data. The
cells involved in the BSC Shortcoming congestion scenario are known in advance. This scenario applies to the
cells serving the surrounding area of the BSC out of order, meaning the cells on the border of the respective
BSC. When the respective BSC goes down, all the traffic is redirected to the neighboring cells. The following
table provides a characterization of the traffic typologies associated with the BSC Shortcoming events. The
results are extracted from the statistical analysis performed in D-2.1.
Table 12: Traffic breakdown during BSC Shortcoming
Combining the data provided above, we can produce the following characterization rule to capture the BSC
Shortcoming scenario.
START RULE: BSC Shortcoming
(Dimension = Medium)
(AGCH Util. = Low)
(SDCCH BR= High)
(TCH BR = High)
(Em. call = Low)
(CLC = Low)
Extra info
(Priority = 1)
END RULE
4.2.12 Catastrophes
After small/medium/large catastrophes like earthquakes, floods, volcanic eruptions, ecological disasters, an
increase of the traffic load is usually observed, due to emergency calls or simply calls to inquire after the safety
and health of relatives and friends. Also damages in the network could worsen the traffic status. The traffic is not

predictable. Some very rough statistical estimation can be made on the basis of the data collected in previous
similar events. The following observable parameters are described in the paragraphs below: channels subject to
All channels are affected in such a scenario. All channels increase to the highest level of utilization. TCH
receives the first congestion situation, followed by the SDCCH. When SDCCH gets highly congested, TCH
utilization degrades, as there cannot be any more TCH assignments (lack of setup resources). If the traffic load is
even bigger, the situation worsens, RACH and PCH overcome the highest level of utilization and the user has
practically no cell phone. Blocking in such a case will be high on all channels. These are the cases most likely
for the network to collapse, if the catastrophe is extended.
No start time or date can be predicted, as the event is totally unpredictable. As far as the duration is concerned, it
depends on the Dimension of the catastrophe and can be roughly predicted using previous statistical data. Thus,
no time window can be specified.
The cells involved in the Catastrophes congestion events are not predictable. Usually, this scenario applies to the
area where the catastrophe has taken place. Depending on the Dimension of the catastrophe, the affected cells
can be easily defined, as they will not behave normally. The following table provides a characterization of the
traffic typologies associated with Catastrophes scenario. The results are extracted from the statistical analysis
performed in D-2.1.
Table 13: Traffic breakdown during Catastrophes
Catastrophes scenario.
START RULE: Catastrophes
(Dimension = High)
(TCH Util. = High)
(PCH Util. = High)
(RACH Util. = High)
(AGCH Util. = High)
(SDCCH BR = High)
(TCH BR = High)
(Em. calls = High)
(CLC = High)
Extra info
(Priority = 2)
END RULE
4.2.13 Accidents
The accident scenario accounts for road accidents and queues, acts of terrorism and so on. When the accident
happens, involved people call not only emergency numbers, but also relatives and friends to inform about the
happening. At first the event is delimited in a restricted area, but can quickly spread out in adjacent areas – for
example, a road accident can block the traffic for many hours, causing queues and slowing down. The traffic is

not predictable. Some very rough statistical estimation can be made on the basis of the data collected in previous
similar events. The following observable parameters are described in the paragraphs below: channels subject to
The channels subject to congestion are mainly the TCH and the SDCCH. Both TCH and SDCCH utilization can
overcome 80% in such a case. The channel that first gets congested is the TCH, then the SDCCH. As far as the
other channels are concerned, both PCH and RACH climb on the medium congestion utilization factor, while
AGCH rests at the lowest level of congestion. TCH BR is expected to overcome the 10% threshold, while
SDCCH, PCH and RACH BRs are estimated in the medium blocking window. AGCH probably won’t encounter
any blocking problems.
No start time or date can be predicted, as the event is totally unpredictable. As far as the duration is concerned, it
depends on the Dimension of the accident and can be roughly predicted using previous statistical data. Thus, no
time window can be specified.
The cells involved in the accident congestion events are not predictable. Usually, this scenario applies to the area
where the accident has taken place. Depending on the Dimension of the accident, the affected cells can be easily
defined, as they will present extra traffic load. The following table provides a characterization of the traffic
typologies associated with Accidents scenario. The results are extracted from the statistical analysis performed in
D-2.1.
Table 14: Traffic breakdown during Accidents
Combining the data provided above, we can produce the following characterization rule to capture the Accidents
scenario.
START RULE: Accidents
(Dimension = Low)
(TCH Util. = High)
(AGCH Util. = Low)
(SDCCH BR = Medium)
(TCH BR = High)
(Em. calls = Medium/High)
(CLC = Low)
Extra info
(Priority = 2)
END RULE
4.2.14 Massive congestion scenario
The Massive congestion scenario is a very particular one, in that it happens only when the request of radio
resources reaches extremely high intensity. This is the case, for instance, when an outage causes some parts of

the cellular network to be not covered for a short period of time, and when the network comes up again, there is
a huge peak of signaling traffic generated by the mobiles that regain their access to the network.
Under these circumstances, the extremely high rate of requests may overload some channels (especially
signaling) up to the point that the resource utilization actually goes down because of the bottleneck effects. This
scenario can be uncovered by looking at the blocking rates and at the clear codes for the calls. Therefore, by
combining the information provided above, we can produce the following characterization rule to capture the
Massive congestion scenario.
START RULE: Massive congestion
(Dimension = Low/Medium/High)
(SDCCH Util. = Low)
(TCH Util. = Low)
(PCH Util. = Low)
(RACH Util. = Low)
(AGCH Util. = Low)
(SDCCH BR = High)
(TCH BR = High)
(Em. calls = Low)
(CLC = High)
Extra info
(Priority = 2)
END RULE

4.2.15 Conclusions
The correct identification of each of the scenarios presented in the above paragraphs is extremely important to
the success of the CAUTION system. The element responsible for this task (RMU respectively), based on the
characterization rules constructed above and the data collected from the ITMU, should take the right decision
and select the most appropriate scenario, for each occasion encountered by the cellular system.
It must be noted that each parameter is uniquely defined and each scenario can be also uniquely defined by a set
of parameters, as shown above. For better comprehension of the scenario recognition method, the following table
presents an overview of all scenarios and the values of the parameters for each one of them.
Table 15: Summary of traffic load scenario parameters
Parameter
Scenario
Priority Dimension SDDCH
TCH
.
PC
H
RACH AGCH
SDCCH
BR
TCH
BR
Em
calls
CLC
Busy Hour 0 H M/H H L L L M M L L
Tourist
Periods
0 H H H M M L M M L L
Bank
Holidays
1 H H H H H M H H L L
Sport Events 1 L H H H H M H H L L
Travel
Services
Strikes
1 L H H L L L H H L L
Religious/
Cultural
events
0 L H H M M M M M L L
Demonstrations 1 M/L H H H H M H H L L
Department
stores
0 L M M/H L L L M M L L
Planned
outages
0 L H M M M L H H L L
BTS
shortcoming
1 L H M M M L H H L L
BSC
shortcoming
1 M H M M M L H H L L
Catastrophes 2 H H H H H H H H H H
Accidents 2 L H H M M L M H M/H L
Massive
congestion
2 L L L L L L M H L H

5 RMU DESIGN
5.1 Introduction
The RMU is the core element of the CAUTION system by which resource management techniques are decided
and executed (through the OMC) after a detection of network congestion. The RMU receives alarms generated
by the ITMUs, which then trigger the RMU's reaction. According to the type of alarm, the RMU will generate
the proper reaction messages towards the OMC. A predicted scenario stored in the system’s internal database can
also trigger the RMU’s reaction. In this case the intervention of the RMU will lead to the prevention of the cell
traffic overload. After a RMT execution, the RMU shall monitor, through the ITMU, if the executed RMT
technique has brought the required results. The RMU will store log files indicating the applied RM technique
and the effects that the RMT has brought on the congested site. As a result, the RMU is able to learn by
experience, and can improve its effectiveness over time through a process that in the literature is called Case-
Based Reasoning. The information stored in the log-files will then influence the decision the RMU will take after
a trigger event (predicted event or ITMU alarm) as indicated in the next sections.
5.2 RMU logical functionalities
As shown in Figure 1, four modules compose the logical architecture of the CAUTION RMU:
• Traffic Load Scenario Recognizer
• Strategy Selector
• Strategy Actuator
• Knowledge Base Manager
In this high-level description, each of the four modules is representing one specific functionality of the RMU. As
we will see in the following, some of the functionalities will be concurrently executed in a multitasking
environment. Throughout this Section, we will not take into consideration the interleaving of RMU functions,
which will be explained in the following Sections.
The main purpose of the Traffic Load Scenario Recognizer (TLSR) is to identify the appropriate traffic load
scenario, whenever this is required, by analyzing the alarm messages coming from ITMU and by enquiring the
internal knowledge base. This module may require more information from the ITMU or from other ITMUs in
order to become more confident about the identified traffic load scenario. Predicted congestion events are
manually inserted in the internal knowledge base. Once a traffic load scenario (both predicted or unpredicted) is
detected, the TLSR shall convey the traffic load scenario parameters to the second module, which is the Strategy
Selector (SS).

Traffic load scenario
recognizer
identified
Strategy
Selector
Strategy
Actuator
RMU
ITMU
OMC
Knowledge
Base
Manager
Alarms
DB
PCSECS
Monitor
Command
manual input
Figure 10: RMU high-level logical architecture
The main purpose of the SS is to match the information coming from the TLSR with one or more Resource
Management Techniques that are supposed capable to a the alleviate the identified problem. In order to identify
and to fine-tune the RMT parameters, the SS may require to get more information from one or several ITMUs or
additionally it may enquire the DB in which previously applied RMTs with their corresponding results have been
stored. In this case the SS shall interact with the Knowledge Base Manager (KBM). As soon as some RMTs are
identified as suitable ones for the recognized TLS, the SS shall send command information (RMT parameters) to
the Strategy Actuator module (SA). SA shall send the command messages to the OMC. Once the RMT is
applied, the RMU shall monitor the overloaded cells in order to verify that the selected RMT was effective. If no
positive effects are obtained, it shall resort to another RMT, if possible. All RMU decisions and the consequent
results shall be recorded by the Knowledge Base Manager into its internal DB, which is used as a source of
information for the tuning over time of the RMU operation.
5.3 RMU high-level state diagrams
The RMU high-level state diagrams and the subsequent ones provide a further level of detail in the description of
the RMU’s operation. The first state diagram describes the TLSR, which manages the alarms received from the
ITMU, tries to identify the traffic load scenario and triggers the SS’s process. The SS is represented in the
second diagram. Taking into account the traffic load scenario identified, the SS performs the decision-making
step, which consists in the selection of the RMT to be applied and the choice of the proper values for the related
parameters. The other state diagrams illustrate the SA, which provides for actuation of the decisions taken by the
RMU, and the KBM, which is in charge of tracking the RMU activity, by accessing the internal DB. We shall
now describe the states of each RMU functionality, and the events that lead the RMU to a transition from one
state to another.
As shown in Figure 11, the TLSR leaves the “ready state” each time an alarm message is received from one or
more of the ITMUs or each time the KBM notifies the probable occurrence of a predicted event, manually and
previously inserted in the internal DB. In the former case, namely when an alarm is received from ITMU, TLSR
accesses the DB to check whether the alarm was due to a predicted event. This information, along with data

40803906 sdcch

Recommandé

Recommandé

Contenu connexe

Similaire à 40803906 sdcch

Similaire à 40803906 sdcch (20)

Dernier

Dernier (20)

40803906 sdcch