40803906 sdcch

1,488 views

Published on

understand sdcch

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,488
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
48
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

40803906 sdcch

  1. 1. D-3.3 Traffic Load Scenario and Decision Making Page 1 Copyright  2001 CAUTION Consortium 13/10/2001 CAUTION IST-2000-25352 D-3.3 Resource Management Application Scenarios Traffic Load Scenarios and Decision-Making Contractual Date of Delivery to the CEC: 30 September 2001 Actual Date of Delivery to the CEC: 15 October 2001 Author(s): Massimo Barbera1 , Cristina Barbero1 , Paola Dal Zovo1 , Fernanda Farinaccio1 , Ivan Mura1 , Stefano Pestrin1 , Gianluca Previti1 , Sofoklis Kyriazakos2 , Evangelos Gkroustiotis2 , Charis Kechagias2 , Chris Karambalis2 , Z. Lioupas2 , B. Petropoulos2 , Kostas Vlahodimitropoulos3 , Achilleas Chatzikonstantinou3 , Filippos Kyriazidis3 Participant(s): MOTOROLA1 , ICCS/NTUA2 , VTT, COSMOTE3 , TELIA Workpackage: WP3 Est. person months: 8 Security: Pub. Nature: R Version: 8.0 Total number of pages: 84 Abstract: This document contains the design of the CAUTION Resource Management Unit (RMU), the component in charge of performing the decision making process that ultimately results in the triggering of the adequate congestion treatment techniques. The RMU receives the information on congestion situations in form of a list of alarmed cells, and executes a matching algorithm to identify the Traffic Load Scenario that best suits the current situations. The RMU contains most of the intelligence of the CAUTION system. Starting from a human included basic knowledge about the possible Traffic Load Scenarios and suitable Resource Management Techniques, the RMU builds over time a database of observed congestion cases and applied techniques, and improves its performances by learning from past experiences through a Case Based Reasoning approach. Searching the database of historical cases allows finding similar situations that occurred in the past and to immediately identify the most successful strategy to deal with the current congestion event. Once a technique has been selected to deal with a congestion event, the parameters necessary to instantiate the technique can be either obtained by similar application cases stored in the database, or can be computed with a fine-tuning model-based approach, which optimizes the Resource Management Technique to meet the network operator goals for the current scenario. The knowledge gained through experience is stored in the RMU database, and will be reused to enhance future decision- making. Moreover, the database information will also be processed to obtain hints on the quality of the basic knowledge provided by the operator, and suggestions for possible modifications and updates. Keyword list: Traffic Load Scenarios, Resource Management Techniques, Decision Making, Case-Based Reasoning, Model-Based Optimization.
  2. 2. D-3.3 Traffic Load Scenario and Decision Making Page 2 Copyright  2001 CAUTION Consortium 13/10/2001 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
  3. 3. D-3.3 Traffic Load Scenario and Decision Making Page 3 Copyright  2001 CAUTION Consortium 13/10/2001 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
  4. 4. D-3.3 Traffic Load Scenario and Decision Making Page 4 Copyright  2001 CAUTION Consortium 13/10/2001 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
  5. 5. D-3.3 Traffic Load Scenario and Decision Making Page 5 Copyright  2001 CAUTION Consortium 13/10/2001 TCP Transmission Control Protocol TLS Traffic Load Scenario TLSR Traffic Load Scenario Recognizer UTLS Undefined Traffic Load Scenario XML eXtended Markup Language
  6. 6. D-3.3 Traffic Load Scenario and Decision Making Page 6 Copyright  2001 CAUTION Consortium 13/10/2001 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.
  7. 7. D-3.3 Traffic Load Scenario and Decision Making Page 7 Copyright  2001 CAUTION Consortium 13/10/2001 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.
  8. 8. D-3.3 Traffic Load Scenario and Decision Making Page 8 Copyright  2001 CAUTION Consortium 13/10/2001 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
  9. 9. D-3.3 Traffic Load Scenario and Decision Making Page 9 Copyright  2001 CAUTION Consortium 13/10/2001 cell as well as on its adjacent cells, the RMU may decide to control the status of the radio resources of the adjacent cells in order to verify that the candidate RMT will not influence negatively the neighboring cells. The RMU may also decide to apply a RMT even before alarms are generated by the ITMUs, when some predicted congestion event is going to happen. In this case the RMU knows beforehand that a particular traffic condition will occur at a given time and at specific cells, and it can decide to prevent the probable cell overload by applying, in advance, the proper RMT. After a radio resource modification, the RMU monitors the radio resource utilization in order to check if the applied RMT has gained the desiderate effects. Concentrator RMU ITMU_02 ITMU_n ... OMC ITMU_01 Emergency call server Emergency call server Emergency call server Priority call server MSC_n BSC Concentrator Concentrator MSC_01 BSC MSC_02 BSC C A' U O' N I T IP IP Figure 1: High-level CAUTION architecture In addition, a PCS and an ECS are connected to the RMU and ITMU elements. Priority call server will be an additional element of the CAUTION architecture that will enable the prioritized assignment of bandwidth, according to the user’s class. ETSI and 3GPP have specified user’s prioritization classes for priority calls, preemption and queuing. In CAUTION project, it will be important to avoid prioritization of users according to their contract with the cellular operator, since several legal issues should be considered. The priority call server will be an element that can be “on the fly” reconfigured in such a way to assign priorities according to the traffic- load situations. The users will be classified to several classes, such as: • Ambulances • Authorities • Police • Fire department
  10. 10. D-3.3 Traffic Load Scenario and Decision Making Page 10 Copyright  2001 CAUTION Consortium 13/10/2001 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.
  11. 11. D-3.3 Traffic Load Scenario and Decision Making Page 11 Copyright  2001 CAUTION Consortium 13/10/2001 4 TRAFFIC LOAD SCENARIOS This section gives information about how the parameters provided by the ITMU to the RMU can be associated to traffic load scenarios. The traffic load scenario identification gives to the RMU a high level vision about the mobile network congestion as well as it allows to take the correct decisions for capacity management techniques. Each of the traffic load scenarios will be characterized by a set of parameters, concerning logical channels utilization and congestion characteristics. In Section 4.1, the parameters collected by ITMU are described in detail. Then, we explain the rationale behind the traffic load scenario characterization and recognition in Section 4.2: In the subsequent Sections (from 4.2.1 to 4.2.13), each traffic load scenario is characterized in terms of channels subject to congestion, duration of congestion and types of traffic. 4.1 ITMU input to resource management The ITMU performs a real-time monitoring on the network, by collecting information about the radio resource utilization. It receives from the concentrator several different data (see [1]) that are appropriately processed to generate the network congestion parameters of interest in CAUTION. In Figure 2, the logical architecture of ITMU is shown. The concentrator listens to the reports generated in the MSC and forwards them to an ITMU, which constructs a matrix for all BTSs. For each BTS, the ITMU matrix contains information about all logical channels. A sliding window aggregates and averages the data, estimating the real-time resource utilization, blocking rate as well as an indication about the percentage of not-normal clear-codes and emergency calls. Bridge RMU BTS1 BTS2 BTS3 BTS4 BTSn . . . SDCCH: 30% TCH: 67% RACH: 20% AGCH: 10% PCH: 4% ... t0 Concentrator RTT, CDR, etc. Figure 2: ITMU logical architecture After the completion of a call (successful or not), the reporting system sends a report, indicating the reason of the connection release. In case the subscriber completed the call normally, the report that is sent to the MSC is ‘0000’ (normal clear). If another value is received, the call was not cleared normally. Some of the not-normal clear codes are reported if the other party does not respond. Obviously these clear codes are not considered for generating an alarm, since they are not combined with a network shortcoming. Therefore, if at a certain cell there is a large amount of not-normal-cleared calls, this should also be reported to the RMU. Therefore, in the ITMU matrix this indicator should be counted and stored. The main reason for reporting not-normal-cleared calls is that they can give a better view of the network shortcoming. If for example, the TCH utilization in a specific cell is around 15%, there are two possible reasons that explain this: • The cell is not congested and there are no additional problems
  12. 12. D-3.3 Traffic Load Scenario and Decision Making Page 12 Copyright  2001 CAUTION Consortium 13/10/2001 • The traffic congestion is enormous and the lack of signaling channels result in a very low TCH utilization. In the second case, it is obvious that the combination of the channel utilization with the not-normal-cleared calls would have diagnosed the congestion, something that would not have been noticed from the sole utilization value. In case the number of not-normal-cleared calls is higher than a threshold, a CLC (CLear Code) report is sent to RMU. The ITMU estimated parameters for each cell are indicated in the following: • TCH utilization • SDCCH utilization • RACH utilization • SACCH utilization • AGCH utilization • PCH utilization • TCH Blocking rate (BR) • SDCCH Blocking rate (BR) • Percentage of not-normal clear-codes • Percentage of emergency call attempts The ITMU will compare each of these parameters with a set of threshold values it stores, to verify whether the threshold value is reached or not. A positive match with the threshold values will result in one alarm to be propagated to the RMU, indicating the necessity of starting a congestion management procedure. Three threshold values are defined for ITMU: • Alarm threshold (ALT), which specifies a threshold value that when reached triggers some overload management RMU actions. ALT is always set. • Relax threshold (RXT), which specifies a threshold value that when reached stops the alarm to be issued by the ITMU. It represents the termination of the congestion situation. A value of RXT consistently less than that of ALT shall be considered, to limit the occurrence of oscillatory phenomena. • Alarm based on the number of not-normal clear codes (CLC). This alarm is generated when the number of not-normal clear codes is above a pre-defined threshold. The plot shown in Figure 3 explains the way the ITMU employs the various thresholds in case of a congestion event. As the resource utilization grows to overcome the ALT value, the ITMU will send an alarm to the RMU. The treatment of overload will continue till the resource utilization factor has decreased below the RXT value. After that, the normal resource management is resumed by RMU. 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 1 2 3 4 5 6 7 8 9 10 11 RXT ALT time Channel utilization Alarm from ITMU Stop overload treatment Figure 3: ITMU threshold utilization
  13. 13. D-3.3 Traffic Load Scenario and Decision Making Page 13 Copyright  2001 CAUTION Consortium 13/10/2001 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 1 2 3 4 5 6 7 8 9 10 11 RXT ALT time Channel utilization Stop overload treatment CLC alarm Figure 4: Creation of a CLC alarm Figure 4 shows how a CLC alarm is generated. In the above example, although the TCH utilization was not higher than the pre-defined threshold, an abnormally high number of not-normal clear codes lead to the conclusion that the network is suffering from some kind of congestion, and generates a CLC alarm. The ITMU will exploit available reports and will calculate cell overload indicators. In every loop the system will check if the values are under or above their threshold values, as described above. If one of the above parameters has reached a threshold, the alarm mechanism is triggered. This alarm will be reported to the RMU. Subsequently, RMU will identify the traffic-load scenario and decide for a management technique. To take into consideration the time necessary for the RMT deployment and impact on resource utilization, after execution of the technique, additional alarms for the same cells should be not be forward from the ITMU to the RMU for a given period of time. The duration of this period between two different alarms (∆t) will be a variable in the system, but is expected to be around 1 minute, in any case not less. In the following flow chart, a simple mechanism to filter redundant alarms is shown. It is important to notice that the ITMU will keep calculating the indicators as normal, though they are not submitted, unless the specific time has passed. Detect alarm for cell_i cell_i timer=0 cell_i timer= ∆t Set filtering-timer for cell_i = 0 Increase timer Fwd alarm to RMU yes yes no no Monitor system Increase timer Figure 5: Filtering of alarm in the ITMU
  14. 14. D-3.3 Traffic Load Scenario and Decision Making Page 14 Copyright  2001 CAUTION Consortium 13/10/2001 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
  15. 15. D-3.3 Traffic Load Scenario and Decision Making Page 15 Copyright  2001 CAUTION Consortium 13/10/2001 4.2 Traffic load scenario characterization Before any attempt is made to characterize the traffic load scenarios, based on a piece of predictable information, such as occurrence time, congestion localization, duration of the event, and amount of traffic observed during the congestion, it must be clear how the information from ITMU should be interpreted according to the statistical analysis performed in [1]. Therefore, utilization and blocking of certain channels in addition to normal and not- normal clear codes, reported by the ITMU element, should be corresponded to performance indicators such as Blocking Rate, Success Rate and Throughput of the respective channels. A quantitative correspondence of the above mentioned indicators is a difficult task with doubtful results, that would produce additional overhead to the whole process. Thus, a qualitative relation is attempted instead. For that reason, two new charts are generated, depicting the network’s reaction in congestion situations for the utilization of the channels, based on the chart generated by the statistical analysis for the performance indicators examined in [1]. The basic idea of the chart is explained in Figure 6. Y-Axis X-Axis SDCCH BLOCKING TCH BLOCKING HANDOVER FAILURES 0 LOW CONGESTION MEDIUM CONGESTION HIGH CONGESTION TRAFFIC THROUGHPUT Figure 6: Network's behavior in congestion situations for performance indicators Low congestion means that only few BSCs are affected and probably is geographically limited, medium congestion means that a respective percent of BSCs participate in the crisis and high congestion means that almost the entire network is affected. The above classification of situations is also based on the results on network level. At first, traffic can also be considered as the throughput of the network. As seen in the diagram, it increases beyond the threshold of the low congestion situation, but reaches a limit beyond the threshold of the medium congestion conditions. This limit represents exactly how much traffic the network can handle (or the maximum throughput the network can achieve). After the threshold of the high congestion, traffic is slightly degrading, as the conditions worsen and the resources responsible for a service establishment (SDCCH mostly) dramatically diminish. As far as the SDCCH Blocking is concerned, it is clearly marked on the diagram that it is increasing proportionally to the augmentation of the congestion level. This is normal, because the demand for establishment resources increases, while resources are static and limited. In that way, blocking is increased proportionally to the demand. The importance of the SDCCH Blocking in the whole study is that all procedures are SDCCH- dependant.
  16. 16. D-3.3 Traffic Load Scenario and Decision Making Page 16 Copyright  2001 CAUTION Consortium 13/10/2001 TCH Blocking also increases as traffic (or demand) increases, beyond the low congestion threshold, and reaches a peak at medium congestion, accordingly to the traffic. As high congestion situations approach, TCH Blocking clearly reduces its figures. This is also SDCCH-dependant and it happens because the network has run out of establishment resources (SDCCH mostly), traffic is reduced and there are TCHs available. It must be noted that, in cellular networks, TCHs outnumber SDCCHs in every single TRX. Finally, Handover failure rate (the same applies for Call Setup failure rate, which is 1-CSSR) follows the curve of TCH Blocking. It is also SDCCH-dependant, reaches its peak when TCH Blocking is at its highest point and diminishes at high congestion conditions, because services cannot be established at this point. According to the above facts, the utilization diagrams follow in the same layout. It is very important, in this exact point of the analysis, to clarify that the following charts slightly precede the one above in terms of time and network monitoring. In other words, monitoring a channel, one will firstly perceive a change in utilization, followed by a change in blocking/success rates. An explanation of the next diagram is shown in Figure 7. UTILIZATION% 0 LOW CONGESTION MEDIUM CONGESTION HIGH CONGESTION TCH 100 50 SDCCH Figure 7: Network's reaction in congestion situations for utilization of SDCCH, TCH As shown above, TCH suffers the first from the congestion situation, followed by the SDCCH. The utilization of the two channels is similar in both low and medium congestion situations. When SDCCH gets highly congested, TCH utilization degrades, as there cannot be any more TCH assignments (lack of setup resources). If the traffic load is even bigger, the situation worsens, RACH and PCH overcome the highest level of utilization and SDCCH utilization starts to degrade also, as call setup attempts are now not perceived at all by the network. In Figure 8, the behavior of RACH, PCH and AGCH utilization is depicted. These channels follow a smoother increase of their utilization, as there are usually enough resources to handle the attempts made. Especially, AGCH rarely encounters problems in blocking and utilization. The most common phenomenon, though, as far as RACH/PCH are concerned, is that problems are encountered in the Abis interface (air interface’s resources are usually adequate to handle most situations), causing congestion situations. Usually, all three channels (PCH, RACH, AGCH) remain in medium or low congestion utilization factor. Combining the information from the three aforementioned charts with the experience of the operator on similar situations and radio coverage, it is feasible to relate utilization and blocking reported by the ITMU to congestion
  17. 17. D-3.3 Traffic Load Scenario and Decision Making Page 17 Copyright  2001 CAUTION Consortium 13/10/2001 and, therefore, to characterize the scenarios. Utilization is the key indicator that will characterize a congestive scenario, as it is more representative of what is really happening and more independent from the situation itself than blocking. On the other side, blocking will provide additional information and, thus, extra help in the characterization of the scenario. Blocking rate depends on certain network parameters, such as radio coverage of the selected area, overlapping of the cells and the use of directed retry. This “drawback” can be used in favor of the method, as it will offer extra characteristics to the situation. For instance, in a congestion situation where utilization reaches high values, it is very possible for blocking to remain in low level because of good cell overlapping and proper use of the directed retry feature. Another possibility is that, while utilization decreases to very low values giving the impression that everything works fine, blocking rate reaches very high values, raising in that way the alarm that channels are not used because of congestion. The use of utilization in combination with blocking will be obvious in the construction of the characterization rule for each scenario, a procedure that follows. UTILIZATION% 0 LOW CONGESTION MEDIUM CONGESTION HIGH CONGESTION 100 50 RACH / PCH AGCH Figure 8: Network's reaction in congestion situations for utilization of RACH, PCH, AGCH Furthermore, a significant point of this analysis is that most of the events are scaling events, meaning that the increase will pass through all the congestion levels, on the road to the highest peak and that must be taken into consideration on the selection of the appropriate scenario. An important role will also be played by the information gathered off the clear codes, which will be combined with the utilization and blocking information for best performance of the matching of the scenarios. It is possible for few selected scenarios to be triggered based only on abnormal behavior of clear codes (e.g. dramatic increase of non-normal clear codes). Finally, because the production of each scenario rule demands certain values for each parameter used, the code of interpretation of numbers to levels (Low, Medium, High) follows. The encoding uses the statistical analysis and the operator’s experience in order to transform numbers to levels.
  18. 18. D-3.3 Traffic Load Scenario and Decision Making Page 18 Copyright  2001 CAUTION Consortium 13/10/2001 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% • Medium: 80% to 90% • High: over 90% SDCCH, PCH, RACH, AGCH Blocking Rate • Low: 0% to 1% • Medium: 1% to 5% • High: over 5% TCH Blocking Rate • Low: 0% to 1% • Medium: 1% to 10% • High: over 10% CLC percentage • Low: 0% to 1% • Medium: 1% to 10% • High: over 10% Emergency call percentage • Low: 0% to 5% • Medium: 5% to 10% • 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.
  19. 19. D-3.3 Traffic Load Scenario and Decision Making Page 19 Copyright  2001 CAUTION Consortium 13/10/2001 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.
  20. 20. D-3.3 Traffic Load Scenario and Decision Making Page 20 Copyright  2001 CAUTION Consortium 13/10/2001 The diagram in Figure 9 shows the typical trend of the total BSC workload (in Erlang) during the day. As it can be observed from Figure 9, two different peaks are reached during the day, with peak traffic values much higher than the average ones. 96.91 57.75 34.58 21.78 15.0011.3712.52 25.86 62.18 117.74 178.18 229.16 256.43254.67 228.66 189.38 174.58 210.43 254.73 266.59 260.52 235.65 190.97 142.43 0 50 100 150 200 250 300 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 Erlang Average Value: 146 Erlang Figure 9: Channel utilization during the Busy Hours Since busy hour’s congestion is a periodical situation, the time occurrence, traffic overload and location of the event are predictable with a good confidence degree. In particular, the following parameters can be estimated based on the statistical analysis of the observed events. The start time of the congestion event, as well as its duration, are statistically predictable. Depending on the area and time of the year, three different busy hours can be defined. Firstly, in a metropolitan area, during wintertime, busy hour occurs in the [12 AM, 1 PM] time window. In the rest of a country, during wintertime, busy hour occurs in the [8 PM, 9 PM] time window. Finally, during summer time, busy hour occurs in the [8 PM, 9 PM] time window almost everywhere. The last case applies mostly to the next scenario of tourist periods. The channels subject to congestion are mainly the TCH and the SDCCH. TCH utilization can overcome 80% during the Busy Hour, while SDCCH utilization reaches values up to 70 %. The channel that first gets congested is the TCH, then the SDCCH. It should be noted that in certain cells of a metropolitan area utilization reaches 100%. As far as the other channels are concerned, all three (PCH, RACH, AGCH) remain in low congestion utilization factor. Blocking rates in this scenario remain in [1%, 10%] percentage window for the TCH and in the [1%, 5%] percentage window for the other channels. Of course, as mentioned before, blocking depends highly on the area, radio coverage and other network parameters and these values are averaged estimations, in order to help the identification process. The cells involved in the Busy Hours congestion events are also predictable. A list of such cells can be provided, depending on the specific geographic area involved in the Busy Hours. As mentioned above, the cells mostly affected are the ones serving urban areas, especially if they are highly populated. This fact means that only few cells in the entire network encounter high congestion on busy hour. The following table provides a characterization of the traffic typologies associated with the Busy Hours events. The results are extracted from the statistical analysis performed in [1]. Table 2: Traffic breakdown during Busy Hours Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 35% 40% 20% 5% Combining the data provided above, we can produce the following characterization rule to capture the Busy Hours occurring during Business Days.
  21. 21. D-3.3 Traffic Load Scenario and Decision Making Page 21 Copyright  2001 CAUTION Consortium 13/10/2001 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
  22. 22. D-3.3 Traffic Load Scenario and Decision Making Page 22 Copyright  2001 CAUTION Consortium 13/10/2001 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 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 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.
  23. 23. D-3.3 Traffic Load Scenario and Decision Making Page 23 Copyright  2001 CAUTION Consortium 13/10/2001 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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 45% 10% 40% 5% 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,…}) (SDCCH Util. = High) (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
  24. 24. D-3.3 Traffic Load Scenario and Decision Making Page 24 Copyright  2001 CAUTION Consortium 13/10/2001 (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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 45% 15% 35% 5% Combining the data provided above, we can produce the following characterization rule to capture the Sport events scenario. START RULE: Sport events (Dimension = Low) (SDCCH Util. = High) (TCH Util. = High) (PCH Util. = High) (RACH Util. = High) (AGCH Util. = Medium) (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.
  25. 25. D-3.3 Traffic Load Scenario and Decision Making Page 25 Copyright  2001 CAUTION Consortium 13/10/2001 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 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 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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 45% 15% 35% 5% 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) (SDCCH Util. = High) (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
  26. 26. D-3.3 Traffic Load Scenario and Decision Making Page 26 Copyright  2001 CAUTION Consortium 13/10/2001 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 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 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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 45% 15% 35% 5% 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) (SDCCH Util. = High) (TCH Util. = High) (PCH Util. = Medium) (RACH Util. = Medium) (AGCH Util. = Medium) (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.
  27. 27. D-3.3 Traffic Load Scenario and Decision Making Page 27 Copyright  2001 CAUTION Consortium 13/10/2001 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 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 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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 40% 25% 30% 5% Combining the data provided above, we can produce the following characterization rule to capture the Demonstrations scenario. START RULE: Demonstrations (Dimension = Medium OR Low) (SDCCH Util. = High) (TCH Util. = High) (PCH Util. = High) (RACH Util. = High) (AGCH Util. = Medium) (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.
  28. 28. D-3.3 Traffic Load Scenario and Decision Making Page 28 Copyright  2001 CAUTION Consortium 13/10/2001 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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 45% 20% 30% 5% 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
  29. 29. D-3.3 Traffic Load Scenario and Decision Making Page 29 Copyright  2001 CAUTION Consortium 13/10/2001 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 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 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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 30% 45% 20% 5% Combining the data provided above, we can produce the following characterization rule to capture the Planned outages scenario. START RULE: Planned outages (Dimension = Low) (SDCCH Util. = High) (TCH Util. = Medium) (PCH Util. = Medium) (RACH 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
  30. 30. D-3.3 Traffic Load Scenario and Decision Making Page 30 Copyright  2001 CAUTION Consortium 13/10/2001 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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 30% 45% 20% 5% Combining the data provided above, we can produce the following characterization rule to capture the BTS Shortcoming scenario. START RULE: BTS Shortcoming (Dimension = Low) (SDCCH Util. = High) (TCH Util. = Medium) (PCH Util. = Medium) (RACH Util. = Medium) (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
  31. 31. D-3.3 Traffic Load Scenario and Decision Making Page 31 Copyright  2001 CAUTION Consortium 13/10/2001 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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 20% 60% 15% 5% Combining the data provided above, we can produce the following characterization rule to capture the BSC Shortcoming scenario. START RULE: BSC Shortcoming (Dimension = Medium) (SDCCH Util. = High) (TCH Util. = Medium) (PCH Util. = Medium) (RACH Util. = 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
  32. 32. D-3.3 Traffic Load Scenario and Decision Making Page 32 Copyright  2001 CAUTION Consortium 13/10/2001 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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 45% 15% 25% 15% Combining the data provided above, we can produce the following characterization rule to capture the Catastrophes scenario. START RULE: Catastrophes (Dimension = High) (SDCCH Util. = 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
  33. 33. D-3.3 Traffic Load Scenario and Decision Making Page 33 Copyright  2001 CAUTION Consortium 13/10/2001 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 Voice LocUpd SMS Other (Emergency etc.) Relative traffic % 50% 15% 20% 15% Combining the data provided above, we can produce the following characterization rule to capture the Accidents scenario. START RULE: Accidents (Dimension = Low) (SDCCH Util. = High) (TCH Util. = High) (PCH Util. = Medium) (RACH Util. = Medium) (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
  34. 34. D-3.3 Traffic Load Scenario and Decision Making Page 34 Copyright  2001 CAUTION Consortium 13/10/2001 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
  35. 35. D-3.3 Traffic Load Scenario and Decision Making Page 35 Copyright  2001 CAUTION Consortium 13/10/2001 4.2.15 Conclusions The correct identification of each of the scenarios presented in the above paragraphs is extremely important to the success of the CAUTION system. The element responsible for this task (RMU respectively), based on the characterization rules constructed above and the data collected from the ITMU, should take the right decision and select the most appropriate scenario, for each occasion encountered by the cellular system. It must be noted that each parameter is uniquely defined and each scenario can be also uniquely defined by a set of parameters, as shown above. For better comprehension of the scenario recognition method, the following table presents an overview of all scenarios and the values of the parameters for each one of them. Table 15: Summary of traffic load scenario parameters Parameter Scenario Priority Dimension SDDCH TCH . PC H RACH AGCH SDCCH BR TCH BR Em calls CLC Busy Hour 0 H M/H H L L L M M L L Tourist Periods 0 H H H M M L M M L L Bank Holidays 1 H H H H H M H H L L Sport Events 1 L H H H H M H H L L Travel Services Strikes 1 L H H L L L H H L L Religious/ Cultural events 0 L H H M M M M M L L Demonstrations 1 M/L H H H H M H H L L Department stores 0 L M M/H L L L M M L L Planned outages 0 L H M M M L H H L L BTS shortcoming 1 L H M M M L H H L L BSC shortcoming 1 M H M M M L H H L L Catastrophes 2 H H H H H H H H H H Accidents 2 L H H M M L M H M/H L Massive congestion 2 L L L L L L M H L H
  36. 36. D-3.3 Traffic Load Scenario and Decision Making Page 36 Copyright  2001 CAUTION Consortium 13/10/2001 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).
  37. 37. D-3.3 Traffic Load Scenario and Decision Making Page 37 Copyright  2001 CAUTION Consortium 13/10/2001 Traffic load scenario recognizer identified Strategy Selector Strategy Actuator RMU ITMU OMC Knowledge Base Manager Alarms DB PCSECS Monitor Command manual input Figure 10: RMU high-level logical architecture The main purpose of the SS is to match the information coming from the TLSR with one or more Resource Management Techniques that are supposed capable to a the alleviate the identified problem. In order to identify and to fine-tune the RMT parameters, the SS may require to get more information from one or several ITMUs or additionally it may enquire the DB in which previously applied RMTs with their corresponding results have been stored. In this case the SS shall interact with the Knowledge Base Manager (KBM). As soon as some RMTs are identified as suitable ones for the recognized TLS, the SS shall send command information (RMT parameters) to the Strategy Actuator module (SA). SA shall send the command messages to the OMC. Once the RMT is applied, the RMU shall monitor the overloaded cells in order to verify that the selected RMT was effective. If no positive effects are obtained, it shall resort to another RMT, if possible. All RMU decisions and the consequent results shall be recorded by the Knowledge Base Manager into its internal DB, which is used as a source of information for the tuning over time of the RMU operation. 5.3 RMU high-level state diagrams The RMU high-level state diagrams and the subsequent ones provide a further level of detail in the description of the RMU’s operation. The first state diagram describes the TLSR, which manages the alarms received from the ITMU, tries to identify the traffic load scenario and triggers the SS’s process. The SS is represented in the second diagram. Taking into account the traffic load scenario identified, the SS performs the decision-making step, which consists in the selection of the RMT to be applied and the choice of the proper values for the related parameters. The other state diagrams illustrate the SA, which provides for actuation of the decisions taken by the RMU, and the KBM, which is in charge of tracking the RMU activity, by accessing the internal DB. We shall now describe the states of each RMU functionality, and the events that lead the RMU to a transition from one state to another. As shown in Figure 11, the TLSR leaves the “ready state” each time an alarm message is received from one or more of the ITMUs or each time the KBM notifies the probable occurrence of a predicted event, manually and previously inserted in the internal DB. In the former case, namely when an alarm is received from ITMU, TLSR accesses the DB to check whether the alarm was due to a predicted event. This information, along with data

×