40803906 sdcch

D-3.3 Traffic Load Scenario and Decision Making

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

Emergencycall 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.

BridgeRMU

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.

00,1

0,20,30,40,50,60,70,8

0,91

1 2 3 4 5 6 7 8 9 10 11

RXT

ALT

time

Channel utilization

Alarm fromITMU

Stop overloadtreatment

Figure 3: ITMU threshold utilization



00,1

0,20,30,40,50,60,70,8

0,91

1 2 3 4 5 6 7 8 9 10 11

RXT

ALT

time

Channel utilization

Stop overloadtreatment

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-Ax

is

X-Axis

SDCCHBLOCKING

TCHBLOCKING

HANDOVERFAILURES

0

LOWCONGESTION

MEDIUMCONGESTION

HIGHCONGESTION

TRAFFICTHROUGHPUT

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.

UTIL

IZAT

ION

%

0

LOWCONGESTION

MEDIUMCONGESTION

HIGHCONGESTION

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.

UTI

LIZA

TIO

N %

0

LOWCONGESTION

MEDIUMCONGESTION

HIGHCONGESTION

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.5821.7815.0011.3712.52

25.86

62.18

117.74

178.18

229.16

256.43254.67

228.66

189.38174.58

210.43

254.73266.59260.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:0

0

12:0

0

14:0

0

16:0

0

18:0

0

20:0

0

22:0

0

Erla

ng

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.

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). 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.

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. 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



Combining the data provided above, we can produce the following characterization rule to capture the 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 congestion, duration of congestion and types of traffic.



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



Combining the data provided above, we can produce the following characterization rule to capture the 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.

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 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.

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. 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 congestion, duration of congestion and types of traffic.

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



Combining the data provided above, we can produce the following characterization rule to capture the 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 congestion, duration of congestion and types of traffic.

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.

PCH 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

PCS ECS

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 timeAlarm from

KBM

Ready Identify Scenario

Get data from ITMUs

Tighten ITMU alarm thresholds

More info needed

Identification completed

Trigger SSRMU 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 strategiesand parameters

Get data from KB and from ITMUs

Monitor ITMU

More info neededStart

End

KB write command

TLSR trigger

TLSR trigger

Trigger SA

success

unsuccess

SS

Evaluate strategies and parameters


Monitor ITMU


End

KB write command

TLSR trigger

TLSR trigger

Trigger SA

success

unsuccess

SS

Evaluate strategies and parameters


Monitor ITMU


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 searchSS request operator 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

EVENTPROFILER

LOCAL PROFILERDATABASE

RECOGNIZER

TIMER

TLSR MODULE

KBM

LOCAL COMDATABASE

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 NEXTADJACENT

CELL IN THE LIST

NO

PREDICTEDEVENT

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

HM L HML H ML

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 ofthe similar case

More info neededfrom other ITMUs

Monitor Strategy effectiveness

Positive impact?

Critical situation ended (RXT alarm)

yes

noSend 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 Timax 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 maxii

opti TTT ≤≤ . An adjacent cell i∈A

has a residual traffic capacity, so optii 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 - T i i opt

T - T j jopt

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

iopt

iEijj

ji

optii

Ejijij

∈∀−≤

∈∀−≤

∑∑

∈

∈

,

,

),(:

),(:

The first constraint states that the amount of traffic to be moved from i to its adjacent cells is at most optii 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:



EjixEkijixx

AiTTx

CiTTxts

xx

ij

ikij

iopt

iEijj

ji

optii

Ejijij

Ci Aj Cjijij

∈∀≥∈∀=

∈∀−≤

∈∀−≤

−

∑∑

∑ ∑ ∑

∈

∈

∈ ∈ ∈

),(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








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

receivedfrom SS?

connectionwith OMC?open session

compose MMLcommand

transmit to OMC

transmissionsuccessful?yes

no

yes

no

no

release command

no

(command from PCS/ECS)

no

return to normalmode

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),( 2121

=

⋅−=

∑

∑

ii

Ci

Cii

ii 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 NCELLNCELLNCELLNCELL

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.


































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> <cell_id> BTS4312 </cell_id>

<user_group_id> POLICE </ user_group_id> <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>


<user_group_id> POLICE </ user_group_id>

<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

Technology

caution consortium

decision making page

rmu database

current scenario

caution ist

caution system

congestion situations

current congestion event