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

about characterization of traffic load scenarios is used in the “Identify Scenario” state, whose goal is the
identification of the traffic load scenario that matches the current congestion situation. The TLSR may also ask
further information to the ITMU that raised the alarm and/or to other ones. It is still possible that no scenario
matches the situation under classification, which is thence marked as ‘undefined scenario’ (UTLS). In the latter
case, namely when the alarms comes from the KBM, the TLSR communicates with the ITMU to tighten the
alarm thresholds related to the predicted congestion event. In this way, an alarm will be raised by the ITMU
before the traffic congestion would have gone really critical. Such a tightening of thresholds entails a sort of
preventive action.
Ask KB about
events predicted for
the present time
Alarm from
KBM
Ready Identify
Scenario
Get data from
ITMUs
Tighten ITMU
alarm thresholds
More info
needed
Identification
completed
Trigger SS
RMU start
ITMU
alarm
TLSR
Figure 11: TLSR state diagram
After the scenario has been identified, the TLSR activates the SS. The SS enters the ‘Evaluate strategies and
parameters’ state. To choose the most effective RMT for the particularly scenario and the parameters values to
be used, the SS exploits past experience by retrieving from the DB information about RMT previously applied in
similar cases. It may also need to get further data from ITMUs. After the RMT and the parameters values to be
used for the detected scenario have been selected, the SS asks the SA to provide for RMT activation, and then
get in the ‘Monitor ITMU’ state. After the execution of the RMT, the SS monitors the overloaded cells in order
to understand whether the applied RMT has obtained positive results. If not, the SS evaluates new strategies and
parameters. In this case the SS can change RMT or it can just re-tune the RMT parameters.
Evaluate strategies
and parameters
Get data from KB
and from ITMUs
Monitor
ITMU
More info needed
Start
End
KB write
command
TLSR trigger
TLSR trigger
Trigger
SA
success
unsuccess
SS
Evaluate strategies
and parameters
Get data from KB
and from ITMUs
Monitor
ITMU
More info needed
Start
End
KB write
command
TLSR trigger
TLSR trigger
Trigger
SA
success
unsuccess
SS
Evaluate strategies
and parameters
Get data from KB
and from ITMUs
Monitor
ITMU
More info needed
Start
End
KB write
command
TLSR trigger
TLSR trigger
Trigger
SA
success
unsuccess
SS
Figure 12: SS state diagram
Figure 13 depicts the Strategy Actuator (SA) module. It translates the RMT actuation request from the SS into a
set of commands that can be executed by the OMC. The RMT actuation may require updating user priority in the
PCS and maybe settings in the ECS, such as bandwidth reservation.

Prepare RM
commands
Ready
RMU start
SS trigger
Check
with ECS
Send data
to OMC
SA
Check
with PCS
Figure 13: SA state diagram
The KBM module, shown in Figure 14, handles the access to the knowledge base memory, which stores
information concerning scenario characterization, predicted events, past congestion events description along with
the adopted strategy and the result of its application. Furthermore, it allows an operator to initially insert in the
DB, for learning purposes, some cases of congestion and of methods to solve them; also, it will be possible to
modify scenario characterizations and thresholds value. The operator may also command the KBM to enter the
‘Analysis of past experience’ state, possibly when the traffic load is low and there are no predicted congestion
events. This state aims at evaluating past activity by performing statistical analysis on results obtained from the
selected strategies. If necessary, the KBM could warn the operator about the unsatisfactory effectiveness of some
of the applied RMT techniques.
Manual
learning
session
Ready
RMU start
SS request
KB write
KB search
SS requestoperator requests
Manage stored
data
KBM
operator requests
Generate alarm
for predicted
event
Figure 14: KBM state diagram

5.4 Traffic load scenario recognizer
Traffic load scenario recognizer (TLSR) is the module responsible for identifying the traffic load scenario that
best matches the values sent to the RMU through-inputs/alarms by the ITMU. Comparing these values with the
predicted congested events and with the traffic load scenario characterization rules, which are manually inserted
in the knowledge database, the TLSR will identify the most likely traffic load scenario. To minimize the
probability of error in the scenario identification process, the TLSR is capable to retrieve extra information from
other ITMUs when is needed. The result of the recognition is forwarded to the Strategy Selector (SS) module
that triggers the appropriate actions.
5.4.1 TLSR sub modules
TLSR can be split in the following three further sub modules of different functionality:
• COM module, in charge of the communication between external modules (mainly with ITMU, but also
with KBM). The major tasks are:
o Getting the information from the ITMU, filtering the message type and the utilization, require
information from adjacent cells
o Updating the KBM, and retrieving information from the KBM about: predefined event, traffic load
scenario characterization rules, cell capacity (for channel utilization, and blocking rate
calculations), new threshold for the ITMU module.
• EVENT PROFILER, in charge of creating the profile of an event by saving the results to the internal
database. Other important tasks are:
o Finding the scale of the event by clustering
o Collect the channel utilization of the congested cells
o Map alarmed cells to SS processes
• RECOGNIZER, in charge of performing the recognition step and to start the SS
o Triggers the SS for to start the treatment of an identified/unidentified congestion event
o Get the list of the scenarios for recognition from the KBM.
KBM
SS
KBM
COM MODULE
ITMU
EVENT
PROFILER
LOCAL PROFILER
DATABASE
RECOGNIZER
TIMER
TLSR MODULE
KBM
LOCAL COM
DATABASE
Figure 15: TLSR scheme

5.4.2 Inputs
The inputs described in this section define the connection format between the TLSR module, the ITMU and the
KBM module. The connection between the TLSR and the ITMU is based on the format of the alarms sent from
the ITMU to the TLSR.
The type of an alarm message can be one of the following: ALT, RXT, CLC, NCI and KBM. A field in the
message format specifies its type. The ALT type of alarm is sent by the ITMU when some channel utilization
overcomes the assigned ALT threshold value. An RXT type of alarm is sent by the ITMU to the TLSR when a
previously congested cell get over the overload and the utilization of the channels goes down the assigned RXT
threshold value. The CLC alarm type is sent by the ITMU when the percentage of abnormal call clear codes
exceed a predefined threshold value. In some cases, the TLSR will ask for information from the ITMU about
cells that are adjacent to a congested one, in order to identify the scale of the event. In this case, the ITMU will
reply to the TLSR request with an NCI (Neighbor Cell Information) type of alarm. Information received through
NCI alarms on cell resource utilization is used by the TLSR to ascertain whether the cell is congested or not.
This is done by comparing thresholds with the values of the utilization of the channels as described in the ITMU
chapter. The other fields of an alarm store the cell identifier, the time and date indicators, and detailed
information about the percentage of the utilization, as listed in the table below.
Table 16: Alarms to TLSR from ITMU
Input to TLSR from ITMU Name
Identifiers of the overloaded cell CELL_ID
Message type ALT, RTX, CLC, NCI
Time indicator TIME
Date indicator DATE
SACCH utilization SECCH_UT
Emergency calls EC_NO
Number of not-normal clear codes CLC_NO
The KBM alarm type, which is sent from the KBM, has a different format. Indeed, its purpose is to inform the
TLSR that some predicted event is going to happen, and therefore the ITMU thresholds value in some cell have
to be reduced. Therefore the format is as follow.
Table 17: Alarms to TLSR from KBM
Input to TLSR from KBM Name
Identifiers of the risky cell CELL_ID
Message type KBM
Duration DURATION

TCH New Thresholds TCH_TH
SDCCH New Thresholds SDCCH_TH
SACCH New Thresholds SACCH_TH
PCH New Thresholds PCH_TH
AGCH New Thresholds AGCH_TH
RACH New Thresholds RACH_TH
A different type of information is sent form the KBM under request of the TLSR. Specifically, when the TLSR
receives an ALT type of alarm for a cell from the ITMU, it checks with KBM whether a predicted event is
foreseen for the current time at that specific cell. The TLSR will receive from the KBM the answer to its query
according to the format shown in the following table.
Table 18: Input to TLSR from KBM
Input to TLSR from KBM Name
Match found YES/NO
Predicted event identifier PRE_EV_ID1
Predicted event schedule PRE_EV_SCH_IND1
Predicted Traffic Load Scenario identifier PRE_TLS_ID1
The TLSR will also receive input from the SS processes, when they terminate their execution. Each SS process
communicates with the TLSR according to the following format.
Table 19: Input to TLSR from SS
Input to TLSR from SS Name
SS Identifier SS_ID
Termination indication TERM_IND
5.4.3 Processing
The TLSR processes alarms from ITMU about congested cells and, when needed, requests additional
information, in order to identify the specific traffic-load scenario the present congestion event belongs to. In the
following sections, we describe the logical flow applied in the procedure for estimation of the event-scale as well
as the matching procedure.
5.4.3.1 Clustering
The clustering task of the TLSR determines the scale of a congestion event by grouping cells that are
geographically adjacent and involved in the same traffic load scenario. The approach followed starts matching a
single congested cell into one traffic load scenario. Then neighbor cells are checked to determine whether they
1
Only if Match found is YES

are also congested and belong to the same scenario. This process is repeated until no more adjacent cell can be
added to the cluster.
Busy
Hour
Accident
Figure 16: Event Clustering
5.4.3.2 Logic flow
The TLSR module is divided into three sub modules. The TLSR is always in READY/START mode, where it
waits to be triggered either from the ITMU module or the KBM module. Thus, when an alarm is received, the
first the task is to determine its type. Five different types are possible: the first four of them are transmitted from
the ITMU (ALT, RXT, NCI and CLC) and the fifth one from the KBM. Consequently, there are five cases in the
operation of the TLSR:
1. Alarm type: ALT: the ITMU has sent an alarm to indicate that there is a congested cell. The TLSR
checks whether there is a predicted event for that cell. If this happens then the scenario is known for
that event and both are stored in the LOCAL EVENT PROFILER DATABASE, for further processing.
If the ALT alarm is not matched with a predicted event, then TLSR stores the EVENT_ID and all the
information concerning the congested cell. After that, the TLSR accesses the KBM Database to get the
list of adjacent cells for the congested cell. Information on cell id of the adjacent cells is needed to find
the scale of the event by clustering. It is possible that one congested cell is clustered with a set of cells
for which the RMU is already taking some corrective actions, i.e. an active SS process exists, which is
dealing with those cells. In this case, the TLSR will simply inform that SS process that the new cell has
to be added to the list of cells it is always treating. The information about the mapping between
congested cells and SS processes is retrieved in the LOCAL EVENT PROFILER DATABASE.
2. Alarm type: CLC. The use of the clear codes allows detecting congestion event in the network even if
the channel utilizations are below the ITMU thresholds. Usually, the clear codes show that there is a
problem not in the TCH but in the SDCCH channel, thus the proper actions should be undertaken.
Certain scenarios are allocated for that type of event, thus when the TLSR is triggered then the event
and the predefined scenario will be stored in the local database as before in the ALT type alarm. The
process is handled in the same way as before, that is by accessing the KBM database to get the list of
the adjacent cells.
3. Alarm type: NCI. When the list of the adjacent cells has been obtained from the KBM, then in order to
define the scale of the event, the TLSR communicates with the ITMU to get more feedback on the
condition of the adjacent cells. The incoming information from ITMU is received through an NCI
alarm. Hence, if an adjacent cell is congested, then that cell id and rest information is stored and search
for the event scale continues to the next adjacent cell in the list. Otherwise, if it is not a congested cell it
just skips that cell and continues with the next in the list.
4. Alarm type: KBM. In the case of the KBM alarm, the KBM informs the TLSR that there is a predefined
event and the ITMU thresholds should be updated with the new ones provided by the KBM Database.

5. Alarm type: RXT. The aim of this alarm is to indicate to the TLSR when the congestion is terminated.
When the channel utilizations falls below the RXT thresholds, the ITMU notifies the TLSR and the
TLSR notify the SS for event termination.
The output file from the EVENT PROFILER for every event is as follows:
• Event id
• Predefined Scenario
• Scale
• Date stamp
• Time stamp
• Congested cells
• Channel Utilization
• Blocking Rate
• Traffic Tape
• Clear Code
Using the output file from the EVENT PROFILER, the recognizer starts the matching procedure by comparing
cell utilizations against the ones that characterize the predefined scenarios inserted from the KBM.
Finally, after every output to the SS module or to the ITMU module for updating with the new threshold values,
the TLSR operation returns to the READY/START condition.

FINISH
YES
NO
START
ALT
RXT
KBM
YES
NO
NCI
YES
COM MODULE
PREDICTED
CONGESTED
ALARM
OUTPUT TO
ITMU tighten
thresholds
OUTPUT TO
ITMU get info on
adjacent cell
STORE
PREDICTED
EVENT
STORE
EVENT ID &
THE
CONGESTED
CELL
CREATE AN
OUTPUT WITH
CONGESTED
CELLS
TLS
MATCH
OUTPUT TO SS
close event
OUTPUT TO SS
with UTLS
OUTPUT TO SS
with known
scenario
EVENT
PROFILER
RECOGNIZER
YES
YES
READ NEXT
ADJACENT
CELL IN THE
LIST
NO
PREDICTED
EVENT
NO
MATCHES
EXPECTED
EVENT
NO
YES
NO
CLC
Figure 17: TLSR processing

5.4.3.2.1 Matching procedure
The matching procedure depicted in Figure 18 describes a method to match the observed event with one
scenario. The scenario’s characterization rule, as described in the previous chapter, defines intervals for the
parameters, which have been calculated from measured data. It is easy to exploit such definition of a traffic load
scenario to define a decisional tree that, starting from the root, at each level discriminates on the values of one
specific parameter, till it reaches a leaf that is uniquely associated to one traffic load scenario. It’s worth notice
that, in the recognition procedure, the scale of the event is considered in a different moment, since it is defined
after looking at the result of the matching of all the others features for each cell in the same geographic cluster.
ROOT
HML
HML HML HML
PARAMETER 1
PARAMETER 2
PARAMETER X
.
.
.
.
.
.
.
.
.
SCENARIO 1 UTLS SCENARIO X
Figure 18: Traffic load scenario matching process
The match procedure will receive in input the parameters of one cell. At the very beginning of the matching,
each traffic load scenario is a potential candidate for the match. Starting from the root, the matching process
compares the first parameter value with the characterization rule of each traffic load scenario. The comparison
will result in the elimination of some traffic load scenario from the list of potential matches. The second step will
do the same with the second parameter, thus eliminating some more traffic load scenario, and this goes on until
the last parameter. The result could be either one specific scenario among those defined in the previous section,
i.e. successful match, or it could be a path that ends to Unidentified Traffic Load Scenarios (UTLS). Notice that,
it is possible to have more than one path on the tree leading to the same scenario.
Other techniques were taken into account for pattern matching. Neural networks and fuzzy logic can result in
accurate scenario identification. Moreover, Hidden Markov Chains can be used [2], in order to compare the
observation sequences (set of parameters reported by the ITMU), in a way to find the actual state. Each state will
be described by the λ-parameter, which is the combination of π, a, b. The Hidden Markov Chain will be the
result of a training based on statistical parameters collected in the first part of the project. In this way, the
alternation of system-states and the probability of changing from state_1 to state_2 will then be controlled by the
transition probability aij.
An important reason for not selecting one of the above-mentioned techniques (neural networks, fuzzy logic,
HMM) is the fact that CAUTION system should be implemented in such a way to achieve fast response and
avoid excessively time-consuming algorithms. Moreover, the traffic load scenarios can be distinguished by
means of ranges of the parameters and not from exact numbers. The statistical evaluation has shown that the
same event (e.g. football match) has most of the times similar parameter values, but not exactly the same.
Therefore, congestion is more easily characterized by intervals, as for instance: low-scale, medium-scale, or
large-scale. Hence, an easy and very effective easiest approach is to construct a simple tree-based matching as
we have already discussed. This approach offers the advantage of being scalable. If new traffic-load scenarios

are to be added, the tree can be very easily extended. The same argument applies if a new parameter is added to
the characterization rule of scenarios.
5.4.3.3 Local data
The TLSR uses two separate databases for its operation. One is used by the COM sub-module and the other one
by the EVENT PROFILER sub-module.
5.4.3.3.1 Local COM Database
The Local COM Database is used when the COM module is accessing the KBM Database. The reason for that is,
when the COM module gets the thresholds for a particular ITMU, and this is happening when there is the need
for finding the scale of an event. Utilization values from the adjacent cells are compared with the stored
thresholds. The reason of having such an internal database is for access time reduction, instead of having the
COM module accessing the KBM Database whenever comparisons are required it is accessing it’s own local
database.
5.4.3.3.2 Local Profiler Database
In the same way, the Local Profiler Database is used for two reasons. The first one is to enquire from the KBM
the list of adjacent cells when a congested cell is reported. It keeps track also of the adjacent cells that have been
tested for congestion and which are remaining. The other use is to store all the different events that are reported.
As the ITMU will report for different congested cells, these may belong into different events. Hence, the
EVENT POFILER should be in charge for storing each event’s profile separately in a local database.
5.4.3.4 Shared data
Distinguishing between the local and the shared data, the shared data belong to the KBM Database in the KBM
module. In addition, the COM module is communicating with the KBM Database for information about the
cell’s capacity. The capacity may be dynamically changed either manually from the operators, or through the
application of the appropriate management techniques. Cell capacity information is also needed for the SS
module for a better understanding of the condition of the network in order to choose the appropriate management
technique.
In the same way, the EVENT RPOFILER accesses the KBM Database for the cell mapping in order to find the
list of the adjacent cells, which are also needed for the SS module, when communicating with the ITMU to
retrieve information about the neighbor cells’ utilizations.
The last shared data is concerned with the scenario database and with the updating of the history from the SS
point of view. The history contains information about the event id, scenario id, congested cells, utilizations, date
and time stamps, but also the applied management technique. The role of the history is for the self-training part
of the TLSR to distinguish between similar events and apply the same technique without further time consuming
pattern matching process.

5.4.3.5 Interrupts and signals
According to the structure of flow diagram the interrupts and signals of the TLSR module is mainly concerned at
the beginning of the process. In READY/START state the process waits to be triggered either from the ITMU or
the KBM modules. Note should be given that all the processes are asynchronous. In case there is an interrupt
from the KBM for tightening the thresholds while comparing utilization values of adjacent cells the process
finishes with the current comparisons, stores the new values, sends the new values to the ITMU module and
continues the process with the new thresholds.
5.4.3.6 Error handling
The error handling mainly is concerned with the connection between the ITMU and the TLSR. In case the TLSR
sends requests for further information on adjacent cells, a timer counts the delay to respond the ITMU with the
NCI type message. After a certain time out the TLSR continues with the rest of the adjacent list and when it
finishes it checks again the problematic adjacent cell report. If the problem persists then a log error is reported:
NCI RT 129 (Neighbor Cell Indicator Round Trip 129-cell id). The rest of the process continues with one less
cell of the event’s scale.
For the connection also between the ITMU and the TLSR, if there has been a time interval that the ITMU has not
reported anything, that might be because either the network is fully optimized or there is problem in the
connection. To define the situation the TLSR sends a random adjacent cell request.
The COM module also maps the first congested cell with the IP of the ITMU, thus when the EVENT
PROFILER needs to retrieve information about the neighbor cells the output is assigned with the event id for
mapping the adjacent cell with the event. In case the ITMU sends an ALT alarm for a congested cell, and the
TLSR before collecting that ALT alarm sends a request for a NCI message to the ITMU, the TLSR holds a flag
waiting for information about that particular cell.
Finally, because of the limited space of threads within the EVENT PROFILER and the storage space of the
LOCAL PROFILER Database, when these modules are close to their limits the connection between the COM
module and the EVENT PROFILER will be closed until the processing capabilities of that module and the
storage of the database returns to acceptable conditions.
Furthermore, in critical conditions where the amount of incoming data will be far away from the limitations of
the system, while all the ITMUs will send enormous amount of data, the COM module should be responsible to
enter in collection mode where it will partially obtain the data from each ITMU.
5.4.4 Outputs
The following outputs will be created from the TLSR towards:
• SS, to obtain the required information about the congested cells, which defines an event and the
specified utilization on which the SS will be based upon to select the appropriate resource management
technique. Moreover, with the same type of output, the TLSR may ask an SS process to add one more
congested cell to the set the process is always dealing with. When the input from the ITMU is an RTX
then the output to the SS is to undo the applied technique. The format of the exchanged messages is
shown in the following tables.
Table 20: Output Event Profile
Output from TLSR to SS Name
Event Identifier EVENT_ID
Traffic Load Scenario Identifier TLS_ID

Identifiers of the overloaded cells CELL_ID1, CELL_ID_2, ...,
CELL_IDn
TCH occupation (for each Cell_id) TCH_CELL_IDX_IND
SDCCH (for each Cell_id) SDCCH_CELL_IDX_IND
SACCH (for each Cell_id) SACCH_CELL_IDX_IND
PCH (for each Cell_id) PCH_CELL_IDX_IND
AGCH (for each Cell_id) AGCH_CELL_IDX_IND
RACH (for each Cell_id) RACH_CELL_IDX_IND
Time indicator TIME_IND
Date indicator DATE_IND
Table 21: RXT release command
Output from TLSR to SS Name
Identifier of the event EVENT_ID
Identifiers of the overloaded cells CELL_ID
• ITMU, to get more information about the condition of the adjacent cells of a congested cell. The TLSR
indicator shows that the current demand is from the TLSR and not from the SS. This is in case when
there is only one communication between the RMU and the ITMU.
Table 22: Request for NCI
Output from TLSR to ITMU Name
TLSR indicator TLSR_ID
Cell identifier CELL_ID
On the other hand, if the output to the ITMU from the TLSR is triggered from the KBM in order to
tighten the thresholds, then the format is shown in the following table.
Table 23: Tightening of the thresholds
Output from TLSR to ITMU Name
Cell identifier predicted CELL_ID
Duration DURATION
TCH New Thresholds TCH_TH
SDCCH New Thresholds SDCCH_TH

SACCH New Thresholds SACCH_TH
PCH New Thresholds PCH_TH
AGCH New Thresholds AGCH_TH
RACH New Thresholds RACH_TH

5.5 Strategy selector
The Strategy Selector module (SS) is responsible to select the RMT and RMT parameters to manage the traffic
load scenario it has been associated to. The SS is a SW process spawned by the TLSR. The TLSR creates one
distinct SS for each identified scenario.
5.5.1 Inputs
The SS module receives from the TLSR information about the scenario, the identifiers of the overloaded cells
and all the traffic load parameters in the overloaded cells as summarized in the following table.
Table 24: Input to the SS from TLSR
Inputs to SS from TLSR Name
Identifiers of the overloaded cells CELL_ID1, …, CELL_IDn
For each Cell: TCH utilization TCH_CELL_IDX_IND
SDCCH utilization SDCCH_CELL_IDX_IND
SACCH utilization SACCH_CELL_IDX_IND
PCH utilization PCH_CELL_IDX_IND
AGCH utilization AGCH_CELL_IDX_IND
RACH utilization RACH_CELL_IDX_IND
TCH blocking rate TCH_BR_CELL_IDX_IND
SDCCH blocking rate SDCCH_BR_CELL_IDX_IND
Emergency calls EC_NO_CELL_IDX_IND
Number of not-normal clear codes CLC_NO_CELL_IDX_IND
Time indicator TIME_IND
Date indicator DATE_IND
In case that TLSR receives an RXT report from the ITMU, the SS is informed with the following format:
Table 25: TLSR-report in case of RXT
Inputs to SS from TLSR Name
Identifier of the event EVENT_ID
Identifiers of the overloaded cells CELL_ID1, CELL_ID2, ... , CELL_IDn

Moreover, the SS module receives from the KBM data related to previously managed congestions event, which
are stored in a cases library, and other data needed to select the RMT that better fits the present situation. The
following table lists the input parameters exchanged from the KBM to the SS.
Table 26: Input to the SS from KBM
Inputs to SS from KBM: a retrieved case Name
Case ID CASE_ID
Event ID EVENT_ID
Case number CASE_NUM
Time indication TIME_IND
Date indication DATE_IND
Number of overloaded cells NUM_CELLS
TCH average utilization TCH_AVR_UT
SDCCH average utilization SDCCH_AVR_UT
SACCH average utilization SACCH_AVR_UT
PCH average utilization PCH_AVR_UT
AGCH average utilization AGCH_AVR_UT
RACH average utilization RACH_AVR_UT
TCH average blocking rate TCH_AVR_BR
SDCCH average blocking rate SDCCH_AVR_BR
Average percentage of emergency call attempts EM_CALLS_AVR
Average percentage of not-normal clear-codes NN_CLC_AVR
Applied strategy ST_ID
Result of strategy application ST_RES
Event Duration EV_DURATION
Number of reuse of case NUM_REUSE
Number of success when reused NUM_SUCCESS
For each cell: cell ID CELL_ID
TCH utilization TCH_CELL_ID_UT
SDCCH utilization SDCCH_CELL_ID_UT
SACCH utilization SACCH_CELL_ID_UT
PCH utilization PCH_CELL_ID_UT
AGCH utilization AGCH_CELL_ID_UT
RACH utilization RACH_CELL_ID_UT
TCH blocking rate TCH_CELL_ID_BR

SDCCH blocking rate SDCCH_CELL_ID_BR
Percentage of emergency call attempts EM_CALLS_CELL_ID
Percentage of not-normal clear-codes NN_CLC_CELL_ID
Applied parameters ST_PAR1_CELL_ID, …,
ST_PARm_CELL_ID
Strategy list associated to a specific TLS
List of associated strategies, in order of preference ST1, ST2, …, STk
Information about network resources
ID of neighbors cells, for a specific BTS BTS_ID
Standard resources allocation PRES_ALLOC_BTS_ID
Table 27: Input to the SS from KBM
Inputs to SS from KBM Name
Event identifier EVENT_ID
Case number CASE_N
Applied strategy identifier APPST_ID
Strategy parameter 1 STPAR_1_IND
Strategy parameter 2 STPAR_2_IND
Strategy parameter n STPAR_n_IND
The SS may ask more information from ITMU. The following table lists the input parameters exchanged from
ITMU to SS.
Table 28: Input to the SS from ITMU
Inputs to SS from ITMU Name
Cell Identifier CELL_ID
TCH utilization TCH_CELL_IDX_IND
SDCCH utilization SDCCH_CELL_IDX_IND
SACCH utilization SACCH_CELL_IDX_IND
PCH utilization PCH_CELL_IDX_IND
AGCH utilization AGCH_CELL_IDX_IND
RACH utilization RACH_CELL_IDX_IND
TCH blocking rate TCH_BR_CELL_IDX_IND
SDCCH blocking rate SDCCH_BR_CELL_IDX_IND
Emergency calls EC_NO_CELL_IDX_IND

After the TLSR receives an RXT report from the ITMU, it informs the SS that the congestion event is
terminated, in order to restore the default cell configuration values.
Table 29: Termination from TLSR to SS
Input from TLSR to SS Name
Identifiers of the overloaded cells Cell_id1, Cell_id2, ...,
Cell_idn
Finally, the SS is informed from the SA about the management technique that is applied from one of the
dominant CAUTION elements, namely ECS and PCS. This is done in order to coordinate the RMU modules and
avoid redundant processing.
Table 30: Input from SA after interaction with ECS /PCS
Input to SS from SA Name
Cell managed by ECS/PCS CELL_ID
RMT applied by ECS/PCS RMT_ID
RMT parameters selected by ECS/PCS RMT_PAR
5.5.2 Processing
The SS flow chart is shown in Figure 19. In order to choose the RMT that best fits the specific scenario and the
parameters values to be used, an SS process is created for each identified congestion event. SS may exploit past
experience by retrieving from the DB some information about previously RMT that was applied in similar cases.
A CBR approach is used to retrieve in the DB similar cases that were previously and successfully managed. The
KBM module manages the CBR procedure and it will be detailed in Section 5.7.
Once the TLSR has identified the scenario, the CBR algorithm will search a similar case by considering only the
stored cases belonging to that specific traffic load scenario. If the TLSR was not able to identify the scenario and
so it results to be an undefined one, the SS asks the KBM module to apply a CBR algorithm looking at the whole
set of previously managed cases.
The similarity between the current observed situation and the cases stored in the DB will be assessed according
to a function that weights the similarities of the key features of the congestion event. If a similar case is found in
the DB, the SS will adopt the same RM strategy, whose previous application successfully solved the congestion
event.
If the CBR algorithm did not find any similar case in the DB, the action undertaken by SS depends on whether
the scenario is known or not. If the scenario is known, the SS is assigned the list of the RMTs proposed by the
operator for that kind of scenario and adopts the first RMT in that list. If the scenario is unknown, the SS adopts
the default list, which contains only the default RMT; such default RMT shall be designed for solving overloads
on a cell-by-cell basis.
In general, parameters of the chosen RMT need to be adjusted to better fit to the new situation. Hereafter, this
adjustment procedure will be referred to as the fine-tuning of RMT parameters, which will be on the fly
computed through a model-based optimization (see Section 5.5.2.1). Notice that, for a proper selection of RMT
parameters, it may be necessary to gather additional information (from ITMU) about the status of neighbor cells.

Once the RMT and the associated parameters have been chosen, the RMU actuates the RMT and goes to monitor
the network through the ITMU to understand whether the applied strategy is having positive results or not. If the
application of the RMT produces positive results, the monitoring procedure is terminated only when the TLSR
indicates that the RXT thresholds in the ITMU are reached. When RXT thresholds are reached the SS will
command the KBM for updating the information associated to the existing case and will ask the SA to restore the
initial network configuration parameters. After that the SS terminates.
If the application of the RMT doesn’t produce positive results another RMT is selected: the SS commands the
KBM to update the DB with unsuccessful result indication and then looks for the next strategy in the list of the
strategies proposed by the operator. If the SS was already using the last strategy in that list (the last strategy in
every list is the default strategy), an Alarm is raised toward the network operator and the SS asks the SA to
restore the initial network configuration parameters without saving a new case. Before terminating the SS then
notify its failure to the TLSR.
In case the TLSR recognizes that a new cell should be added to the scenario managed by an already on going SS,
or if TLSR classify the present congestion event as a different scenario, a “kill” interrupt is sent to the SS: before
terminating, the current SS will command the KBM to update the information associated to the existing case.
The way the new case has been managed, along with the obtained result (negative or positive), is always tracked
in a log file and some counters used for statistics are updated. Moreover, is the new case has been successfully
managed, it is added to the Case Base for future reuse.
Process
killed
Scenario
known?
Send data to
KBMm for CBR
retrieval on
specific scenario
Found
similar?
no
(UTSL)
no Use default
List
yes
yes
no
yes
Optimize
Strategy
parameters
Send Strategy
parameters to the
Actuator
Send data to
KBM for CBR
retrieval onto all
DB cases
Take Strategy of
the similar case
More info needed
from other ITMUs
Monitor Strategy
effectiveness
Positive
impact?
Critical situation
ended (RXT alarm)
yes
no
Send data to
KBMm for DB
update
KBMm
update
Ask the actuator for
restoring initial network
configuration parameters
to the Actuator
start
stop
Is it
UTLS?
yes
no
Consider first
Strategy
proposed by
operator list
Last
Strategy?
Choose next
Strategy
available
Add cell
or scenario changed
TLSR
Raise Alarm
Figure 19: Strategy selector flow chart
5.5.2.1 Model-based fine tuning
Once an RMT has been chosen to deal with an identified scenario, a model-based approach will be used to
perform the fine-tuning of RMT parameters. The list of parameters to be set, the affected cells and the
constraints to be considered depend on the specific RMT, so for each RMT a different model has to be devised.
Several resource management techniques will be taken into account within the CAUTION project to achieve an

increased network capacity [1]. To better describe our fine-tuning approach we divided those RMTs into two
classes:
• Local impact RMTs: consisting of RMTs whose application on a specific cell has a negligible effect on
adjacent cells (for instance, techniques that modify the channel allocation).
• Global impact RMTs: consisting of RMTs whose application on a specific cell causes a traffic variation
on adjacent cells (for instance, cell resizing with the use of C values, forced handover).
In the first case, a Petri Net model can be applied to determine, cell by cell, the suitable choice of parameters. In
the second case, since the fine-tuning of RMT parameters of a given cell can’t leave out of consideration the
traffic situation of adjacent cells, an optimization model that considers the whole congestion situation will be
applied.
As an example, we will present a model for both a technique belonging to the first class and a technique
belonging to the second one.
5.5.2.1.1 An optimization model for the dynamic SDCCH allocation technique
Suppose that the dynamic SDCCH allocation technique has been selected as a solution for alleviating the
congestion in a set of congested cells },,1{ nC Κ= . Since any modification in the assignment of logical
channels can be decided on a cell basis, we can separate the problem and perform a local optimization.
In the dynamic SDCCH allocation, the mapping between logical channels and physical channels is varied so that
the amount of channels used for signaling (SDCCHs) is increased at the expenses of traffic channels (TCHs).
Each timeslot in a TCH can be reallocated for the purposes of signaling and used as an SDCCH. The problem of
devising the optimal number of additional SDCCH obviously depends on the amount of traffic Ti (expressed for
instance in Erlang) at the specific cell, and must take into consideration the balance between the decrease in the
SDCCH utilization and the increase in the utilization of TCHs.
The Petri Net model shown in the following Figure can be used to estimate the proper allocation of channels.
The traffic Ti at the cell i can be converted into an equivalent arrival rate, which is assigned to transition arrival.
Firing of transition arrival models the request for a user to establish a call, and generates a token that is put in the
output place. At this point, the call can be either granted an SDCCH or blocked, depending on the availability of
SDCCH and TCH channels. Blocked calls are lost. Calls that get one SDCCH complete the setup and reach the
TCH granting phase. After the call termination, the TCH is released.
SDCCH pool TCH pool
arrival SDCCH grant
block
TCH grant
SDCCH release TCH release
Figure 20: Petri Net model for evaluating channel allocation
The model can be off-line solved with a Petri Net tools to devise the allocation of SDCCH and TCH channels
that minimizes the blocking factor. The obtained results can be conveniently stored in a lookup table and used at
run time to obtain the SDCCH allocation for the current cell traffic situation.

5.5.2.1.2 An optimization model for the cell resizing technique
Assume the cell resizing RMT with the use of C values has been chosen for a previously identified Traffic Load
Scenario (TLS). The fine-tuning aims at determining how much the radius of each congested cell can be reduced
in order to move part of the cell traffic to adjacent cells.
Consider the bipartite graph G=( )( ACC ∪∪ , E) in Figure 21, where },,1{ nC Κ= is a cluster of congested
cells, },,1{ mA Κ= is the set of cells adjacent to congested ones, while E is the set of arcs. Notice cells in A
are not congested. An arc (i,j) belongs to E if i and j are adjacent cells. For each cell i in AC ∪ the figures Ti,
Ti
opt
, and Ti
max
represent its current amount of traffic, optimum amount of traffic and theoretic capacity (in
Erlang). Since a congested cell i∈C has traffic overload, for that cell
max
ii
opt
i TTT ≤≤ . An adjacent cell i∈A
has a residual traffic capacity, so
opt
ii TT ≤≤0 . The purpose of the cell resizing technique is to move part of
the traffic of congested cells to adjacent cells that are not overloaded.
T - Ti i
opt
T - Tj j
opt
Congested
Cells
Adjacent
Cells
Figure 21: Cell resizing graph
Let xij be the amount of traffic moved from i to j, for each (ij) ∈ E. The traffic reallocation is subject to the
following constraints:
AiTTx
CiTTx
i
opt
i
Eijj
ji
opt
ii
Ejij
ij
∈∀−≤
∈∀−≤
∑
∑
∈
∈
,
,
),(:
),(:
The first constraint states that the amount of traffic to be moved from i to its adjacent cells is at most
opt
ii TT − ;
the second constraint states that the amount of traffic that can be absorbed by a non congested adjacent cell can’t
exceed its residual capacity.
The resizing technique achieves the traffic reallocation by a radius reduction. Under the assumption that users
are uniformly distributed within the cell, a radius reduction implies an equal amount of traffic is moved to each
adjacent cell. To express this situation, we impose the equality of traffic movement from a congested cell i to all
its adjacent cells as follows:
EkijikjCixx ikij ∈∀∈∀= ),(),,(:,,,
Moreover, to have a feasible problem, no limit has been imposed on the amount of traffic that can be absorbed
by congested cells. Actually, any movement to congested cells corresponds to a loss of users, since these cell
have exceeded their capacity. The objective function should penalize this of leaks users. We propose to
maximize the difference between the amount of traffic successfully moved to non-congested cells and the
amount of traffic moved to congested cells.
The final linear programming model is as follows:

Ejix
Ekijixx
AiTTx
CiTTx
ts
xx
ij
ikij
i
opt
i
Eijj
ji
opt
ii
Ejij
ij
Ci Aj Cj
ijij
∈∀≥
∈∀=
∈∀−≤
∈∀−≤








−
∑
∑
∑ ∑ ∑
∈
∈
∈ ∈ ∈
),(0
),(),,(,
,
,
..
max
),(:
),(:
The model needs to be solved on-line at run time, for the specific set of cells involved in the congestion scenario.
Well known polynomial time algorithm exist to this goal.
The error handling is mainly concerned with the connection between the ITMU and the SS. In case the SS sends
to the ITMU a request for further information on adjacent cells, a timer is set. If timer has expired without the
arrival of the reply message from ITMU, then an error is both reported in a log file and displayed. The
processing continues as if that cell was near to congestion. In case the SS sends to the ITMU an info request for
monitoring purposes and the answer is not received before timer expiration, SS both reports an error in a log file
and displays an error message.
5.5.3 Outputs
The SS will indicate the SA the RMTs to be actuated and the related RMT parameters values. Moreover, it will
provide to the KBM the relevant information to be stored in the DB about the present case. The SS also interacts
with one or more ITMUs. All the output parameters are shown in the following tables.
Table 31: Output parameters to the SA from SS
Outputs to SA from SS Name
RMT Identifier (for each cell) RMT_ID_CELL_ID
RMT parameter 1 (for each cell) RMT1_IND_CELL_ID
RMT parameter 2 (for each cell) RMT2_IND _CELL_ID
RMT parameter x (for each cell) RMTx__IND CELL_ID

Table 32: Output parameters to the KBM from SS
Outputs to KBM for Case Base update (a case) Name
Case ID CASE_ID
Event ID EVENT_ID
For each cell1
: cell ID CELL_ID
1
Note that the channels utilization and applied parameters for each cell are sent to the KBM only for predictable
scenarios involving few cells

ST_PARm_CELL_ID
Data sent to KBM for CBR matching
Data about current resources allocation
For each involved BTS: BTS ID BTS_ID
Present resources allocation PRES_ALLOC_BTS_ID

Table 33: Output parameters to the ITMU from SS
Outputs to ITMU from SS Name
Identifiers of the cells to be monitored CELL_ID
Start monitor indicator (for each cell) SM_IND_CELL_ID
End monitor indicator (for each cell) EM_IND_CELL_ID
Table 34: Output parameters to the TLSR from SS
Outputs to TLSR from SS Name
SS identifier SS_ID
Termination indication TER_IND

5.6 Strategy Actuator
The Strategy Actuator (SA) is the module responsible for the execution of the RMTs that are selected in a
previous stage of the RMU processing. The SS, following decision making mechanisms and retrieving data from
the DB, takes an initial decision for the RMT that should be applied for each congested cell. The SA should
receive the information about the selected RMTs and translates this into the appropriate commands that can be
transferred and executed at the OMC. It is also possible that the SA receives commands from other CAUTION
system components, namely PCS and ECS. In this case, the command execution is not based on knowledge
management mechanisms, but on a manual decision of the operator. The decisions of the operator are given the
highest priority, so the SA filters the SS commands that violate the ECS/PCS decisions. In order to avoid
conflicts with the rest of the software modules of the RMU, SA should inform the SS about the cell that is
currently managed by the PCS/ECS and give additional details in order to restart those SS processes that may
have taken decisions that violate the ECS/PCS choices.
5.6.1 Inputs
The SA receives input data from SS, PCS and ECS. SS transmits to the SA serial information about the RMTs
that should be applied to the target cells to cope with traffic overload. Moreover, the SA may receive commands
from both PCS and ECS. As mentioned in the previous chapters, PCS and ECS are two elements that have
respectively the task to enable a manual change of the subscribers’ priority status and to reserve resources for
emergency calls. Actually, these two external elements process the data differently from RMU, but send to the
SA the same commands as the SS does. The input data are specified in Table 35 and subsequent ones.
Table 35: Input parameters to the SA from SS
Outputs to SA from SS Name
RMT Identifier (for each cell) RMT_ID_CELL_ID
RMT parameter x (for each cell) RMTx_IND CELL_ID
Table 36: Input parameters to the SA from ECS
Inputs to SA from ECS Name
RMT Identifier RMT_ID
RMT parameter 1 RMT1

RMT parameter x RMTx
RMt Identifier RMT_ID
Normal mode REL
Table 37: Input parameters to the SA from PCS
Inputs to SA from PCS Name
RMT parameter x RMTx
RMt Identifier RMT_ID
Normal mode REL
Although the commands from SS, ECS and PCS will be the same, they will be transferred in another way. The
reason is that SS and SA are two software modules in the same element, while ECS and PCS are external
elements. ECS and PCS will use XML structures to submit the commands. The low level specification of the
exchanged messages is described in section 5.9.2. In any case, the SA should also include a parser that will get
the transmitted information from the XML documents. After extracting the information, the processing will be
performed in the same way.
5.6.2 Processing
In the following subsections, the logic flow of the procedures performed in the SA is described along with
information such as local/shared data, interrupts and error handling.
5.6.2.1 Logic flow
SA is initially in an idle mode (ready). When the SS selects a RMT to be applied, it sends a command to the SA
containing, for each involved cell, the RMT to be executed and its parameters. Then, the SA composes the MML
commands to be transmitted and executed at the OMC. If no connection is open to the OMC (CAUTION

interface N) SA should open a telnet session, sending the required authentication information. The commands
will be then transmitted to the OMC and executed. The SA processing is shown in Figure 22.
Ready
received
from SS?
connection
with OMC?
open session
compose MML
command
transmit to OMC
transmission
successful?yes
no
yes
no
no
release
command
no
(command from PCS/ECS)
no
return to normal
mode
yes
yes
yes
control
restart SS
process
active
(no more priority to ECS/PCS
manual commands)
SS
contrast
ECS/PCS?
SS
contrast
ECS/PCS?
restart SS
process
yes
Figure 22: Processing in the SA
The SA can also receive input commands from external elements, namely PCS and ECS. These elements take
decisions that are deemed dominant compared to the ones from the SS. The SA receives the data and composes
the MML command in the same way described above. In case SA receives commands from PCS and ECS, it
enters a mode, in which commands from SS related to the cells managed by PCS and ECS are executed only if
they are not violating the dominant decision of the external element. Such contrasting decisions may be taken
when some SS process is activated before the ECS/PCS modifications to the network resources allocation get
stored in the RMU database.
Precisely, when ECS or PCS asks for the execution of a certain RMT on a certain cell, different cases are
possible:
• A SS process had decided for a RMT that doesn't violate the successive decision of the external
elements. In this case RMT requested from external elements is executed. SS process continues its
activities without being affected by ECS/PCS decisions.
• A SS process had previously decided for a RMT that was in contrast with the decision of the external
elements. In this case RMTs requested from external elements are executed, while SS process is
restarted.

• No SS process is presently managing those cells. Suppose that, after a while, a SS process is activated
and it decides for a RMT (partially) in contrast with the decision of the external element. Then SA
activates a thread that monitors incoming commands. This thread considers the applied technique from
the external element (ECS/PCS) and checks if for the same cell there is conflict with the incoming SS-
commands. Only not-conflicting commands are executed. If a conflicting command is requested, SA
notify to the SS that it hasn't executed it because of the dominant decision from the external elements.
The SS process will be then restarted.
At a certain moment, the external element that had asked the application of a RMT on some cells can send to the
SA that it stops managing those cells. So, the SA is informed that in case of congestion it’s again up the RMU
the management of those cells; in other words it enters the ‘normal mode’.
5.6.2.2 Local data
There are several local variables that are locally stored and used from the SA. The most important local data are
those related to the filtering of SS-commands.
5.6.2.3 Shared data
There are no shared data used by the SA. The SA receives input from SS and forward commands to the OMC. In
addition, SA does not share a cache with the rest of the modules and therefore there are no data in the shared
memory.
5.6.2.4 Interrupts and signals
The main interrupt in the SA is related to the input from the SS. Each SS-process creates a command that is
forward to the SA. The SA, can be then seen as a finite state machine that is initially in a “ready” state. After
receiving an interrupt, i.e. command from SS, the next step is to follow the logical flow described in the previous
section.
The logical flow of the SA is simple and there are no major errors that can be caused in this module. After
receiving commands from the SS, the actuator transmits this to the OMC. This procedure can be interrupted or
even fail. Therefore, the SA should set a timeout whenever transmitting a message to the OMC. In case there is
no acknowledgement within the time-period, the message should be retransmitted.
There are also other situations that can be considered as errors, such as “no connection with OMC”. In this case,
the SA should open a new telnet-session.
Data overflow is not considered for this module, since the received data from the SS-processes can be managed
within a reasonable time.
5.6.3 Output
The SA communicates with the SS, the PCS and the ECS. On the other hand, the SA sends an acknowledgement
to the PCS and ECS, after executing one of the commands. In the following tables, the outputs to PCS, ECS and
SS are shown.

Table 38: Outputs to PCS from SA
Outputs to PCS from SA Name
RMT results RMT_RES_IND
Acknowledgement EXEC_ACK
Table 39: Outputs to ECS from SA
Outputs to ECS from SA Name
RMT results RMT_RES_IND
Acknowledgement EXEC_ACK
The SA informs SS whenever it actuates a command received from ECS/PCS. The output parameters are:
Table 40: Outputs to SS from SA
Outputs to SS from SA Name
Cell managed by ECS/PCS Cell_id
RMT applied by ECS/PCS RMT_id
Finally, the SA communicates with the OMC over a telnet session. The output parameters are not listed in a
table, since it is an MML command, which reconfigures the network parameters.

5.7 Knowledge Base Manager
The Knowledge Base Manager (KBM) module is in charge of performing a set of tasks requiring data exchange
with the internal DB. Namely, it manages the Case Base, provides RMU interface towards human operator,
keeps track of performed actions, triggers alarms towards TLSR to indicate that a predicted event is likely to
occur, and so on.
5.7.1 Inputs
The KBM module can receive from the SS module, respectively:
• A case to be inserted in the Case Base
• A new case to be matched with the old ones in the Case base,
• Data about current network resources allocation
All the above points are summarized in the following table.
Table 41: Inputs from SS to KBM
Input from SS for Case Base update
A case with the structure of Table 43.
Data of new case to be matched
Data structure of Table 44.
Data about current resources allocation Name
For each involved BTS: BTS ID BTS_ID
Present resources allocation PRES_ALLOC_BTS_ID
Moreover, the KBM module receives from the human operator the CAUTION configuration parameters,
information about the predicted events, new or modified cases to be included in the DB (see Table 42).
Table 42: Inputs from human operator to KBM
CAUTION configuration parameters
Thresholds values for utilization of channels, as per Table 47
Ordered lists of strategies, for each TLS, as per Table 48
Weights for similarity functions, as per Table 48
TLS characterization parameters, as per Table 49
Information on predicted events
Data on predicted events Table 47
New or modified cases
A case with the structure of Table 43

5.7.2 Processing
The tasks performed by the KBM module are described in the following subsections.
5.7.2.1.1 Case Base management
The organization of knowledge concerning past experience in ‘cases’ is inspired from Case Base Reasoning
(CBR) methodology. CBR is a widespread Artificial Intelligence area aiming at solving new problems by
reusing and adapting solutions that were successfully used to solve similar problems ([5], [6]).
A case represents a previously experienced situation and, in general, comprises the problem, the proposed
solution and the outcome of its application. In the CAUTION context, a case represents a specific traffic
congestion event, along with the RM strategy applied and the result obtained by its application. This information
is stored in a Case Base, so that it may be used to solve future similar situation. To solve a new problem, the
CBR approach is first to retrieve the most similar case by using appropriate similarity metrics; then the strategy
successfully adopted in that case is reused after tuning the parameters. The new experience is retained in the DB
as a new case.
The Case Base is managed by the KBM module, which stores cases in the data structure described in Table 43.
Each case, associated to a case identifier, is related to an event identifier and a case number. The former specifies
the congestion event as identified by the TLSR, while the latter concerns an attempt to solve it with a specific
strategy. Namely, for a specific event, the first strategy adopted to cope with congestion is described in a case
with the event id and case number zero. If the strategy comes out to be inadequate, another one could be tried: a
related new case is generated with the same event id and case number one, and so on. Additional information
stored in a case comprises the associated TLS (or an UTLS if no scenario has been identified), beginning time
and date, number of congested cells, identifiers of congested cells, average values of parameters characterizing
the congestion (e.g. percentage of channels utilization), the identifier of the applied strategy, the result of the
strategy application, the duration of the event.
For some of the traffic load scenarios (those related to predictable events concerning few cells), parameters
describing congestion in each involved cell and parameters selected for strategy application are also specified in
the case.
A case also stores two values that do not strictly describe the event, but are used in future selection of the most
suitable case to take into account performance statistics. These values are the number of reuse of the case
(number of times it is chosen as the most suitable one in future circumstances) and the number of success when
reused (number of times a success is obtained when it is chosen as the most suitable one and the same strategy is
reused).
Hereafter, CBR management tasks performed by the KBM module are described. The CBR retrieval procedure
is used to retrieve in the Case Base similar cases that were previously and successfully managed. If the TLSR
has identified the scenario, the CBR algorithm will be applied only to the stored cases belonging to that specific
traffic load scenario.
If the TLSR was not able to identify the scenario and so it results be the undefined one (UTLS), the SS asks the
KBM module to apply a CBR algorithm looking at the whole set of previously managed cases.
SS sends to the KBM the data about the new case, according to the format of
Table 44. This information consists of the identifier of the associated TLS and of the values of the key features
(number of overloaded cells, average channel utilization, etc).
The similarity between the current observed situation and the cases stored in the DB will be assessed according
to a function that weights the similarities of the key features. The similarity between two cases is expressed by:

1
),,(1),( 21
21
=
⋅−=
∑
∑
i
i
C
i
C
ii
i
i ffsimCCSIM
ω
ω
where iω are the weights that allow giving more importance to more meaningful features. Weights shall be
configurable and, in general, they depend on the specific scenario. The similarity between the single features is
assessed by the similarity functions isim . For instance, for the TCH utilization, the similarity function may be
the difference between the average TCH utilization of case 1 (previous case, stored in the Case Base) and case 2
(new case) :
simi = |TCH1 – TCH2|
while for the number of cells involved in the congestion event it may be the difference between the two values,
normalized by the maximum between them:
( )21
21
,max NCELLNCELL
NCELLNCELL
simi
−
=
The new case is matched with an old one not only on the basis of the similarity function described above, but
only considering a measure of confidence that is proportional to the number of time the old case has been reused
and to the percentage of success when reused. The measure of confidence is also inversely proportional to the
case number of the old case, since the situation of the old case could have been affected by the impact of
previously applied strategies and in this case could be considered a less reliable example.
By applying the above-described method, the old case that best fits the new situation is retrieved.
If its degree of suitability is high enough, it is sent to the SS and its number of reuse is incremented. Otherwise, a
message of unfound case is sent.
Another task up to the KBM is the storing of new cases. The SS sends to KBM the new cases to be stored. If the
new case is a successful one, SS sends to the KBM a structure like that of Table 43 with the whole information
related to the case. SS may also ask the KBM to increment the “number of success when reused” value of the
case that had suggested the applied strategy, provided its case id. If, on the contrary, the new case is not a
successful one, KBM reports its data in a log file that may be examined by the operator. Anyway, KBM keeps
track of the number of success/failure of each strategy for each scenario.
The operator will be allowed to perform manual search/insertion/deletion of cases in the Case Base. If, in spite of
this, the number of cases stored for a specific TLS gets too high, KBM automatically deletes the older and less
successful cases for that TLS in order to reserve memory space for new cases.
5.7.2.1.2 Interface with human operator
One of the most important tasks performed by KBM is a useful interface towards the human operator, allowing
him/her to monitor the RMU activities, to configure parameters, to insert relevant information for cases
classification, and so on.
The functionalities of the interface are:
• Insert/Modify/Delete the characterization of a specific TLS.
• Associate to a specific TLS an ordered list of RMT.
• Set ALT and RXT threshold values for each relevant parameter.
• Insert/Modify weights of similarity functions.
• Insert/Modify/Delete predicted events description.

• Show the RMU activities: alarms received from ITMU, matched case, selected strategy and
parameters, results…
• Insert/Modify/Delete cases in the Case Base.
• Search cases that match a certain research key and view related data
• View statistics about cases.
• Terminate a specific SS process or all the active SS processes.
5.7.2.1.3 Management of network resources data
KBM also handles some data concerning network topology, standard resources configuration, and current
resources configuration. In particular, the structure storing this information is that of
Table 45. BTS identifier, the list of adjacent cells identifiers, and the standard resources configuration in that
BTS are static data. Instead the present resources allocation is updated every time the SS sends to SA a new
command to be executed on that cell. The PID of the SS process that is managing the cell is provided by TLSR
as the new process is created, and is deleted when the process is terminated.
5.7.2.1.4 Communication with TLSR
At start-up time, KBM must provide to the TLSR the scenarios characterizations and threshold values and it
must inform TLSR of any change made on these data by the human operator. KBM also manages a calendar for
the predicted events: when any predicted event is about to occur, KBM informs the TLSR, so that it can lower
the alarm threshold.
5.7.2.2 Local data
The following data are stored in the KBM module: the cases in the Case Base (having the general structure
shown in Table 432
), the data of the new case to be matched (Table 44), the structure storing information about
network resources (Table 45) the structure storing information about predicted events (Table 46), ALT and RXT
threshold values (Table 47), the parameters associated to each TLS (Table 48), the data characterizing the TLSs
(Table 49), the data collected for statistic purposes (Table 48).
Table 43: General structure of cases stored in the DB
Structure of cases stored in the DB ID
Case ID CASE_ID
Event ID EVENT_ID
2
Note that the channels utilization and applied parameters for each cell are stored only for predictable scenarios
involving few cells.

ST_PARm_CELL_ID
Table 44: Data of new case to be matched
Data of new case to be matched Name

Table 45: Structure storing information about network resources
Data stored for each BTS Name
BTS ID BTS_ID
ID of neighbor cells BTS_ID1, … BTS_IDn
Standard resources allocation STANDARD_ALLOC
Present resources allocation PRES_ALLOC
PID of process managing cell PID_PROCESS

Table 46: Structure storing information about predicted events
Data stored for each predicted event Name
Predicted Event ID PRED_EVENT_ID
Identifiers of the overloaded cells CELL_ID1, …, CELL_IDN
Predicted duration PRED_DURATION
Table 47: ALT and RXT threshold values
Thresholds Name
TCH ALT threshold TCH_ALT_TH
SDCCH ALT threshold SDCCH_ALT_TH
SACCH ALT threshold SACCH_ALT_TH
PCH ALT threshold PCH_ALT_TH
AGCH ALT threshold AGCH_ALT_TH
RACH ALT threshold RACH_ALT_TH
CLC ALT threshold CLC_ALT_TH
Em. calls ALT threshold EC_ALT_TH
TCH RXT threshold TCH_RXT_TH
SDCCH RXT threshold TCH_RXT_TH
SACCH RXT threshold TCH_RXT_TH
PCH RXT threshold TCH_RXT_TH
AGCH RXT threshold TCH_RXT_TH
RACH RXT threshold TCH_RXT_TH
CLC RXT threshold CLC_RXT_TH
Em. calls RXT threshold EC_RXT_TH

Table 48: Parameters for each TLS
Parameters for each TLS Name
List of associated strategies, in order of preference ST_LIST
Weight for similarity for feature 1 W_SIM1
Weight for similarity for feature 2 W_SIM2
… …
Table 49: TLS characterization
Data characterizing each TLS Name
TLS ID TLS_ID
Event duration EV_DURATION
Dimension DIM
Priority PRIOR
SACCH utilization SACCH_UT
Percentage of emergency call attempts EM_CALLS
Percentage of not-normal clear-codes NN_CLC
Table 50: Collected statistics
Statistic data Name
Total number of cases in the Case Base TOT_NUM_CASES
For each scenario:
Number of successful/unsuccessful NUM_CASES_SUCC,

cases for that scenario NUM_CASES_UNSUCC
For each strategy in that scenario:
Number of
successful/unsuccessful
cases for that strategy in
that scenario, deriving from
matches with previous
cases
NUM_CASES_SUCC_FROM_MATCH,
NUM_CASES_UNSUCC_FROM_MATCH
Number of
successful/unsuccessful
cases for that strategy in
that scenario, deriving from
choices in the operator list
NUM_CASES_SUCC_FROM_LIST,
NUM_CASES_UNSUCC_FROM_LIST
Number of predicted events that
occurred/not occurred
NUM_PRED_OCC,
NUM_PRED_NOT_OCC
5.7.2.3 Shared data
KBM will handle the RMU database, which will be accessed by the other RMU modules and the human operator
by invoking the methods it makes available to access/store information. Therefore, all the information contained
in the DB can be seen as being shared, though it is entirely managed by the KBM.
KBM will be able to handle communications problems with other modules, by replying with error notifications
in case improper values are sent to its interface.
5.7.3 Outputs
The KBM module sends to the SS the retrieved case best matching the new one, the strategy list associated to a
specific TLS, and information about network resources (see Table 51).
Table 51: Outputs from KBM to SS
Retrieved case
A past case that best matches a new case, with the structure
described in Table 43.
Strategy list associated to a specific TLS
Strategy list in Table 48.
Information about network resources
Standard resources allocation, as in Table 45.

Moreover, the KBM sends to the TLSR module the TLSR configuration parameters set by the operator, and
information concerning predicted events (see Table 52).
Table 52: Outputs from KBM to TLSR
TLSR configuration parameters
Thresholds as in Table 47.
TLS characterization parameters as in Table 49.
Information on predicted events
Alarm and data on predicted events as in Table 46.
The outputs sent by the KBM to the human operator are the collected statistic data, and all the displayed data
(see Table 53).
Table 53: Outputs from KBM to human operator
Statistic data
Statistic data, as in Table 50.
Displayed data
Tracking of RMU activity
Case Base
CAUTION configuration parameters
TLS characterization parameters as in Table 49.

5.8 Specification of RMU internal interfaces
To enhance the modularity RMU will be developed according to an object-oriented model. RMU modules
described in the previous sections exchange the data specified in the Input and Output related sections. As inter-
process communications mechanism, CAUTION implmemtation of the RMU will use the Component Object
Model (COM), which is a model for binary code developed by Microsoft. COM is a software architecture that
allows applications to be built from binary software components, providing the foundation for higher-level
software services. COM enables to develop objects that can be accessed by any COM-compliant application and
it provides a standard mechanism for inter-process or inter-host communication, for shared memory management
between components, for error and status reporting, for dynamic loading of components. COM will allow
composing entire applications by tying together multiple individual components.
RMU will be developed according to a client-server model and client software will access a server object
through a pointer to the object interface, which consists in a set of methods. Therefore, the input/output specified
in the previous sections will be directly mapped into method invocations.
5.9 Detailed Description of External Interfaces
The RMU communicates with all CAUTION elements and with the Network Management System. It is
important during the specification part of the project to define the external interfaces, in order to allow a
simultaneously implementation of the modules. The interfaces are the following:
• O’ is the interface between RMU and PCS
• N is the interface between RMU and OMC
• I is the interface between RMU and ITMU
• T is the interface between RMU and ECS
In order to specify the interface in a low-level it is necessary to define the system topology. The CAUTION
system will be based on a distributed monitoring system with a centralized resource management mechanism.
The reports that will be exploited from the ITMUs will be collected at each MSC, therefore, ITMU will monitor
the system distributed at each MSC.
The ECS will also be a distributed system, since it will adjust several parameters related to the area of coverage
of the responsible MSC. On the other hand, obviously the ECSs will be accessible over the operator’s Intranet, in
order to allow one operator to adjust all ECSs.
PCS is a centralized element, since it can change the priority status of the user’s without considering their
location.
Finally, the OMC is assumed to be centralized in a GSM system. In reality there might be several OMCs in a
cellular network, especially when part of the network is based on equipment of one vendor and part of the
network from another one.
5.9.1 Communication protocols
The communication protocols of the external interfaces will be in-detail described in deliverable D-3.2 (System
Architecture). Nevertheless it is important to specify even at a high level the interfaces from this point, since
RMU is the element that has a focal position in the CAUTION architecture. Network elements designed by the
project are planned to be connected over the Intranet of the GSM network. This is the most effective way to
allow system components located at remote places to be controlled from one site. The use of the operators
Intranet guarantees the secure transmission of data from one element to another.

All CAUTION elements will be connected using http via TCP/IP. Since the communication will be in both ways,
the elements will have the role of a typical server-client topology, where each component will be simultaneously
server and client in order to send and receive data respectively.
The HTTP/1.1 interface supports persistent connections. This allows issuing more than one request during the
same TCP/IP session without having to establish a new connection for each request, thus greatly improving
throughput if you send a large number of messages. It is important to mention that RMU communicates with the
OMC over telnet connection.
In order to construct a scalable system that will be able to communicate with elements using different operating
systems and software modules, programmed in different languages, XML structures will be used for the
transmission of messages. The messages will be a set of output parameters that are described in the above
sections. The software modules, responsible for transmission of these messages, will make use of a specific
grammar/syntax and on the other side the client will use a parser to get the information needed.
5.9.2 Messages exchanged
The messages exchanged between RMU and the rest of the CAUTION elements will be in-detail specified after
finalizing the system specifications. Nevertheless the general structure of the messages is listed in the following
sections.
5.9.2.1 Messages exchanged between RMU and ITMU (Interface I)
ITMU monitors the system and sends alarms when detecting values above threshold. It is also possible to send
alarm due to the fact that many “not-normal-cleared” calls are reported. Moreover, the RMU might require
additional information about specific cells. Finally, ITMU reports an RTX message, when the problem is solved
in order to inform RMU to return to the default values. The RMU receives messages from ITMU in the
following structure:
<‫؟‬xml version=”1.0”?>
<alarm>
<alarm_type> ALT | RTX | CLC | NCI </alarm_type>
<cell_id> BTS4312 </cell_id>
<time_stamp> 12:03:47 </time_stamp>
<sdcch_utilization> 41 </sdcch_utilization>
<tch_utilization> 73 </tcch_utilization>
<rach_utilization> 28 </racch_utilization>
<pch_utilization> 3 </pch_utilization>
<agch_utilization> 2 </agch_utilization>
<tch_blocking> 34 </tch_blocking>
<sdcch_blocking> 54 </sdcch_blocking>
</alarm>
On the other hand, RMU can request from ITMU additional information for adjacent cells. Additionally, RMU
can require a threshold-change in ITMU, if congestion is predicted. The messages from RMU have the following
structure:

<add_info>
</add_info>
<change_thresholds>
<sdcch_threshold> 50 </sdcch_threshold>
<tch_threshold> 50 </tcch_threshold>
<rach_threshold> 50 </racch_threshold>
<pch_threshold> 60 </pch_threshold>
<agch_threshold> 60 </agch_threshold>
<tch_blocking> 34 </tch_blocking>
<sdcch_blocking> 54 </sdcch_blocking>
</change_thresholds>
5.9.2.2 Messages exchanged between RMU and ECS (Interface T)
RMU mainly receives alarms from the ITMU and performs several computations in order to decide which
technique should be applied in each case. The TLSR recognizes the traffic load scenario and the SS decides for
the technique that will be applied. In case of emergency, or is the operator wants to configure the system
manually, ECS can send to RMU a command, which contains the technique to be applied. The message has the
following format:
<ecs_command>
<rmt_id> rmt_4 </rmt_id>
<rmt1> 12 </rmt1>
<rmt2> 43.2 </rmt2>
<rmt3> 5 </rmt3>
<rmt4> 0.4 </rmt4>
<rmt5> 11 </rmt5>
<rmt6> 24,5</rmt6>
…
<rmtx> 23 </rmtx>
</ecs_command >
After the system returns to the normal mode, the ECS will decide for restoring the default system values. RMU
will be notified by a Rel command, as follows:

<return2normal>
<normal_mode> rel </normal_mode>
</return2normal>
On the other hand, the Am sends the following information to ECS, in order to inform about the system status:
<info2ecs>
<tls_id> tls_5 </tls_id>
<time_ind> 12:04:47 </time_ind>
<rmt_id> rmt_4 </rmt_id>
<rmt_res_ind> better | same | worse </rmt_res_ind>
</info2ecs>
In addition, RMU can notify the ECS that the requested management techniques were applied. If the ECS does
not get this acknowledgement within a specific time, it will re-send the request. The acknowledgement has the
following structure:
<acknowledgement>
<exec_ack> 1 </exec_ack>
</acknowledgement>
5.9.2.3 Messages exchanged between RMU and PCS (Interface O’)
The messages exchanged between PCS and RMU will be constructed using the XML structures, as the elements
are considered external, in the general CAUTION architecture. Thus, in order to construct a scalable system that
will be able to communicate with elements using different operating systems and software modules, programmed
in different languages, XML structures are essential for the transmission of messages. The messages will be a set
of output parameters that are described below. The software modules, responsible for transmission of these
messages, will make use of a specific grammar/syntax and on the other side the client will use a parser to get the
information needed.
Looking through the procedure, the RMU mainly receives alarms from the ITMU and performs several
computations in order to decide which technique should be applied in each case. The TLSR recognizes the traffic
load scenario and the SS decides for the technique that will be applied. In case of emergency, where the operator
decides a manual configuration, the PCS sends to the RMU a command, which contains the desirable adjustment
in the priority status of the selected user group and the area where it will be applied. The message has the
following format (the user group selected is POLICE):
<pcs_command>

<user_group_id> POLICE </ user_group_id>
<priority_level> 3 </priority_level>
</pcs_command >
After the system returns to the normal mode and the prioritization is not needed further, the PCS will decide for
restoring the default priority status. Then, the RMU will be notified by a Rel command, as follows:
<return2normal>
<normal_mode> rel </normal_mode>
</return2normal>
In addition, the Actuator module of the RMU will notify the PCS that the requested priority adjustment was
executed correctly. If the PCS does not get this acknowledgement within a specific time, it will re-send the
request. The acknowledgement has the following structure and includes also the information about the selected
area, user group and priority level changed:
<acknowledgement>
<exec_ack> 1 </exec_ack>
<priority_level> 3 </priority_level>
<time_ind> 12:04:47 </time_ind>
</acknowledgement>
5.9.2.4 Messages exchanged between RMU and OMC (Interface N)
There are two alternatives for the architecture of the N interface: The first approach is based on using a telnet
session. The second one is based on sockets communication where a daemon running on the OMC is always
listening on a specific port for any command originated from the RMU. The definitive choice will be indicated in
deliverable D3.2 – System Architecture.
• N-Interface communication using a Telnet Session
The RMU communicates with the OMC over a telnet connection and from protocol point of view the N interface
uses a permanent TCP/IP connection. The output data from the Am sub-module of the RMU towards the OMC
are MML commands in order to activate or deactivate and even change the parameters of the underlying cellular
network. These commands are usually given through a graphical menu but also directly without using the menu
selection or guidance. When the RMU is involved these commands are formulated, transferred and executed
automatically. In this part there in no need to use an XML structure for transferring the data from the RMU to
the OMC as telnet communication is already provisioned for the OMC. On the other hand defining an XML

structure for this interface requires that all required MML messages could be accommodated something, which is
both very difficult and not flexible.
To open a telnet connection, the system should be configured to communicate under DX 200. The DX 200
TCP/IP is intended to be used in a trusted private intranet environment only. After activation, all Telnet
connections originating from any IP address are accepted. Generally each TCP/IP application has a unique port
number associated with it, where Telnet is associated to the port number 23. For more information about the
parameters that are involved in TCP/IP configuration see the following table.
Table 54: Special parameters in TCP/IP configuration for Telnet communication.
Parameter Explanation Possible values
port number Each TCP/IP application has a unique port number
associated with it. The port numbers of the applications
are given in the manual. Usually you do not need to take
care about the value of this parameter.
1 - 65535
protocol type Two protocol types can be used: TCP and UDP. TCP is
for connection-oriented and UDP for connectionless
protocols. Usually you do not need to take care about the
value of this parameter.
TCP or UDP
netmask length This parameter defines the range of the IP addresses used
in the network. For more information about netmasks and
general network issues, refer to the chapter Introduction
to DX 200 TCP/IP environment of this manual.
4 - 30
ethernet frame type This parameter defines the frame type which is used by
the the sent IP packets. Default value is DIX standard,
and the IEEE is based on IEEE 802.3 standard.
IEEE or DIX
MTU Maximum
Transmission Unit
Defines the maximum size of the IP packet sent to the
network.
Depends on
Ethernet frame type.
primary/secondary
DNS server
See section Use of Domain Name Server (DNS) of this
manual.
-
Priority See section Route priorities of this manual. 1 (low) - 255 (high)
• N-Interface communication using a Socket connection via TCP/IP
By designing and creating a socket connection we can implement the communication between the RMU and the
OMC. The implementation takes place by creating a daemon type program running on the OMC that is
responsible for “listening” to the predefined socket for the data that contain the MML commands. We believe
that this implementation achieves better performance at the cost of reserving just one port at the OMC's host. In
addition daemon type programs are widely used and thus their implementation would not be difficult.

6 CONCLUSIONS
This document describes the role and the architecture of the Resource Management Unit of the CAUTION
system. This element is the key core of the congestion management process of CAUTION.
The RMU is able to distinguish among a set of possible congestion situations, thus enabling the most effective
resource management techniques to be applied for dealing with the specific case. The decision on which resource
management technique is to be preferred for a particular traffic load condition is mainly left in the hands of
operators, which are allowed guiding the RMU operations according to the specific needs of their networks. A
tuning of the parameters for the instantiation of resource management techniques is instead under the
responsibility of the RMU, which on-the-fly decides the details of the network reconfiguration, based on the
solution of a set of optimization models. A key feature of the RMU is represented by its self-learning capability.
Through simple knowledge management mechanisms the RMU is made able of tuning its behavior over time,
and to adapt to changing network conditions. Thus, the RMU may explore different solutions for the same
problem over time, and inform the operator of the obtained results, contributing to improve the level of
knowledge operators have about their systems.
The decisions taken within this document impact on most of the CAUTION architecture, as all other CAUTION
network elements interact with the RMU. Modularity, extensibility and flexibility have guided the design
choices of the RMU, and will also beneficially affect the other CAUTION system components. This is especially
relevant in the context of a research and development project like CAUTION, which ultimately aims at gaining
the trust of operators by proposing a solution that is easily customizable to the specific needs.

REFERENCES
[1] CAUTION D-2.1 “Requirement Analysis and Functional Specifications”, July 2001
[2] Rabiner L., “A Tutorial on Hidden Markov Models and Selected Applications in Speech Recognition”,
Proceedings of the IEEE, pp. 257-286, Feb. 1989
[3] Mouly M. and Pautet M., “The GSM System”, France, 1992
[4] Walke B., “Mobile Radio Networks – Networking and Protocols”, Wiley, 1999
[5] Aamodt A. and Plaza E., “Case-Based Reasoning: Foundational Issues, Methodological Variations, and
System Approaches”, AI Communications, 7(1): 39-59, 1994
[6] Bergmann R. (Ed.), “Engineering Applications of Case-Based Reasoning”, Special Issue of the
International Journal “Engineering Applications of Artificial Intelligence”, 1999
[7] Hillier F. S. and Lieberman G: J., “Introduction to Operations Research” 7th ed., McGraw-Hill, 2001
(ISBN 0-07-232169-5)
[8] Bazaraa M. S., Jarvis J. .J. and Sherali H. D., “Linear Programming and Network Flows” 2nd ed.,
Wiley, 1990 (ISBN 0-471-51284-2)
[9] Ajmone-Marsan M., Conte G., Balbo G., “A Class of Generalized Stochastic Petri Nets for the
Performance Evaluation of Multiprocessor System”, ACM Transactions on Computer System, Vol 2,
pp 93-122, 1984

40803906 sdcch

More Related Content

Similar to 40803906 sdcch

Recently uploaded

40803906 sdcch