Optimisation OF GSM

COURSE WL9016 GSM Mobile Network Optimization STUDENT GUIDE
Lucent Technologies Proprietary This document contains proprietary information of Lucent Technologies and is not to be disclosed or used except in accordance with applicable agreements Copyright 1996 Lucent Technologies Unpublished and Not for Publication All Rights Reserved .
WL9016 Version 01 e Issue c February 1998
This material is protected by the copyright and trade secret laws of the United States and other countries. It may not be reproduced, distributed or altered in any fashion by any entity, including other Lucent Technologies Business Units or Divisions, without the expressed written consent of the Customer Training and Information Products organization. For permission to reproduce or distribute please contact: Product Development Manager 1-800-334-0404
Notice
Every effort was made to ensure that the information in this document was complete and accurate at the time of printing. However, information is subject to change.
Mandatory Customer Information

Federal Communications Commission (FCC) Statement
None for this document but here to illustrate the feature.
Security
This is a sample security statement.
Trademarks
FrameMaker is a registered trademark of Frame Technology Corporation. UNIX is a registered trademark of UNIX Systems Laboratories, Inc.
Warranty
Lucent Technologies provides no warranty for this product.
Lucent Technologies Proprietary See notice on rst page
Table of Contents WL9016 - ST.e.3 GSM Mobile Network Optimization
______________________________________________________________________________ LESSON TITLE TAB V.L.I. ______________________________________________________________________________ ______________________________________________________________________________ WL9016 Table of Contents 00 ST.e.3.toc 9W530 Cellular Network Optimization Overview 01 01.e.d 6W002 OMC-2000 Functional Description 02 03.e.c BSS Parameters and Functions 03 01.e.c 9W535 6W003 OMC-PMS Functional Description 04 03.e.b 9W531 Using Network Performance Monitoring Guide 05 01.e.a Drive Testing and Analysis 06 01.e.c 9W533 9W537 Optimization Casework 07 01.e.b 9C500 Erlang Tables 08 01.e.a 9W534 GSM System Network Performance Monitoring Guide 09 01.e.a
CELLULAR NETWORK OPTIMIZATION OVERVIEW
1
1-1 1-1 1-1 1-3 1-3 1-5 1-6 1-7 1-9 1-11 1-11 1-11 1-13 1-13 1-15 1-16 1-19 1-21 1-21 1-23 1-23 1-25 1-27 1-27 1-27 1-27
Contents
INTRODUCTION TO NETWORK OPTIMIZATION
s s
LESSON INTRODUCTION LESSON OBJECTIVES
OPTIMIZING THE NETWORK

s s
WHAT IS OPTIMIZATION WHY OPTIMIZATION Accuracy of Radio Planning Implementation Environment
NETWORK OPTIMIZATION PROCESS

s s
DEFINITION PHASES Phase I - Preparation Phase II - Definition of Sub-Networks Phase III - Quality Assessment Phase IV - Optimization
NETWORK OPTIMIZATION PARAMETERS

s
ENABLE/DISABLE GSM FEATURES Discontinuous Transmission Frequency Hopping Power Control
s s
BSS PARAMETERS NEIGHBOR CELL LISTS Definition Optimization Impact Scenarios
Version 01 e
issue d
1-i
Contents
s s
ANTENNA PARAMETERS FREQUENCY CHANGES
1-29 1-31
1-ii
Version 01 e
issue d
INTRODUCTION TO NETWORK OPTIMIZATION

LESSON INTRODUCTION
1
1
This lesson discusses the principles of cellular network optimization by giving the following topics:
s
The denition of cellular network optimization (or asking the question: what is cellular network optimization?) The reason for optimizing the cellular network (or asking the question: why is it necessary to optimize the cellular network?) The network optimization process and its phases The tools which are used to optimize the network The optimization parameters, which are the parameters that can be adjusted to improve the performance of the cellular network, including site re-congurations and frequencies
s s s
LESSON OBJECTIVES
At the end of this lesson, participants will be able to:

s s s s s
Know what cellular network optimization is. Know the reason for cellular network optimization. List the different phases of the network optimization process. List the tools which are used to optimize the network. Identify the parameters that can be adjusted in order to improve the performance of the network.
Version 01 e
issue d
1-1
9W530
Coverage denition Trafc forecast
Design
Optimization
Planning
Coverage Interference Handover behavior Trafc distribution
Implementation
Cell sizes (coverage) Number of BSSs Cell structure Cell sizes (capacity) TRX dimensioning
Figure 1-1.
ENDLESS CYCLE OF NETWORK PLANNING AND OPTIMIZATION
1-2
Version 01 e
issue d
9W530
OPTIMIZING THE NETWORK

WHAT IS OPTIMIZATION
1
1
Cellular network optimization is the activity of achieving and maintaining the required quality targets in the existing network without changing the number and location of base stations in the network. The quality targets are determined during the Design phase of the cycle of cellular network planning and optimization as is depicted in the gure on the opposite page. Targets are normally changed once the network starts to mature. The following phases are shown in this gure: Design The dimensioning parameters of the network are determined, which are: Coverage denition, including: mobile classes (for example, 2W or 8W), mobile environment (outdoor or indoor), coverage probability (for example, 90% of the area), area denition, and special coverage objects (for example, airport or shopping mall). Trafc forecast, including: number of subscribers, target groups (business or private), and trafc distribution over the country and within cities. Planning The dimensioning parameters of the design phase are translated into a real network consisting of, for example, TRXs. Note that planning is also known as engineering. The following mapping is done in the planning phase:
Design Phase Coverage definition Traffic forecast
Planning Phase - Cell sizes (coverage) - Number of BSSs - Cell structure - Cell sizes (capacity) - TRX dimensioning related to growth
Implementation Optimization
The equipment is installed in the cellular network (including masts, antennas and radios). Activities are performed to meet the required quality targets in the cellular network. The following quality parameters have to be considered: Coverage (across the whole cell) Minimization of interference Handover behavior Trafc distribution and congestion RX quality
Version 01 e
issue d
1-3
9W530
REASONS FOR OPTIMIZATION: Deviations between plan and reality Deviations due to:
Reason Deviation Examples of Error Sources 1. Inaccuracy of - Statistical variations in the path loss radio planning characteristics - Finite terrain data base resolution 2. Implementation - Antenna radiation pattern and effective radiated power - Antenna pattern distortion 3. Environment - Seasonal environmental changes e.g.trees and leaves - Environmental changes such as new highways, raised rail systems and new buildings, because each environmental change is different we normally optimize for street level
1-4
Version 01 e
issue d
9W530
Note that a poor design, planning and maintenance cannot be compensated by optimization.
WHY OPTIMIZATION
When translating the cell design into engineering parameters for cell planning, deviations can exist. The deviations between the plan and the reality frequently exist due to: 1. 2. 3. Inaccuracy of the radio planning Implementation Environment
In practice, the complexity of the real life environment has meant that many generalizations and approximations have to be made in the design and planning process. Inevitably, this will lead to departure of the actual performance from the design objective at least in isolated areas or under specic conditions. Many of the shortcomings in the radio planning process will not be obvious until the part of the network becomes life. This will lead to customer dissatisfaction and an increase in the volume of complaints to an operator. It is, therefore, that network optimization is a necessary and inevitable activity.
Version 01 e
issue d
1-5
9W530
Accuracy of Radio Planning
There are many factors which affect the accuracy of cell planning. These may be due to the resolution and the accuracy of the planning tool and the input data. Some of the key reasons are highlighted in the following table.
Source Path loss modeling Signal fading modeling Terrain database Morphology database Calculation intervals Antenna radiation pattern
Reason for incurring error Statistical modeling by linear regression and approximation in diffraction modeling Statistical characterization of the mobile environment by known probability functions Finite resolution of the terrain maps and the accuracy of digitizing contours and terrain features Finite resolution and categorization of land use Finite resolution of the incremental steps in the calculation process Finite resolution in the digitalization of the antenna radiation patterns and the extrapolation of the three-dimensional radiation patterns from the vertical and the horizontal plane patterns
Frequently the deviation is not due to a single factor but a myriad of convolved reasons. For instance, the characterization of the radiowave environment is statistical rather than deterministic. With statistical radiowave propagation models, the prediction of radio coverage has to be associated with a probability. The uncertainty is further increased by the nite resolution of and the inevitable approximation made in the terrain and morphology databases. Naturally, the physical environment is not static and is constantly evolving over time. In particular, the morphology database will rarely be able to keep up with the changes of man-made structures due to continual construction and demolition of buildings across the service area. Even if the database is up-to-date, there is always a time lapse between successive cycles of network replanning and retuning. The seasonal variations in the vegetation and foliage as well as the more unpredictable changes in the atmospheric conditions are yet adding further uncertainties in the precision of the cell plan. For these reasons, a signicant planning margin has to be incorporated in order to protect the network performance. For a network with near uniform trafc distribution, such as across a city centre, the outage statistics across the area can almost be directly translated to the proportion of dissatised customers. For instance, a ve percent coverage outage can result in ve percent dissatised customers in the network.
1-6
Version 01 e
issue d
9W530
Implementation
Apart from inherent error sources due to the cell planning tool, practical constraints in the physical implementation will also lead to further sources of error. Some of these are illustrated in the following table. As we can see, many of these deviations are beyond control of cell planners and once again, a sufcient planning margin should be allowed in the planning process to protect inadvertent performance degradation due to implementation uncertainties and practicalities.
Sources Antenna radiation pattern and effective radiated power Antenna radiation pattern distortion Antenna height and ground height Antenna orientation and downtilt
Reasons for incurring errors The variation of the antenna gain due to tolerance in the manufacturing processes and the aging of the antenna construction over time Distortion of the radiation pattern due to the physical mounting arrangement and the physical location of the mounting structure (e.g. mounting against a water tank at a roof top). The accuracy of the antenna height estimation above mean ground level and the spot height of the location where the antenna structure is installed The accuracy of aligning the azimuthal and the vertical angles of the antenna. For the azimuthal angle, this is due to the alignment process, while for the vertical angle, this is due to the precision of the downtilt bracket The accuracy of cable loss and connector loss estimation and the accuracy of the measurement process if the insertion loss is measured physically on site The adoption of averaged loss value as provided by the vendor The adoption of reference sensitivity for link budget calculations and the variation of the performance of individual receiver due to tolerance in the manufacturing process
Cable loss and connector loss Combiner loss Base site and mobile receive sensitivity
Version 01 e
issue d
1-7
9W530
1-8
Version 01 e
issue d
9W530
Environment
A third key source of error is due to the dynamic nature of a mobile environment. This is depicted in the following table. In particular the position of the handset as adopted by individual customers in sending and receiving calls, the body loss, the building and vehicle penetration loss as well as the efciency of the handset antennas (retracted versus extended position) can only be estimated by a cell planner. A large standard deviation can exist among the value of these parameters for individual customer which can lead to a variation in the perception of service quality.
Sources Physical environment Body loss
Reason for incurring errors Due to new buildings, highways, trafc patterns and foliage The shielding and detuning by the head and the distortion of the mobile antenna radiation pattern due to the dielectric and conductive nature of a human body The signal attenuation due to the construction material of a building as well as the aspect of the building in relationship to the base site The location of the handset inside the vehicle and the aspect of the vehicle relative to the base site The diversity gain is related to the scattering radius within an environment. For a more scattering area, the diversity gain is higher The signal to noise gain from frequency hopping is related to the mobile speed. For slow moving mobiles, the gain is higher. The physical construction of the handset antenna and whether a customer extends or retracts the antenna when placing or receiving a call. Handset not located at an optimal position, e.g. lying at on a desk top or placed inside a pocket
Building penetration loss
Vehicle penetration loss Diversity gain
Frequency hopping gain Handset antenna efciency
Handset position
NOTE:
This is a source that falls outside the scope of optimization, but can cause problems in the network
Version 01 e
issue d
1-9
9W530
Check Network Administration
Preparation Phase
Identify Stable Regions
Sub-Network Definition Phase
Perform Functional Tests
Perform Measurements
Identify Locations with e.g. High Call Failure Rate, Call Setup Problems or Bad RX Quality
Quality Assessment Phase
Optimization Phase
Perform Detailed Measurements in those Locations
Identify Optimization Problem
Suggest Solutions and Predict Effects
Implementation of Solution Chosen
Repeat Measurements
Evaluate Results
Problem Solved
no yes
Figure 1-2.
1-10
Version 01 e
issue d
9W530

DEFINITION
1
1
Network optimization is a continuous process that generally consists of the following two steps:
s
Measure the cell performance of the operating cellular network to determine its current status, and Improve the cell performance of the network using the measurements as input, if applicable.
The network optimization process starts before the cellular network comes into (commercial) operation. However, network optimization is much more important when the network is in full operation (after the commercial launch). For example, the following effects can only be properly evaluated when the amount of trafc in the network is growing:
s s s
Capacity bottlenecks, Uplink interference level, and Down-link interference level due to additional TRXs (transceivers) in each cell as the capacity of the network is increased.
PHASES
1
The network optimization process consists of the following phases: 1. 2. 3. 4. 5. Preparation Denition of sub-networks Quality assessment Optimization Re-assessment
The network optimization process is illustrated in the gure on the opposite page. The different phases of the network optimization process are discussed in the following sections.
Version 01 e
issue d
1-11
9W530
Preparations in phase I: Create a database for optimization problems. Retrieve cell site information. Select the measurement devices.
Requirements in phase II: All BSSs reached the operational status. All neighbor cells are in place and operational. The nearest co- and adjacent channel cells are in place and operational.
1-12
Version 01 e
issue d
9W530
Phase I - Preparation
The network optimization requires controlled and documented planning procedures and a disciplined approach to network operation and quality. For this purpose a data base has to be available to log progress of each optimization case. For example, the following information has to be stored for each optimization case: optimization problem, date and time, suggested solutions and results of solutions implemented. A requirement which must be met before the actual network optimization can start, is that the data bases related to the cellular network are properly maintained; the data bases must reect the current state of the network. The following information must be properly available: cell sites, frequencies used, handover parameters, coverage, interference levels and cell boundaries. In order to survey the network, output reports of the following devices can be used:
s s s
The GSM OMC (Operations and Maintenance Center) Test mobile vehicles Hand-portable terminals
This is only possible when sufcient test mobile vehicles and hand-portable terminals are available.
Phase II - Denition of Sub-Networks
In the second phase of the network optimization process, the stable sub-networks (or regions) of the cellular network are identied. A stable sub-network is that part of the cellular network that meets the following requirements:
s
All BSSs in that particular sub-network have reached the operational status, All neighbor cells are in place and operational, and The nearest co- and adjacent channel cells are in place and operational. Note that a co-channel cell of a particular cell is a cell that uses the same frequencies. An adjacent cell of a particular cell is a cell that uses one or more adjacent frequencies.
s s
Typically, a sub-network consists of 10 to 12 BSSs with in total approximately 30 cells. The area covered by a sub-network can be, for example, a small town in a low density rural area or a business center in an urban area. The reason for dividing the cellular network into sub-networks is to reduce the complexity of a performance problem by, for example, ignoring the inuence of instable regions.
Version 01 e
issue d
1-13
9W530
Means in phase III: Functional system checks. OMC-PMS statistics. Drive testing. Customer feedback.
Steps in phase IV: Analyse the retrieved data. Identify the problem. Suggest solutions and predict side-effects. Implement solution. Perform measurements to evaluate the solution. Log the solution, and results in the optimization database.
1-14
Version 01 e
issue d
9W530
Phase III - Quality Assessment
In the quality assessment phase the performance of the cellular network is evaluated in order to identify sub-networks causing problems (i.e. sub-networks with a high call failure rate). The means to perform quality assessment are:
s
Functional system checks The functional system checks are used to test if the BSS equipment is properly functioning. This kind of network observation is normally performed by the OMC. OMC-PMS statistics The OMC-PMS (Operations and Maintenance Center - Performance Management Subsystem) collects measurements data from the connected BSSs and MSCs. This performance evaluation tool can be used to analyze the measurements data. During analyzing of the BSS measurements data, the following parameters are in particular of interest: Downlink quality of the signal measured by the mobile station (RXQUALDL) Downlink signal level measured by the mobile station (RXLEVDL) Mobile station transmit power Call set-up time Number of handovers per call Time between handovers Reason for handovers Number of dropped calls These parameters can, for example, be compared to thresholds specied. Note that it not possible to determine all problems using the OMC-PMS. It is, for example, not possible to detect an interference problem in the network, you only can get an indication of the presence of a possible interferer by looking to the reasons for handovers.
Version 01 e
issue d
1-15
9W530
Drive testing Drive tests are performed using a trafc mobile system. A trafc mobile system can consist of test mobile vehicles and/or hand-portable terminals. These pieces of equipment are used to generate (automatically) calls and, optionally, to store the measurements in details and subsequently analyze them. Especially, measurements related to handovers and received signal levels are of interest. In comparison to using the OMC-PMS statistics, drive testing has the disadvantage that it is more time consuming, more labor intensive and can increase the network loading (because test calls are usually generated during working hours).
Customer feedback Customer complaints or other sort of feedback can be used to evaluate the performance of the network. Customers can complain about, for example, a poor speech quality, a high rate of dropped calls, failed call set-ups and a poor coverage in a particular cell or area. Note that the value of customer feedback should be assessed carefully. The feedback analyst need to be aware that customer perception is normally subjective and could be dependent on many factors including the quality of the handset and specic pattern of the handset utilization by an individual customer.
Phase IV - Optimization
The result of the previous phase (quality assessment) is a priority-list with one or more sub-networks causing problems. In the optimization phase, the performance of each of these sub-network is evaluated and is improved. The following steps are performed to optimize a cellular sub-network:
s
Perform detailed measurements to diagnose the cause of the problem. For this purpose the OMC-PMS statistics, test mobile vehicles and handportable terminals can be used. Identify the optimization problem. For example, the problem of a poor speech quality in a particular area of a cell is a coverage hole caused by a large building. Suggest/Identify solutions and predict side-effects. Every optimization solution has side effects, either at the location within the same cell or on neighbor cells.
1-16
Version 01 e
issue d
9W530
Implement the solution chosen. A solution can be, for example, modifying an BSS parameter (at the OMC) or tilting an antenna (at the base station). Only one optimization solution should be taken at a time so that its effect can be measured. Measure the sub-network to verify the predictions. Evaluate the solution chosen using the measurements as input. If the optimization problem is not solved, another solution has to be implemented. The solution chosen, the evaluation and the result of the optimization case should be logged in the progress data base.
s s
Version 01 e
issue d
1-17
9W530
Adjustments Performance Enable BSS Nbour Antenna Frequency Determinants GSM Tilt, Cell ParaChanges etc. Features meters List Coverage Interference Handover Behavior Traffic Distribution
Table 1-1. NETWORK PARAMETER AND PERFORMANCE DETERMINANTS
1-18
Version 01 e
issue d
9W530
NETWORK OPTIMIZATION PARAMETERS
During the network optimization process, the quality or the performance of the airinterface in the cells of a sub-network is determined and, when necessary, improved by adjusting network parameters. The factors that determine this performance are called performance determinants. The following performance determinants should be taken into account:
s
Coverage
The quality of the air-interface in a cell with respect to coverage is good when there are no coverage holes. This means that the signal level is good enough to receive across the whole cell.
Interference
The quality of the air-interface in a cell with respect to interference is good when the interference in the cell is at a reasonable level.
Handover behavior
The quality of the air-interface in a cell with respect to handover behavior is good when no unnecessary handovers are performed and the signal quality received by the mobile stations is at a reasonable level, and mobile and BTS can use minimum power.
Trafc distribution
The quality of the air-interface in a cell with respect to trafc distribution is good when a maximum amount of trafc can be handled. In order to handle more trafc, the cell size is made smaller.
The following parameters can be adjusted in order to solve problems that occur in the performance determinants mentioned above:
s s s s s
Enable or disable GSM features BSS parameters Neighbor cell lists Antenna tilt, height and direction (antenna parameters) Frequency changes
The table on the opposite page gives the relation between the parameters that can be adjusted and the performance determinants. The different parameters that can be adjusted in order to solve the problems in a sub-network, are discussed in the following sections.
Version 01 e
issue d
1-19
9W530
Discontinuous Transmission: Advantages:

s
Decreases interference level Saves battery power (in uplink mode)
Disadvantage:
s
Deteriorates transmission quality
Frequency Hopping: Advantages:

s
Decreases the probability of interference Suppresses the effect of Rayleigh fading
Power Control: Advantages:

s
Saves battery power (when enabled to MS) Decreases interference level (when enabled to MS and BS)
1-20
Version 01 e
issue d
9W530
ENABLE/DISABLE GSM FEATURES
In a GSM cellular network optional features can be enabled or disabled. The GSM features which can inuence the performance of the air-interface are:
s s s
DTX (Discontinuous Transmission) Frequency Hopping Power Control
Discontinuous Transmission
DTX inhibits the transmission of the radio signal when not required from an information point of view. In the DTX mode, speech is encoded at 13 Kbit/s when the user is effectively speaking, but in a speech pause information is transmitted at a bit rate around 500 bit/s. This low rate ow is sufcient to encode the background noise, which is re-generated to ensure that the listener does not think that the connection is broken (comfort noise). DTX may be applied independently to each direction, so that the control of DTX must take into account two components:
s s
The uplink mode The downlink mode
When DTX is applied, actual transmission on the radio path is reduced. This will cause a decrease of the interference level in co-channel cells (using the same frequency). Another advantage will appear when using DTX in the uplink mode: it saves battery power for the mobile station. However, a disadvantage of the DTX mode is that it slightly deteriorates the quality of transmission. Note that transmitting in DTX mode does not save time slots on the air-interface.
Version 01 e
issue d
1-21
9W530
Performance Determinants:
Solution:
Local Signal fluctuations
Enable Frequency Hopping
Enable DTX Interference Enable Frequency Hopping Enable Power Control
Figure 1-3.
IMPROVEMENT SCHEME ASSOCIATED WITH ENABLE/ DISABLE GSM FEATURES
1-22
Version 01 e
issue d
9W530
Frequency Hopping
The Frequency Hopping feature changes the frequency used by a channel on the air-interface every new TDMA frame in a regular pattern. The advantages of using Frequency Hopping are:
s
Decreasing the probability of interference

Frequency Hopping will spread the annoyance of interference over different mobile stations in a particular cell.
Suppressing the effect of Rayleigh fading

Rayleigh fading (or multipath fading) is caused by different paths followed by the radio signal. Rayleigh fading can cause coverage holes. Rayleigh fading is location and frequency dependent. When the mobile station is stationary or moves at a slow speed, Frequency Hopping will signicantly improve the level of the air-interface performance. However, when the mobile station moves at a high speed, Frequency Hopping does not harm, but does not help much either. The more frequencies are used in a particular cell, the more Frequency Hopping can gain in suppressing the effect of Rayleigh fading.
Power Control
Power Control enables the mobile station and/or the base station to increase or decrease the transmit power. It can be enabled for the mobile station and/or the base station. The mobile station adopts power according to the base station power control commands. This will save mobile station battery power. However, the main reason for Power Control is reducing the interference level within the cellular network. Reducing power on the base station or the mobile station, while keeping similar signal quality received, decreases interference caused on the other calls in the surrounding area. If Power Control is disabled for the mobile station, the mobile station will always transmit at maximum power level. The same is applicable for the base station: if Power Control is disabled for the base station, it will always transmit at maximum power level.
Version 01 e
issue d
1-23
9W530
Solution:
Interference Handover behavior Traffic distribution Adjust BSS parameters
Figure 1-4.
IMPROVEMENT SCHEME ASSOCIATED WITH BSS PARAMETERS
1-24
Version 01 e
issue d
9W530
BSS PARAMETERS
The quality of the air-interface can be improved by adjusting the BSS parameters. BSS parameters are user-controllable parameters which are used to dene the conguration, system services and characteristics of the cellular network. They consist of thresholds, margins, timers and other types of parameters. The BSS parameters are normally modied at the OMC. The BSS parameters signicantly control the network behavior with respect to the handover performance and the power control performance. Examples of BSS parameters are:
s
Power Control thresholds, when exceeded, transmit power increase or reduction is initiated Power Control reduction or increase steps, indicating the number of dBm that the transmit power is reduced/increased when Power Control is initiated Signal level and quality handover thresholds, when exceeded, a handover to another cell is performed
Note that the BSS parameters can only be used for ne tuning of the performance of the network.
Version 01 e
issue d
1-25
9W530
B A
MS
MS
A'
Figure 1-5.
EXAMPLES RELATED TO NEIGHBOR CELL LISTS
Solution:
Interference Handover behavior Traffic distribution
Add neighbor cell definition Add/remove neighbor cell definition Add/remove neighbor cell definition
Figure 1-6.
IMPROVEMENT SCHEME ASSOCIATED WITH NEIGHBOR CELL LISTS
1-26
Version 01 e
issue d
9W530
NEIGHBOR CELL LISTS Denition
1 1
The neighbor cell list contains the cell identiers to which a handover is allowed. It is kept in the BSC of a particular cell. The list is transferred to the mobile station in the BCCH during the registration phase of a wireless call. The mobile station uses the neighbor cell list by only measuring the signals from the base stations located in the cells that are on the list. The measurements are used to decide a handover or Power Control adjustment.
Optimization Impact
It is essential to limit the neighbor cell list only to those cells that are really necessary (approximately 6 to 8). The reason for this is that the mobile station can only measure a limited number of signal level samples of the neighbor cell in a report interval (480 ms). This maximum number of samples measured is about 100. The more neighbor cells are measured, the less precise are the measurements. For example, when the neighbor cell list contains 6 cell identiers, 16 to 18 samples can be taken by the mobile station. When it contains 32 cell identiers, three to four samples can be taken. When the measurements are not precise enough, the probability of an incorrect handover decision will increase. However, a too short neighbor cell list can lead to more dropped calls, because of missing potential best handover-candidate cells. Another consequence of a too short neighbor cell list can be a higher interference probability. This is caused by an unnecessary increased transmit power of the currently serving base station.
Scenarios
The gure on the opposite page depicts two scenarios related to the neighbor cell list. If the mobile station moves from cell A to cell B, while cell B is not on the neighbor cell list of cell A and cell B would be the best candidate cell, then base station A could continue sending at maximum transmit power, until for example the cell will be dropped or taken over by base station D with a low signal quality. In area A, base station A produces the best signal level, because the signal from base station C is shadowed by a large obstacle and is therefore weaker than the signal from base station A. However, the signal from base station C in area A is sufcient to do the job. The mobile station moves from cell C via area A back to cell C. To avoid unnecessary handovers, cell A is not included in the neighbor cell list of cell C. Note that it is possible to put cell C in the neighbor cell list of cell A (this implies an asymmetric neighbor relationship).
Version 01 e
issue d
1-27
9W530
Performance Determinants: Coverage Interference Traffic distribution and congestion
Solution: Antenna tilt Antenna height Antenna direction
Figure 1-7.
IMPROVEMENT SCHEME ASSOCIATED WITH ANTENNA PARAMETERS
1-28
Version 01 e
issue d
9W530
ANTENNA PARAMETERS
Also the antenna parameters can inuence the performance of the air-interface. The antenna parameters are comprised of:
s s s s
Antenna tilt Antenna height Antenna direction Antenna radiation pattern
Tilting an antenna reduces the power transmitted in the horizontal direction. It decreases the distance between the base station and the cell edge, and increases the signal strength near the base station site. This results in an improved interference situation in this particular cell. The antenna parameters can also be used to change the coverage in the particular cell by, for example, tilting the antenna, positioning the antenna higher in the antenna mast or change the transmit/receipt direction of the antenna.
Version 01 e
issue d
1-29
9W530
B
f1 f2
B
f1 f2
f1 f2
f3 f2
Figure 1-8.
FREQUENCY CHANGES
Performance Determinants: Interference
Solution: Change frequencies
Figure 1-9.
IMPROVEMENT SCHEME ASSOCIATED WITH FREQUENCY CHANGES
1-30
Version 01 e
issue d
9W530
FREQUENCY CHANGES
In order to improve the performance of the air-interface in a sub-network, the frequencies used by the base stations in that sub-network can be changed. Retuning of the frequencies used may be necessary due to unexpected interference. Refer to the gure on the opposite page. A mobile station positioned in cell A is interfered by frequency f1 in cell B for some reason (Terrain or low serving RXlevel). When cell A will change this frequency to frequency f3, the interference probability of cell B in cell A may decrease. .
Version 01 e
issue d
1-31
9W530
1-32
Version 01 e
issue d
OMC-2000 FUNCTIONAL DESCRIPTION
2
2-1 2-1 2-1 2-1 2-3 2-3 2-5 2-5 2-7 2-7 2-9 2-9 2-11 2-13 2-13 2-15 2-17 2-19 2-19 2-19 2-19 2-19 2-20 2-21 2-22
Contents
INTRODUCTION TO THE OMC-2000 FUNCTIONAL DESCRIPTION
s s s
LESSON INTRODUCTION LESSON OBJECTIVES DOCUMENTATION
OVERVIEW
s
THE OMC-2000 IN THE GSM NETWORK
THE OMC INFORMATION MODEL

s
OBJECT RELATIONSHIPS
OMC-2000 FUNCTIONALITIES
s s s s
CONFIGURATION MANAGEMENT FAULT MANAGEMENT PERFORMANCE MANAGEMENT SYSTEM ADMINISTRATOR FUNCTIONS
OMC-2000 MAIN SYSTEM PARTS

s s
OMC HARDWARE OMC SOFTWARE
OMC-2000 USER INTERFACES

s
GUI (GRAPHICAL USER INTERFACE) OMC Network Performance Management Fault Management Configuration Management
AUI (ASCII USER INTERFACE)
EXTERNAL OMC-2000 INTERFACES CAPACITY AND CONFIGURATION
Version 03 e
issue c
2-i
Contents
2-ii
Version 03 e
issue c
INTRODUCTION TO THE OMC-2000 FUNCTIONAL DESCRIPTION 2

LESSON INTRODUCTION 2
This lesson gives an introduction of the functions and capabilities of the OMC (Operation and Maintenance Center).
LESSON OBJECTIVES
At the end of this lesson students are able to:
s s s s
Explain the position of the OMC in the GSM network Describe the OMC functionalities and tasks Identify the OMC hardware, LAN and I/O components Identify the different User Interfaces
DOCUMENTATION
The documentation for this lesson is:
s
The SOG (Lucent Technologies GSM System Operations and Maintenance Center 2000 System Operators Guide). The AG (Lucent Technologies GSM System Operations and Maintenance Center 2000 Administration Guide)
Version 03 e
issue c
2-1
6W002
Figure 2-1.
2-2
Version 03 e
issue c
6W002
OVERVIEW
This chapter explains the position of the OMC in the GSM network. Also the main interfaces to and from the OMC are discussed.
The OMC (Operations and Maintenance Center) manages the BSS (Base Station System) in a GSM network. The BSS provides digital cellular call processing and switching between mobile stations and between mobile stations and the public switched network and consists of the BTS (Base Transceiver Station), BCE (BSS Central Equipment) or BCF (Base Station Controller Frame), the TCE (TransCoding Equipment) or STF (Speech Transcoder Frame). Through the OMC full access to the operations and maintenance functions of the BSS can be obtained via an O-interface. The OMC provides conguration management, fault management and performance management for the BSS and the 5ESS-2000 Switch MSC, including GSM specied subscriber databases. The gure on the opposite page shows the relationships between the OMC, the BSS, and the public telephone network.
Version 03 e
issue c
2-3
2-4
GSM Network
1 7140 48 28
Version 03 e MMN
2 1 CLK 8 1 BCON MCON 1 [8] [16] (2) EXTC 1 1 1 2 STC 1 4 SLC 1 2 PSC 1 BTC 1 8 1 3 1 1 CCG 4 1 RT 1 CHN 8 24 1 PST 1 PSM 1 PwrCtrl 32 AdjRes [96] (12) 1 n m 1 HoCtrl 32 OutAdjCell PG SW BTS CCMP 1 MPC 1 144 LapdLink 1 2 SDU PCS LINK 3 1 MEAS BSC 30 1 26 9 48 1 OPC 1 1 LSET 1 4
Figure 2-2. BSS ErrorDenition
issue c
FH
[48] 1 ARU
26
TCG
Log
TCB
TRC
OMC INFORMATION MODEL
Lucent Technologies Proprietary See notice on rst page n m
[720]
IncAdjCell
LEGEND
[nn] = per BSS limit (nn) = per BTS limit
Precongured object in BSS
Reference Relationship (n objects point to m objects) Containment Relationship (from n superiors to m subordinates)
6W002
6W002
THE OMC INFORMATION MODEL 2

The OMC is based on the management information model. This model represents all of the objects in the BSS system and their relationships to each other. Understanding the OMC information model is important. Certain objects are created automatically, while you must create others manually. Also, not all objects can be modied and/or deleted. Much of this stems from their position in the hierarchy or tree. The gure on the opposite page illustrates the OMC information model. In the gure, italicized terms indicate virtual objects. For example, the objects POWER, HOCTRL (handover control), ADJCELL (adjacent cell), ARU (alarm relay unit), and ADJRES (adjacent cell reselect) are virtual objects within the BTS physical object. The importance of understanding how the system components interrelate becomes clear, for example, when handling BTS error messages and troubleshooting. In such cases, it helps to know that an error could be coming from a POWER or HOCTRL object within the BTS.
OBJECT RELATIONSHIPS
Through the OMC you cannot only view objects, but you can also create, delete, and modify them. Looking at the previous gure you can see that objects can be related in either of two ways: by a containment relationship or by a reference relationship.
s
A containment relationship exists when one object contains another, in a parent-child hierarchy. An example of this is when a BSS has one or more Base Transceiver Stations (BTSs) under it as child objects. Containment is reected in the full distinguished name of an object. An example of such a path name is BSS:10-BTS:14-BTC:0, which shows BTC:0 within BTS:14, and BTS:14 within BSS:10. A reference relationship, sometimes called a service provider relationship exists when one object relies on the services of another. An example of a reference relationship is when a Radio Terminal (RT) refers to LAPDLink. In some cases, a service-providing object may need to be created before you create the service user. For example, there should be a B Connection (BCON) object available before creating a Base Transceiver Station (BTS) object.
The design of the OMC allows you to view the containment and reference relationships between objects.
Version 03 e
issue c
2-5
6W002
s
Conguration Management Fault Management Performance Management Graphical User Interface System Administration Tasks
CONFIGURATION MANAGEMENT
s
Viewing BSS conguration and status Creating, modifying, and deleting BSS objects State management Software administration Audits
2-6
Version 03 e
issue c
6W002
The OMC provides operation and maintenance control capabilities from one central location based on the management information model. To perform daily operational routines the OMC provides the following tasks on the BSSs:
s s s s
Conguration management Fault management Performance management System Administration
The rst two tasks can be performed either from AUI (ASCII User Interface) or GUI (Graphical User Interface) terminals of the OMC. The performance management tasks can be done only from the GUI. Besides, performance management resides on a different platform, the OMC Performance Management Subsystem.
CONFIGURATION MANAGEMENT
The OMC provides the following BSS conguration management capabilities:

s s s s
Viewing BSS conguration and status Creating, modifying, and deleting BSS objects Managing object states Software administration for BSS loadable units
The OMC allows remote BSS conguration. A BSS is initially congured using a bulk load tape containing the BSS software and its conguration. As the network grows, additions and provisioning changes are done from the OMC. Provisioning may also be based on performance and fault information.
s
Audits to synchronize data in both OMC and BSS MIB
The MIB (Management Information Base) stores all system information on all system objects, their attributes, and their states. All BSS objects are stored in the system twice: once in the OMC MIB and once in the BSS MIB. An audit function automatically correlates the MIBs in both the OMC and BSS. The audit data from the BSS is compared with the conguration in the OMC database. The OMC MIB automatically updates its information and an audit mismatch record is generated. By using various combinations of these conguration management operations, you can:
s s s
Install new cell sites Install new trafc channel capacity Perform maintenance functions such as loading new software or restarting a piece of equipment that has failed
Version 03 e
issue c
2-7
6W002
FAULT MANAGEMENT
s
Alarms (event reports) indicating abnormal conditions for the BSS Alarm management functions: acknowledging and clearing alarms Alarm correlation Fault tracking records Support for external alarms
PERFORMANCE MEASUREMENTS
s
Gathering Performance Measurements Storing Performance Measurements Analyzing Performance Measurements
2-8
Version 03 e
issue c
6W002
FAULT MANAGEMENT
The Fault Management area of the OMC handles event and alarm messages received from the BSSs connected to the OMC. The OMC collects and classies these events and alarm messages, and displays the appropriate status to OMC operators. The idea behind having an integrated Fault Management subsystem is to increase system availability by providing the OMC with the ability to monitor the network and detect faulty equipment or objects as soon as possible. Specically, the BSS detects faults and state changes within the network by monitoring the network elements. When the BSS detects problems, it reports them to the OMC, which uses the information to display status reports to network operators. These reports contain information about the causes of errors, the equipment that is faulty, and the defensive actions the OMC will take to resolve the condition(s). Whenever possible, errors are corrected by the BSS itself. In some cases, defensive actions are implemented not only to correct the error, but to minimize the impact of the error on the network. If the BSS cannot correct itself, the operator notication includes information about the maintenance procedure that must be performed to eliminate the problem(s). Monitoring of BSS alarms and management of alarms are included in the fault tracking system. Management capabilities include:
s s s s s
Alarms (event reports) indicating abnormal conditions for the BSS. Alarm management functions: acknowledging and clearing alarms. Alarm correlation. Fault tracking records. Support for external alarms.
PERFORMANCE MANAGEMENT
The Performance Management capabilities of the OMC let you collect, store, and analyze measurements that the Base Station System (BSS) collects from specied Base Transceiver Stations (BTS). Measurements consist of calculations or data collected about the performance of different aspects of the BSS and its associated BTSs. The OMC stores the measurements for a period of time during which the data can be used to create a performance prole of the network. Performance Management data allows you to measure such things as quality of service, plan network conguration and growth, and improve network availability and reliability. Performance measurements capabilities include:
s s s
Gathering Performance Measurements Storing Performance Measurements Analyzing Performance Measurements
Version 03 e
issue c
2-9
6W002
2-10
Version 03 e
issue c
6W002
SYSTEM ADMINISTRATOR FUNCTIONS
Certain tasks within the OMC environment are the responsibility of the OMC system administrator. Although a typical user can access most of the OMCs capabilities, only the system administrator has the authority to perform the following tasks:
s
Workstation administration (adding, deleting, and modifying workstation information) User Administration (adding, deleting, and modifying user accounts) Loading error denition les Maintaining the network clock
s s s
Each of these tasks, as they apply to the system administrator, is explained in the System Operators Guide.
Version 03 e
issue c
2-11
6W002
Figure 2-3.
HARDWARE OF OMC-2000
2-12
Version 03 e
issue c
6W002
OMC-2000 MAIN SYSTEM PARTS
The Lucent Technologies GSM OMC server provides the OMC application services. All of the system processes execute on this node. The gure on the opposite page shows the relationship between the components of the OMC System. The system is under control of a UNIX server. The workstations, both AUI and GUI, can be assigned with partitioning in either function control or limits, or geographical location control, or a mix of both. The OMC administrator assigns these limits to the operator associated with a particular login.
OMC HARDWARE
The OMC consists of an HP server system and HP workstations and X terminals connected to the server via local and remote LANs. Operators may also connect to the OMC from local or remote ASCII terminals through a terminal server. The server is capable of supporting a large amount of main memory and several gigabytes of disk storage. The server has a Lucent Technologies GSM OMC LAN interface and X.25 interfaces. The OMC consists of an HP server (D350) with:
s s s s s s s s
512-MB on-board RAM Five (5) 2-GB external disks, mirrored, total 20 GB Two (2) 4-GB external disks, mirrored, total 16 GB Two (2) SCSI interface cards 4-8 GB DAT drive Console, keyboard Two (2) ACC card (each card supports up to eight X.25 links). One (1) CD ROM drive
The OMC operator workstation consists of:

s s s s
128-MB on-board RAM 2-GB disk 19" color monitor, keyboard, and mouse A CD ROM (optional)
Version 03 e
issue c
2-13
6W002
OMC HARDWARE The Server consists of:

s
512-MB on-board RAM Ten (10) 2-GB external disks Four (4) 4-GB external disks 2 Tape drives (DAT and cartridge) Console and keyboard
The Operator workstation consists of:

s
128-MB on-board RAM 2-GB disk 19" color monitor, keyboard, and mouse
The Network consists of:

s
A Terminal Server Routers, Hubs, X.25 PAD
OMC SOFTWARE
s
OMC Application BaseWorX SYBASE DataViews, FrameViewer, SwitchTerm
2-14
Version 03 e
issue c
6W002
The network consists of:

s
The HP DTC-16TN Terminal Server that supports local and remote ASCII terminals and access to external systems through serial ports. The HP SR Router The HP Ethernet Hub Plus Communications facilities for the terminal server and routers. Modems X.25 PAD
s s s s s
OMC SOFTWARE
There are four software applications that comprise the OMC Server software. They are:
s
Operating System
The server software consists of the HP-UX 10.0 operating system with:
s s s
Platform Applications OMC Application The server third party applications: SYBASE* - This software package supplies the Relational Database Management System. The OMC MIB is contained in the SYBASE Database. BaseWorX6.1.- This Lucent Technologies software package is used to build the OMC application, and to support OMC functions, such as OA&M (operations, administration, and maintenance), and communications. FrameViewer4.0 - This desktop publishing system is used to support the OMC HELP function. DataViews 9.5 - This software package allows the Graphical User Interface (GUI) to display maps and graphical views. SwitchTerm 4.1 - This software package supports the connection to the MSC.
For more information about the software refer to the Installation manual.
SYBASE is a registered trademark of Sybase, Inc. BaseWorX is a trademark of Lucent Technologies. FrameViewer is a registered trademark of Frame Technology Corporation. DataViews is a registered trademark of V.I. Corporation.
Version 03 e
issue c
2-15
6W002
GUI (Graphic User Interface)

s
X Windows/Motif based point and click interface A graphical display On-line help function
AUI (ASCII User Interface)

s
An MML based command line interface Batch script capability On-line help function
2-16
Version 03 e
issue c
6W002
OMC-2000 USER INTERFACES
One of the main functions of the OMC is to provide access to the BSS network. The BSS network can be accessed via:
s s
The GUI (Graphical User Interface) The AUI (ASCII User Interface)
When you log in to the OMC from a workstation, you typically access the system through the GUI. The GUI has the following features:
s s s
X Windows/Motif based point and click interface A graphical display On-line help function
The AUI provides a command line interface for operators accessing the OMC via an ASCII terminal. The AUI can also be started via a window on the workstation. The AUI has the following features:
s s s
An MML based command line interface Batch script capability On-line help
Version 03 e
issue c
2-17
6W002
Figure 2-4.
GRAPHICAL USER INTERFACE (GUI) DESKTOP
Figure 2-5.
EXAMPLE OF A LOGICAL VIEW OF A BSS
2-18
Version 03 e
issue c
6W002
GUI (GRAPHICAL USER INTERFACE)
When you start up the GUI the OMC Desktop appears on the screen (see gure). From the OMC desktop the following functional areas can be accessed:
s s s s
OMC Network Performance Management Fault Management Conguration Management
OMC Network
From the OMC Network icon you can access the following areas:
s s s s
the Topographical view of the BSS network. the BSS browser view which shows all connected BSSs. the OMC detailed view. the Error Records browser.
Performance Management
From the Performance Management icon you can access the following areas:
s s s s
Measurement Scheduling Measurement Records Performance Management Subsystem. Access the Basic Performance Management Report.
Fault Management
From the Fault Management icon you can:
s s s s
Display the alarm browser. Display the Fault Tracking Records Browser. Display the Error Denition Browser. Access the Locked or Disabled Object Report.
Conguration Management
From the Conguration Management icon you can:

s s s
Congure the GSM network through the logical view (see gure). Access the Audit Records Browser. Access the Log les.
Version 03 e
issue c
2-19
6W002
AUI (ASCII USER INTERFACE)
The AUI is a non graphical interface which can be used for direct commands and to execute commands stored in a script le. The bulk load script les provided by Lucent Technologies are especially useful during the initial conguration stage of your GSM network. Batch operations are ordered sequences of New, Modify or Delete requests, that you assemble into a batch, which you can then execute as a single request. This tool is useful to experienced users who want to create a number of similar requests, and then run them as part of a batch. Once the batch request is made, the OMC automatically executes the items in the group in sequence. You can only execute batch operations from the ASCII User Interface (AUI) mode. However, the modication requests and objects created are visible in GUI mode while batch operations are executing from the AUI. Use a text editor to create script les. It is not possible to edit script les within the AUI. Once you create and save the scripts in a directory, you can run them from the AUI. The AUI uses a standard MML (huMan Machine Language) as dened by the ITU-T. An MML command consists of:
s s s
A command verb (denes the action) An object (denes the (logical) unit) Parameters (object attributes)
For a detailed description of the MML commands refer to the System Operators Guide.
2-20
Version 03 e
issue c
6W002
EXTERNAL OMC-2000 INTERFACES 2

The OMC interfaces to the BSS through the O interface. This allows the BSS to communicate with an OMC in a DTE conguration. The interface is dened by the X.25 interface specication.
Version 03 e
issue c
2-21
6W002
CAPACITY AND CONFIGURATION 2

The OMC-2000 hardware platform is powered by a 204 to 264 V (240 V AC nominal) single phase power supply of 48 to 62 Hz and dissipates roughly 150 W. Terminals such as Notebook PCs or Workstations or Printers dissipate between 40 W and 120 W. The OMC standard conguration consists of one Operations and Maintenance Processor (OMP) with one ACC card and two local workstations. One ACC card can support eight direct connections (to 8 BSSs), or up to 48 virtual circuit connections to the BSSs (supported with 4600 Transceivers) Optional components for the OMP are:
s s s s s
Additional disks for mirroring Additional local workstations for a maximum of 16 Additional remote workstations for a maximum of 16 (local and remote) Additional ACC cards for a total of six Additional X.25 links and other associated components to support management.
The OMC Performance Management Subsystem (OMC-PMS) is a highlyrecommended option. Additional disks for mirroring and additional local workstations (3 more, for a total of 4) are an optional feature. Other capacities are as follows:
s s
3 MSCs 48 users (16 simultaneous logins)
2-22
Version 03 e
issue c
BSS PARAMETERS AND FUNCTIONS
3
3-1 3-1 3-1 3-3 3-5 3-5 3-5 3-7 3-7 3-7 3-9 3-11 3-11 3-11 3-13 3-15 3-17 3-19 3-21 3-21 3-21 3-23 3-25 3-25 3-25 3-27
Contents
INTRODUCTION TO BSS PARAMETERS AND FUNCTIONS
s s
LESSON INTRODUCTION LESSON OBJECTIVES
GROUPS OF PARAMETERS CELL (RE)SELECTION

s s s
WHAT IS CELL (RE)SELECTION CELL PRIORITY C1 CRITERION Calculation of C1 Operational Aspects
s s
EXERCISE CELL SELECTION C2 RESELECTION CRITERION C2 Criterion Calculation of C2 Cell Reselection For Fast Moving MS Cell Reselection For Slow Moving MS
s s s
TIMING FOR CELL RESELECTION C2 EXERCISE CELL RESELECT HYSTERESIS Example With Reselect Hysteresis Operational Aspects
PARAMETERS
POWER CONTROL RELATED PARAMETERS

s s
WHAT IS POWER CONTROL POWER CONTROL PROCESS RXLEV
Version 01 e
issue c
3-i
Contents
RXQUAL
Averaged Parameter Calculation Example with Quality Averaged Parameter Power Control Evaluation Increase Decrease Uplink and Signal Level Signal Level and Signal Quality Time between Power Control Commands Acknowledge Timer Interval Timer
s
3-27 3-29 3-29 3-31 3-31 3-31 3-31 3-33 3-35 3-35 3-35 3-37 3-41 3-41 3-41 3-43 3-45 3-45
PARAMETERS
HANDOVER CONTROL RELATED PARAMETERS

s s
WHAT IS HANDOVER CONTROL HANDOVER PROCESS Distance Averaged Parameters Cell Structures
HANDOVER CONTROL EVALUATION IN A NON-HIERARCHICAL NETWORK 3-47 Power Budget Handover Intra-cell Handover Interference Boundaries Traffic Load Criteria Calculation of the Traffic Load Criteria Traffic Load Example 3-49 3-49 3-49 3-53 3-53 3-53 3-55 3-57 3-59 3-63 3-63 3-63 3-63 3-63 3-65
TRAFFIC LOAD EXERCISE Handover Control Evaluation in a Network Consisting of a Multiple Cell Layer
PARAMETERS
RADIO LINK
s s s s s
INTRODUCTION PAGING CHARACTERISTICS DISCONTINUOUS RECEPTION PAGING CHANNEL CONFIGURATION PCH CONFIGURATION PARAMETERS
3-ii
Version 01 e
issue c
Contents
Downlink Signaling Failure Counter
3-67 3-69 3-69 3-69 3-71 3-71 3-73 3-73 3-73 3-75 3-77 3-77 3-81 3-82 3-82 3-82 3-82
RANDOM ACCESS
s s s
TRIGGERS RANDOM ACCESS SCHEME RACH CONTROL PARAMETERS Example RADIO LINK FAILURE Radio Link Time Out Radio Link Failure Warning
PARAMETERS
BSS TIMERS
s s s
BSSMAP TIMERS Um TIMERS ANSWERS C1 EXERCISE C2 EXERCISE TRAFFIC LOAD EXERCISE
Version 01 e
issue c
3-iii
Contents
3-iv
Version 01 e
issue c
INTRODUCTION TO BSS PARAMETERS AND FUNCTIONS

LESSON INTRODUCTION
3
3
This lesson discusses the Base Station System (BSS) parameters which can be adjusted in order to improve the quality or performance of the Um- or air-interface. BSS parameters are user-controllable parameters which are used to dene the conguration, system services and characteristics of the cellular network. They consist of thresholds, margins, timers and other types of parameters. The BSS parameters are normally modied at the Operation and Maintenance Center (OMC). The BSS parameters given in this lesson are applicable for GSM software Release 6.5
LESSON OBJECTIVES

s
Explain the BSS parameters which can be adjusted to improve the quality of the air-interface. Explain the effects of adjusting BSS parameters in relation to optimizing the air-interface.
Version 01 e
issue c
3-1
9W535
GROUPS OF PARAMETERS: Cell (re)selection Power Control Handover Control Radio link Signaling timers
AREAS OF IMPROVEMENT: Minimization of interference Handover behavior improvement Trafc distribution Increase call completion
3-2
Version 01 e
issue c
9W535
GROUPS OF PARAMETERS
The BSS parameters which are related to the improvement of the air interface, can be divided into ve groups. Each group consists of parameters which are related to:
s s s s s
Cell (re)selection Power Control Handover Control Radio link Signaling timers
In this lesson these ve groups will be discussed in ve separate sections. By adjusting the BSS parameters improvement in the following areas can be achieved:
s s s
Minimizing interference Handover behavior improvement (avoiding unnecessary handovers). Trafc distribution (a maximum amount of trafc can be handled by each BTS) Increase call completion.
Version 01 e
issue c
3-3
9W535
Figure 3-1. .
CELL SELECTION
CELL_BAR QUALIFY False False True True Table 3-1.
CELL_BAR ACCESS False True False True
Priority for Cell Selection Normal Barred Low Low
Priority for Cell Reselection Normal Barred Normal Normal
CELL PRIORITY LIST
3-4
Version 01 e
issue c
9W535
CELL (RE)SELECTION
WHAT IS CELL (RE)SELECTION
3
3
To ensure that an MS is camped on to a cell with the best transmission quality, the cell selection criteria is introduced. The cell selection is not only for selection of a proper cell but can also be used to nd a better cell. In that case it is called cell reselection. The mobile station attempts to nd a suitable cell by passing through the list in descending order of received signal strength; the rst BCCH channel which satises a set of requirements, is selected. The requirements that a cell must satisfy before a mobile station can provide service from it, are: 1.
It should be a cell of the selected PLMN The mobile station checks whether the cell is part of the selected PLMN. For this purpose the MCC and MNC are used. It should not be barred The PLMN operator may decide not to allow mobile stations to access certain cells. These cells may, for example, only be used for handover trafc. Barred cell information is broadcast on the BCCH to instruct mobile stations not to access these cells. The radio path loss between the mobile station and the selected BTS must be below a threshold set by the PLMN operator
2.
3.
There are two radio path loss cell (re)selection criteria dened by the GSM specications. The rst one, C1, is used for cell selection and reselection. The second one, C2, is used in a hierarchical cell structure for reselection only.
CELL PRIORITY
Cells can have two priority levels, low and normal priority. Suitable cells which are of low priority are only camped on if there are no other suitable cells of normal priority available. Operators may prefer a certain type of cell not to be selected unless it is the only suitable type. The operator may also decide not to allow MSs to camp on certain cells (e.g. cells only used handover trafc). Barred cell information is broadcast on the BCCH to instruct MSs not to camp on these cells. The barred status of a cell depends on the parameters CELL_BAR ACCESS and on the cells priority indicated by CELL_BAR QUALIFY. Table 3-1 shows the relationship between the two parameters for cell selection and cell reselection
Version 01 e
issue c
3-5
9W535
C 1 = ( A Max (B ,0) )
Satised if C1 > 0
Figure 3-2.
C1 CRITERION
3-6
Version 01 e
issue c
9W535
C1 CRITERION
The MS uses a path loss criterion C1 to determine whether a cell is suitable to camp on. The following parameters are used to calculate the C1 criterion:
s s
The received signal level at the MS side. The parameter RXLEV_ACCESS_MIN, which is broadcast on the BCCH, is related to the minimum received level at the MS required for access to the network. The parameter MS_TXPWR_MAX_CCH, which is also broadcast on the BCCH, is the maximum power that a MS may use when initially accessing the network The maximum power of the MS
Calculation of C1
The pathloss criterion C1 can be calculated with the following formula:
C 1 = ( A Max (B ,0) )
Where:
A B
= Received Level Average - RXLEV_ACCESS_MIN = MS_TXPWR_MAX_CCH - max. output power of the MS
except for class 3 GSM1800 MS where:
= MS_TXPWR_MAX_CCH + POWER OFFSET - max. power of MS
The path loss criterion is satised if C1 > 0. This means that a cell can be selected if the C1 value is positive.
Operational Aspects
It is up to the operator to choose the values for RXLEV_ACCESS_MIN and MS_TXPWR_MAX_CCH to obtain the correct compromise between cell boundaries, trafc, and quality of transmission for different classes of mobiles, as well as consistency with the handover algorithms and parameters. A default value for RXLEV_ACCESS_MIN is -102 dBm. A default value for MS_TXPWR_MAX_CCH is 35 dBm.
Version 01 e
issue c
3-7
9W535
BTS2
BTS1
BTS3
Figure 3-3.
CELL SELECTION EXERCISE
3-8
Version 01 e
issue c
9W535
EXERCISE CELL SELECTION
Two mobile stations at nearly the same location, are trying to access a GSM network (refer to the gure on the opposite page). The maximum output power of the handset is 0.8 W (29 dBm). The maximum output power of the car set is 8 W (39 dBm). The table bellow gives the values of the cell selection parameters.
BTS 1 Received level (at MS) RXLEV_ACCESS_MIN CELL_BAR QUALIFY CELL_BAR ACCESS Questions: 1. 2. -75 dBm -90 dBm True False
BTS 2 -80 dBm -85 dBm 35 dBm False True
BTS 3 -85 dBm -90 dBm 35 dBm False False
MS_TXPWR_MAX_CCH 39 dBm
To which BTS will each mobile camp on? What would happen if the operator sets the CELL_BAR ACCESS parameter to False for BTS 2?
Version 01 e
issue c
3-9
9W535
C2 Criterion Calculation:
C2 = C1 + CELL_RESELECT_OFFSET - TEMPORARY_OFFSET H(PENALTY_TIME - T)

(for PENALTY_TIME innity)
C2 = C1 - CELL_RESELECT_OFFSET
(for PENALTY_TIME = innity) Where for non serving cells: H(x) = 0 for x < 0 = 1 for x 0 For serving cells: H(x) = 0
3-10
Version 01 e
issue c
9W535
C2 RESELECTION CRITERION
When an idle MS moves into a hierarchical cell structure, the selected cell can be either a microcell or the umbrella cell. Without the C2 criterion the strongest cell will always be selected, which would be a microcell. When the MS moves into the area covered by another microcell, reselection would again occur. This scenario would continue until the MS left the hierarchical cell structure. If the MS is just passing trough the hierarchical cell structure, this would result in many reselections, thus increasing the signaling load on the system. The C2 reselection criterion enables a fast moving MS to camp on the umbrella cell and remain camped on there until leaving the hierarchical cell structure.
C2 Criterion
In order to optimize cell reselection, additional cell reselection parameters are introduced. The additional reselection parameters are broadcasted on the BCCH of each cell. The cell reselection process employs the C2 criterion which depends on the following parameters:
s
CELL_RESELECT_OFFSET. Applies an offset to the C2 reselection criterion for that cell. This offset can be used to give different priorities to different bands when multiband operation is used. PENALTY_TIME. When the MS places the cell on the list of the strongest carriers, it starts a timer which expires after the PENALTY_TIME. This timer will be reset when the cell is taken off the list. For the duration of this timer, C2 is given a negative offset. This will tend to prevent fast moving MSs from selecting the cell. TEMPORARY_OFFSET. This is the amount of the negative offset. An innite value can be applied, but a number of nite values are also possible.
Calculation of C2
The reselection criterion C2 is used for cell reselection only and is dened by:
C2 = C1 + CELL_RESELECT_OFFSET - TEMPORARY_OFFSET H(PENALTY_TIME - T) (for PENALTY_TIME innity) C2 = C1 - CELL_RESELECT_OFFSET (for PENALTY_TIME = innity)
Where for non serving cells: H(x) = 0 for x < 0 = 1 for x 0 The mobile camps on to the cell with the highest positive C2 value. For serving cells: H(x) = 0
Version 01 e
issue c
3-11
9W535
U1
M2 D
M1 M3
C
Distance: A - B = 100m B - C = 500m C - D = 500m
B A
36 km/h
U1
Temporary Offset M3
C2
Temporary Offset M2
0 A
20
40
Penalty Time M3
60 C
80
T
100
120 D (sec)
Penalty Time M2
Figure 3-4.
CELL RESELECTION FOR FAST MOVING MS
3-12
Version 01 e
issue c
9W535
NOTE:
When the previous serving cell is placed by the MS on the list of strongest carriers at cell reselection, the timer T shall be set to the value of PENALTY_TIME.
Cell Reselection For Fast Moving MS
Figure 3-4 shows an example of a fast moving subscriber in a hierarchical cell structure. The subscriber remains camped on to the umbrella cell due to the temporary offset and the penalty time for the two microcells. To travel through the micro cell it takes 500m: 10 m/s = 50 s. In this case the Penalty Time should be at least 50 s. For this period of time the temporary offset should be high enough to reduce the C2 value of the micro cell.
NOTE:
ETSI specied steps of 20 s for the Penalty Time, in this case in means that the Penalty Time should be set to 60 s.
s
At point A the MS camps on to the umbrella cell because this is the only suitable cell. At point B the MS also receives signals from micro cell M3. To avoid the reselection to M3 a Temporary Offset is set to reduce the C2 value of the M3. It takes the MS 50 s to travel through the M3. The Penalty Time for M3 is set to 60 s, so the MS remains camped on to U1. At point C the MS receives signals from M2, but again due to the Temporary Offset and the Penalty Time the MS remains camped on to U1. At point D the MS leaves the hierarchical cell structure and is still camped on to U1.
Version 01 e
issue c
3-13
9W535
U1
M2 D
M1 M3
C
Distance: A - B = 100m B - C = 500m C - D = 500m
B A
3.6 km/h
U1
M3
Temporary Offset
U1
M2
C2
0 A
100 B
200
600 C
T
700
800
(sec)
Penalty Time M3
Figure 3-5.
CELL RESELECTION FOR SLOW MOVING MS
3-14
Version 01 e
issue c
9W535
Cell Reselection For Slow Moving MS
Figure 3-5 shows an example of a slow moving subscriber. Every time the subscriber moves to an other cell reselection takes place. In this case it takes 500m: 1m/s = 500 s to travel trough the micro cell. After the Penalty Time is expired (50 s) the MS will camp on to the micro cell.
NOTE:
Keep in mind that this is a theoretical example with strict boundaries. In a normal network these boundaries are not strict.
s
At point A the MS camps on to the umbrella cell because this is the only suitable cell. At point B the MS also receives signals from micro cell M3. Due to the Temporary Offset of M3 the MS is still camped on to U1. It takes the MS 500 s to travel through micro cell M3. The Penalty Time for M3 is set to 60 s, so after 60 s reselection takes place to M3 (the C2 value of M3 is higher than the C2 value of U1.) At point C the MS receives signals from M2, but again due to the Temporary Offset and the Penalty Time the MS performs a reselection to U1. After 60 s in M2 again a reselection occurs from U1 to M2. At point D the MS leaves the hierarchical cell structure and the MS camps on to U1 immediately (there is no Temporary Offset dened for U1).
s s
Version 01 e
issue c
3-15
9W535
MEASURE C2 AND C2 EVERY 5 SEC.
NO
C2 > C2 FOR 5 SECONDS
YES
PREV. 15 SECONDS RESELECTION?
NO
YES
NO
C2 > C2 + 5dB FOR 5 SECONDS YES
SELECT C2
Figure 3-6.
CELL RESELECTION FLOW DIAGRAM
3-16
Version 01 e
issue c
9W535
TIMING FOR CELL RESELECTION
At least every 5 seconds the MS calculates the value C1 and C2 for the serving cell and recalculate the C1 and C2 values for non serving cells. The MS checks whether:
s
The path loss criterion C1 for the current serving cell falls bellow zero for a period of 5 seconds. This indicates that the path loss to the cell has become too high. The calculated value of C2 for a non serving suitable cell exceeds the value of C2 for the serving cell for a period of 5 seconds.
Figure 3-6 gives the ow diagram of how the MS selects the proper cell using the C2 algorithm. C2 is the C2 value of the current serving cell. C2 is the C2 value of the new cell.
Version 01 e
issue c
3-17
9W535
U1
3.6 km/h 0.8 W 36 km/h 8W
M1
M2
TXPWR_MAX_CCHU1=37 dBm TXPWR_MAX_CCHM1=36 dBm TXPWR_MAX_CCHM2=36 dBm
RXLEV_ACCESS_MINU1=-104 dBm RXLEV_ACCESS_MINM1= -102 dBm RXLEV_ACCESS_MINM2= -102 dBm
Figure 3-7.
C2 EXERCISE
3-18
Version 01 e
issue c
9W535
C2 EXERCISE
Two MSs are traveling through a hierarchical cell structure of an umbrella cell and two micro cells. The radius of the micro cells is 100m. The signal level received from U1 is -89 dBm. The signal level received is -76 dBm from M1 and, -79 dBm. from M2 These values are valid across each cell area. Questions: 1. Calculate the CELL_RESELECT_OFFSET, TEMPORARY_OFFSET and, PENALTY_TIME of the three cells so that the fast moving subscriber uses the umbrella cell and the slow moving subscriber uses the micro cells. Make a Time diagram for both subscribers showing the reselection behavior. What happens if the slow moving subscriber takes his/her mobile into a car (v=36km/h)?
2.
Version 01 e
issue c
3-19
9W535
Location Update to LA1 Location Update to LA2
LA1
LA2
RESELECT HYSTERESIS LA1 RESELECT HYSTERESIS LA2
LA1
LA2
Figure 3-8.
CELL RESELECT HYSTERESIS
3-20
Version 01 e
issue c
9W535
CELL RESELECT HYSTERESIS
Cell reselection on the border of two location areas result in a location update. When an MS moves on the border of two location areas, lots of location updates take place. To avoid these location updates, the Reselect Hysteresis is introduced A location update is only performed if:
s
The C1 value of the new location area is higher than the C1 value in the current location area and The received signal strengths have at least a difference of the Reselect Hysteresis.
Example With Reselect Hysteresis
The upper part of Figure 3-8 shows an example of a car moving through two different location areas. Due to different received signal levels on the border of the two location areas, lots of location updates take place. The lower part of Figure 3-8 shows the Reselect Hysteresis for LA1 and LA2. The MS starts in LA1 and will stay in this location area because the received signal level from LA2 will not exceed the received signal level from LA1 + Reselect Hysteresis.
Operational Aspects
Increasing the Reselect Hysteresis will enlarge the overlap regions between the two location areas. A default value for the Reselect Hysteresis is 6 dB.
Version 01 e
issue c
3-21
9W535
3-22
Version 01 e
issue c
9W535
PARAMETERS
The list of BSS parameters which are related to cell (re)selection is summarized bellow:
s
MS_TXPWR_MAX_CCH
The maximum TX power level an MS may use when accessing the system. The higher this values the less mobiles with low output power will use this cell to camp on to. Range: [5 to 39] dBm (GSM900), [15 to 43] dBm (DCS1800), in steps of 2 dB.
RXLEV_ACCESS_MIN
Minimum received level at the MS required for access to the system.The lower this value the higher the chance that an MS will camp on to this cell. Range: [-110 to -48] dBm.
CELL_RESELECT_OFFSET
Applies an offset to the C2 cell reselection to force MS in a certain cell or in a different band in case of multiband operation. Range: [0 to 126] dB, in steps of 2dB.
TEMPORARY_OFFSET
Applies a negative offset to C2 for the duration of PENALTY_TIME. Range: [0 to 60] dB, in steps of 10 dB, and innity.
PENALTY_TIME
Denes the duration for which the temporary offset is applied. Range: [0 to 620] s in steps of 20 s.
CELL_BAR_ACCESS
To dene if a cell is barred or not. Range: [True, False]
CELL_BAR_QUALIFY
To dene the priority of a cell. A cell can have a normal or low priority. In case of low priority the cell is only selected if there is no other suitable cell available. Range: [True, False]
CELL_RESELECT_HYSTERESIS
Denes the RXLEV hysteresis for cell reselection in case of a location update. A high value enlarges the boundaries between two location areas. Range: [0 to 14] dB, in steps of 2 dB.
Version 01 e
issue c
3-23
9W535
BSC BTS MS
BSS Parameters MS Measurements BTS Measurements
Evaluate Measurements
Decide Power Control Averaged Parameters
Calculate Averaged Parameters
Um Interface Figure 3-9.
Abis Interface POWER CONTROL PROCESS
After averaging Signal Level Before averaging
Time Figure 3-10. SIGNAL LEVEL AVERAGING
3-24
Version 01 e
issue c
9W535
POWER CONTROL RELATED PARAMETERS

WHAT IS POWER CONTROL
3
3
Power Control enables the Mobile Station (MS) and/or the Base Transceiver Station (BTS) to increase or decrease the transmit power. It can be enabled for the MS and/or the BTS. The main reason to enable Power Control is reducing the interference level within the cellular network. Reducing power on the BTS or the MS, while keeping similar signal quality received, decreases interference caused on the other calls in the surrounding area. Power Control also saves MS battery power. If Power Control is disabled for the MS, the MS will always transmit at maximum power level. The same is applicable for the BTS: if Power Control is disabled for the BTS, it will always transmit at maximum power level.
POWER CONTROL PROCESS
The Power Control process (Figure 3-9) consists of the following steps:
s
The BTS measures the uplink and receives downlink measurements from the MS every 480 ms (every SACCH multi-frame, 104 TDMA frames). The following measurement parameters are used in the Power Control process: RXLEVDL (receive signal level or strength measured by the MS) RXLEVUL (receive signal level measured by the BTS) RXQUALDL (receive signal quality measured by the MS) RXQUALUL (receive signal quality measured by the BTS) The BTS reports the measurements to the BSC. The BSC calculates the following averaged parameters using a sliding (or rolling) window to control the speed of the Power Control process to react on new situations: AV_RXLEV_XL_PC AV_RXQUAL_XL_PC For example, AV_RXLEV_XL_PC is calculated to remove the effect of Rayleigh fading on the measurements (refer to Figure 3-10).
s s
NOTE:
XL means either UL (Uplink), or DL (downlink).
s
The BSC evaluates whether a Power Control increase or decrease action should be initiated. It compares the averaged parameters to dened thresholds (BSS parameters).
Version 01 e
issue c
3-25
9W535
Signal Level 0 1 2 .. 62 63
Table 3-2.
Range (in dBm) RXLEV < -110 -110 < RXLEV < -109 -109 < RXLEV < -108 .. -49 < RXLEV < -48 RXLEV > -48
SIGNAL LEVELS
Signal Quality 0 1 2 3 4 5 6 7
Table 3-3.
Range (in BER) BER < 0.2 0.2 < BER < 0.4 0.4 < BER < 0.8 0.8 < BER < 1.6 1.6 < BER < 3.2 3.2 < BER < 6.4 6.4 < BER < 12.8 BER > 12.8
SIGNAL QUALITY LEVELS
3-26
Version 01 e
issue c
9W535
Optionally, the BSC commands the BTS and/or MS to adopt transmit power.
RXLEV
3
The signal level or signal strength is measured in dBm. There are 64 levels of signal strength that can be reported (refer to Table 3-2). Signal level 0 indicates a weak signal, whereas signal level 63 indicates a strong signal.
RXQUAL
The signal quality is measured in bit error rate (BER), which represents the percentage of the number of incorrect bits received (after channel decoding). The signal quality can be poor due to inter-symbol, co-channel and/or adjacentchannel interference. There are 8 levels of signal quality (refer to Table 3-3). Signal quality 0 indicates a good quality, whereas signal quality 7 indicates a bad quality.
Version 01 e
issue c
3-27
9W535
Averaged Parameter Calculation:
A_LEV_PC AV_RXLEV_XL_PC = -----------------------------------------------------------A_LEV_PC
RXLEV XL
AV_RXQUAL_XL_PC = A_QUAL_PC --------------------------------------------------------------------------------------------------------------------W_QUAL_PC A_QUAL_PC
( RXQUAL XL W_QUAL_PC )
Sample: Speech Weighting RXQUALUL Table 3-4.
1 yes 2 3
2 no 1 2
3 yes 2 5
4 no 1 3
WEIGHTING FACTOR EXAMPLE
3-28
Version 01 e
issue c
9W535
Averaged Parameter Calculation
After the BSC receives the measurements from the MS and the BTS, it starts evaluating the quality of the air-interface. For this purpose, the BSC calculates averaged parameters using the measurements and the BSS parameters as input. These averaged parameters are used to decide a Power Control adjustment. The averaged parameter AV_RXLEV_XL_PC (averaged RXLEV used in the Power Control process for uplink/downlink) is calculated using the following formula:
AV_RXLEV_XL_PC = -----------------------------------------------------------A_LEV_PC where: A_LEV_PC is the BSS parameter dening the window size. The window size represents the number of measurements/samples used to calculate the averaged parameter. The averaged parameter AV_RXQUAL_XL_PC (averaged RXQUAL used in the Power Control process for uplink/downlink) is calculated using the following formula: ( RXQUAL XL W_QUAL_PC ) AV_RXQUAL_XL_PC = A_QUAL_PC ---------------------------------------------------------------------------------------------------------------------W_QUAL_PC A_QUAL_PC where: A_QUAL_PC is the BSS parameter dening the window size, and W_QUAL_PC is the BSS parameter dening the weighting factor used to minimize the inuence on the quality averaging procedure caused by Discontinuous Transmission (DTX). W_QUAL_PC has a domain value of: 1, 2 or 3. When DTX is not applicable for a specic measurement, W_QUAL_PC has the value 1. Otherwise, it has the value 2 or 3.
RXLEV XL A_LEV_PC
Example with Quality Averaged Parameter
An example of calculating AV_RXQUAL_UL_PC with DTX switched on (with Weighting Factor is equal to 2, and window size is equal to 4) is given below, The measurement values are given in Table 3-4.
AV_RXQUAL_UL_PC =
(2 x 3) + (1 x 2) + (2 x 5) + (1 x 3) =3 2+1+2+1
Version 01 e
issue c
3-29
9W535
Transmitted power in MS:

MSPWR (in dBm)
MS_TXPWR_MAX POW_INCR_STEP_SIZE
Received power in BTS:

AV_RXLEV _UL_PC (in dBm)
U_RXLEV_UL_P
L_RXLEV_UL_P
Power Control Increase Command to Mobile Station
Time
Figure 3-11. POWER CONTROL INCREASE FOR THE UPLINK RELATED TO SIGNAL LEVEL
3-30
Version 01 e
issue c
9W535
Power Control Evaluation Increase
3 3
A Power Control increase is initiated when the following conditions are fullled:
AV_RXQUAL_XL_PC > L_RXQUAL_XL_P

or
AV_RXLEV_XL_PC < L_RXLEV_XL_P

where: L_RXQUAL_XL_P is the BSS parameter dening the lower receive quality for the Power Control, and L_RXLEV_XL_P is the BSS parameter dening the lower receive level for the Power Control.
Decrease
A Power Control decrease is initiated when the following conditions are fullled:
(AV_RXQUAL_XL_PC < U_RXQUAL_XL_P and AV_RXLEV_XL_PC > L_RXLEV_XL_P + POW_RED_STEP_SIZE)

or
AV_RXLEV_XL_PC > U_RXLEV_XL_P

where: U_RXQUAL_XL_P is the BSS parameter dening the upper receive quality for the Power Control, POW_RED_STEP_SIZE is the BSS parameter dening the RF power reduce step size for Power Control, and U_RXLEV_XL_P is the BSS parameter dening the upper receive level for the Power Control.
Uplink and Signal Level

Figure 3-11 illustrates the uplink Power Control process. When the BSC notices that the signal level measured on the uplink (AV_RXLEV_UL_PC) becomes below the BSS parameter L_RXLEV_UL_P because the MS moves away from the BTS, it sends a Power Control command to the MS to increase its transmit power (MS_TXPWR) by one step of POW_INCR_STEP_SIZE dB. The transmit power of the MS can be increased until a maximum dened MS power level is reached (BSS parameter MS_TXPWR_MAX). The BSC can also send a Power Control command to the MS to reduce its transmit power with POW_RED_STEP_SIZE dB, when it notices that the signal level measured becomes above the BSS parameter U_RXLEV_UL_P. The downlink Power Control process is similar as for the uplink Power Control process.
Version 01 e
issue c
3-31
9W535
Signal Quality AV_RXQUAL _UL_PC (in BER)
+ +
Optimum
+
U_RXLEV _UL_P 63
U_RXQUAL _UL_P
L_RXQUAL _UL_P
+
7 0 L_RXLEV _UL_P
Signal Level AV_RXLEV _UL_PC
Legend:
: transmit power is decreased : transmit power is increased
Figure 3-12. POWER CONTROL FOR THE UPLINK
3-32
Version 01 e
issue c
9W535
Signal Level and Signal Quality

In the description of Power Control given up to this point, the reason for Power Control is that the uplink/downlink signal level measured is higher or lower than thresholds specied. Other reasons for activating Power Control is an uplink/ downlink signal quality measured which is higher or lower than thresholds specied. Figure 3-12 illustrates the complete uplink Power Control process. In the "optimum" area, the area delimited by the different BSS parameters, no Power Control actions are taken. If signal quality and/or level are beneath the specied thresholds, Power Control will increase power (indicated by '+'). If signal quality and/or level are above the specied thresholds, Power Control will reduce transmit power (indicated by '-'). The downlink Power Control process is similar as for the uplink Power Control process.
Version 01 e
issue c
3-33
9W535
BSC
BTS
Power Control Command
P_CON_ACK
New BTS Power
P_CON_INTERVAL
Power Control Command
Figure 3-13. MINIMUM TIME BETWEEN TWO COMMANDS
3-34
Version 01 e
issue c
9W535
Time between Power Control Commands
The minimum time between two Power Control commands is represented by the BSS parameters P_CON_INTERVAL and P_CON_ACK. After any Power Control action the BSS will wait for the specied time before performing the next Power Control action for the call involved.
Acknowledge Timer
To avoid that the BSC keeps waiting for a message of the BTS the P_CON_ACK timer is introduced. When the BSC sends the power control command the timer P_CON_ACK starts. If a power update message (New BTS Power) is received from the BTS the P_CON_ACK timer stops running. If during the P_CON_ ACK interval no acknowledge is received from the BTS the BSC can decide to send a new power control command (depending on the received measurements for power control).
Interval Timer
To avoid that the BSC sends Power Control Commands all the time, the P_CON_INTERVAL timer is introduced. As soon as an acknowledge message from the BTS is received the P_CON_INTERVAL timer starts. The BSC has to wait for this period of time before it can send another power control command. The algorithm used to control the minimum time between two Power Control commands is depicted in the Figure 3-13.
Version 01 e
issue c
3-35
9W535
3-36
Version 01 e
issue c
9W535
PARAMETERS
The list of BSS parameters which are related to Power Control, including the consequences of updating each of the parameters, is summarized below:
s
A_LEV_PC and A_QUAL_PC

The bigger the window size (number of measurements) is, the more precise the values of the averaged parameters are. When the values are not precise enough, the probability of an incorrect Power Control decision will increase. However, too big a window size can cause a delayed power adjustment, and so a higher interference probability. This is caused by an unnecessary increased transmit power of the currently serving base station. Range: [0 -31] SACCH multi frames.
W_QUAL_PC
Weighting factor for quality measurements to compensate for DTX. Range [1 to 3], 1 is no compensation.
BS_TXPWR_RED
This parameter determines the actual maximum transmit power of the BTS: Max_BS_Txpwr = TRX Power Class BS_TXPWR_RED The actual maximum transmit power of the BTS inuences the interference situation in a cell. Range: [0 to 12] dB, in steps of 2 dB.
MS_TXPWR_MAX
A too high value can cause a bad interference situation. A too low value can cause that the power regulation process will not function properly, because the handover function is often initiated too soon. Range: [5 to 43] dBm.
L_RXLEV_XL_P and U_RXLEV_XL_P

When the difference between the upper and lower threshold is not big enough, the number of power increase/decrease commands can excessively increase. This will lead to too much signaling trafc over the air-interface. The signaling trafc on the air-interface should not be too high. Range: [-110 to > -48] dBm.
Version 01 e
issue c
3-37
9W535
3-38
Version 01 e
issue c
9W535
L_RXQUAL_XL_P and U_RXQUAL_XL_P

The same is applicable as for the level thresholds. Range: [0 to 7], (See Table 3-3).
POW_INCR_STEP_SIZE
Smaller values result in an increased number of Power Control commands and therefore in more signaling trafc. Larger values result in a more coarse power regulation process. Range: [2 to 6] dB, in steps of 2 dB.
POW_RED_STEP_SIZE
The same is applicable as for the POW_INCR_STEP_SIZE. Typically, the reduce step size is chosen smaller than the increase step size in order to assure a secure communication and a sufcient high stability of the Power Control process. Range: [2, 4] dB.
P_CON_ACK and P_CON_INTERVAL

These parameters inuences the number of Power Control commands that are transferred via the air-interface. The relation with the parameters POW_INCR_STEP_SIZE and POW_RED_STEP_SIZE must be dened with care: smaller steps sizes must go along with a smaller value of P_CON_INTERVAL. Range: [0 - 31] 2 SACCH multi frames.
Version 01 e
issue c
3-39
9W535
BSC BTS MS
BSS Parameters MS Measurements BTS Measurements
Evaluate Measurements
Decide Hand Over Averaged Parameters
Calculate Averaged Parameters
Um Interface
Abis Interface
Figure 3-14. HANDOVER CONTROL PROCESS
3-40
Version 01 e
issue c
9W535
HANDOVER CONTROL RELATED PARAMETERS

WHAT IS HANDOVER CONTROL
3
3
The handover process allows to change the serving cell without loosing the call in progress. Note that the handover process will normally only be started if power control is not helpful anymore. The reasons to perform a handover are:
s s s s
Distance (or propagation delay) between MS and BTS becomes too big Receive signal quality (RXQUAL) becomes too bad Receive signal level (RXLEV) becomes too bad Path loss situation for the MS to another cell is better
Depending on the duration that the MS stays in a cell, the handover can be performed to a micro- or umbrella cell.
HANDOVER PROCESS
The Handover process consists of the following steps:

s
The BTS measures the uplink and receives downlink measurements from the MS every 480 ms. The following measurement parameters are used in the handover process: RXLEVXL (receive signal level measured by the MS/BTS) RXQUALXL (receive signal quality measured by the MS/BTS) RXLEV_NCELL(1-6) (receive signal levels of the best six neighbor cells measured by the BTS) DIST (distance between BTS and MS, expressed in the timing advance)
s s
The BTS reports the measurements to the BSC. The BSC calculates the following averaged parameters using a sliding window to prevent frequently handovers between two BTSs: AV_RXLEV_XL_HO AV_RXQUAL_XL_HO AV_RXLEV_SCELL (averaged receive level of the serving cell) AV_RXLEV_NCELL(i) AV_DISTANCE
The BSC evaluates whether a handover should be initiated. It compares the averaged parameters with dened thresholds (BSS parameters).
Version 01 e
issue c
3-41
9W535
Distance 0 1 2 .. 30 31 Table 3-5.
Range (in km) 0 < DIST < 1.1 1.1 < DIST < 2.2 2.2 < DIST < 3.3 .. 33.2 < DIST < 34.3 DIST > 34.3
DISTANCE STEPS
3-42
Version 01 e
issue c
9W535
If the handover threshold comparison determines that an inter-cell handover is required, the BSC determines whether a good handover candidate is available. If a good handover candidate is available for the MS, the call is handed over to this cell.
Distance
3
The MS measures the timing advance (propagation delay) of the signal from the BTS and subsequently derives from this measurement the distance to the BTS. The distance is reported in units of 1107 meter (Refer to the Table 3-5). The distance of 1107 meter corresponds to the GSM bit length (3.69 s).
Version 01 e
issue c
3-43
9W535
Averaged Parameter Calculation:
A_LEV_HO AV_RXLEV_XL_HO = -----------------------------------------------------------A_LEV_HO
RXLEV XL
A_QUAL_HO AV_RXQUAL_XL_HO = ----------------------------------------------------------------------------------------------------------------------W_QUAL_HO A_QUAL_HO
( RXQUAL XL W_QUAL_HO )
Cell Structures: Hierarchical cell structure: Micro cells + Umbrella cells

s
Non-hierarchical cell structure Standard cells
3-44
Version 01 e
issue c
9W535
Averaged Parameters
The averaged parameter AV_RXLEV_XL_HO (averaged RXLEV used in the handover process for uplink/downlink) is calculated using the following formula:
AV_RXLEV_XL_HO = -----------------------------------------------------------A_LEV_HO where: A_LEV_HO is the BSS parameter dening the window size. The window size represents the number of measurements/samples used to calculate the averaged parameter. The averaged parameters AV_RXLEV_NCELL(i), AV_DISTANCE and AV_RXLEV_SCELL are calculated in the similar way. To calculate AV_RXLEV_NCELL(i) and AV_RXLEV_SCELL, the BSS parameter A_PBGT_HO is used. To calculate AV_DISTANCE, the BSS parameter A_DIST_HO is used. The averaged parameter AV_RXQUAL_XL_HO (averaged RXQUAL used in the handover process for uplink/downlink) is calculated using the following formula:
RXLEV XL A_LEV_HO
( RXQUAL XL W_QUAL_HO ) A_QUAL_HO AV_RXQUAL_XL_HO = ----------------------------------------------------------------------------------------------------------------------W_QUAL_HO A_QUAL_HO
where: A_QUAL_HO is the BSS parameter dening the window size, and W_QUAL_HO is the BSS parameter dening the weighting factor used to minimize the inuence on the quality averaging procedure caused by Discontinuous Transmission (DTX).
Cell Structures
The algorithm performed in the threshold comparison process depends on the network cell structure. The network is organized into one of the following structures:
s
Hierarchical cell structure (Multiple Cell Layer) Is composed of two different layers: the lower cell layer with rather small cells (micro-cells) and an upper cell layer with large cell (umbrella cells).
Non-hierarchical cell structure (Single Cell Layer) Is composed of standard cells.
Version 01 e
issue c
3-45
9W535
AV_DISTANCE > MS_DIST_MAX
True
False Power Control not helpful anymore AV_RXQUAL_XL_HO > L_RXQUAL_XL_H and AV_RXLEV_XL_HO > RXLEV_XL_IH False Intra-cell Handover True
AV_RXQUAL_XL_HO > L_RXQUAL_XL_H False
True 1 Select the best from neighboring cells fullling the following condition: True AV_RXLEV_NCELL(i) > RXLEV_MIN(i) + 2 x Max (0, P - MS_TXPWR_MAX(i)) & Trafc Load Criteria True
AV_RXLEV_XL_HO < L_RXLEV_XL_H False
PBGT(i) > HO_MARGIN(0,i) False
Inter-cell Handover
(No Handover)
Figure 3-15. HANDOVER CONTROL ALGORITHM FOR STANDARD CELLS
3-46
Version 01 e
issue c
9W535
HANDOVER CONTROL EVALUATION IN A NON-HIERARCHICAL NETWORK
If the BSC determines that either the signals has too low quality or too low level, it decides to perform Power Control for the MS and the BTS. If power control is not helpful anymore, the BSC normally starts the inter-cell handover procedure A handover in a network consisting of a single cell layer is initiated due to:
s s s s
Distance between MS and BTS RXQUAL RXLEV Power budget
In Figure 3-15 the conditions are given which have to be satised to initiate an inter-cell or intra-cell handover. The parameters L_RXQUAL_XL_H, L_RXLEV_XL_H, MS_DIST_MAX, HO_MARGIN, RXLEV_XL_IH, RXLEV_MIN(i) and MS_TXPWR_MAX are BSS parameters. The parameters RXLEV_MIN(i) dene the minimum received BCCH signal levels for each neighboring cell before the MS is allowed to be handed over to this particular cell. The parameter P represents the MS power-class. After one of the handover conditions is satised, the target cell selection procedure is started. In this procedure an ordered handover target cell list is determined. The list is ordered using the value of the expression
PBGT(i) HO_MARGIN(0,n)
The power budget between the serving cell and the neighbor cell i is given by the formula:
PBGT(i) = AV_RXLEV_NCELL(i) - AV_RXLEV_SCELL + (MS_TXPWR_MAX(i) - MS_TXPWR_MAX) * 2

The cell with the highest value of the expression has the highest priority. When more than one target cells on top of the list have the same value, the target cell is determined using the trafc load criteria.
Version 01 e
issue c
3-47
9W535
RXLEV (Received by MS)
Server
HO_MARGIN(0,i)
Neighbor Handover Time
Figure 3-16. POWER BUDGET HANDOVER MARGIN
AV_RXQUAL _XL_HO
+
U_RXQUAL _XL_P
Optimum
+
Intra-cell Handover
63
AV_RXLEV _XL_HO
+
L_RXQUAL _XL_P
+
L_RXQUAL _XL_H 7 0 L_RXLEV _XL_H L_RXLEV _XL_P
InterCell Handover
U_RXLEV RXLEV _XL_P _XL_IH
Figure 3-17. HANDOVER CONTROL FOR THE UPLINK
3-48
Version 01 e
issue c
9W535
Power Budget Handover
A power budget handover takes place as soon as a better cell with respect to the power budget is available to handle the call. A power budget handover is based on the path loss. The path loss is the difference between the actual transmit power of the BTS and the signal level received by the MS. Generally, the MS will switch to the BTS with the lowest path loss. By switching to another cell, the necessary power transmitted by both the MS and the BTS is reduced and the inuence of interference is decreased. To avoid ping-pong situations, the BSS parameter HO_MARGIN(0,i) is introduced. Figure 3-16 shows an example handover margin.
Intra-cell Handover
If the signal quality decreases below the BSS parameter L_RXQUAL_XL_H, while the averaged parameter AV_RXLEV_UP_HO is still above the BSS parameter RXLEV_XL_IH, an intra-cell handover will take place, rather than an inter-cell handover. An intra-cell handover is to switch a call from one TCH (Trafc Channel) to another idle TCH within the same cell (either TCHs on the same or on different frequencies). With Frequency Hopping invoked, this type of handover will be seldom needed.
Interference Boundaries
For each idle (unallocated) channel the level of interference will be averaged over a period of INTAVE (Interference Process Averaging Period). The procedure for measurement of interference is based on the gaining of RXLEV measurements on idle TCHs of each TRX averaged over a number of SACCH multiframes specied by this parameter. This period is also used as a sending period of the Resource Available Information Element from BTS/TRX to the BSC. The levels of the ve bands are dened at the OMC based on the following 5 thresholds:
s s s s s
INT_BOUND_1 = Integer [(L_RXLEV_UL_P - 2) / 4] INT_BOUND_2 = Integer [(L_RXLEV_UL_P - 1) / 2] INT_BOUND_3 = Integer [L_RXLEV_UL_P * 3/4] INT_BOUND_4 = L_RXLEV_UL_P INT_BOUND_5 = 63 (xed)
Where INT_BOUND_1 has the least interference.
Version 01 e
issue c
3-49
9W535
Interference Boundaries:
s
INT_BOUND_1 = Integer [(L_RXLEV_UL_P - 2) / 4] INT_BOUND_2 = Integer [(L_RXLEV_UL_P - 1) / 2] INT_BOUND_3 = Integer [L_RXLEV_UL_P * 3/4] INT_BOUND_4 = L_RXLEV_UL_P INT_BOUND_5 = 63 (xed)
3-50
Version 01 e
issue c
9W535
The dependency is that: INT_BOUND_1<INT_BOUND_2<INT_BOUND_3<INT_BOUND_4<INT_BOUND _5 The idle channel supervision is used for measuring interference levels on channels, which are a candidate for: channel allocation, intracell and intercell handover. The philosophy is to direct every MS onto an idle channel with an interference level as low as possible. This is applied for TCHs. For the allocation of SDCCHs of a BTS the consideration of interference bands is not required. When a new BTS is created, the OMC automatically calculates the values for the interference boundaries using the L_RXLEV_UL_P.
Version 01 e
issue c
3-51
9W535
Cell n FreeChan = 5
Cell k FreeChan = 10
Serving BTS
Serving BTS: PBGT(n) = 7 dB HO_MARGIN(0, n) = 6 dB LINKfactor(0, n) = 0 dB PBGT(k) = 7 dB HO_MARGIN(0, k) = 6 dB LINKfactor(0, k) = 0 dB
Cell n: FREElevel_1 = 4 FREElevel_2 = 7 FREEfactor_1 = 4 dB FREEfactor_2 = 6 dB
Cell k: FREElevel_2 = 8 FREElevel_3 = 11 FREEfactor_2 = 6 dB FREEfactor_3 = 10 dB
FREEfactor_X(n) = FREEfactor_2 = 6 dB FREEfactor_X(k) = FREEfactor_3 = 10 dB
Order(n) = 7-6+0+6=7 Order(k) = 7 - 6 + 0 + 10 = 11
Figure 3-18. TRAFFIC LOAD EXAMPLE
3-52
Version 01 e
issue c
9W535
Trafc Load Criteria
When there are more target cells with the same priority (regarding to PBGT HO_MARGIN), the trafc load criteria can be used to determine the most preferable cell. This handover is only valid for non-hierarchical networks. The trafc load criteria can not generate a request for a handover.
Calculation of the Trafc Load Criteria

The cell with the highest value for the trafc load equation is the cell to which a handover is performed. The trafc load equation is as follows: Order(n) = PBGT(n) HO_MARGIN(0,n) + LINKfactor(0,n) + FREEfactor_X(n) The cell with the highest Order value is the most preferable cell to handover to. The BSS parameter LINKfactor(0,n) denes a correction factor for each neighbor cell for the neighbor cell evaluation regarding trafc load. It is used to weight the different neighbor cells. The parameter FREEfactor_X(n) identies the trafc load of the neighbor cells. Its value is determined using the BSS parameters FREEfactor_X and FREElevel_X. FREElevel_X is used to classify the trafc load situation of a cell. Each FREElevel_X (X=1..5) specify the number of free channels in the cell necessary to reach the FREEfactor_X for the cell.
FREEfactor_X(n) is determined using the following table, where FreeChan represents the number of free TCHs in the cell:
Criteria 0 FreeChan FREElevel_1 FREElevel_1 < FreeChan FREElevel_2 FREElevel_2 < FreeChan FREElevel_3 FREElevel_3 < FreeChan FREElevel_4 FREElevel_4 < FreeChan max. Free Chan. Table 3-6. FREE FACTOR CRITERIA Values used for FREEfactor_X(n) FREEfactor_1 FREEfactor_2 FREEfactor_3 FREEfactor_4 FREEfactor_5
Trafc Load Example

Figure 3-18 shows an example of the trafc load criteria. In this example a handover can be performed to cell k and n. Both cells have the same cell priority (based on the expression PBGT(i) HO_MARGIN(0,n) .) The trafc load will decide the target cell. In the example Cell n has 5 free channels, and cell k has 10 free channels. According to Table 3-6 cell n uses FREEfactor_2 and cell k uses FREEfactor_3. This results in an order(n) of 7 and an order(k) of 11.In this case the handover will be performed to cell k.
Version 01 e
issue c
3-53
9W535
Cell l FreeChan = 2
Cell m FreeChan = 4
Cell k FreeChan = 4
Cell n FreeChan = 3
Serving BTS
Figure 3-19. TRAFFIC LOAD EXERCISE
3-54
Version 01 e
issue c
9W535
TRAFFIC LOAD EXERCISE
In a GSM network a handover based on power budget is performed. The cells to which the handover should be performed are all part of the same BSS, and the load regard parameter is set to True. The following data of the BTSs is available: Serving BTS: PBGT(k) = 8 dB, HO_MARGING(0,k) = 6 dB, LINKfactor(0,k) = 1 dB PBGT(l) = 9 dB, HO_MARGING(0,l) = 7 dB. LINKfactor(0.l) = 0 dB PBGT(m) = 8 dB, HO_MARGING(0,m) = 7 dB, LINKfactor(0,m) = 0 dB PBGT(n) = 7 dB, HO_MARGING(0,n) = 5 dB, LINKfactor(0,n) = 0 dB Target cell information: FREElevel_1 = 2, FREEfactor_1 = 1 dB FREElevel_2 = 3, FREEfactor_2 = 2 dB FREElevel_3 = 4, FREEfactor_3 = 3 dB FREElevel_4 = 5, FREEfactor_4 = 4 dB max. Free Chan. = 7, FREEfactor_5 = 5 dB The Freelevels are valid for all the cells, the FREEfactors are only valid for cell k, l, and m. Questions: 1. 2. 3. What should be the Freefactor for cell n so the handover is performed to cell n? What is the order of the preferable cells in this case? How many free channels should be available on cell k to become the most preferable cell for handover?
Version 01 e
issue c
3-55
9W535
Current Cell of MS Micro cell
Duration of Stay Criterion Cdos < C_MICRO_HO Cdos >=C_MICRO_HO
Other Handover Criteria RXLEV, RXQUAL RXLEV (1), RXQUAL (2) RXLEV, RXQUAL, PBGT(3) None
Preferable Target Cell Umbrella or standard cell Micro cell Umbrella or standard cell Micro cell
Umbrella cell
Cdosnc(i)=< C_UMBRELLA_MICRO _HO Cdosnc(i)> C_UMBRELLA_MICRO _HO
Table 3-7.
HANDOVER CONTROL ALGORITHM FOR UMBRELLA AND MICRO CELL
3-56
Version 01 e
issue c
9W535
Handover Control Evaluation in a Network Consisting of a Multiple Cell Layer
A handover in a network consisting of a multiple cell layer is initiated due to:

s s s s
Distance between MS and BTS RXQUAL RXLEV Power budget
Depending on the Duration that the MS stays in a cell the handover is performed to a micro- or umbrella cell. The algorithm which is used in the handover process in a multiple cell layer network, is similar to the algorithm used in a single cell layer network. The criteria which have to be fullled to initiate an inter-cell or intra-cell handover, are given in Table 3-7. The following should be noted:
s
Irrespective of the cell type the rst part of the handover comparison process is the process for Distance Handover. In a network consisting of a multiple cell layer a handover has not to wait until the Power Control has adjusted the maximum RF power. In a multiple cell layer network the policy in mind is: a slow moving MS should be connected to one of the lower layer cells while a fast moving MS will cause less handovers in a large cell of the upper layer. For this purpose the counters Cdos (duration of stay of the MS in a micro cell) and Cdosnc(i) (duration of stay in the coverage area of a neighboring micro cell i) are used. These counters, in combination with the cell type the MS currently stays, decide which other criteria has to be fullled to start a handover. The counters Cdos and Cdosnc(i) are incremented every 480 ms. When the MS stays in a micro cell, the counter Cdos is compared to the BSS parameter C_MICRO_HO, which denes the threshold for the duration of stay of an MS in the micro cell. When the MS stays in an umbrella cell, the counters Cdosnc(i) are compared to the BSS parameter C_UMBRELLA_MICRO_HO, which denes the duration of stay of an MS in the area of a micro cell while it is assigned to the umbrella cell.
The counter Cdosnc(i) is only started for micro cells which fulll the following criterion: AV_RXLEV_NCELL(i) > RXLEV_MIN(i) + C ( i ) Where:
C(i) = UMBRELLA_MICRO_HYST + 2*MAX(0, P - MS_TXPWR_MAX(i))
Version 01 e
issue c
3-57
9W535
UMBRELLA_MICRO_HYST is the BSS parameter dening a hysteresis for the decision whether an underlying micro cell is seen as good enough for a handover from the upper cell layer to the lower cell layer. Some criteria which have to be fullled to initiate a handover (refer to the column other handover criteria in the table), are expanded in comparison to a single cell layer network. The expanded criteria are:
(1) RXLEV: AV_RXLEV_XL_HO < L_RXLEV_XL_H
and
RXLEV_XL_HO L_RXLEV_XL_H + MICRO_HO_PC_HYST C
RXLEV_XL_HO represents the value of the last recent level measurement. MICRO_HO_PC_HYST is the BSS parameter dening a hysteresis for the decision to execute a Power Control step instead of a handover. The parameter C is a correction part due to Power Control. The correction part is different for the uplink and downlink.
(2) RXQUAL: AV_RXQUAL_XL_HO < L_RXQUAL_XL_H
and
RXLEV_XL_HO L_RXLEV_XL_H + MICRO_HO_PC_HYST C
and
MICRO_HO_PC_HYST + 2 C < 0 The term MICRO_HO_PC_HYST + 2 for Power Control. (3) PBGT: If at the time when Cdosnc(i) reaches C_UMBRELLA_MICRO_HO a handover cause Power Budget to an adjacent Umbrella Cell or Standard Cell Occurs. The handover shall be performed to the respective Micro Cell (i). represents the power reserve
3-58
Version 01 e
issue c
9W535
PARAMETERS
The list of BSS parameters which are related to Handover Control, including the consequences of updating each of the parameters, is as follows:
s
A_DIST_HO, A_LEV_HO, A_PBGT_HO and A_QUAL_HO

The bigger the window size (number of measurements) is, the more precise the values of the averaged parameters are. When the values are not precise enough, the probability of an incorrect Power Control decision will increase. However, a too big window size can cause a delayed power adjustment, and so a higher interference probability. This is caused by an unnecessary increased transmit power of the currently serving base station. Range: [0 to 14880] ms, in steps of 480 ms.
L_RXLEV_XL_H
The higher the signal level handover threshold is set, the more handover attempts are made, which lead, in general, to a better speech quality. If the threshold is set too low, there will be an increased risk of dropped calls. The difference between L_RXLEV_XL_P and L_RXLEV_XL_H must be large enough (for example 6 dB). With a rapidly falling signal level, both thresholds could be passed before Power Control can operate. This can lead to an increasing number of handovers. Range: [-110 to -48] dBm.
L_RXQUAL_XL_H
The lower the signal quality handover threshold is set, the more handover attempts are made and the better the speech quality is. If the threshold is set too high, there will be an increased risk of dropped calls. Range: [0 to 7], see Table 3-3.
MS_DIST_MAX
This parameter can be used to limit the cell size. The higher the value of the distance threshold, the longer a handover can be delayed. When this time is too long, the signal quality will be decreased and possibly the call will be disconnected. Range: [0 to 31], in steps of 1107m.
Version 01 e
issue c
3-59
9W535
HO_MARGIN
The higher the value of the power budget handover margin, the less handovers will be triggered. Another consequence is that the size of the cell will be bigger, and so the spectral efciency will decrease. However, the lower the value of the power budget handover margin, the more handovers will be triggered, which will cause more signaling trafc. It can also lead to ping-pong situations. Range: [-24 to 24] dB.
RXLEV_XL_IH
The lower the threshold is set, the more intra-cell handover attempts are made. Range: [-110 to 48] dBm.
INT_BOUND_1..5
Species the ve boundaries for the idle trafc channels. Range: [0 to 63]
INTAVE
Species the averaged period to calculate to which interference band an idle trafc channel belongs.
FREEfactor_X
Classies the trafc load to different bands depending upon the number of free trafc channels. Range: [-16 to 16] dB.
FREELEVEL_X
Analyzes the number of free trafc channels of a specic cell to adjust the cell order or preferred neighboring cells. Range: [0 to 255]
LINKfactor
Denes the order preference of the concerned adjacent cell. Range: [-24 to 24] dB.
C_MICRO_HO
The higher the value of this parameter the more handover steps are executed from the lower cell layer into the upper cell layer. This can result in the need to assign more radio resources to the upper cell layer. Such situations should be avoided as far as possible. Range: [0 to 127] SACCH multi frames.
3-60
Version 01 e
issue c
9W535
C_UMBRELLA_MICRO_HO
The lower the value the higher is the number of down-stepping handovers from the umbrella cell to a micro cell. Range: [0 to 127] SACCH multi frames.
MICRO_HO_PC_HYST
This parameter is used for the decision whether a handover or a Power Control step should be executed. The higher the value the more handovers are executed, because the current RXLEV value has to be very good for changing the handover request to a Power Control step. Range: [0 to 31] dB.
UMBRELLA_MICRO_HYST
This parameter is used for the decision whether the RXLEV of an underlying micro cell is good enough for a handover into this cell. It inuences the number of down-stepping handovers from the umbrella cell to a micro cell. Range: [0 to 31] dB.
Version 01 e
issue c
3-61
9W535
Requirements for successful paging: MS is powered on MS is in idle mode Successful location update has been performed
Discontinuous Reception: Listen only to specic PCH blocks Blocks can be identied using paging channel conguration parameters: BS_CC_CHANS BS_CC_CHANS_COMB BS_AG_BLKS_RES BS_PA_MFRMS
3-62
Version 01 e
issue c
9W535
RADIO LINK
INTRODUCTION
3
3
To optimize the access of an MS on the radio link, and to reduce the signaling load in the BSS, several parameters can be changed.
PAGING CHARACTERISTICS
Paging is provided simultaneously in all cells belonging to the same location area using the PAGCH (Paging and Access Grant Channel) on the BCCH frequency. For successful paging some MS requirements are necessary:
s s s
The MS is powered on The MS is in idle mode listening to paging messages of the serving cell A successful location update has been performed
DISCONTINUOUS RECEPTION
Constant listening to the PAGCH channel in idle mode consumes battery energy. To increase MS standby time GSM specied the DRX (Discontinuous Reception) feature. Using this feature the MS does not listen to each paging message provided by the serving cell, but only to those which are dedicated to this specic MS. The BSS and MS know when relevant page requests will be sent and the MS can power down for the period when it knows that page requests will not occur. The technique works by dividing the MSs within a cell in disjunct groups. All paging requests to each group are then scheduled and sent at a particular time. Each MS is informed by the BSS via specic BCCH parameters how the logical channels on the air interface are congured.
PAGING CHANNEL CONFIGURATION
Characteristics of the paging channel conguration are:

s
Paging information is transmitted on the PCH. The PCH is contained in a CCCH (Common Control Channel). A CCCH contains both the PCH and AGCH on the downlink. Different logical channel combinations can bear CCCH channels: logical channel combination 5 This combination combines CCCH and SDCCH channels. The number of CCCH blocks per multi-frame (of 51 TDMA frames) is 3. logical channel combination 4 and 6 The number of CCCH blocks per multi-frame is 9. The CCCH blocks are allocated as either PCH blocks or AGCH blocks.
Version 01 e
issue c
3-63
9W535
BS_CC_CHANS = 1 BS_CC_CHANS_COMB = False BS_AG_BLKS_RES = 4 BS_PA_MFRMS = 2

1 physical channel is used channel combination 4 is used # PCH blocks per mult-frame = 9 - 4 = 5 N = 5 x 2 = 10
Downlink
AGCH block
PCH block
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
FCCH SCH BCCH
FCCH SCH BCCH
CCCH
FCCH SCH
CCCH
FCCH SCH
CCCH
CCCH
CCCH
FCCH SCH
CCCH
FCCH SCH
CCCH
CCCH
CCCH
FCCH SCH
CCCH
FCCH SCH
CCCH
CCCH
CCCH
FCCH SCH
CCCH
FCCH SCH
CCCH
CCCH
CCCH
CCCH
Figure 3-20. PCH CONFIGURATION PARAMETERS EXAMPLE
3-64
Version 01 e
issue c
9W535
Up to four physical channels (time slots) can support CCCH channels. All of these physical channels are transmitted on the rst dened frequency of the cell allocation. Physical channel 0 is always in use. Physical Channel 0 2 4 6 Logical Channel Combination 4 or 5 6 6 6
PCH CONFIGURATION PARAMETERS
The paging channel on which the MS expects to receive a page message, is identied using parameters transmitted by the BTS on the BCCH. These physical channel conguration parameters are:
s
BS_CC_CHANS This parameter represents the number of physical channels that support CCCH channels (range: 1-4). BS_CC_CHANS_COMB This parameter indicates whether or not the CCCH and SDCCH channels are combined. Using this parameter the MS is able to determine the maximum number of CCCH blocks in time slot 0. BS_AG_BLKS_RES This parameter indicates the number of CCCH blocks on each CCCH which are allocated for AGCH blocks. Using this parameter the MS is able to know the number of CCCH blocks which are allocated for paging purposes. Its range is: 0-2, if the CCH and SDCCH are combined, otherwise 0-7. BS_PA_MFRMS This parameter indicates the number of TDMA multi-frames between transmissions of paging messages to a specic MS (range: 2-9).The number of times a MS should monitor a PCH channel is calculated using the PCH conguration parameters. The MS is required to monitor the PCH channel every Nth paging blocks, where:
N = ( # blocks allocated for PCH per multiframe ) BS-AG-BLKS-RES
The particular block of the available paging blocks which the MS should monitor, is calculated using its IMSI (which is known to both the BTS and MS at that time). An example of the use of the PCH conguration parameters is depicted in the gure on the opposite page. In this gure two TDMA multi-frames containing logical channel combination 4 are shown.
Version 01 e
issue c
3-65
9W535
18 16 14 DSC 12 10 8 6 4 2 0 6 12 18 24 Cell Reselection
30
36
42
48
54
60
66
Multi Frames
Figure 3-21. DOWNLINK SIGNALING FAILURE
3-66
Version 01 e
issue c
9W535
Downlink Signaling Failure Counter
This BS_PA_MFRMS parameter is also used as Downlink Signaling failure Counter (DSC). When an MS camps on to a cell, DSC is set to a value equal to the nearest integer of 90/BS_PA_MFRMS for that cell. If a message is successfully decoded DSC is increased by 1, otherwise DSC is decreased by 4. When DSC 0 cell reselection is performed. Figure 3-21 shows an example of this process.
Version 01 e
issue c
3-67
9W535
Purpose Random Access:

s
obtain a SDCCH
Triggers:
s
to perform a Location Update to answer to a paging-message as a result of a user request
Random Access Scheme:

s
Used to prevent collision on RACH Slotted -Aloha scheme is used BCCH parameters used: Tx-integer max retrans
3-68
Version 01 e
issue c
9W535
RANDOM ACCESS
The MS uses the Random Access procedure or initial assignment procedure to obtain a signaling channel (SDCCH) from the GSM network.
TRIGGERS
The Random Access procedure is always triggered upon the request of the MS, for one of the following reasons:
s s s
To perform a Location Update To answer to a paging-message As a result of a user request, for example, a mobile-originating call establishment
RANDOM ACCESS SCHEME
When a mobile station needs to communicate, always rst a channel request is forwarded to the network via the RACH. The network is dealing with several mobile stations within each cell simultaneously, and has no method of knowing exactly when mobile stations will start their communication. It is possible that mobile stations send an access burst at the same time (a so-called collision), and that neither of the bursts can be interpreted by the network, because they are received within the same uplink time slot. If a collision occurs, the mobile stations involved will notice that the network does not respond, and so the mobile stations will retry to access the network. If the mobile stations would retry simultaneously, another collision would occur. In order to prevent multiple collisions and assure efcient access to the network for all mobiles, a sophisticated access scheme is required. GSM uses the so-called slotted-Aloha scheme, which is one of the best-known and simplest access schemes. This scheme uses the following measures to deal with network access:
s
If a mobile station access attempt is not answered by the network, the mobile will re-attempt, however after a random interval. As a result, two mobiles that collided during their rst attempt, will almost for sure not collide during the next attempt. When the offered trafc load increases, the probability of having a collision with another mobile with every next attempt also increases. Therefore, in GSM, the network controls the offered load in terms of access requests and makes sure that the offered amount of access bursts does not exceed a particular threshold. In order to do so, the network provides the mobile stations with information on the allowed amount of re-attempts and the average duration of the interval between attempts. This information is spread via the BCCH on a cell-per-cell basis.
Version 01 e
issue c
3-69
9W535
Tx-integer 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Table 3-8.
# Time Slots between two Attempts 3 4 5 6 7 8 9 10 11 12 14 16 20 25 32 50
VALUES OF TX-INTEGER
3-70
Version 01 e
issue c
9W535
RACH CONTROL PARAMETERS
To prevent collisions on the air-interface the following parameters are sent on the BCCH channel:
s
Tx-integer
This parameter represents the time interval between re-transmissions of a random request. The MS draws a random value for each transmission with uniform probability distribution in the set which is determined using the Tx-integer value. This random value represents the number of timeslots on the RACH between the initiation of the Random Access procedure and the rst access attempt (RIL3-RR CHANNEL REQUEST message), or between two successive access attempts.
max retrans
This parameter represents the maximum number of access attempts allowed if there is no AGCH answer (RIL3-RR IMMEDIATE ASSIGNMENT message) from the network within a certain time interval controlled by the timer T3120. If there is still no answer after the maximum number of access attempts, the MS performs a Cell Reselection. The parameter can have the value 0-3, representing 1, 2, 4 or 7 retransmissions.
Example
3
Suppose Tx-integer is set to the value 11. The number of timeslots on the RACH between the initiation of the Random Access procedure and the rst access attempt is randomly drawn from the set:
{0, 1, ..., max(Tx-integer) - 1} = {0, 1, ..., 10}

Suppose the value 3 is drawn. This results in 6 time slots between the initiation of the Random Access procedure and the rst access attempt.
Version 01 e
issue c
3-71
9W535
8 7
RADIO_LINK_WARNING RADIO_LINK_TIMEOUT
6 5 4 3 2 1 1 1 1 RT/MS on max. power 0 0 1 1 1 1 1 1 1 Connection cut off
BFI
Figure 3-22. RADIO LINK FAILURE
3-72
Version 01 e
issue c
9W535
RADIO LINK FAILURE
The criterion for determining Radio Link Failure in the MS is based on the success rate of decoding messages on the downlink SACCH.
Radio Link Time Out
The aim of determining radio link failure in the MS is to ensure that calls with unacceptable voice/data quality, which cannot be improved either by RF power control or handover, are either re-established or released in a dened manner. In general the parameters that control the forced release should be set such that the forced release will not normally occur until the call has degraded to a quality below that at which the majority of subscribers would have manually released. This ensures that, for example, a call on the edge of a radio coverage area, although of bad quality, can usually be completed if the subscriber wishes. The radio link failure criterion is based on the radio link counter S. If the MS is unable to decode a SACCH message (BFI=1),S is decreased by 1. In the case of a successful reception of a SACCH message (BFI=0) S is increased by 2. In any case S shall not exceed the value of RADIO_LINK_TIMEOUT. If S reaches 0 a radio link failure shall be declared and the connection is cut off. The RADIO_LINK_TIMEOUT parameter is transmitted by each BSS in the BCCH data. The algorithm shall start after the assignment of a dedicated channel and S shall be initialized to RADIO_LINK_TIMEOUT value set by the operator.
Radio Link Failure Warning
There is also the parameter RADIO_LINK_WARNING. It does the same as the Radio Link Time-out parameter, only if S reaches 0 the BSC directs the MS and the BTS to use their maximum RF power. This parameter has normally a lower value then the RADIO_LINK TIMEOUT. Figure 3-22 shows an example of the two parameters.
Version 01 e
issue c
3-73
9W535
3-74
Version 01 e
issue c
9W535
PARAMETERS
The list of BSS parameters which are related to the Radio Link is summarized bellow:
s
BS_AG_BLKS_RES
Species the number of Access Grant blocks on the BCCH/BCCHcomb. Range: [0 to 7] blocks, 0 means up to network.
MAX_RETRAN
Species the maximum number of retransmission an MS may perform on the RACH when there is on AGCH available. Range: [1, 2, 4, 7] attempts.
BS_PA_MFRMS
Species the number of multiframes between two paging messages of the same paging group. The MS is required to monitor the PCH channel every Nth paging block where:
N = (# blocks allocated for PCH per multiframe) x BS_AG_BLKS_RES

The typical paging block pattern to which the MS should tune, is calculated using its IMSI. This parameter is also used as downlink signaling failure counter. Range: [2 to 9] multiframes.
RADIO_LINK_TIMEOUT
Species the threshold for the number of failures on the radio link. If this threshold is reached the connection is cut off. Range: [4 to 64] SACCH blocks, in steps of 4 SACCH blocks.
RADIO_LINK_WARNING
Species the threshold for the number of failures on the radio link. If this threshold is reached the BSC directs the MS and the BTS to use their maximum power. Range: [0 to 60] SACCH blocks, in steps of 4 SACCH blocks.
Version 01 e
issue c
3-75
9W535
BSSMAP TIMERS:
s
T1 BLOCKING/UNBLOCKING SUPERVISION T4 RESET ACKNOWLEDGE TIMER T7 HANDOVER REQUIRED PERIODICITY T8 SUCCESSFUL HANDOVER TIMER T10 ASSIGNMENT COMPLETE/FAILURE TIMER T11 ASSIGNMENT REQUEST TIMER T13 RESET GUARD PERIOD T17 OVERLOAD TIMER T18 OVERLOAD TIMER T19 RESET CIRCUIT PROCEDURE Tqho MAXIMUM QUEUING TIME HANDOVER
3-76
Version 01 e
issue c
9W535
BSS TIMERS
BSSMAP TIMERS
3
3
The BSS MAP timers are dened by the ETSI (European Telecommunications Standards Institute). For GSM 6.5 the following timers are used:
s
T1, T4, T7, T8, T10, T11, T13, T17, T18, T19, and Tqho.
For a more detailed description of these timers refer to the ETSI documents. BSSMAP Timer 1 Time to receive blocking/unblocking supervision for a single circuit acknowledge: The MSC performs blocking/unblocking procedures to be informed about terrestrial circuits of the BSS that are out of service. The BSS may block a terrestrial circuit because:
s
Operation and Maintenance intervention makes the circuit unavailable for use. An equipment failure makes the circuit unavailable. Radio resource is not accessible from the terrestrial circuit.
s s
When the timer expires for the rst time (no (UN)BLOCKING ACKNOWLEDGE message is received), it is started again. If it expires for the second time the CIC is assumed as blocked/unblocked. The value must be higher than the MSC maximum reaction time and the transmission time for the blocking/unblocking and the belonging acknowledge message Range: [1 - 60s]. Suggested default: 2 s.
BSSMAP Timer 4 Time to receive of RESET ACKNOWLEDGE message. If the BSS sends a RESET message to the MSC and receive no RESET ACKNOWLEDGE message within a period T4 then it shall repeat the entire reset procedure. Range: [4 - 60s]. Suggested default: 10 s.
Version 01 e
issue c
3-77
9W535
BSSMAP Timer 7 After the rst HANDOVER REQUIRED message from the BSS, the updated message shall be repeated by the BSS within periodicity of this timer until:
s s s s s
A handover command message is received, A reset message is received, The reason for the original handover required message disappears, All communication is lost with the MS and the transaction is abandoned, The transaction ends.
Range: [5 - 60s]. Suggested default: 10 s.
BSSMAP Timer 8 Time to receive a not CLEAR COMMAND or HANDOVER FAILURE on the old channel. If before the expiry of this timer no CLEAR COMMAND message from the MSC is sent to the old BSS or a HANDOVER FAILURE from the MS is not received, then the old BSS shall release the dedicated radio resources. The terrestrial resource on the old BSS shall remain assigned until a CLEAR COMMAND is received from the MSC, at which point the old BSS shall mark the terrestrial resource as idle and return a CLEAR COMPLETE message to the MSC. Range: [1 - 60s]. Suggested default: 32 s.
BSSMAP Timer 10 Time to return ASSIGMENT COMPLETE or ASSIGMENT FAILURE message. The purpose of this timer is to keep the old channel sufciently long for the MS to be able to return to old channel. Range: [1 - 30s]. Suggested default: 25 s.
BSSMAP Timer 11 This timer denes the maximum allowed queuing delay time for an ASSIGNMENT REQUEST message. After a QUEUING INDICATION message is sent to the MSC timer T11 starts. If the timer expires the ASSIGNMENT REQUEST message will be removed from the queue and a CLEAR REQUEST message is sent to the MSC, with the Cause no radio resource available Range: [1s - 5min]. Suggested default 4 s.
3-78
Version 01 e
issue c
9W535
BSSMAP Timer 13 In the event of a failure at the MSC which has resulted in the loss of transaction reference information a RESET message is sent to the BSS Timer T13 is started after the reception of a RESET message in the BSS. It gives time for the BSS to release all affected calls and reference. After expiration of this timer the BSS sends a RESET ACKNOWLEDGE message to the MSC. Range: [5s-30s]. Suggested default: 10 s.
BSSMAP Timer 17 and 18 Overload control timers. On receipt of the rst OVERLOAD message the trafc load is reduced with one step, and timer T17 and T18 are started. During T17 all received overload messages are ignored. Reception of an OVERLOAD message after expiry of T17 but still during T18, will decrease the trafc load by one more step, and restart T17 and T18. If T18 expires and no OVERLOAD messages are received, the trafc will be increased by one step and T18 will be restarted until the full load has been resumed. Range: [30 - 120s]. Suggested default T17: 40s, T18: 60s (T17 < T18).
BSSMAP Timer 19 This timer is used at the BSS to supervise the reset circuit procedure. If the timer elapses before a response (RESET, RESET CIRCUIT ACKNOWLEDGE or UNEQUIPPED CIRCUIT) is returned to the BSS, the procedure is repeated. Range: [1 - 60s]. Suggested default: 10 s. BSSMAP Timer Tqho This timer species the maximum queueing delay time for a handover request. If the timer expires the handover request shall be removed from the queue and a handover failure message shall be sent to the MSC with the cause value no radio resource available (see also T11). Range [1 - 30s]. Suggested default: 2 s.
Version 01 e
issue c
3-79
9W535
AIR TIMERS:
s
T3101 IMMEDIATE ASSIGNMENT TIMER T3107 ASSIGNMENT COMMAND TIMER T3109 CHANNEL RELEASE TIMER T3111 CHANNEL DELAY TIMER
3-80
Version 01 e
issue c
9W535
Um TIMERS
The Um timers are related to the air interface. The following timers are dened by the ETSI. T3101 This is used to complete the channel assignment after a IMMEDIATE ASSIGNMENT. This timer is started on receipt of the CHN_ACT_ACK message. If no Establish_Ind is received during this time, the RF_CHN_REL message is sent to the BTS. Range: [1 - 30s]. Suggested default: 3 s. T3107 This timer is used to guard the seizure of the MS on the new channel. This timer is started by the sending of an ASSIGNMENT COMMAND message and is normally stopped when the MS has correctly seized the new channel. If the timer expires before an ASSIGNMENT_COMPLETE or an ASSIGNMENT_FAILURE message has been received from the MS, the allocated resources on the new channel have to be released and an ASSIGNMENT_FAILURE is expected on the old channel. Range: [1 - 32s]. Suggested default: 23s. Dependency: T3107 < T10 T3109 This timer is used to guard the reception of the RELEASE INDICATION (waiting time for channel deactivation on the network side). This timer is used in the channel release procedure. Its purpose is to release the channels in case of loss of communication. The timer is started on sending the DEACT_SACCH message to the BTS. If no RELEASE INDICATION is received during this time, the message RF_CHANNEL_RELEASE is sent to the BTS. The value should be high enough to ensure that the mobile station detects a radio link failure. Range: [1 - 30s]. Default 12 s. T3111 This timer is used to delay the release of the channel resources in the BTS after disconnection of the main signaling link. It is started on receiving a RELEASE INDICATION message. When the timer times out the RF_CHANNEL_RELEASE message is sent to the BTS. Range: [1 - 30s]. Default: 1 s.
Version 01 e
issue c
3-81
9W535
ANSWERS C1 EXERCISE
1. 2.
3 3
The handset will camp on to BTS 1. The car set will camp on to BTS 3. The handset will camp on to BTS 1. The car set will camp on to BTS 2.
C2 EXERCISE
1.
3
CELL_RESELECT OFFSET = not applicable TEMPORARY_OFFSET (M1) = 20 dB TEMPORARY_OFFSET (M2) = 10 dB PENALTY_TIME (M1, M2) = 20 s Same offsets are applicable, so no problem.
2.
TRAFFIC LOAD EXERCISE

1. 2. 3. FREEfactor_2 = 5 The priority is n, k, l, m.
Free trafc channels on cell k should be 6
3-82
Version 01 e
issue c
OMC-PMS FUNCTIONAL DESCRIPTION
4
4-1 4-1 4-1 4-1 4-3 4-3 4-3 4-5 4-7 4-7 4-7 4-7 4-9 4-11 4-11 4-11 4-11 4-13 4-13 4-13 4-15 4-15 4-15 4-15 4-17 4-17
Contents
INTRODUCTION TO OMC-PMS
s s s
LESSON INTRODUCTION LESSON OBJECTIVES NEW FUNCTIONALITY IN RELEASE NPR2.2
POSITION AND PURPOSE OF OMC-PMS

s s s
MEASUREMENTS DATA FLOW METRICA/NPR SYSTEM OMC-PMS LAYERS
APPLICATION AREAS
s s s
NETWORK OPERATIONS ENGINEERING TRAFFIC MANAGEMENT
SYSTEM CONFIGURATION MAIN SYSTEM COMPONENTS

s s s s s s s s s s s s
PARSER LOADER TQL SERVER ADMINISTRATION DATABASE PERFORMANCE DATABASE SCHEDULER SUMMARY SCRIPTS ARCHIVER BATCH REPORTS ANALYSIS FUNCTIONS ADMINISTRATION MODULE REPORTING MODULES
Version 03 e
issue b
4-i
Contents
KINGFISHER
4-19 4-21 4-21 4-21 4-21 4-23 4-23 4-24 4-24 4-26 4-29 4-33 4-33 4-33 4-34 4-34 4-35 4-39 4-39 4-39 4-40 4-40 4-41 4-41 4-45 4-45 4-45 4-47 4-47
USER TASKS
s s
TYPES OF USERS DAILY OPERATIONS MODULE Overview of Daily Operations Module Functions of Daily Operations Module Pre-defined Reports Graphs Pre-defined Graphs User-controllable Graphs Using the Daily Operations Module
HISTORICAL REPORTING MODULE Overview of Historical Reporting Module Functions of Historical Reporting Module Pre-defined Reports Pre-defined Trend Charts Using the Historical Reporting Module
FORECASTING MODULE Overview of Forecasting Module Functions of Forecasting Module Pre-defined Prediction Reports Pre-defined Graphical Forecasts Exporting Traffic Data Using the Forecasting Module
KINGFISHER Overview Functions of Kingfisher
ADMINISTRATION MODULE Overview of Administration Module
4-ii
Version 03 e
issue b
INTRODUCTION TO OMC-PMS
LESSON INTRODUCTION
4
4
This lesson describes the optionally provided sub-system of the Operations and Maintenance Center (OMC) for analyzing BSS performance data: the Performance Management Subsystem (OMC-PMS). The OMC-PMS has been built using the Metrica/NPR (Network Performance Reporting) performance management system. This system is in use by a large number of GSM operators around the world. The OMC-PMS provides a set of pre-dened reports and graphs for analyzing Base Station System (BSS) and Mobile Switching Center (MSC) performance and quality of service indicators. The system provides visibility of availability, utilization and grade of service.
LESSON OBJECTIVES

s s s s s
Explain the position of the OMC-PMS in the network. Identify the functions of the OMC-PMS. Identify the main components of the OMC-PMS. Identify the user tasks of the OMC-PMS. Identify the tools of the OMC-PMS.
NEW FUNCTIONALITY IN RELEASE NPR2.2
The new functionality in release NPR 2.2 is as follows:

s s
Handling of MSC performance measurements Generating additional reports and graphs for both BSS and MSC by the modules: Daily Operations, Historical Reporting and Forecasting New operations and maintenance facilities (e.g. license functionality)
Version 03 e
issue b
4-1
6W003
MSC
BSC
OMC-R
OMC-PMS (Metrica/NPR)
BSC MS
BTS
Figure 4-1.
MEASUREMENTS DATA FLOW
4-2
Version 03 e
issue b
6W003
POSITION AND PURPOSE OF OMCPMS 4

MEASUREMENTS DATA FLOW 4
For GSM cellular network operations, engineering and trafc management purposes, performance measurements data is collected in the Base Station Controllers (BSCs) and in the Mobile Switching Centers (MSCs). This data is transferred to the Operations and Maintenance Center (OMC) every 15 minutes. The OMC can consist of two sub-systems:
s s
The OMC-R The optional Performance Management Sub-system (OMC-PMS)
The 15-minutes measurements data transferred from the BSCs/MSCs to the OMC is collected at the OMC-R and stored in data les. Each le contains data that is generated during a regular 1-hour time interval. This le does not get closed and transferred to the OMC-PMS until an hour past the end of the time interval. This extra time is to accommodate for any delay in receiving data from the BSC/MSC. For example, for the 10:00-10:59 time period, the le will nally be transferred around 12:00. The OMC-PMS is used to analyze performance measurements data. Besides the performance measurements data collection, the OMC-R is also responsible for the administration and the maintenance of the cellular network.
METRICA/NPR SYSTEM
The Performance Management Sub-system (OMC-PMS) has been built using the Metrica/NPR system. Metrica/NPR provides a powerful infrastructure for the rapid deployment of a highly sophisticated and functional performance reporting system. This functionality covers network operations, engineering and trafc management type capabilities. Because no telecommunications operator is the same as any other, both in the type and amount of network infrastructure and in their business processes and priorities, Metrica/NPR must be congured and tailored for each installation.
Version 03 e
issue b
4-3
6W003
Lucent Technologies Specic Development GSM Specic Layer
Metrica/NPR Core
Metrica DBMS
Figure 4-2.
OMC-PMS LAYERS
4-4
Version 03 e
issue b
6W003
OMC-PMS LAYERS
OMC-PMS consists of:
s
Lucent Technologies specic developments This layer includes special interfaces to the OMC-R as well as modications for support of all BSS and MSC performance counters. GSM specic layer This layer provides a data base model for the representation of performance data for GSM. A set of reporting modules generate a range of reports from this data and provide basic visibility of all performance counters. Metrica/NPR Core This layer provides the basic infrastructure for the management of the performance data that is provided by the network elements or element management systems. It is the conguration of sub-systems in this layer that form the major part of initial deployment and it is the maintenance of these sub-systems that form the bulk of system administration tasks. Metrica Data Base Management System Metrica is a powerful Data Base Management System (DBMS) specically designed for the storage, analysis and presentation of technical data.
Version 03 e
issue b
4-5
6W003
APPLICATION-AREAS OMC-PMS:
s
Network operations: observe operation of equipment Engineering: detect equipment overload or under-utilization Trafc management: forecast the exhaustion of the network elements
Telecommunication Networks
Performance Measurements
Maintenance Hours, minutes
Network Operations Function
Re-engineering
12
Month, weeks Earth
Engineering Function
Network Extensions Year, months Figure 4-3. NETWORK FUNCTIONS
Trafc Management Function
4-6
Version 03 e
issue b
6W003
APPLICATION AREAS
s s s
The main application-areas in which the OMC-PMS is used, are: Network operations Engineering Trafc management
The OMC-PMS is able to perform the network operations, engineering and trafc management functions by using a user-friendly graphical user interface, which provides graphical displays and extended summary reporting capabilities. The graphical displays allows the user to display a variety of key measurements from the network in graphs, such as cell loading, dropped calls and handover performance.
NETWORK OPERATIONS
The object of network operations is to ensure the quality of service provided by the cellular network. The tasks of network operations include helping in fault diagnosis, verifying fault repair, planning outages and helping to detect performance problems that may be caused by equipment faults.
ENGINEERING
The cellular network is designed using specic engineering parameters. The task of engineering is to monitor the performance of the network to detect whether the engineering parameters are correctly dened, or in other words to detect where to much trafc is being directed (overload) and to detect where equipment is hardly occupied even during peak hours (over-capacity). If structural overload conditions occur in a particular part of the cellular network, the normal action would be to plan an extension in equipment (for example, additional TRXs). In the case of a structural low trafc, the network is normally re-engineered. This means that equipment is re-allocated in order to make optimum use of all network elements.
TRAFFIC MANAGEMENT
The objective of trafc management is to see trends in trafc and performance. Based on the actual trafc carried on the network, the trafc management function will extrapolate the trafc growths to forecast the exhaustion of the network elements.
Version 03 e
issue b
4-7
6W003
LAN
Local Disks
OMC-PMS (Metrica/NPR) Data base Server
OMC-PMS Workstation
OMC-PMS Workstation
OMC-R OMC-R Workstation
OMC-R Workstation
Figure 4-4.
EXAMPLE CONFIGURATION
4-8
Version 03 e
issue b
6W003
SYSTEM CONFIGURATION
The OMC-PMS consists of a server and one or more workstations. The local disks of the server (an HP-9000 computer) contain the performance and the administration data bases. The server supports all data base activity for all users of the system and for the critical activities of loading performance data and generating summary data. In the gure on the opposite page an example conguration is shown. This conguration has a shared Local Area Network (LAN) for both the OMC-R and the OMC-PMS. Using this conguration both users of the OMC-R workstations and users of the OMC-PMS workstations are able to access the OMC-PMS application.
Version 03 e
issue b
4-9
6W003
Daily Operations Module Admin. Module
Historical Reporting Module
Fore Casting Module King Fisher
Parser
Loader
Performance Measurements Data Files
TQL Server
Scheduler
Analysis Functions
Archiver
Summary Scripts
Batch Reports
Performance Data Base
Admin. Data Base
: Data Flow (read and/or write) : Function interaction
Figure 4-5.
SYSTEM DIAGRAM
4-10
Version 03 e
issue b
6W003
MAIN SYSTEM COMPONENTS
The OMC-PMS consists of a number of sub-systems which are organized as in the system diagram on the opposite page.
PARSER
4
The OMC-PMS contains a parser which is congured to process the BSS/MSC performance data as output from the OMC-R. The parser is solely concerned with interpreting the syntax of the BSS/MSC data and simply reformats the data into the OMC-PMS standardized format.
LOADER
The loader is a highly congurable sub-system that reads the output of the parser and loads the data into the performance database. Because the parser is only concerned with the syntactic transformation of the data, the loader must deal with any semantic transformations required in the data i.e mapping the performance counters produced by the network elements onto the columns dened in the GSM data model. This mapping process can be very complex and will typically involve mapping multiple counters onto a single column using various arithmetic expressions. The loader also provides mechanisms to validate incoming data and to set defaults when the data is missing. The smooth operation of the loader is essential to the usefulness of the OMCPMS system. If data is incomplete, the data set as a whole often loses its value. Also, summary calculations rely on complete data.
TQL SERVER
The Technical Query Language (TQL) Server is a standard OMC-PMS component that provides access to a high performance technical relational Data Base Management System (DBMS). It also provides a wide range of data analysis functions. The TQL server manages both the administration and performance data bases. To access the data bases the TQL query language is used.
Version 03 e
issue b
4-11
6W003
SYSTEM COMPONENTS:
s
Parser Interprets syntax of the performance data and formats it into standard format Loader Performs semantic transformations and loads the data into the Performance Data base TQL Server Manages the system data bases Administration data bases Contains data related to the system conguration Performance data base Contains the 15-minutes performance data, summary data and network hierarchy tables Scheduler Schedules the summary scripts, archiver and batch scripts
4-12
Version 03 e
issue b
6W003
ADMINISTRATION DATABASE
The administration database is a set of tables that maintain information regarding the conguration and administration of the OMC-PMS. The data base contains tables that dene for example:
s s s
The users of the OMC-PMS and their capabilities The activities to be run by the scheduler The age of data that is to be maintained in the performance data base by the archiver
PERFORMANCE DATABASE
The performance data base is a large set of tables that contain all the performance data loaded from the cellular network. It is from this database that all the reporting applications derive information. The database contains:
s
15-minutes performance data loaded from the OMC-R by the OMC-PMS Loader Daily, weekly and monthly summary tables that are populated automatically by the summary scripts executed by the Scheduler Network hierarchy tables that store information on the relationships of network elements to other nodes, for example BTS to BSC
The performance database is potentially very large (typically many gigabytes). It is being almost constantly added to by the loader and to a lesser extent by the summary scripts which run daily.
SCHEDULER
The scheduler is responsible for executing various activities on a daily, weekly or monthly basis. It provides a mechanism for prioritizing the execution of tasks and for dening dependencies between tasks. The scheduler is used to execute the following activities:
s s s
Daily, weekly and monthly summary scripts Archiver Batch Reports
Version 03 e
issue b
4-13
6W003
Performance Measurements Data Files
Parser & Loader Script
Daily Summary Script
15-minutes Performance Data Daily Summary Data Weekly Summary Data
Weekly Summary Script
Monthly Summary Data
Performance Data base Monthly Summary Script
Figure 4-6.
SUMMARY SCRIPTS
4-14
Version 03 e
issue b
6W003
SUMMARY SCRIPTS
Summary scripts are TSL (Technical Scripting Language, which is the Metrica application development language) programs which are run daily, weekly or monthly by the Scheduler to summarize the 15-minutes performance data into higher level statistics. The summary data is stored in the performance data base. The summary scripts usually calculate per network element busy hours or busy day busy hours and determine appropriate averages or totals during these busy hours (for some network elements multiple busy hours are maintained). Period totals are also maintained.
ARCHIVER
The archiver is run on a regular basis (daily or weekly) by the Scheduler to maintain a xed time-window of 15-minutes performance data and/or summary data in the database and thus ensure stable disk usage. The archiver optionally unloads old data into compressed archive les and then deletes the old data from the database.
BATCH REPORTS
All tabular reports that are dened as part of the interactive reporting modules can be executed in batch mode by the Scheduler. This allows daily, weekly and monthly reports to be generated automatically by the system. Facilities are provided to dene the input parameters to each report and to direct each report to le, printer or to a set of E-mail recipients.
ANALYSIS FUNCTIONS
The OMC-PMS DBMS provides a means of extending the analysis capabilities of the TQL Server by implementing User Dened Functions (UDFs). These functions are built into the TQL language and can be used by all OMC-PMS components. The OMC-PMS includes a range of analysis functions specically designed for use in network performance reporting and trafc analysis. The functions include:
s
Interpolation and hourly segmentation functions to cope with missing and variable period data Busy hour functions Erlang-B functions for calculating grade of service, offered trafc and capacity Miscellaneous functions to support percentage failure and successful measures
s s
Version 03 e
issue b
4-15
6W003
SYSTEM COMPONENTS (Continued):
Summary scripts Create daily, weekly and monthly summary data in the performance data base Archiver Archives and/or deletes data from the performance data base Batch reports Generate automatically daily/weekly/monthly reports Analysis functions Provides extended analysis capabilities to the OMC-PMS components
4-16
Version 03 e
issue b
6W003
ADMINISTRATION MODULE
The administration module is an application that allows the system administrator to monitor and control the key sub-systems within the OMC-PMS.
REPORTING MODULES
The reporting modules are a set of applications built using TSL which provide data model specic reporting capabilities in the area of daily operations, historical reporting and trending, forecasting and cross-network performance visualization. The Daily Operations module provides reports and analysis of the 15-minutes performance data that has been loaded by the system. For example, it can be used to plot daily trafc proles for a specied network element. The focus of this module is on the use of performance data in an operations environment, for example in the support of fault diagnosis or to help in planning outages. The Historical Reporting module provides reports and trend plots based on the summary data, for example daily and weekly busy hours, that are constantly being calculated by the system. It can also be used to look at trends in trafc on a network element or look at quality indicators, such as dropped calls on TCH. The focus of this module is on the use of performance data in longer term operations and in planning, for example in the support of operations responsibility for network quality of service. The data used by the historical module is pre-compiled, so reports can be generated much faster. The Forecasting module provides reports and graphs based on the summary trafc data that can be used to help predict exhaustion in the network and to nd elements that are constantly under-utilized. For example, it can be used to nd a list of all cells that will reach a critical trafc level within 90 days. The focus of this module is to provide base data into the planning and trafc management process. Note that the module does not provide any modeling capabilities. It simply indicates to the user that elements will reach exhaustion if some change in the network does not take place.
Version 03 e
issue b
4-17
6W003
SYSTEM COMPONENTS (Continued): Administration module Serves as user-interface for the OMC-PMS administrator
Reporting modules Serves as user-interface for the OMC-PMS users: Daily Operations Module Historical Reporting Module Forecasting Module
Kingsher Is a data analysis and manipulation tool
4-18
Version 03 e
issue b
6W003
KINGFISHER
Kingsher is a standard OMC-PMS tool for ad hoc data analysis of data held in the OMC-PMS databases. It uses an intuitive point-and-click interface to specify queries and analysis functions on data in the database and has a powerful graphics capabilities for automatically displaying the results of queries. Kingsher can fulll a number of roles in an OMC-PMS environment:
s s
It provides ad-hoc analysis and query capabilities for network engineers. It allows system administrators to monitor database structure and to control the access rights of database users.
Kingsher is a very powerful database front-end tool that can nd use in all areas of network operations.
Version 03 e
issue b
4-19
6W003
TYPES OF USERS:
s
OMC-PMS users: Daily Operations Module Historical Reporting Module Forecasting Module Kingsher
OMC-PMS administrator: Administration Module
Figure 4-7.
ICON BOX REPRESENTING THE MODULES
4-20
Version 03 e
issue b
6W003
USER TASKS
TYPES OF USERS
4
4
In general there are two types of users of the OMC-PMS:

s s
OMC-PMS users OMC-PMS administrator
Each type of user has its own tasks and responsibilities. The OMC-PMS administrator is responsible for conguring, monitoring and controlling the OMCPMS. The administrator will normally use the Administration module to perform his/her tasks. The OMC-PMS user is responsible for evaluating the cellular network. To do his/ her job, the OMC-PMS user can use the Daily Operations module, the Historical Reporting module, the Forecasting module and/or the Kingsher. Each of the modules mentioned is described in the following sections.
DAILY OPERATIONS MODULE Overview of Daily Operations Module
4 4
The Daily Operations reporting module provides reports and graphs derived from the 15-minutes performance data. This module is intended for use by operations staff to help in fault diagnosis, verifying fault repair, planning outages and helping to detect performance problems that may be caused by equipment faults. The reporting module can be used essentially in two distinct ways:
s
Reactively, where the operator wants to look at some performance parameter (for example trafc) of a known network element or service. Pro-actively, where the operator wants to search for elements that are poorly performing on the basis of some thresholds.
Graphical displays provide the main method of using the system reactively. A wide range of pre-dened graphs, as well as operator controllable, are available which allow key performance parameters and counters to be plotted for a known network element. Textual reports provide the method of using the system pro-actively. A number of pre-dened reports are available which search across a whole set of network elements to nd elements that fall above specied thresholds. These reports can be thought of a hit list of elements that should be more closely examined to explain their behavior.
Version 03 e
issue b
4-21
6W003
DAILY OPERATIONS MODULE:

s
Searches for network elements with poor performance Shows performance of suspected faulty network elements Produces output from 15-minutes performance data: Pre-dened reports, e.g: Cell TCH performance Daily MSC trafc Pre-dened graphs, e.g: Cell blocking Congestion of a route User-controllable graphs, e.g: Cell handover HLR statistics
4-22
Version 03 e
issue b
6W003
Functions of Daily Operations Module
The Daily Operations module produces the following types of output from the 15minutes performance data:
s s s
Pre-dened reports Pre-dened graphs User-controllable graphs
Pre-dened Reports
The input of a pre-dened report is the 15-minutes performance data selected from a given period of time (one or more days). A pre-dened report is generated by selecting that specic report from a menu (of the graphical interface) that contains a list of report types that can be produced. After selecting a report from the menu a report parameter dialog is displayed. The user can specify the following selection criteria:
s s s s
Scope of the search; for example all cells parented to a particular BSC Time domain for the report; for example totals for the busy hour Sort criteria; for example by descending congestion (worst rst) Threshold values to use to select the data; for example more than 3 Erlangs trafc
The following pre-dened reports are available:

s
Cell TCH performance Parameters on this report are, for example: the average number of TCH that were in service, trafc carried in Erlangs, and percentage dropped calls. Cell SDCCH performance Parameters on this report are, for example: the average number of SDCCH that were in service, trafc carried on SDCCH in Erlangs, and number of blocked seizures. Cell handover performance This report shows the performance of intra-cell handover, together with incoming and outgoing inter-cell BSS handover. It also lists all the causes for cell handover and the success rates per cause, and the performance of cell-to-neighbour-cell handover. Route trafc This report shows statistics for specied routes throughout the mobile network. Linkset availability This report shows the availability of a link set in the Common Channel Signaling (CCS) No. 7 network. Linkset utilization Parameters on this report are, for example: usage in Erlang for both TX and RX, and number of MSUs sent and received.
Version 03 e
issue b
4-23
6W003
Daily MSC trafc Parameters on this report are, for example: the total switched trafc calls and the total switched trafc in Erlang. MSC handover performance Parameters on this report are, for example: the number of inter-cell and inter-MSC handovers that failed/were attempted. Network availability Parameters on this report are, for example: the average number of dened TCH and average number of available in-service TCH, and the total cell down-time in minutes.
Graphs
The Daily Operations module has a facility for displaying both pre-dened graphs representing network performance parameters, and graphs representing any of the performance data being collected from the cellular network (a usercontrollable graph). The input of both types of graphs is the 15-minutes performance data selected from a given period of time (one or more days).
Pre-dened Graphs
Plotting a pre-dened graph is done in the same way as for generating a predened report. A pre-dened graph is generated by selecting that specic graph from a menu (of the graphical interface) that contains a list of graph types that can be produced. After selecting a graph from the menu a graph parameter dialog is displayed. The user can select the network element whose performance (s)he wish to graph (for example BSS:19-BTS:67). The following pre-dened graphs are available:
s
Cell trafc and performance This chart displays for a single cell three plots: trafc in Erlangs against time, percentage of blocked calls, and percentage of dropped calls. Cell blocking This chart displays for a single cell four plots: the number of blocked calls against time, the total attempted calls, the percentage blocked calls and the number of available channels. Dropped call This chart displays for a single cell the following plots: the number of dropped calls against time due to RF loss, and due to target channel (seizure) failure, the total non-blocked calls, and the percentage of dropped calls due to RF loss or seizure failure. SDCCH trafc and performance The plots for a chosen cell are: trafc in Erlangs on SDCCH against time, percentage of blocked calls, and percentage of dropped calls. SDCCH cell blocking The four plots for a chosen cell are: the number of blocked calls against time, the total attempted calls, the percentage blocked calls, and the available channels.
4-24
Version 03 e
issue b
6W003
SDCCH dropped calls The plots for a chosen cell are: the number of dropped calls against time due to RF loss, and due to target channel (seizure) failure, the total nonblocked calls for the selected cell, and the percentage of dropped calls. Cell handover performance The plots for a chosen cell are: successful and failed incoming inter-cell internal handovers, successful and failed outgoing inter-cell internal handovers, and successful and failed intra-cell handovers. Cell availability The plots are: trafc channel availability, and control channel availability. Worst-Performing Cells This chart displays the n-worst cells which are under control of a BSC/MSC or in a particular region. Best-Performing Cells This chart displays the n-best cells for the highest daily trafc total. BSS cell trafc The plots are: trafc in Erlangs against time for all cells within the chosen BSS, average percentage of blocked calls for the BSS, and average percentage of dropped calls for the BSS. Cell trafc for a region The three plots are: trafc in Erlangs against time for all cells in the selected region, percentage blocked calls for the region, and percentage dropped calls for the region. Load on a processor This displays the load against time on a support processor associated with a node on the selected days. Trafc on a route The three plots are: incoming and outgoing trafc on the route in Erlangs, incoming and outgoing calls for the route in Erlangs, and answer seize ratio for the route. Congestion of a route The four plots are: number of congested calls against time for the route, total bids, percentage congestion, and dened and available circuits. Availability of a CCS No. 7 Link The two plots are: percentage availability for the link, and total link failures. Utilization of a CCS No. 7 Link The three plots are: transmitted and received MSUs for the link, transmitted and received SIF and SIO octets for the link, and transmitted and received trafc in Erlangs. Availability of a CCS No. 7 Linkset The two plots are: percentage availability for the linkset and the availability of its constituent links, and failures of the constituent links.
Version 03 e
issue b
4-25
6W003
Utilization of a CCS No. 7 Linkset (TX) The three plots are: transmitted MSUs for the linkset and the transmitted MSUs for the constituent links, transmitted trafc on the linkset and the transmitted trafc on the constituent links, and load sharing of the links in the linkset for transmitted data. Utilization of a CCS No. 7 Linkset (RX) The three plots are: received MSUs for the linkset and the received MSUs for the constituent links, received trafc on the linkset and the received trafc on the constituent links, and load sharing of the links in the linkset for received data. MSC Trafc The two plots are: total switched trafc in Erlangs against time for the appropriate trafc categories on the MSC, and percentage of calls that failed (were not answered). MSC Performance The two plots are: total network incoming calls on the switch, overlaid with the failed calls, and total mobile originating calls on the switch, overlaid with the failed calls. MSC Handover Performance The three plots are: total number of successful inter-cell handovers attempts and failures, total number of incoming inter-MSC handover attempts and failures, and total number of outgoing inter-MSC handover attempts and failures. Home Location Register (HLR) Subscribers The two plots are: number of subscribers registered in the selected HLR, and the number registered in all VLRs, and the percentage of active subscribers, that is, the percentage of subscribers whose subscriber records have been loaded into a VLR. Total system trafc The two plots are: total switched trafc for the appropriate trafc categories, totalled for all MSCs in the network, and total cell trafc channel trafc for all cells in the network. BSC Data Coverage This chart displays a bar chart that shows the percentage of data coverage of a selected BSC on the selected days. MSC Data Coverage This chart displays a bar chart that shows the percentage of data coverage of a selected MSC on the selected days.
User-controllable Graphs
A user-controllable graph is generated by selecting an attribute group from a menu that contains a list of all attribute groups. The attributes are the performance parameters of the cellular network that have supported measurements. For example, the attribute group Cell Handover contains the attribute Successful intracell handover.
4-26
Version 03 e
issue b
6W003
After selecting an attribute group from the menu a network element counter parameter dialog is displayed. The user can specify the following selection criteria:
s s
Select the network element whose performance the user wishes to graph Select up to three performance parameters that the user wishes to view
The following attribute groups are available to plot a graph:

s s s s s s s s s s s s s s s s s s s s s s s
Cell Resource Usage Cell Interference Cell handover Cell handover reasons Cell-Cell Trafc Flow Cell performance details Cell handover details Cell Handover Performance Details Processor Details CCS No. 7 Link Performance CCS No. 7 Linkset Performance BSS SCCP Statistics CCS No. 7 Signalling Dispersion CCS No. 7 MAP Signalling MSC Trafc MSC/Visitor Location Register (VLR) Performance Supplementary Service Data Call Completion Data Home Location Register (HLR) Statistics Wireless Summary Data (Non-Handover) Wireless Summary Data (Handover) VLR/EIR Details Home Location Register (HLR) Details
Version 03 e
issue b
4-27
6W003
SUMMARY BSS CELL TCH TRAFFIC REPORT DAY OF 97/01/30 FOR ALL BSC IN REGION WEST (BUSY HOUR VALUES)
Min. Traffic (E) Min. % Blocking Min. % Dropped Min. % Data Coverage
: : : :
BSC Id. WEST-BSS:1 WEST-BSS:2 WEST-BSS:3 WEST-BSS:4 WEST-BSS:6 WEST-BSS:8
Busy Hour 10:45 16:45 11:15 14:30 10:45 18:30
Channels Def. 170 170 186 59 134 66 Avail. Attempts 158.8 168.7 186.0 59.0 132.8 66.0 424 464 716 696 475 503
Blocking (%) 0.00 0.00 0.00 0.00 0.00 0.00
Dropped (%) 0.24 1.08 1.26 0.86 1.68 1.59
Traffic (E) 5.01 5.62 6.06 6.59 6.07 2.72
-----------------------------------------------------------------------------------------------------------------------------------
Figure 4-8.
CELL TCH PERFORMANCE REPORT
4-28
Version 03 e
issue b
6W003
Using the Daily Operations Module
On the opposite page and on the next pages the following examples are presented:
s s s
The pre-dened report: Cell TCH Performance report The pre-dened graph: Cell Trafc and Performance graph The user-controllable graph representing the attributes TCH Attempts, TCH RF Loss and TCH Blocking of attribute group Cell TCH and SDCCH
Version 03 e
issue b
4-29
6W003
Traffic (E)
1.4 1.2 1.0 0.8 (E) 0.6 0.4 0.2 0.0 00:00 5.0 4.0 (%) 3.0 2.0 1.0 0.0 00:00 25.0 20.0 (%) 15.0 10.0 5.0 0.0 00:00 03:00 03:00 03:00
Cell TCH Traffic Cell COMCSRV-BSS:1-BTS:13 on 93/02/24
06:00
09:00
12:00
15:00
18:00
21:00
00:00
% Blocking
06:00
09:00
12:00
15:00
18:00
21:00
00:00
% Dropped Calls
06:00
09:00
12:00
15:00
18:00
21:00
00:00
Figure 4-9.
CELL TRAFFIC AND PERFORMANCE GRAPH
4-30
Version 03 e
issue b
6W003
300.0 250.0 200.0 # 150.0 100.0 50.0 0.0 22 Feb 23 Feb 24 Feb
TCH Attempts for Cell C00019-1
25 Feb
26 Feb
27 Feb
28 Feb
01 Mar
18.0 16.0 14.0 12.0 10.0 8.0 6.0 4.0 2.0 0.0 22 Feb 23 Feb 24 Feb
TCH RF Loss for Cell C00019-1
25 Feb
26 Feb
27 Feb
28 Feb
01 Mar
3.0 2.5 2.0 # 1.5 1.0 0.5 0.0 22 Feb 23 Feb 24 Feb
TCH Blocking for Cell C00019-1
25 Feb
26 Feb
27 Feb
28 Feb
01 Mar
Figure 4-10. USER-CONTROLLABLE GRAPH
Version 03 e
issue b
4-31
6W003
HISTORICAL REPORTING MODULE: Shows long term performance trends on single network element Generate performance summaries of network Produces output from daily, weekly and monthly summary data: Pre-dened reports, e.g: Cell TCH performance MSC trafc Pre-dened trend charts, e.g: Cell trafc and performance trends Trends in utilization on a route
4-32
Version 03 e
issue b
6W003
HISTORICAL REPORTING MODULE Overview of Historical Reporting Module
4 4
The Historical Reporting module provides reports and trend charts derived from the summary performance data which is automatically calculated by the OMCPMS every day, week and month. This module is intended for use by operations staff who have a responsibility for the ongoing quality of service provided by the network and by planners and network engineers who need to see trends in trafc and performance. The reporting module can be used essentially in two distinct ways:
s s
To show trends in performance on a single element or service To produce summary reports of network performance
Graphical displays provide a range of trend charts showing long term variations in key performance indicators of different network elements. These displays can be used as the basis for starting investigations into quality of service issues such as vendor related performance and congestion issues due to trafc growth. Textual reports provide summaries of the performance of the network and can be based on daily, weekly or monthly aggregates such as busy hour and busy day busy hour. These reports can form the basis of regular reporting regime and be input into a management reporting process.
Functions of Historical Reporting Module
The Historical Reporting module produces the following types of output from the daily, weekly and monthly summary performance data selected from a given period of time:
s s
Pre-dened reports Pre-dened trend charts
The way to generate a pre-dened report or trend chart using the Historical Reporting module is similar as for the Daily Operations module. The user can generate a report or plot a chart using menus and a report parameter dialog.
Version 03 e
issue b
4-33
6W003
Pre-dened Reports
The following pre-dened reports are available:
s
Cell TCH performance This report includes: the average number of TCH that were in service, trafc carried in Erlangs, percentage dropped calls, and grade of service (i.e the probability of a TCH assignment being blocked). Cell SDCCH performance This report includes: the average number of SDCCH that were in service, trafc carried on SDCCH in Erlangs, number of seizure attempts, and percentage blocking. Cell handover performance This report shows the cell-handover performance, the cell-handover causes, and the performance of cell-to-neighbor cell handover. Performance of BSS This report includes: trafc carried in Erlangs, percentage blocking, and percentage dropped calls. Performance of Routes This report includes: dened and available channels, that is, the average number of in-service TCH totalled for all cells in the BSS, trafc carried in Erlangs, total number of calls, and percentage blocking (call congestion). Linkset Availability This report includes: percentage availability of the linkset, and duration of unavailability. Linkset Utilization This report includes: busy hour in the selected period, number of MSUs sent and received, and occupancy of the entire linkset in Erlangs. MSC Trafc This report includes: total switched trafc calls, total failures for switched calls, and total answered switched calls. MSC Handover Performance The report shows: intra-MSC handover attempts and failures, and incoming and outgoing inter-MSC handover attempts and failures.
Pre-dened Trend Charts

The pre-dened trend charts are similar to the pre-dened graphs generated by the Daily Operations module. The following pre-dened trend charts are available:
s s s s s
Cell trafc and performance trends Cell utilization trends Cell blocking trends Dropped calls trends SDCCH trafc and performance trends
4-34
Version 03 e
issue b
6W003
s s s s s s s s s s s s s s s s s s s s s s
SDCCH cell blocking trends SDCCH dropped calls trends Cell handover performance trends Handover Cause Trends Handover Cause Percentages BSS cell trafc trends Trends in the Load on a Processor Trends in Traffic on a Route Trends in Utilization of a Route Trends in the Congestion of a Route Trends in the Availability of an CCS No. 7 Link Trends in the Utilization of an CCS No. 7 Link Trends in the Availability of an CCS No. 7 Linkset Trends in the Availability of an CCS No. 7 Linkset (TX) Trends in the Availability of an CCS No. 7 Linkset (RX) Trends in MSC Traffic Trends in MSC Performance Trends in MSC Handover Performance Trends in HLR Subscribers Total system trafc trends Trends in BSC Data Coverage Trends in MSC Data Coverage
Using the Historical Reporting Module

s s
On the next pages the following examples are presented: The pre-dened report: summary cell TCH Performance The pre-dened trend chart: Cell Trafc and Performance Trend chart
Version 03 e
issue b
4-35
6W003
SUMMARY CELL TCH TRAFFIC REPORT DAY OF 97/02/04 FOR ALL CELLS IN AREA Columbus (BUSY HOUR VALUES)
Min. Traffic (E) Max. Traffic (E) Min. % Blocking Min. % Dropped Calls Min. % Utilisation Min. % Data Coverage Min. Grade of Service Max. Mean Holding Time Cell Id. Busy Hour
: : : : : : : : Channels Def. Avail . 11 15 15 11 15 15 11.0 15.0 15.0 11.0 15.0 15.0 Attempts Blocking (%) Dropped (%) Traffic (E) Util. (%) GOS MHT (s) Erlang B (DGOS=0.01)
-------------------------------------------------------------------------------------------------------------------------------------------------------CI-0005423261 CI-0005423262 CI-0005423263 CI-0005423651 CI-0005423661 CI-0005423961 15:15 12:45 18:15 15:15 09:30 23:00 480 256 338 412 188 27 0.00 0.00 0.00 0.00 0.00 0.00 0.21 0.39 0.89 1.21 1.06 0.00 4.15 3.46 3.72 2.64 1.76 1.27 80.68 42.74 45.91 51.22 21.74 15.66 0.0025 0.0000 0.0000 0.0001 0.0000 0.0000 31.1 48.7 39.6 23.1 33.8 71.5
Figure 4-11. SUMMARY CELL TCH PERFORMANCE REPORT
4-36
Version 03 e
issue b
6W003
Cell TCH Traffic (Weekly BDBH) Cell WOMCSRV-BSS:1-BTS:12 from 93/02/22 to 93/06/28
Traffic (E)
12.6 12.4 12.2 12.0 11.8 (E) 11.6 11.4 11.2 11.0 10.8 10.6 10.4 01 Feb 93 01 Mar 93 01 Apr 93 01 May 93 Mean 0.0000 01 Jun 93 01 Jul 93 Mean 11.5258
% Blocking
1.0 0.8 0.6 0.4 0.2 0.0 01 Feb 93 01 Mar 93 01 Apr 93
(%)
01 May 93
01 Jun 93
01 Jul 93
% Dropped Calls
10.0 8.0 6.0 (%) 4.0 2.0 0.0 01 Feb 93 01 Mar 93 01 Apr 93
Mean
6.1800
01 May 93
01 Jun 93
01 Jul 93
Figure 4-12. CELL TRAFFIC AND PERFORMANCE TREND CHART
Version 03 e
issue b
4-37
6W003
FORECASTING MODULE: Generate reports on cells that are nearing capacity and on trafc history Analyze graphically a trafc forecast for a single cell Produces output from weekly summary data: Pre-dened prediction reports, e.g: Cell exhaustion Route exhaustion Pre-dened graphical forecasts, e.g: Predicted future cell loading Predicted future route loading
4-38
Version 03 e
issue b
6W003
FORECASTING MODULE Overview of Forecasting Module
4 4
The Forecasting module provides reports and graphs which forecast the exhaustion of network elements and consistent under-utilization based on summary weekly trafc data that is automatically collected by the OMC-PMS. This module is intended for use by operations staff who are responsible for monitoring the efcient use of capacity and by network planners who both need information on the actual trafc carried on the network and actual measured trafc growths. This module does not provide any support for using demographic or marketing data. It is intended solely to help locate areas where short term capacity problems may develop so as to pro-actively avoid congestion problems in the near future. The reporting module can be used essentially in two distinct ways:
s s
To generate reports on cells that are nearing capacity and on trafc history To analyze graphically a trafc forecast for a single cell
Graphical displays allow the forecast for a single network element to be displayed and allow the operator to manually adjust the forecast based on his knowledge of network events in the period or to accommodate peaks in trafc. Textual reports provide lists of elements that will exhaust or remain under-utilized within a specied time period (typically 90 days). These reports can form the basis of a more careful analysis of problems on these elements, unexpected trafc conditions or to conrm plans already in place to extend the network. Exhaustion forecasts and related trafc history reports are vital input both into network planning and trafc management processes.
Functions of Forecasting Module
The Forecasting module produces the following types of output from the weekly summary performance data selected from a given period of time:
s s
Pre-dened prediction reports Pre-dened graphical forecasts
The way to generate a pre-dened report or graphical forecast using the Forecasting module is similar as for the Daily Operations module. The user can generate a report or plot a graphical forecast using menus and a report parameter dialog.
Version 03 e
issue b
4-39
6W003
Pre-dened Prediction Reports

The prediction reports allow the user to predict all cells or routes that will reach exhaustion or remain under-utilized within the specied prediction period, based on extrapolation from the summary data. An under-utilized cell/route is dened as one has a low utilization at both the start and the nish of the prediction period. A prediction is based on:
s
Dimensioning parameter, which can be selected from:

Busy day busy hour trafc (BDBH) Three-day average trafc (3-DAV) Five-day average trafc (5-DAV)
Regression type, which can be selected from:

Linear regression Logarithmic regression Exponential regression
The following pre-dened prediction reports are available:

s s s s s s s s s s
Cell Traffic for a Set of Cells Traffic for a Single Cell Cell exhaustion Cell under-utilization Cell Channel Requirements Route Traffic Traffic for a Single Route Route Exhaustion Route Under-Utilization Route Circuit Requirements
Pre-dened Graphical Forecasts

The pre-dened graphical forecasts display past and future trends for the cellular network, such as cell loading, and estimate when the capacity of a cell or route will be exceeded. The Forecasting module provides graphs showing the chosen dimensioning parameter and then the curve t extrapolated out the specied number of days. The graph is extensively annotated with the results of the regression. Four types of graphs are provided:
s s s
Cell trafc trends based on historical data Predicted future cell loading Route trafc trends based on historical data
4-40
Version 03 e
issue b
6W003
Predicted future route loading
The main purpose of the trend graphs is to display the data for the historical period on which the user chose to base predictions. The Predicted Future Cell/Route Loading graphs allows the user to predict trafc trends for a cell or route, based on extrapolation from the summary data selected. The plots show a forecast of the parameter chosen, extrapolated over the forecasting period. The graph also shows the predicted exhaustion level of the selected cell or route, as the point at which the regression line bisects the critical trafc level for the cell or route (the grade of service). Prediction is based on the following parameters to be specied:
s s s s
Forecast period Regression type Date range of data on which the prediction is based Dimensioning parameter
After the forecast is displayed on the graph the user can manipulate the forecast in a number of ways. The user can interactively:
s
Remove any outliers from the forecast Outliers are points that do not fall in the broad trend of the data and may be caused by untypical events in the network or in the environment that the user does not wish to include in the forecast. Adjust any outliers from the forecast Shift the regression up or down The line or curve that has been drawn through the points is based on a least squares measure of best t. This means that many points may be actually greater than the tted curve. The user may want to shift the line upwards so that the forecast effectively accommodates more of the actual data.
s s
After adjusting a parameter the graph is re-calculated.
Exporting Trafc Data

The Forecasting module also provides the facility to export weekly trafc data in a variety of le formats for use by other planning, trafc management or general statistics packages.
Using the Forecasting Module

s s
On the next pages the following examples are presented: The pre-dened prediction report: Cell Exhaustion The pre-dened graphical forecast: Predicted Future Cell Loading graph
Version 03 e
issue b
4-41
6W003
90-DAY CELL TCH EXHAUSTION REPORT FORECAST FROM 96/10/07 TO 97/02/03 FOR ALL CELLS IN AREA Columbus
Dimensioning Parameter Regression Type Min.Correlation Min. % Data Coverage
: Offered 3-DAV Traffic : Linear : : Dimen Para (E) 4.53 Capacity (E) 8.11 Sorted by Exhaustion Date ------------------ Forecast -----------------Sample Size 4 0.826 Corr. Growth E/week 0.38 Exhaust On 97/03/28 Erlang B (DGOS=0.01)
--------------------- Latest BDBH ------------------Cell Id. CI-542 Carried (E) 4.96 Blocking (%) 0.00 Util. (%) 61.2 0.0001 GOS Lost (E) 0.00
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Figure 4-13. CELL EXHAUSTION REPORT
4-42
Version 03 e
issue b
6W003
90-Day Cell TCH Traffic Forecast For Cell WOMCSRV-BSS:1-BTS:12 from 93/02/23 to 93/07/1
Linear regression on Offered 3-DAV Traffic Correlation Coefficient 0.938 CELL WILL REACH CAPACITY IN THE WEEK OF 93/09/06 Linear (y=A+B*x) 14.00 3-DAV Traffic Capacity
11.20
8.40 (E) 5.60
2.80
0.00 01 Feb 93 01 Mar 93 01 Apr 93 01 May 93 01 Jun 93 01 Jul 93 01 Aug 93 01 Sep 93 01 Oct 93
Figure 4-14. PREDICTED FUTURE CELL LOADING GRAPH
Version 03 e
issue b
4-43
6W003
KINGFISHER: Used by the system administrator and the OMCPMS users System administrator: To monitor the system dened data bases To modify the system dened data bases OMC-PMS user: For data analysis purposes: To dene queries to retrieve data from the (performance) data base To dene graphical reports of parameters selected from the (performance) data base
4-44
Version 03 e
issue b
6W003
KINGFISHER Overview
4 4
The Kingsher is an optional OMC-PMS module used to build and maintain OMCPMS data bases. It is also used for data analysis purposes. The Kingsher is intended for use by both the system administrator and the OMC-PMS users. It can be used by the system administrator in the following ways:
s
To monitor the system dened data bases, including the performance data base and the administration data base (for example, to control the access rights of data base users). To modify the system dened data bases, for example, used to update the access rights of data base users.
The OMC-PMS user uses the Kingsher for data analysis purposes. The Kingsher can be used in the following ways to analyze the data:
s s
To dene queries to retrieve data from the performance data base To dene graphical reports of parameters selected from the performance data base
Functions of Kingsher
The Kingsher can perform the following functions using the powerful graphical user-interface:
s s s
Data base querying Graphical report generating Data base maintaining
Data base querying can be performed by using the graphical user-interface or by running a user-created TQL query. TQL (Technical Query Language) is a simplied version of SQL (Structured Query Language). The output of the query is presented in a tabular format. It can also be presented in a graphical format. The graph can be either a line chart (two-dimensional plot) or a surface plot (threedimensional plot). The format of the graph can also be changed. Other formats are for example a scatter graph or a graph according to a linear t.
Version 03 e
issue b
4-45
6W003
ADMINISTRATION MODULE: Conguring, controlling and monitoring the OMC-PMS components User administration Other functions, e.g. data base backup
4-46
Version 03 e
issue b
6W003
ADMINISTRATION MODULE Overview of Administration Module
4 4
The Administration module is the graphical interface used by the OMC-PMS administrator for the following purposes:
s
Conguring and controlling the OMC-PMS components, such as the Loader, the Scheduler and the Archiver. Examples of tasks to perform are: Loader Scheduler Start/schedule or stop Loader Start or stop Scheduler Schedule daily/weekly/monthly summary scripts Schedule Archiver Schedule batch scripts Archiver Start or stop Archiver manually Maintain Archiver denitions (what and when to archive and/or delete)
Monitoring the OMC-PMS components. The TQL Server run processes that monitor the status of the system. Status information can be shown using the Administration module. Administrating of users of the OMC-PMS. Users can be allowed or disallowed to use the system Other functions, such as making of data base backup, and performing recovery procedures in case of system problems.
Version 03 e
issue b
4-47
6W003
4-48
Version 03 e
issue b
USING NPM GUIDE
5
5-1 5-1 5-1 5-1 5-3 5-11 5-13 5-15
Contents
INTRODUCTION TO USING THE NETWORK PERFORMANCE MONITORING GUIDE
s s s
LESSON INTRODUCTION LESSON OBJECTIVES DOCUMENTATION
MEASUREMENTS AND REPORTS FROM BSS AND MSC ANALYSIS CONTENTS OF THE NPM GUIDE CASEWORK
Version 01 e
issue a
5-i
Contents
5-ii
Version 01 e
issue a
USING NPM GUIDE
INTRODUCTION TO USING THE NETWORK PERFORMANCE MONITORING GUIDE

LESSON INTRODUCTION
5
5
This lesson explains how the OMC-2000 PMS (Performance Management System) system can provide data to identify trouble areas in the GSM network and how it is used for monitoring and evaluating improvement.
s s
GSM Functional Overview Measurements and reports form BSS (Base Station System) and MSC2000 (Mobile Switching Center) Analysis
LESSON OBJECTIVES

s s s s s
Identify trouble areas from OMC PMS reports. Introduce BSS reports and their value for optimization. Interpret BSS reports and draw conclusions Introduce MSC reports and their value for optimization Interpret MSC reports and draw conclusions
DOCUMENTATION
Lucent Technologies GSM System Network Performance Monitoring Guide
Version 01 e
issue a
5-1
USING NPM GUIDE
9W531
OMC-PMS MODULES:
s
DAILY OPERATIONS HISTORICAL REPORTING FORECASTING
BSS REPORTS:
s
BASIC MISCELLANEOUS TRAFFIC FLOW OPC (Originating Point Codes) LINK BSC (Base Station Controller)
5-2
Version 01 e
issue a
USING NPM GUIDE
9W531
MEASUREMENTS AND REPORTS FROM BSS AND MSC
The reports that we use for the BSS-side of the network will be created by the OMC-PMS (Metrica). Although BSS and MSC allow a direct retrieval of data/ reports, the OMC-PMS is normally used for creation and analysis reports. OMCPMS consists of the following modules:
s s
Daily Operations: Needed for Network operations Historical Reporting: Needed for Network operations and Engineering functions Forecasting: Needed for Trafc management
The reports from the BSS can be divided into six parts:
s
Basic Measurements in this group are BTS-based, and are required by the PMS. In previous releases of the OMC-2000, these measurements were referred to as Automatic measurements. For example: Average number of simultaneous calls Trafc Channel congestion time Number of Radio Frequency losses Number of incoming intercell handovers Average trafc channel holding time on the Abis interface
Miscellaneous These measurements, which are not included in any of the remaining groups, are also BTS -based. However, they are independent measurements, and the system treats each as its own single-member group. In previous releases of the OMC-2000, these measurements were referred to as Manual measurements. For example: Number of attempted SDCCH seizures in a period Number of lost calls because of no access grant channel (AGCH) Mean number of idle trafc channels per interference band Average PCH-AGCH queue length Unsuccessful BSS-controlled outgoing handovers with successful return to old channel
Version 01 e
issue a
5-3
USING NPM GUIDE
9W531
BSS REPORTS:
s
BASIC MISCELLANEOUS TRAFFIC FLOW OPC (Originating Point Codes) LINK BSC (Base Station Controller)
5-4
Version 01 e
issue a
USING NPM GUIDE
9W531
Trafc Flow Measurements in this group are also BTS-based. They differ from other BTS measurements though, because they track the signal activity of neighbour cells. This group is also unique because the network object must contain exactly one BTS object. For example: Number of attempted incoming SDCCH handovers Number of successful incoming full-rate handovers Location Area Code (LAC) Cell Identier (CI)
OPC Measurements in this group are concerned with Originating Point Codes in the SS7 (Signaling System number 7) network. For example: Number of messages received by SCCP in the BSC with an invalid subsystem number The number of UDT (UnIt Data) messages sent to the BSC.
LINK Measurements in this group are concerned with the performance of the SS7 links connecting the BSC to the MSC. For example: The number of signaling units (SUs) with errors received by the Signaling Link Controller (SLC) The number of retransmitted octets
BSC Measurements in this group are concerned with the Base Station Controller. For example: The percentage of the maximum possible load on the BSCs central processor
Version 01 e
issue a
5-5
USING NPM GUIDE
9W531
MSC REPORTS:
WIRELESS SPECIFIC REPORTS: WRLSSUM (WIRELESS SUMMARY REPORT) WRHAND (WIRELESS HANDOVER REPORT) HLRVLR (HLR AND VLR REPORT) WSS (WIRELESS SUPPLEMENTARY SERVICES REPORT)
GENERAL TRAFFIC MEASUREMENT REPORTS: TGCOMP (TRUNK GROUP COMPONENT REPORT) SMCOMP (SWITCHING MODULE COMPONENT REPORT) CICSUM (CALL INCOMPLETION CODE SUMMARY REPORT) SLCOMP (SIGNALLING LINK COMPONENT REPORT) SLSCOMP (SIGNALLING LINK SET COMPONENT REPORT) TRAFFLOW (TRAFFIC FLOW REPORT)
5-6
Version 01 e
issue a
USING NPM GUIDE
9W531
The reports from the MSC can be divided into Wireless specic reports and General trafc measurement reports:
s
Wireless Specic reports: WRLSSUM (Wireless Summary Report) Identies the total wireless call and handover activity as seen by the 5ESS-2000. WRHAND (Wireless Handover Report) Identies the number of MSC controlled handovers on a per BSC basis. HLRVLR (HLR and VLR Report) Is concerned with activity at the HLR (Home Location Register), VLR (Visitor Location Register), AUC (AUthentication Center) and EIR (Equipment Identity Register) when they are resident on the 5ESS-2000. The VLR is the only one who is always resident on the 5ESS-2000. WSS (Wireless Supplementary Services Report) Provides measurements for the wireless supplementary services to characterize the usage of the service.
General Trafc Measurement Reports: TGCOMP (Trunk group Component Report) It identies the usage of the trunks connected to the 5ESS-2000, including the BSSAP trunks. SMCOMP (Switching Module Component Report) Identies trafc, primarily trunk trafc, on an SM basis, plus number of handovers coming into an SM. CICSUM (Call Incompletion Code Summary Report) Includes a number of GSM specic codes which are identied in Appendix A of the Network Performance Monitoring Guide. SLCOMP (Signalling Link Component Report) Contains information about SS7 links between the 5ESS-2000 and the BSSs as well as the PSTN. SLSCOMP (Signalling Link Set Component Report) Contains information about the SS7 link sets between the 5ESS2000 and the BSSs as well as the PSTN. TRAFFLOW (Trafc Flow Report) Information about call ows through the 5ESS-2000 for both answered attempts and ineffective attempts for the following 4 subparts of this report that are concerned with GSM/OMC-PMS are covered: Originating-Terminating, Originating-Outgoing, IncomingTerminating and Incoming-Outgoing.
Version 01 e
issue a
5-7
USING NPM GUIDE
9W531
MSC REPORTS:
WIRELESS SPECIFIC REPORTS: WRLSSUM (WIRELESS SUMMARY REPORT) WRHAND (WIRELESS HANDOVER REPORT) HLRVLR (HLR AND VLR REPORT) WSS (WIRELESS SUPPLEMENTARY SERVICES REPORT)
GENERAL TRAFFIC MEASUREMENT REPORTS: TGCOMP (TRUNK GROUP COMPONENT REPORT) SMCOMP (SWITCHING MODULE COMPONENT REPORT) CICSUM (CALL INCOMPLETION CODE SUMMARY REPORT) SLCOMP (SIGNALLING LINK COMPONENT REPORT) SLSCOMP (SIGNALLING LINK SET COMPONENT REPORT) TRAFFLOW (TRAFFIC FLOW REPORT)
5-8
Version 01 e
issue a
USING NPM GUIDE
9W531
For a more detailed overview of the above mentioned reports, go to Section 4 (5ESS-2000 Reports), Section 5 (OMC-PMS Reports and Graphs) and Appendix A (5ESS-2000 and BSS Measurements) of the Lucent Technologies Network Performance Monitoring Guide.
Version 01 e
issue a
5-9
USING NPM GUIDE
9W531
ANALYSIS SCENARIOS
s
Capacity Issues Higher carried trafc on TCH than expected Zero (0) trafc carried on TCH and SDCCH during normally busy hours Lower carried trafc on TCH than expected Not enough capacity to meet short-term TCH demand for grade of service Forecasting future TCH demand Higher carried trafc on the SDCCH than expected Lower carried trafc on SDCCH than expected Not enough capacity to meet short-term SDCCH demand for grade of service Not enough capacity to meet short-term CCCH demand
Availability Issues Monitoring TCH availability Monitoring SDCCH availability
Quality of Service Issues No service shown on handset main indicators Ability to setup and receive calls Ability to maintain calls Ability to perform BSS controlled intercell handovers
5-10
Version 01 e
issue a
USING NPM GUIDE
9W531
ANALYSIS
s
5
Capacity Issues Higher carried trafc on TCH than expected Zero (0) trafc carried on TCH and SDCCH during normally busy hours Lower carried trafc on TCH than expected Not enough capacity to meet short-term TCH demand for grade of service Forecasting future TCH demand Higher carried trafc on the SDCCH than expected Lower carried trafc on SDCCH than expected Not enough capacity to meet short-term SDCCH demand for grade of service Not enough capacity to meet short-term CCCH demand
The scenarios that follow are presented within the following sections:
Availability Issues Monitoring TCH availability Monitoring SDCCH availability
Quality of Service Issues No service shown on handset main indicators Ability to setup and receive calls Ability to maintain calls Ability to perform BSS controlled intercell handovers
For the procedures for all above mentioned analysis, use part 6 Performance Analysis of the Network Performance Monitoring Guide.
Version 01 e
issue a
5-11
USING NPM GUIDE
9W531
CONTENTS OF THE NPR GUIDE
4.
INTRODUCTION GSM FUNCTIONAL OVERVIEW INTRODUCTION TO PERFORMANCE ANALYSIS 5ESS-2000 AND OMC-2000 REPORTS OMC-PMS REPORTS AND GRAPHS PERFORMANCE ANALYSIS GLOSSARY ABBREVIATIONS 5ESS-2000 AND BSS MEASUREMENTS SIGNALING FLOW DIAGRAMS
5.
6.
7.
8.
9.
10.
11.
a.
b.
5-12
Version 01 e
issue a
USING NPM GUIDE
9W531
CONTENTS OF THE NPM GUIDE
The NMP guide is divided into eight chapters and two appendixes. The rst chapter describes the manual. The second chapter gives you a general (high level) overview of the GSM system, including the Lucent products (BCE-2000, BTS-2000, STF-2000and the OMC2000). The third chapter introduces you to Performance Analysis, it explains some standard terms (Quality of Service, Capacity and Availability), introduces input sources for Performance Analysis (Drive tests, RF Planning tools) and gives you some considerations and limitations of Data Analysis. The fourth chapter deals mainly with explaining the 5ESS-2000 reports and is introducing the OMC-200 reports. The fth chapter introduces the OMC-PMS reports and graphs, one by one will all reports and graphs be explained for their purposes and what the parameters on the report or graph mean. The sixth chapter gives you some guidelines for Performance Analysis, by giving you some scenarios, we explain the problem and what report(s)/graph(s) you can use to make a decision how to solve the problem. The seventh chapter is a glossary and the last chapter (eight) is a abbreviations list.
The rst appendix explains in detail (on a peg counter) basis what each counter means on the 5ESS-2000 and BSS Reports and what there relation is with other counters. The second appendix is given you in a graphical way some signaling ow diagrams, this for both the MSC and the BSS.
Version 01 e
issue a
5-13
USING NPM GUIDE
9W531
5-14
Version 01 e
issue a
USING NPM GUIDE
9W531
CASEWORK
Will be handed out by the instructor.
Version 01 e
issue a
5-15
USING NPM GUIDE
9W531
5-16
Version 01 e
issue a
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
DRIVE TESTING AND ANALYSIS
______________________________________________________________________________________________________
LESSON OVERVIEW
_ ______________________________________________________________
There are many factors affecting GSM system performance. Improving the system performance is done by optimizing RF design and operational parameters, such as the current build out plan, BSS parameters, antenna configurations, power budgets, and handover parameters. The network can provide information about congestion, dropped calls etc. by itself via the OMC-PMS. However, additional information is often required to find out where and how a performance problem occurs. Customer trouble tickets will give possibly a high-level problem description Drive testing is required to find out e.g. where and why the calls were dropped. Dedicated measuring equipment (such as a protocol analyzer or a spectrum analyzer) gives more details for pin-pointing problems.
This lesson describes the performance data gathering other than via the OMCPMS, which is mainly the drive testing. In addition to the collection of data, this lesson presents a number of very common optimization problems including suggestions for improvement.
Version 01 e issue c
February 17, 1998
6-1
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
6-2
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
LESSON OBJECTIVES
_ ______________________________________________________________
Upon completion of this lesson, you should be able to: 1. Describe the function of the customer trouble ticket 2. Describe the various ways to assess a cell 3. Explain the utility of a protocol analyzer 4. Describe the aspects of drive testing for performance monitoring. 5. Identify drive test equipment. 6. Describe different ways to assess a cell 7. Give suggestions for trouble shooting in common performance problems.
February 17, 1998
6-3
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
______________________________________________________________________________________________________
TROUBLE TICKET
Problem Area
1 - Problem Unable to call out Unable to receive Unable to hear Unable to be heard Unable to call specific Glass breaking sound Noisy connection
Customer
Crosstalk Call dropped Echo Busy tone Announcement Other
2 - Originator No. 4 - Originator name 6 - Calling from City
3 - No. being called Local Nat. Int.
Tel. No.
5 - Originator contact No.
Area
Street
7 - Was mobile originator? Stationary Driving In building Speed

Customer care area
8 - Time of trouble 9 - Type and Model of phone 12 - Time 14 - Contact No.
10 - Ticket No. 13 - Operator name 15 - Problem description

Cell site numbers
11 - Date
16 - Clearance details Date

Trouble found Action taken
Time
______________________________________________________________________________________________________
Figure 6-1. EXAMPLE OF A TROUBLE TICKET
6-4
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
TROUBLE TICKET _ ______________________________________________________________

The trouble ticket is a document by which various problems reported by customers are passed along through the organization. An example of a trouble ticket is shown on the opposite page. The trouble ticket process maximizes problem solving expertise at each stage of the escalation process. Staff must rely upon experience and knowledge to determine which option to take. However, specific guidelines are given so that staff know how to decide when and who to report a particular problem. According to the problem area, location and origin of the call, different scenarios can be followed to solve the problem. For example drive testing, parameters changes, etc. It is also important to verify if the problem is not related to the mobile itself. Many problems result from wrong handling of the mobile set. Check for example: If the set is turned on, Battery is charged, Is subscriber within coverage area, Is SIM card properly inserted, Is PIN (Personal Identification Number) code properly entered and/or Is PUK (PIN UnlocK) needed to unlock PIN?
February 17, 1998
6-5
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
______________________________________________________________________________________________________
base station subsystem

mast and antennas Air interface
switching subsystem
BTS BSC
TRX
MSC
POI
Mobile Switching Centre
MS
Mobile Station Base Transceiver Station
Base Station Controller

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Um interface
A bis interface
OMC-PMS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...............................
Point of Interconnect
A interface
Operations & Maintenance Centre Performance Management System
______________________________________________________________________________________________________
Figure 6-2. ASSESSING THE CELL
6-6
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
ASSESSING THE CELL _ ______________________________________________________________

The Interfaces of Interest
In order to assess the functioning of a particular cell, there are a number of interfaces that can provide information: OMC-PMS
U m (Air Interface)
A Interface (E 1 link, 2 Mb/s)
A bis Interface (E 1 link, 2 Mb/s)

The assessment of a cell by the OMC-PMS is discussed in lesson 9W531. The other interfaces will be examined more closely in this lesson.
February 17, 1998
6-7
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
Air interface information:
RxLEV RxQual BCCH, BSIC of the serving cell BCCH, BSIC and RxLev of the 6 best neighbours Timing advance GSM best server
6-8
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
The U m Interface
It is required to have access to a radio based test system to allow measurements to be conducted on the U m interface. The test system should be able to discriminate between cells to enable information for the cell under test to be gathered. An example is the drive test vehicle. Measurements on the U m interface will provide information about: RxLEV RxQUAL BCCH, BSIC of the serving cell BCCH, BSIC and RxLEV of the 6 best neighbours Timing advance GSM best server (sometimes this is not defined in the neighbour list and is the cause of problems)
The A Interface
This is a good interface to examine. However, the A interface tends to include the information for many cells within the system. It will be useful to have access to a test system that can simultaneously monitor several SS7 links to gather the information for a single cell. This may require "triggers and filters" for the Layer 2/3/4 protocols.
The A bis Interface

This interface tends to contain the information for one cell only. It can, therefore, be the most practical place to assess/monitor a particular cell. Looking at the A bis Interface, what is there to consider and examine? The A bis is manufacturer specific May need to monitor up to a maximum of 10 signaling channels for each A bis 2Mb/s link Able to assess both UL (up-link) and DL (down-link) channel Radio levels may be monitored.
February 17, 1998
6-9
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
A bis Analysis
Monitoring the A bis link over a period of time allows a number of quantities to be assessed, such as: The busy hour (BH) - the busiest four consecutive periods of 15 mins. over a 24-hour period Traffic Growth - the variation of traffic in the cell over time, plot of busy hours Interference effects - plot of call "set-up" requests and "RX Qual" Unforeseen events - plot of Timing Advance (TA) and "RX Qual"
It may be useful to gather information from monitoring several A bis interfaces. For example, the following parameters are interesting: RX levels Timing Advance RX Quality (Bit Error Rate) Selected A bis RSL protocols (Layer 3)
6-10
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
MOBILE RADIO ANALYZER
_ ______________________________________________________________
The Mobile Radio Analyzer is a GSM protocol analyzer with built-in standard PCM test capabilities. It handles all interfaces in the mobile radio fixed network and the SS7 gateways to the PSTN, including all features needed to analyze SS7 protocols and applications (e.g. ISUP). For optimization purposes, an important parameter to measure is the Radio Resource Indication (GSM 08.58). The purpose of the resource indication procedure is : To inform the MSC of the amount of radio resource that is spare at the BSS and available for traffic carrying purposes The total amount of the accessible radio resource (i.e. available for service or currently assigned). This cannot easily be derived from the traffic that the MSC is carrying. The MSC may take these pieces of information into account for the external handover decision. Using a GSM protocol analyzer makes it possible to monitor for example the number of idle traffic channels in the different interference bands.
February 17, 1998
6-11
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
DRIVE TESTING:
Propagation measurements
Mobile network performance monitoring
6-12
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
DRIVE TESTING _ ______________________________________________________________

In general, drive testing serves two goals: 1. Propagation measurements the first goal is determining the propagation model parameter values prior to a new cellular design activity. These measurements and the averaging thereof have been discussed in course WL9012, GSM RF Cellular Engineering. 2. Quality assessment the second goal of drive testing is a continuous process of testing the existing mobile network from mobile positions anywhere in the network. These drive tests are done for quality assessment and optimization by: Basic testing of BSS installation and performance after switch-on. Statistical measurements for regular monitoring of the mobile network performance in rural areas and along main roads, to determine if quality targets are met. Detection, location, and detailed diagnosis of troublesome areas. Verifying the results after optimization attempts. This section gives background information for the second type of drive testing and discusses the follow topics: Reasons for drive testing. When and where to drive test. Coverage problems troubleshooting. Downlink interference determination. Equipment examples. Drive test data presentation.
February 17, 1998
6-13
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
REASONS FOR NETWORK PERFORMANCE MONITORING DRIVE TESTING:
Quality assessment
Optimization
6-14
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
REASONS FOR NETWORK PERFORMANCE MONITORING DRIVE TESTING
_ ______________________________________________________________
After the mobile network has come to life, drive testing is required for various purposes related to network monitoring. A number of examples is given below.
Quality Assessment
Besides the information gained from customer reports and OMC-PMS statistics, drive testing is very helpful for quality assessment by: Basic testing of a single BSS Functional checking of the BSS in the network environment Statistical measurements: Test mobile measurements: generation of large volumes of stored data including GPS locations, gathered by a special test vehicle with skilled personnel. The drive tester has to make sure that enough samples of data are collected to make a good averaged reading. Intensive field trials (IFT): come closer to actual subscriber behaviour by using off-the-shelf mobile phone equipment, but these trials generate less accurate data.
Optimization
Optimization is now being recognized as a major factor in reducing customer churn, i.e. stopping customers from switching from one operator to another. This is done by spotting flaws in the network performance before the customer does.
February 17, 1998
6-15
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
DRIVE TESTS FOR OPTIMIZATION
Initial network coverage verification and benchmarking. Verification before and after changes Locating and measuring interference Locating areas where traffic problems exist Locate coverage holes Logging excessive handovers due to poor network design Preventive maintenance Simultaneous measurements of other networks.
6-16
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
For optimization purposes, drive testing is done for: Initial network coverage verification and benchmarking. This will be a basis for network optimization. Benchmarking is basically the initial set of standards that the network is expected to perform to, such as interference levels in particular areas, the percentage of dropped or blocked calls etc. Verification before and after changes are made to the network: Before a new TRX is to be powered on, data is collected and plots are drawn for the cells that could be affected. After powering on the new TRX, the changes to the network have to be observed. Whenever a new site is put in service, for an update of network coverage. Verification of coverage problem areas. Whenever power adjustments have been made by hardware or software. Whenever new buildings are built that may cause interference or shadowing in cells. Before and after antenna changes, e.g. downtilting an antenna or changing the antenna type. Note: the mobile network must be as optimized as possible before expansion as the expansion will only amplify the problems. E.g. if it is acceptable to live with a little bit of interference in one area, it will become intolerable after expansion. Locating and measuring interference, which leads normally to excessive handovers. Interference may be co-channel or adjacent channel interference caused by other sites in the own network or from competitive operators in-country or in neighbouring countries. Interference may originate from other sources outside the GSM mobile network but which are working in the GSM frequency bands, e.g. an illegal transmitter.
February 17, 1998
6-17
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
DRIVE TEST DATA COLLECTION:
Cell ID RxLEV RxQUAL BCCH, BSIC Timing advance TX power Layer 3 messages GPS position data Time stamps
6-18
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
Locating areas where traffic problems exist. Calls being blocked: where the mobile is unable to set up a call in a certain area. Dropped calls where a call is set up and then dropped. Maintaining a call is impossible. Locate low power areas (coverage holes). Logging excessive handovers due to poor network design (many good servers). Preventive maintenance: regular testing of the network will show areas that slowly degrade over time and this can be monitored against the initial set of standards. Driving around (at certain times of the day) in areas that have been known to give trouble in the past. A regular street-level coverage to update the status of the network for any hardware degradation (e.g. antenna movement, environmental changes). Recommended monitoring intervals are monthly or every two months at the longest. If the intervals are too long, the operator may become reactive to the customer complaints rather that proactive. Simultaneous multiple network/multiple technology measurements for competitive analysis. Monitoring the performance of other local networks, e.g. ETACS or the GSM network of a competitor along the same drive route. The coverage quality of competing operators abroad can be evaluated as well where drive test vehicles can easily roam into neighbouring countries.
Drive Test Data Collection

During a drive test, the following data are collected for examination: Cell ID including BSIC, LAC, and time slot RxLEV for the serving and the neighbour cells RXQUAL for the serving cell BCCH, BSIC for the serving and the neighbour cells Timing advance TX power Layer 3 messages GPS position data Time stamp.
February 17, 1998
6-19
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
______________________________________________________________________________________________________
HOOD CORNER magn -2.4 dB ON GLASS -0.5 dB
ROOF CORNER magn -0.2 dB
ROOF MOUNT perm 0.0 dB (reference) magn -0.2 dB
ON GLASS -0.5 dB -1.2 dB -2.6 dB TRUNK CORNER lip mount -3.3 dB
TRUNK perm -2.1 dB magn -2.8 dB
______________________________________________________________________________________________________
Figure 6-3. ANTENNA PLACEMENT ON A CAR
6-20
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
DRIVE TEST EQUIPMENT
_ ______________________________________________________________
For optimization, sufficient mobile test vehicles must be provided. During startup, one vehicle is required for each 50 new sites. Also, special hand portable mobile sets can be used for monitoring during a walk test if access by a vehicle is difficult or impossible.
The Mobile Test Vehicle

A diesel powered vehicle is preferred over a petrol powered vehicle. The reason is that fewer diesel vehicles have engine management systems (EMS) as opposed to petrol vehicles. EMS can interfere with the measurements taken. In addition, diesel vehicles tend to have bigger alternators capable of powering the equipment. When a vehicle is driving at night in the rain, it can have a tremendous drain on power resources.
Antennas
The mobile test vehicle, is often used to monitor the network as it is perceived by a walking subscriber. Hence, the test mobile must emulate a pedestrian carrying a hand-held phone. This means that the antenna mounted on the roof of a huge four-wheel drive is not a representative situation: The roof antenna height is more than the normal mobile antenna height of 1.5 or 2 meters. The gigantic ground plane of the car roof causes a more favourable antenna pattern than the hand-held mobile would have.
These effects can be compensated by using 0 dBi antennas in combination with e.g. 6 dB attenuators, and/or using a lower car type. Antennas on cars can be mounted in the following ways: Roof mounted Glass mounted Trunk mounted
The figure on the opposite page shows the options for mobile antenna placement on a car. The best position is where it will have the maximum possible omnidirectional coverage at the highest unobstructed point of the vehicle. This is usually on the roof, which is taken as a reference (0.0 dB level). The values shown in dB show the amount of loss for a specific location of a single antenna, which should be at least 1 m away from any other antennas.
February 17, 1998
6-21
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
DATA PRESENTATION BY DRIVE TEST EQUIPMENT:
RxLEV for On-line call with cell indentification Adjacent channel energy Best server with cell indentification TX power Timing advance (TADV) Time slot (TSLOT) MAHO list data with NCC/BCC Noise and SINAD measurements Hand-over quality display and list GSM RF spectrum RxLEV scan
6-22
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
Drive Test Equipment

In general, the drive test equipment will be made up of a combination of the following components: Scanning receiver for logging RF information of the entire GSM spectrum. The speed of the scanner is essential. For instance, the average driving speed is 35 mph = 56 km/hr = 15.6 m/s. A scanner scanning at 25 channels/second will take 5 seconds to scan the entire GSM band leaves a distance of 78 m between two consecutive measurements. Therefore, it is vital to have a dedicated number of tests. One or multiple transceiver systems for different networks and technologies with SIM card access for flexible operation. Automatic call generators (automated dialling), making e.g. 2-minute calls. GPS navigation system (optionally backed up by a dead-reckoning system, if GPS lock cannot be maintained). Audio quality measurement system for UL and DL (noise, SINAD) for an objective assessment of audio quality from end-to-end of the network. Display for e.g. dashboard mounting. Colour notebook for data storage, analysis and real-time replay. Two roof antennas. Power conditioning and distribution equipment.
Calibration
It is very important to calibrate the equipment on a regular basis, due to drift over time. The big temperature excursions that may occur inside the car are often compensated by air-conditioning or heating.
Installation
The equipment should be firmly fixed to the vehicle. It must be ensured that transportables are not positioned anywhere that would interfere with the functioning of the vehicle, such as right on above the anti-blocking system (ABS) braking system.
February 17, 1998
6-23
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
______________________________________________________________________________________________________
GPS antenna GPS receiver GSM antenna 1 wide band scanning receiver GSM antenna 2
transceiver
RS232
............ ............ ............ ............
notebook PC
map-info compatible output
mobile phone handset loud speaker

...... ...... ...... ...... ......
visual display
.. .... ...... .... ..
microphone
______________________________________________________________________________________________________
Figure 6-4. BLOCK DIAGRAM OF EQUIPMENT IN TEST DRIVE VEHICLE
6-24
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
A typical example of drive test equipment aboard the mobile test vehicle is shown on the opposite page. The system equipment set-up comprises the following: Mobile phone with SIM card GSM transceiver Wide band scanning receiver 3 Antennas (two GSM, one GPS) Visual display unit GPS (Global Positioning System) navigation equipment Microphone Loudspeaker box Laptop computer (Notebook PC).
Antenna 1 is used by the mobile phone. Antenna 2 is used by the wide band scanning receiver for scanning GSM frequency channels 1 - 124, checking the signal strength.
GPS
GPS operates on the principle of time differences in the arrival of radio signals coming from different satellites. The GPS uses a sensor (antenna) and a group of satellites to calculate position coordinates by measuring the distance between the sensor and each satellite. The travel time a radio signal takes to reach the sensor from a satellite determines the distance between them. The GPS receiver selects and analyzes radio signal from three satellites overhead. A fourth satellite signal reference is also required to cancel out timing errors. More satellites will increase the accuracy of the position readout. A differential GPS can be used for higher accuracy.
February 17, 1998
6-25
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
6-26
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
ROUTE PLANNING
_ ______________________________________________________________
The area to be drive-tested is ascertained before leaving the office. A route is prepared as follows: Photocopy a map Colour-in the route Plan a drive test in both directions to check where handovers occur or where calls are dropped. The handovers should be noted in both directions at approximately the same speed, e.g. first driving north and then driving south. For new sites being switched on, it is recommended to stretch the cell as far as possible in all directions before it hands over. This is done to check the signal strength and therefore to determine the coverage area. The areas that should be covered by drive testing are as follows. 1. Primary route (street level) includes all major roads, highways, and wide thoroughfares. This should be prioritised whenever conducting a coverage test, unless a new site is put into service for a specific objective. 2. Secondary route (street level) includes all streets, subdivisions and compounds, when accessible. 3. Miscellaneous routes (in-building and special locations) includes golf courses, beach resorts, shopping malls, department stores, convention centres, hotel lobbies, etc.
Special Events
Note that special locations should have been covered before any scheduled special events or activities take place to ensure good coverage. For example, a big sports event where extra coverage is required over a relatively short period of time. An example is the one-day 200 km long "Elfstedentocht" ice-skating tour in Holland, where many skating people carry mobile phones to report their progress to their families. To provide the required extra coverage for the thousands of mobile subscribers on the ice, special mobile BTSs were erected alongside the ice track.
Night/Day
Sometimes it is better to drive a route at night, when coverage is of the main importance. This avoids the vehicular traffic congestion during the day.
February 17, 1998
6-27
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
______________________________________________________________________________________________________
network manager
network planner
network engineer
radio analyst
switch analyst
technician
technician
technician
______________________________________________________________________________________________________
Figure 6-5. TYPICAL STAFF STRUCTURE
6-28
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
DRIVING AND DATA COLLECTION Personnel
_ ______________________________________________________________
Drive testing requires skilled staff. There are typically a number of RF optimization teams, each team consisting of one driver, one technician and a radio analyst. A typical staff structure for mature network operators is shown on the opposite page.
Drive Test Technician

The drive tester technician job is to monitor the performance of the mobile network. He usually obtains instructions from the radio analyst. The drive test technician collects the data and does some crude analysis in the field, to make sure that he has covered all the areas he needs for that day. Tasks that make up the drive test technician job are: Planning of drive routes Drive testing in designated areas Collecting data Analyzing data
Radio Analyst
The radio analyst will remain at the office to perform other daily tasks. The driver and the technician will go out with the drive test vehicle. After the drive test, the technician supplies the data to the radio analyst, who will go through the data and produce a report on the radio problems for a particular problem. The radio analyst will present the report to the network engineer who also has a report coming in from the switch analyst for the same problem. Based on the two reports, the network engineer will make a decision on how to remedy the problem whilst working in conjunction with the network planner. The network engineer is primarily responsible for making decisions on parameter changes. Once the alterations have been made, the traffic and radio statistics before and after the change are compared. This is reported back to the network manager.
February 17, 1998
6-29
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
Note: this structure is very dependent on the operator and the network. In smaller or younger networks, the network planner may be the same person as the switch and radio analyst. In large networks, there is a large number of network planners, analysts, and technicians due to the greater complexity of the network.
Safety
There should always be a team of two people in the drive test vehicle. One person is the driver, who is responsible for driving the designated route as specified by the RF engineer. The other person is the technician, who takes care of the measurements, making the notes, watching the display and the computer. He is also responsible for plotting the collected data.
Recorded Announcement
In order to make calls from a drive test vehicle, a subscriber number is needed featuring a recorded announcement. This number can be dialled all the time for setting up and maintaining a call during the drive test.
Drive Testing Procedure

Steps for drive testing are: The technician talks to the radio analyst to verify if the work orders are implemented correctly. If the work orders are not done correctly, the field engineer will discuss with the radio analyst to select different testing routes. The equipment should be powered on for at least 30 minutes before any testing is started, in order to compensate for temperature drifts. Check all test equipment prior to leaving the office to make sure that everything is functioning properly. Wait until the GPS unit tracks the satellites and displays the positioning information on the computer. Once the position information is available, the team should drive to the designated test area and prepare to test. Know what sector you are in by monitoring the BCCH and also note the BTS where you are handed over to. After driving in one direction, start a new file for the opposite direction otherwise the data for both directions could be merged together. Files should be stored every hour irrespective of size, in case the vehicle stalls or the equipment fails. Put in markers for dropped calls and excessive handovers.
6-30
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
The collected data should be saved in different files to make sure that the file is not too large. Sometimes a file will be closed automatically when it reaches the maximum size allowed and a new file will be opened. Make a stop and check the time slots on each cell, making sure that all of the TRX are functioning correctly. All abnormalities whilst drive testing are directly reported to the OMC in order to check: whether the OMC operators know what is occurring if any maintenance on a site is being carried out. For example, low power can be observed while technicians are working on a site during the "down-time" period as agreed with the mobile operator (customer). In some cases, the OMC will be asked to lock or unlock RTs. Perform preliminary analysis out on the field. The data should be checked out to see if there is any obvious coverage hole, or route that needs to be driven. A redrive should be performed where data could be queried.
Data Collection
While conducting a test drive through an expected coverage region, the RxLEV and RxQUAL data should be collected, saved, and be tagged with: Time stamp GPS position stamp Current BSIC RF channel number in use.
A selectable alarm threshold to RxLEV allows the saving or printing on any occurrence of low or high signal strength.
February 17, 1998
6-31
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
6-32
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
Data Analysis
1. After the drive test has been completed, the team will return to the office to plot the files and print out the portions of data that support the findings. 2. After determining solutions, the proposals will be discussed with the team radio analyst. 3. The radio analyst creates work orders. If the work orders may affect the adjacent clusters, the responsible radio analyst must discuss the recommended changes with the radio analyst in charge of the adjacent cluster. 4. All plots, supporting data and work orders are brought to the oversight meeting with the optimization coordinator. 5. The work orders are submitted to the optimization coordinator once they are approved. 6. The work order implementation will be verified: If the work orders were correct, the technician must go to verify the changes. If the changes do not fix or reduce the problems, alternative solutions need to be found. Once all possibilities of a solution have been explored and the problem still exists, then the radio analysts must submit work orders to change everything back to the original settings. 7. All unsolved problems will be kept in a different log. 8. Once the specific routes have been verified, the radio analysts must transfer data, plots etc. to the network database.
February 17, 1998
6-33
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
PROBLEMS:
Cell dragging Dropped calls Ping-ponging System busy Handover boundary
6-34
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
PROBLEMS AND REMEDIES _ ______________________________________________________________

This chapter presents a number of performance problems that are often encountered during optimization, together with some suggestions for troubleshooting.
Cell Dragging
Calls may drag a cell beyond the desired handover boundary. The results often are dropped calls or a bad audio quality. The following suggestions may solve the drag problem: Create an appropriate neighbour cell list Change handover parameters such as thresholds, hysteresis, etc. Check the serving cells cell identifier in the neighbour cells neighbour list. Check the neighbour carrier number Check the possibility of multiple BSC assignments Change antenna configuration If parameter changes still do not solve the problem, then check for the possibility of a hardware failure.
Dropped Calls
Dropped calls can be caused by either RF environments or incorrect system parameters. Below are some suggestions for determining the causes: Inappropriate neighbour cell list. For example, after a sequence of undesired handovers, the calls may end up being served by a distant site and unable to get back to the correct server. Inappropriate handover parameters Existing or new coverage holes Serving cells might go down Severe interference Abnormalities (unsuccesful call set-up, drop without obvious causes, etc.)
February 17, 1998
6-35
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
Ping-ponging
Ping-ponging means that the servers keep changing. As a result, the audio quality is degraded due to handover muting. Some possible causes are given below: Inappropriate neighbour cell list Inappropriate handover parameter settings Interference Lack of dominant server Poor coverage Not optimal antenna configuration.
Legit System Busy

Reception of "system busy" on several call attempts and the site appears consistently on the traffic report. Suggested solutions are: Short term: reduce the traffic on the congested cell/site. However, the proposed changes must not create any unacceptable problems such as coverage holes, dropped calls, ..etc. Some short term solutions are: Re-design the antenna configuration Re-evaluate the BTS parameters Long term: build a new cell site to off-load traffic.
6-36
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
Handover boundary
When handovers do not occur at the desired handover boundary, the result is an imbalance in traffic distribution across the system. Possible causes are: Inappropriate neighbour cell list. A call cannot be handed over to an adjacent cell which is not on the list. A call is directly handed over to a distant site, not by a sequence of handovers, and is dropped short thereafter. This is due to a wrong neighbour cell identifier. Inappropriate handover parameter settings Inappropriate antenna configurations of the serving and neighbour cells Interference No TCH available in the neighbour cell (congestion).
For measuring the handover performance, details are required on hysteresis, frequency of occurrence of handovers, or choices of handover sites. A saved record of a handover should contain: The current BSIC and channel number, with RxLEV and RxQUAL value The six neighbour BSICs and channels The new BSIC and channel The timing advance for the serving cell, permitting analysis of the timing advance as a handover parameter.
These data can be used for determining the the efficiency of the handover algorithm. The cumulative number of handovers and the current call duration will also be stored for analysis of the handover frequency.
February 17, 1998
6-37
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
6-38
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
INTERFERENCE TROUBLE SHOOTING Uplink Interference
_ ______________________________________________________________
The following example is taken from an UL interference problem that occurred in reality. All the steps in the troubleshooting process will be described in detail.
Observation of the Problem

When experiencing a significant amount of UL interference, a number of effects may be observed: Reduced traffic capacity Handover failures Many intra-cell handovers soon after traffic channel assignment Short call holding times Dropped calls Poor voice quality on the UL (890 - 915 MHz), while the voice quality on the DL (935 - 960 MHz) can be acceptable if the DL frequency is not interfered.
Investigations
In order to pinpoint the source of the interference problem, a number of investigations need t be done in the affected cell or group of cells. In case of suspected co-channel or adjacent channel interference, the prediction by the radio network planning tool is very valuable. 1. A bis signaling can be monitored using Protocol Analyzing equipment such as the Wandel & Golterman MA-10 and Hewlett Packard HP 37900. Decoding is necessary of the Resource Indication measurement, which is sent from the BTS up to the BCF on an RT and time slot basis. The Resource Indication messages contain UL interference measurements performed on idle TCHs in accordance to GSM Rec. 08.58. Interference bands are classified from Band 1 (lowest) to band 5 (highest). Normally, Band 1 interference should be reported if no UL interference is detected by the BTS. 2. A correlation can be found between specific RTs reporting Band 2 and higher interference, and the incidence of sleeping RTs whereby the specific affected RTs can be seen to handle much less traffic than RTs with only Band 1 threshold or less interference. The affected RTs only seem to handle calls when most of the time slots on the other RTs of the cell are busy. They also seem to handoff faster from the time slots of RTs with UL interference to other RTs. This may affect the traffic capacity during the busy hour to some extent as these sleeping RTs will only handle calls as a last option and then for a short period compared to other RTs.
February 17, 1998
6-39
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
3. This behaviour can possibly be accounted for by the call processing algorithms in the BCF where the BCF assigns calls mainly on RTs with Band 1 interference in preference to RTs with Band 2 or higher interference. Also, when a call is in progress on a timeslot of an RT with UL interference, the UL receive quality (RxQUAL) as measured by the BTS for that call could be too poor so the BTS may initiate a handover, which would be an intra-cell handover in most cases. 4. Additional effects of UL interference are hypothesised as follows and deserve further investigation: High RACH (random access channel) access. It can be observed from OMC-PMS reports, that cells with Band 2 or higher interference on RT0 are reporting very high RACH access. The RACH is used in the UL direction by MS when first requesting service (e.g. a subscriber presses the SEND button after keying in a dial number). The BTS has to process first the access signal (an UL interference signal or a genuine mobile access) to determine if the access is a genuine mobile access. It is hypothesised that this is why some cells (with high UL interference present near the RT0 tuned frequency) are reporting RACH access attempts of several million or more "accesses" per day. This level of real mobile accesses on any cell is not considered to be realistic. It is assumed that due to this high RACH load, some genuine mobile call access attempts may fail if the RACH channel is overloaded due to UL interference on RT0 of a cell. SDCCH (stand alone dedicated signaling control channel) failure. Another effect may be the potential for SDCCH signaling failure where there is UL interference on any of the RT0 and RT1 tuned frequencies of a cell as these RTs (time slot 0 in each case) have SDCCH logical channels configured. This SDDCH failure affects the signaling for mobile calls (incoming and outgoing) and handover attempts. This may also be a factor in the experience that some call set-ups a reported which apparently do not progress and fail without indication to the MS. 5. A drive test visit to the affected cell will be necessary to trace the source of interference. In some cases there are external (non-GSM) interference sources in parts of the UL band which account for the specific interference reports from the BTS/RT. A suggested test set-up for tracing the source of UL interference at the site consists of a spectrum analyzer in the UL band(e.g. HP-8594E), connected either: Directly to the RX antenna feeder of a sector cell, via a 50 coaxial cable
6-40
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
A spare RXMC port of a BTS. 6. All RTs at the site are locked from the OMC. With all RTs locked, and thus not transmitting, a test can be conducted to check if the source of interference is still present after all RTs were locked. An approved maintenance window for downtime needs to be requested and granted to permit tests for isolating the interference source, which can be internal or external to the site. It is also possible, after consultation of the frequency planning group, to swap the RTs temporarily to other frequencies outside the interfered band. This method will not disrupt service. 7. The source of interference needs to be eliminated, after pinpointing the location of the interference source. The following method can be used: Perform drive test measurements in the vicinity of the affected site with the spectrum analyzer on board, connected to a yagi antenna. The cross point of the different bearings taken from various test positions will provide a small search area where the source of interference should be located. A visual survey may unveil the transmitting antenna if it is mounted outdoor. 8. The sources of interference must be identified and quickly removed by taking countermeasures. The internal (GSM) interference can be removed by: Changing the frequency plan by the frequency planning group Change the output power of the interfering BTS Depending on the geographical spread of the interference, antenna changes (antenna type, tilt and/or azimuth) can be effective too. DTX and FH may help, if available. The external sources of interference should be removed by calling in the help of local radio spectrum management authorities. Depending on the geographical spread of the interference and the affected bandwidth, it can also be practical to change the RT frequencies. 9. After taking a countermeasure at a site (or group of sites), the number of Band 2 up to Band 5 interference level reports should decrease. This may lead to an improvement of the network performance by: An increase of network traffic capacity by reducing the number of sleeping RTs
February 17, 1998
6-41
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
A reduction of handovers (and potential handover failure) An improvement in UL voice quality. The traffic measurement reports from the OMC-PMS can be compared to record and verify the improvement in performance. Due to the reduced UL interference, improvements should be observed in call blocking, average holding time, handover failures, and call drops.
Downlink Internal Interference

While the co-channel interference cannot be measured directly, it can be inferred if the RxQUAL is high while the RxLEV is also high. How to determine a DL interference source: 1. During the drive test, technicians take notes of location, frequency, severity (garbled audio, dropped calls) of the interfered cell. 2. The interference data is plotted and printed and submitted to frequency planning group. 3. The frequency planning group submits work orders to retune the interfered cell to a test frequency. 4. Upon completion of the work orders, the radio analyst and the technician must check the OMC-PMS reports for potential errors. 5. The interfered cell is revisited and checked for co-channel interference levels. 6. The collected data is analyzed to determine which co-channel site is causing interference. 7. The data and the comments are submitted to the frequency planner. 8. Until a permanent frequency retune is done, technicians continue to optimize different ares.
6-42
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
LUCENT TECHNOLOGIES QUALITY INDEX

TOTAL ACCES CALLS ATTEMPTED TOTAL TIME ONLINE ACCES QUALITY MEASUREMENT MEAN ACCESS TIME NORMALLY TERMINATED REORDER FAST BUSY NO SERVICE ONLINE QUALITY MEASUREMENT DROPPED CALLS NOISE MEASURED BY MOBILE VERY GOOD ( < GOOD (-50.00 to FAIR (-40.00 to POOR (-30.00 to VERY POOR (-20.00 to NOISE MEASURED BY ANSWER VERY GOOD ( < GOOD (-50.00 to FAIR (-40.00 to POOR (-30.00 to VERY POOR (-20.00 to SYSTEM -50.00 -40.00 -30.00 -20.00 -10.00 SYSTEM -50.00 -40.00 -30.00 -20.00 -10.00
pre-optimization 124 154.14 min.
post-optimization 96 169.84 min.
15.23 84 0 34 0
sec. (67.74%) ( 0.00%) (27.42%) ( 0.00%)
14.71 82 0 11 0
sec. (85.42%) ( 0.00%) (11.46%) ( 0.00%)
6 (2.37/hr.)
3 (1.05/hr.)
dBm) dBm) dBm) dBm) dBm)
96.84% 0.73% 0.81% 1.28% 0.34%
97.58% 0.83% 0.78% 0.62% 0.19%
dBm) dBm) dBm) dBm) dBm)
98.97% 0.43% 0.09% 0.43% 0.09%
99.29% 0.16% 0.09% 0.39% 0.07%
SINAD MEASURED BY MOBILE SYSTEM VERY GOOD ( > 25.00 dB) GOOD (20.00 to 25.00 dB) FAIR (15.00 to 20.00 dB) POOR (10.00 to 15.00 dB) VERY POOR ( < 10.00 dB) SINAD MEASURED BY ANSWER SYSTEM VERY GOOD ( > 25.00 dB) GOOD (20.00 to 25.00 dB) FAIR (15.00 to 20.00 dB) POOR (10.00 to 15.00 dB) VERY POOR ( < 10.00 dB) WEIGHTED QUALITY SCORE Figure 6-6. QUALITY INDEX REPORT
23.91% 46.55% 23.70% 2.88% 2.95%
18.41% 50.13% 27.07% 2.33% 2.07%
68.75% 21.71% 1.64% 1.32% 6.58% 67.70
71.01% 23.36% 1.68% 0.50% 3.45% 79.36
February 17, 1998
6-43
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
6-44
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
REPORTS AND PRESENTATION
_ ______________________________________________________________
This paragraph will show a number of report and plot examples that result from drive testing.
Quality Index
The quality index used in evaluating a mobile network is based upon a number of observations and measurements, which are performed through drive tests. During a drive test, a number of calls will be attempted to reach an answer system. The report on the opposite page shows an example of the quality index report resulting from a drive test before and after the optimization campaign in an urban area. Appendix A provides a number of examples for drive test plots. The SINAD measurement is explained in the next paragraph.
Changes
The quality improvement of mobile the network has been achieved by a combination of various optimization changes: Changing jumper between BTS and antenna to feeder due to RF loss Redoing coaxial connectors with a too high VSWR reading (voltage standing wave ratio). The VSWR must be 1, while values of 1.3 or 1.4 are considered to be too high. Replacing antennas with a too high VSWR reading Changing antenna downtilt angles (e.g. 5 o to 8 o ) and/or replace mechanical downtilt by electrical downtilt Rotate antennas in azimuth (e.g. 20 o ) Changing to a lower value of RxQUAL.Ho (e.g. from 4 to 3) or RxQUAL.Ho.Avg (e.g. from 8 to 5) Enabling of BSC handovers Enabling of intracell handovers at all sites Changing HO margin (e.g. from 30 to 28 or 32 or 34) Changing strength UL/DL balance from e.g. 36 to 45 Changing BTS pwr reduction from 3 to 2 Changing quality averaging period from 8 to 5 Verification and changing of neighbour lists for mutual neighbours Verification and matching of reselect lists and neighbour lists for the whole region.
February 17, 1998
6-45
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
______________________________________________________________________________________________________
768 ts
TONE GENERATOR 1000 Hz
signal + noise + distortion
SINAD SYSTEM UNDER TEST

NOTCH FILTER
S
POWER METER
1000 Hz
noise + distortion
______________________________________________________________________________________________________
Figure 6-7. SINAD MEASUREMENT
6-46
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
The SINAD Measurement

The SINAD (Signal to Noise and Distortion Ratio) measurement can be used to assess the noise in a channel and also the distortion of e.g. a 1 KHz sine wave. It is an objective test of the baseband voice quality. To evaluate the audio on UL and DL, an answering system is required to do the SINAD measurement. Note: an "uplink" measurement is not a true UL measurement unless the drive test vehicle is placed at the BTS, as the signals will flow through switches and the PSTN before (generally) reaching the dedicated logging computer at the other end. It deserves a careful examination if not e.g. the switch is the problem instead of the U m interface. The SINAD can be expressed as:
total output power signal + noise + distortion _________________ _________________________ SINAD = _ = _ non signal power noise + distortion
The SINAD value can be measured by comparing: The 1 KHz tone signal including noise and distortion The noise and distortion only. This measurement is shown in the picture on the opposite page. The 1 KHz tone is filtered out by a notch filter, the noise and distortion remaining. The SINAD measurement can also be used to distinguish noise and distortion: 1. For a high signal level and an insignificant distortion, this expression reduces to
signal + noise signal SINAD = ______________ ______ noise noise

which is the Signal to Noise ratio. 2. For a high signal level and a low noise situation, this expression reduces to
signal + distortion _________ signal ________________ SINAD = _ distortion distortion

which is the Distortion.
February 17, 1998
6-47
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
The following ratings can be used for the on-line quality measurement with SINAD: _ ____________________ SINAD MEASURED _ ____________________ good 20 to 25 dB fair 15 to 20 dB poor 10 to 15 dB _ ____________________
Exercises SINAD
a. What SINAD value (in dB) is equivalent to an input signal level of -112 dBm in GSM equipment? Assume that the signal is distortion-free, the J thermal noise power is N = k T B Watt, with k = 1. 38 . 10 23 __ and K the temperature is + 17 0 C. b. What would be the SINAD value if the input signal level were -98 dBm? c. How would you rate these SINAD values?
Measuring RFPC
By measuring the RxQUAL and the TxPWR, a study of the relationship between these two parameters provides an indirect method of evaluating RFPC. An effective RFPC algorithm will maintain good speech quality by varying TxPWR. Although RxQUAL at the drive test vehicle is not necessarily equal to the RxQUAL measured at the BSS, the radio path will affect it in a similar way.
6-48
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
APPENDIX A: DRIVE TEST PLOT EXAMPLES _ ______________________________________________________________

This appendix provides a number of drive test plots that were obtained before and after the optimization campaign in an urban area. The following plots are included: BCCH RX Level Plot Call Results RxQUAL TCH RX Level Handovers <insert here FrameMaker file with plots from Marc Nulens>
February 17, 1998
6-49
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
6-50
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W533
EXERCISE ANSWERS _ ______________________________________________________________

Exercises SINAD
a. Noise power = K T B = 1. 38 . 10 23 ( 17 + 273 ) 2 . 10 5 = 120 dBm. SINAD = -112 -(-120) = 8 dB b. SINAD = -98 -(-120) = 22 dB c. 8 dB is rated as very poor, 22 dB is good.
February 17, 1998
6-51
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
6
6-1 6-3 6-5 6-7 6-7 6-9 6-9 6-9 6-10 6-11 6-13 6-15 6-15 6-15 6-19 6-21 6-21 6-21 6-23 6-23 6-23 6-25 6-27 6-27 6-27 6-29
______________________________________________________________________________________________________
Contents
LESSON OVERVIEW LESSON OBJECTIVES
TROUBLE TICKET ASSESSING THE CELL

The Interfaces of Interest The U m Interface The A Interface The A bis Interface A bis Analysis MOBILE RADIO ANALYZER
DRIVE TESTING
REASONS FOR NETWORK PERFORMANCE MONITORING DRIVE TESTING Quality Assessment Optimization Drive Test Data Collection DRIVE TEST EQUIPMENT The Mobile Test Vehicle Antennas Drive Test Equipment Calibration Installation GPS ROUTE PLANNING Special Events Night/Day DRIVING AND DATA COLLECTION
February 17, 1998
6-i
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
Contents
Personnel Drive Test Technician Radio Analyst Safety Recorded Announcement Drive Testing Procedure Data Collection Data Analysis 6-29 6-29 6-29 6-30 6-30 6-30 6-31 6-33 6-35 6-35 6-35 6-36 6-36 6-37 6-39 6-39 6-39 6-39 6-42 6-45 6-45 6-45 6-47 6-48 6-48 6-49 6-51 6-51
PROBLEMS AND REMEDIES

Cell Dragging Dropped Calls Ping-ponging Legit System Busy Handover boundary INTERFERENCE TROUBLE SHOOTING Uplink Interference Observation of the Problem Investigations Downlink Internal Interference REPORTS AND PRESENTATION Quality Index Changes The SINAD Measurement Exercises SINAD Measuring RFPC
APPENDIX A: DRIVE TEST PLOT EXAMPLES EXERCISE ANSWERS

Exercises SINAD
6-ii
February 17, 1998
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
OPTIMIZATION CASEWORK
______________________________________________________________________________________________________
LESSON OVERVIEW
_ ______________________________________________________________
This lesson provides casework related to optimization problems. The cases require simple calculations only.
Section 1 provides the work assignments.

The answers are given in Section 2. The appendixes contain useful data such as path loss tables for 900 and 1800 MHz and tilted antenna patterns.
LESSON OBJECTIVES
_ ______________________________________________________________
This lesson has been designed to teach you to: 1. Solve simple optimization problems on paper.
Version 01 e issue b
November 5, 1997
7-1
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
7-2
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
CASES _ ______________________________________________________________
CASE 1
_ ______________________________________________________________
A cell with two TRXs and 15 TCHs available shows a traffic demand of 7 Erlang in the busy hour. The total number of call attempts is 1600 per hour. However, 1000 attempts per hour are blocked (unsuccessful). Investigation learned that there are no faulty components, there is no maintenance activity, all cell parameters seem to be O.K. while also the Daily Cell SDCCH report shows no anomalies.
a. What could be the reason for this congestion? Use chapter 6 of the Network Performance Monitoring Guide to find scenario(s) to solve this problem. b. What reports could help you with solving this problem and why? c. What could be a solution to reduce the number of unsuccessful call attempts?
November 5, 1997
7-3
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
__________________________________________________________________________________________
Cell Utilization (Daily BH) Cell BN045A from 10/03/96 to 18/03/96

32 28 24 20 16 12 8 4 0 . . . . . . . . Offered Carried Critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .... . . . .. . . . . . . . . ..... . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . .... .. .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traffic (E) .
(E)
19.4E
10 Mar
11 Mar
12 Mar
13 Mar
14 Mar
15 Mar
16 Mar
17 Mar
18 Mar
250.0 200.0 150.0 100.0 50.0 0.0
% Utilisation .
. . . . . . . . . . . . . . . .
(%)
. . . . . . . . . . . . . . . . . 12 Mar
. . . . . . . . . . . . . . . . . 13 Mar
. . . . . . . . . . . . . . . . . 14 Mar
. . . . . . . . . . . . . . . . 15 Mar
. . . . . . . . . . . . . . . . . 16 Mar
. . . . . . . . . . . . . . . . . 17 Mar 18 Mar
10 Mar
11 Mar
0.25 0.20 0.15 0.10 0.05 0.00
Grade. of Service .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 13 Mar
. . . . . . . . . . . . . . . . . 14 Mar
. . . . . . . . . . . . . . . . . 15 Mar
. . . . . . . . . . . . . . . . . 16 Mar
. . . . . . . . . . . . . . . . . 17 Mar 18 Mar
10 Mar
11 Mar
12 Mar
__________________________________________________________________________________________
Figure 7-1. TCH UTILIZATION REPORT
7-4
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
CASE 2
_ ______________________________________________________________
Sector cell BN045A is part of a 3-3-3 sector cloverleaf system in a GSM 900 network. It suffers from overload in the busy hour on most of the days. The OMC-PMS report example on the opposite page illustrates that the GOS reaches values up to 9.4 %. The cell BN045A is also picking up some UL interference which should preferably be reduced too in the optimization process. The cell is covering a low density urban area, the base station antenna height is 30 m. The site distances are 4.15 km. There is no traffic growth expected for the future. All the DP6013 15.2 dBi sector antennas in the network have been given a standard 8 o electrical downtilt during the installation phase. The tilted antenna diagrams for the DP6013 antenna are given in Appendix B. In order to optimize the performance of cell BN045A, here are a number of questions to be answered. a. How would you solve this congestion and interference problem with a minimum of cost or effort?
November 5, 1997
7-5
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
__________________________________________________________________________________________
BN046A
3 BN046C 3 3
lake
BN046B
. . . . . . . . . . . . . . . . . .... .. .. .. .. .. .. .. .. .
BN045A
3
highway
BN045C
3 3 BN045B
__________________________________________________________________________________________
Figure 7-2. CELL BN045A AREA
7-6
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
Increasing the traffic capacity by adding a TRX is considered to be an expensive option because there is no growth forecasted. A reduction of the traffic load for cell BN045A could be achieved by decreasing the cell size. This promises to be a good remedy because the neighbouring cells BN046B and BN046C seem to have enough spare capacity available to pick up some more traffic. Because of the UL interference problem, it has been suggested by the RF network engineer to try first a further electrical downtilt of the antenna to achieve the desired traffic load reduction. Another option, lowering the BTS antenna height, is more expensive while the mast construction does not easily allow height alterations of the antennas. b. Determine to what amount the traffic load must be reduced. c. What is the excess amount of subscribers served by cell BN045A if the average subscriber traffic is 45 mE. Traffic distribution is uniform across the cell. d. Propose a new electrical downtilt angle for the antenna of cell BN045A in such a way that the GOS in the cell remains within limits. For simplicity, the cell can be assumed to be hexagonal. e. Does the new situation also imply a change in transmit power? f. What other desired effects can be the result of the changes made to the downtilt angle? g. What would the antenna height be to achieve the same load reduction while at the standard downtilt angle of 8 o ? h. Do you know other options to avoid the overload in cell BN045A if the interference problem did not exist?
November 5, 1997
7-7
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
__________________________________________________________________________________________
N
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bis . . . . . . . . . . . . . . . . . . . . . . . . . .. . . .
51
A bis
88

.. ... .. ... . . . A bis ... .. ... ... ... .
82
BSC
...
.. .
.. ...
...
...
.. ...
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
150
A bis
63
__________________________________________________________________________________________
Figure 7-3. SITE 88 AREA MAP
7-8
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
CASE 3
_ ______________________________________________________________
In a GSM network in an suburban area, reports have been received from subscribers complaining about poor voice quality in the coverage area of site 88. A map of the area around cell 88 is shown on the opposite page. OMC-PMS reports indicate an unrealistic high number of call attempts per hour while the number of handovers and dropped calls is higher than normal.
a. What could be a possible cause for the reported poor voice quality? b. What action is to be taken for further investigation? The following GSM Interference bands are being reported by BTS 0, 1, and 2 at site 88 towards the BCE: _ ___________________________________________ site sector RT channel interference _ ___________________________________________ _ ___________________________________________ 88 2 124 Band 3 88 0 118 Band 4 88 2 122 Band 4 88 _ ___________________________________________ 0 112 Band 3
All other RTs at site 8 report Band 1 interference only. The following GSM interference bands are being reported by BTSs at sites close to site 88 (see map on the opposite page): _ ___________________________________________ site sector RT channel interference _ ___________________________________________ _ ___________________________________________ 150 1 120 Band 3 82 1 116 Band 3 63 0 117 Band 3 63 0 123 Band 2 _ ___________________________________________
All other RTs at these sites report Band 1 interference only. c. What would be a plausible conclusion from these data? d. What test will be the next step to do?
November 5, 1997
7-9
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
_ ______________________________________________________________________________________________
13:34:45 JUL 18, 1997 MKR 913.110 MHz REF .0 dBM AT 10 dB -78.21 dBm . . . . . . . . . . . . . . . . . . . . . . . . . . . PEAK . . . . . . . . . . . . . . . . . . LOG . . . . . . . . . . . .... . . . . . . . . . . ..... . . . . . . . . . . .... . . . . . . . . . . .... . . . . . . . . . . .... . . . . . . . . . . .... . . . . . . . . . . ..... . . . . . . . . . . .... . . . . . . . . . . .... . . . . . . . . . . . . . . . . . . . . 10 . . . . . . . . . . . . . . . . . . . . . . . . . . dB/ . . . . . . . . . . . ... . . . . . . . . . . .... . . . . . . . . . . ... . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . ... . . . . . . . . . . .... . . . . . . . . . . ... . . . . . . . . . . ... . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . ... . . . . . . . . . . .. . . . . . . . . . . . ............ . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ............ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .. .. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . . ............ . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . ... . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . ... . . . . . . . . . . .. . . . . . . . . . . . ............ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ............ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
START 912.000 MHz RES BW 30 kHz
VBW 30 kHz
STOP 916.000 MHz SWP 20.0 msec
_ ______________________________________________________________________________________________
Figure 7-4. SPECTRUM ANALYZER PLOT
7-10
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
A spectrum analyzer provided results for the UL in the sector, and a typical spectrum plot is shown on the opposite page. The measurements were made repeatedly using the single sweep mode and automatic peak level detection on the spectrum analyzer to allow more accurate measurement of the signals. The observations for the UL in the and sector gave similar results, with minor differences in the peak level. e. What is the nature of the interfering signal displayed on the spectrum analyzer considering its center frequency, bandwidth, and power level with respect to the other signals in the UL band? f. Can this signal be considered to be an internal (GSM) or external signal? g. What will be the effect of this signal to the RTs of site 88? h. What actions do you recommend in order to solve this interference problem?
November 5, 1997
7-11
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
SUMMARY CELL TCH TRAFFIC REPORT DAY OF 97/07/01 FOR ALL CELLS (BUSY HOUR VALUES) Min. Traffic : Min. Traffic (E) : Min. % Blocking : Min. % Dropped Calls : Min. % Utilisation : Min. & Data Coverage : Min. Grade of Service : Min. Mean Holding Time :
Erlang B (GOS=0.01)
Blocking Dropped Traffic Util. GOS MHT Cell Busy Channels (%) (%) (E) (%) (s) Id. Hour Def. Avail. Attempts ------------------------------------------------------------------------------------------------------------------734- 550 08:30 22 22 25.0 2 14.8 100 0.007 90 0.7 1 10.2 87 08:30 22 22 375 85 0.002 458- 0.05 1 8.2 73 0.001 08:30 22 22 100 89 432
Summary Cell TCH Traffic Report (SCCTR)
CELL-CELL DETAILS Sorting & Thresholding on Incoming Handovers Min. Handover Attempts: Min. % Failure : Min. Data Coverage :
----------Incoming-------------- --------------Outgoing-------------Source Target Busy Handover Handover Failure Handover Handover Failure Cell Cell Hour Attempts Failures (%) Attempts Failures (%) Id. Id. ---------------------------------------------------------------------------------------------------------------------0 0 0 0 0 0 08:30 458- 432- 734- 189 0 0 237 0 0 08:30 458- 432- 734- 08:30 5 2.49 203 4 1.97 201
Cell-Cell Handover Report
______________________________________________________________________________________________________
Figure 7-5. OMC-PMS REPORTS
7-12
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
CASE 4
_ ______________________________________________________________
The following problem has occurred in reality. In a GSM network in the Dalton suburban area, mobile subscribers around site 734 were complaining about the availability of the network. They had to retry several times before they were granted access to the network.
a. Can you confirm this problem by looking to the Summary Cell TCH Report as shown on the opposite page? b. What could be a cause for this problem?
November 5, 1997
7-13
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
348
432
main road
problem area
RXLEV < -85 dBm
458
RXLEV = -75 dBm
734
______________________________________________________________________________________________________
Figure 7-6. SITE 458 AREA MAP
7-14
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
Investigation learns that there are sufficient numbers of TCHs and SDCCHs available. Because the problem is hence not caused by a shortage of resources (TCH and SDCCH), drive tests were performed along the road between sites 348 and 734. When driving north from site 458 in the direction of site 348, the real problem occurs between sites 432 and 458. At the edge of sector cell 458- (see the designated area in the map on the opposite page), the drive testers expected to be handed over from 458- to 432. But instead, handovers occurred to 734-, which is in the opposite direction. The OMC-PMS report SUMMARY CELL TCH TRAFFIC (refer to the first page) shows that there is more traffic handled by cell 734- than expected, and also in report CELL-CELL HANDOVER it shows that there is no traffic handed over from cell 458- to cell 432-. c. What could be a possible cause for the reported handover behaviour? Cell 432- is on the neighbour list of cell 458-. A further investigation learned that the RxLEV for site 432- in the problem area is -85 dBm, while for site 734- the RxLEV appears to be -75 dBm. d. What could be a solution for making sure that in the problem area a handover will occur to cell 432- instead of to cell 734-?
November 5, 1997
7-15
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
C645
25m C567 60m
______________________________________________________________________________________________________
Figure 7-7. ROAD MAP FOR HIGHWAY HANDOVER PROBLEM
7-16
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
CASE 5
_ ______________________________________________________________
Since the construction of a new highway, mobile subscribers driving on it started complaining about bad quality during calls on the GSM1800 network. With a drive test we could confirm this complaint and measured that on this highway a lot of handovers occurred over a short distance. When we mapped this drive test information with the layout of the network, we found out that the boundary between the two cells (C567- and C645-) is right along on the highway. This caused the ping-pong handovers. The area is dense urban (clutter factor U2), the antenna height is 15m and the radii of the cells are 0.34 km. a. What is the path-loss for cell C567- at the centerline of the highway? b. What could be a solution for the ping-pong problem? c. What could be the value for the parameter to move the cell border of cell C567- some 85 meter away from the highway median strip (see figure on the opposite page)?
November 5, 1997
7-17
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
CASE 6
_ ______________________________________________________________
Site 77 has a 4-4-4 configuration. A problem occurs in cell area 77-. There are complaints about bad quality during a call. This problem needs further investigation.
a. What could be a possible cause for the reported poor quality? b. What step is to be taken for further investigation? c. What test will be the next step to do? Monitoring the A bis link with a protocol analyzer (MA10 or HP) unveils: There are too many intra-cell handovers Confirm the bad RX quality (4% to 6%). d. What is a plausible conclusion? e. How can this conclusion be confirmed? A sweep test using a spectrum analyzer shows: TX output power is OK (0 dBm) RXMC pilot signal is OK (-27 dBm) No interference seen on the RX or the TX carrier. f. What is the conclusion now? g. What will be the next step for further investigation? A drive test in cell 77- unveils: RX level for all RTs in the cell is OK (-46 to -60 dBm) RX quality for RT2 is 4% while for RT0, RT1, and RT3 it is 0% all the time. h. Which RT is causing trouble? i. Is this an optimization problem?
7-18
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
ANSWERS _ ______________________________________________________________
CASE 1
_ ______________________________________________________________
a. Too many very short calls are offered. b. Daily Cell SDCCH (DCCTR): SDCCH seizure will be high and BLOCKS will be above GOS. Summary Cell SDCCH (SCCTR): High # attempts and high # blocking. Summary Cell TCH (DCTTR): Utilization will be above 100%. c. 2 TRXs with 15 TCHs in total can absorb 9.0 Erlang at 2% blocking (Erlang tables). Hence, 2 TRXs provide enough TCH capacity for the cell, but obviously there is a bottleneck in the SDCCH channels. Available were 4 SDCCH (TRX0, timeslot 0). By sacrificing one TCH in TRX1 for SDCCH usage, the total number of SDCCHs will increase from 4 to 12 while the number of TCHs will decrease from 15 to 14. This reduces the TCH capacity from 9.0 to 8.2 E.
CASE 2
_ ______________________________________________________________
a. The traffic load must be reduced b. The reduction in traffic load is 19. 4 14. 9 = 4. 5 E. 4. 5 c. There are about ______ = 100 subscribers too many in cell BN045A. 0. 045 d. Increasing the downtilt angle to 10 o will reduce the antenna gain. We assume in the calculation that the cell shape remains hexagonal. e. The transmit power levels remain unchanged. f. The UL interference experienced in cell BN045A will hopefully decrease, while the coverage quality in cell BN045A will improve (higher field strength closer to the BTS). The other cells (BN046B and BN046C) are expected to pick up an extra traffic load of 2.25 E each. This can be achieved by uptilting their antennas (if no interference occurs). g. The new antenna height would be 22.6 m. h. Other options for load reduction in cell BN045A are: increasing traffic capacity by addition of an extra TRX, or installing a microcell to offload traffic on a hot spot.
November 5, 1997
7-19
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
7-20
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
CASE 3
_ ______________________________________________________________
a. The possible cause for the reported poor voice quality is interference. b. The next action to be taken is to verify the interference problem and to determine its impact. This can be done by monitoring the Resource Indicator on the A bis links running to site 88, which gives most complaints. A protocol analyzer can be plugged on the DSX monitoring point at the BSC. c. The measurements show that site 88 and cells in the vicinity of site 88 using ARFCNs between 116 and 124 suffer heavily from interference, reporting Band 3 or 4 interference levels. The ARFCN numbers correspond to the frequency band between 890 + 0. 2 116 = 913. 2 MHz and 890 + 0. 2 124 = 914. 8 MHz The radiation direction is probably NW - SE. d. The next step is to find out what the nature of the interference is. All RTs at site 88 will be locked from the OMC. With all RTs locked, and thus not transmitting, a test can be conducted to check if the source of interference is still present after all RTs were locked. An approved maintenance window for downtime needs to be requested and granted to permit tests for isolating the interference source, which can be internal or external to site 88. Go to site 88 and use a spectrum analyzer (connected to the RX antenna feeder or to a RXMC port) to sweep the affected frequency band. e. The spectrum analyzer shows for the UL in the sector a strong and well defined signal centered around 913.6 MHz (channel 118) with a spread of approximately 2.5 MHz. A maximum level of -54 dBm can be observed, which is more than 20 dB greater than the other signals in the GSM UL band. f. This is definitely a non-GSM signal, due to its wide bandwidth and its high power level. The transmitted signal is obviously a video signal. g. This strong interfering signal will cause high interference to be reported by RTs with carrier frequencies within the interference band. The net result is that the affected RTs will handle traffic only when all other time slots are busy with calls on that sector cell. However, the call quality can be expected to be lower for calls on the affected RTs.
November 5, 1997
7-21
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
A number of neighbouring sites appear to be affected too by the interference source if they have UL frequencies located within the band of interference. h. Site 88 is interfered most, the other sites (150, 82, 63) less. Probably there is a beam transmitted close to site 88, pointing to the other sites. In reality, the interfering transmitter was found to have a visible yagi antenna mounted on a house roof very close to site 88. Its transmitting direction was SSE in the direction of site 150. The interference source, being a non-GSM transmitter in the GSM band, must be reported to the local radio spectrum management authorities for taking further action. Meanwhile, also the frequency plan was changed.
7-22
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
CASE 4
_ ______________________________________________________________
a. Yes, there is a high number of attempts and also the blocking (25%) is above the desired GOS (1%). b. The cell could have a shortage of TCHs, SDCCHs or is pulling traffic from another cell. c. Cell 734- illuminates the problem area too much (RxLEV = -75 dBm), so that a MS mobile moving away from cell 458 to the west is handed over to cell 734- instead of cell 432-, which produces locally only an RxLEV of -85 dBm or less. d. Solutions: Removing 734 from the neighbour list is not a good solution. A good approach is reducing the local power level of cell 734- in the problem area. This can be accomplished in different ways: Reduction of the BTS TX level for cell 734-. This was done in the real situation. Downtilting the antenna for cell 734-. An increase from 5 o to 8 o was effected in the real situation. Rotating the antenna clockwise away from the problem area (not done however). In the real situation, the HO margin between cells 458- and 432- was also reduced.
November 5, 1997
7-23
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
Border Move
C645
C567
25m 60m
______________________________________________________________________________________________________
Figure 7-8. CELL BOUNDARIES AND PING-PONG HANDOVER PROBLEM
7-24
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
CASE 5
_ ______________________________________________________________
a. Path loss L = 123 dB b. Redesign your network Changing the HandOver margin on the Adjacent Cell object form on the OMC. c. 7 dB. The figure on the opposite page shows the new situation after changing the handover margin to 7 dB. The cell boundaries have moved some 85 meters away left and right from the centerline of the highway.
CASE 6
_ ______________________________________________________________
a. Likely an interference or system problem in cell 77-. b. Confirm the problem for cell 77- via OMC-PMS, search for unsuccesful call attempts and intra-cell handovers plus their reasons. c. Monitor the Abis link with a protocol analyzer, check for RX quality. d. Interference is the first suspicion. e. Sweep the band with a spectrum analyzer. Check the power levels and search for interference. f. This is definitely not an interference problem. g. Next step is to check signal levels and quality in cell 77-, on a per-RT basis. A drive test is required. h. Obviously RT2 has a problem, however it is not interference but rather a non-RF system failure. i. This is not an optimization problem, but a maintenance problem. Hand it over to the maintenance department. Summary: Observed problem: If there is any free channel in the BTS, RT2 does not handle calls. Reason: Due to the bad RX quality, the BSC forces the MS to handover from RT2 to another free channel. If there is no free channel available, the MS will maintain calls on RT2. Solution: The BTS and the MS always measure the RX quality and send the result to the BSC for evaluation. The only RT suffering is RT2. This means that there is a defective unit within the same rack related to RT2, or there is a high interference level but this is not confirmed by the sweep
November 5, 1997
7-25
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
measurement. Fault clearance: The followed procedure was (this is maintenance, just for information): 1. Replace non-sector affecting service units (TXU, RXU, RTC-PER and RTC-PRC one-by-one until the fault is cleared) for RT2. Fault was not cleared. 2. Replace sector affecting service packs (FHE, related to frequency hopping) for RT2 in the maintenance windows (e.g. 03:00 - 06:00 AM). Fault was cleared. 3. Run a test call for 5 minutes and monitor the RX quality. It was 0%. 4. Connect the protocol analyzer MA10 to site 77-. Monitor RT2 selecting the proper time slot for 2 hours. RX quality before replacing FHE pack was 4%, after replacing FHE pack it was 0.2%.
7-26
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
APPENDIX A: PATH LOSS TABLES _ ______________________________________________________________

This appendix provides a set of path loss tables for base station antenna heights of 15, 30, and 45 meters for 900 MHz and 1800 MHz while the mobile antenna height is 1.5 meter.
The following Okamura-Hata propagation prediction formulas were used:
for 900 MHz: L = 69. 55 + 26. 16 log f 13. 82 log h b a ( h m ) + [ 44. 9 6. 55 log h b ] log d L c and for 1800 MHz: L = 46. 3 + 33. 9 log f 13. 82 log h b a ( h m ) + [ 44. 9 6. 55 log h b ] log d L c
November 5, 1997
7-27
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
RACE Model: Propagation curves Frequency f (MHz): BTS antenna height h b (m): MS antenna height h m (m): 900 15 1.5
____________________________________________________________________________________________ U2 U1 S3 S2 S1 F2 F1 O2 O1 W Clutter class: ____________________________________________________________________________________________ Corr.factor Lc (dB) 0 3 8 5 11 9 19 19 24 29 ____________________________________________________________________________________________ ____________________________________________________________________________________________ Path loss Range ____________________________________________________________________________________________ L(db) d(km) ____________________________________________________________________________________________ _ ___________________________________________________________________________________________ 120 ____________________________________________________________________________________________ 0.52 0.63 0.85 0.71 1.03 0.91 1.69 1.69 2.30 3.13 0.55 0.67 0.91 0.75 1.09 0.97 1.79 1.79 2.44 3.33 121 _ ___________________________________________________________________________________________ 122 ____________________________________________________________________________________________ 0.59 0.71 0.97 0.80 1.16 1.03 1.91 1.91 2.60 3.54 0.63 0.75 1.03 0.85 1.24 1.09 2.03 2.03 2.77 3.77 123 ____________________________________________________________________________________________ 0.67 0.80 1.09 0.91 1.32 1.16 2.16 2.16 2.94 4.01 124 _ ___________________________________________________________________________________________ 125 0.71 0.85 1.16 0.97 1.40 1.24 2.30 2.30 3.13 4.27 ____________________________________________________________________________________________ 0.75 0.91 1.24 1.03 1.49 1.32 2.44 2.44 3.33 4.54 126 ____________________________________________________________________________________________ 127 0.80 0.97 1.32 1.09 1.58 1.40 2.60 2.60 3.54 4.83 ____________________________________________________________________________________________ 0.85 1.03 1.40 1.16 1.69 1.49 2.77 2.77 3.77 5.14 128 _ ___________________________________________________________________________________________ 129 ____________________________________________________________________________________________ 0.91 1.09 1.49 1.24 1.79 1.58 2.94 2.94 4.01 5.47 0.97 1.16 1.58 1.32 1.91 1.69 3.13 3.13 4.27 5.81 130 _ ___________________________________________________________________________________________ 131 ____________________________________________________________________________________________ 1.03 1.24 1.69 1.40 2.03 1.79 3.33 3.33 4.54 6.19 1.09 1.32 1.79 1.49 2.16 1.91 3.54 3.54 4.83 6.58 132 ____________________________________________________________________________________________ 1.16 1.40 1.91 1.58 2.30 2.03 3.77 3.77 5.14 7.00 133 ____________________________________________________________________________________________ 134 1.24 1.49 2.03 1.69 2.44 2.16 4.01 4.01 5.47 7.45 ____________________________________________________________________________________________ 1.32 1.58 2.16 1.79 2.60 2.30 4.27 4.27 5.81 7.92 135 _ ___________________________________________________________________________________________ 136 1.40 1.69 2.30 1.91 2.77 2.44 4.54 4.54 6.19 8.43 ____________________________________________________________________________________________ 1.49 1.79 2.44 2.03 2.94 2.60 4.83 4.83 6.58 8.97 137 ____________________________________________________________________________________________ 138 ____________________________________________________________________________________________ 1.58 1.91 2.60 2.16 3.13 2.77 5.14 5.14 7.00 9.54 1.69 2.03 2.77 2.30 3.33 2.94 5.47 5.47 7.45 10.15 139 _ ___________________________________________________________________________________________ 140 ____________________________________________________________________________________________ 1.79 2.16 2.94 2.44 3.54 3.13 5.81 5.81 7.92 10.80 1.91 2.30 3.13 2.60 3.77 3.33 6.19 6.19 8.43 11.49 141 ____________________________________________________________________________________________ 2.03 2.44 3.33 2.77 4.01 3.54 6.58 6.58 8.97 12.22 142 ____________________________________________________________________________________________ 143 2.16 2.60 3.54 2.94 4.27 3.77 7.00 7.00 9.54 13.00 ____________________________________________________________________________________________ 2.30 2.77 3.77 3.13 4.54 4.01 7.45 7.45 10.15 13.83 144 _ ___________________________________________________________________________________________ 145 2.44 2.94 4.01 3.33 4.83 4.27 7.92 7.92 10.80 14.71 ____________________________________________________________________________________________ 2.60 3.13 4.27 3.54 5.14 4.54 8.43 8.43 11.49 15.65 146 _ ___________________________________________________________________________________________ 147 ____________________________________________________________________________________________ 2.77 3.33 4.54 3.77 5.47 4.83 8.97 8.97 12.22 16.65 2.94 3.54 4.83 4.01 5.81 5.14 9.54 9.54 13.00 17.72 148 _ ___________________________________________________________________________________________ 149 ____________________________________________________________________________________________ 3.13 3.77 5.14 4.27 6.19 5.47 10.15 10.15 13.83 18.85 150 3.33 ____________________________________________________________________________________________ 4.01 5.47 4.54 6.58 5.81 10.80 10.80 14.71 20.05
7-28
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
November 5, 1997
7-29
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________ U2 U1 S3 S2 S1 F2 F1 O2 O1 W Clutter class: ______________________________________________________________________________________________ Corr.factor Lc (dB) 0 3 8 5 11 9 ______________________________________________________________________________________________ 19 19 24 29 ______________________________________________________________________________________________ Path loss Range ______________________________________________________________________________________________ L(db) d(km) ______________________________________________________________________________________________ ______________________________________________________________________________________________ 120 ______________________________________________________________________________________________ 0.76 0.94 1.31 1.07 1.61 1.40 2.76 2.76 3.87 5.43 0.82 1.00 1.40 1.15 1.72 1.50 2.95 2.95 4.14 5.81 121 ______________________________________________________________________________________________ 122 ______________________________________________________________________________________________ 0.88 1.07 1.50 1.23 1.84 1.61 3.16 3.16 4.43 6.21 0.94 1.15 1.61 1.31 1.97 1.72 3.38 3.38 4.74 6.65 123 ______________________________________________________________________________________________ 1.00 1.23 1.72 1.40 2.11 1.84 3.62 3.62 5.07 7.11 124 ______________________________________________________________________________________________ 125 1.07 1.31 1.84 1.50 2.25 1.97 3.87 3.87 5.43 7.61 ______________________________________________________________________________________________ 1.15 1.40 1.97 1.61 2.41 2.11 4.14 4.14 5.81 8.14 126 ______________________________________________________________________________________________ 127 1.23 1.50 2.11 1.72 2.58 2.25 4.43 4.43 6.21 8.71 ______________________________________________________________________________________________ 1.31 1.61 2.25 1.84 2.76 2.41 4.74 4.74 6.65 9.32 128 ______________________________________________________________________________________________ 129 ______________________________________________________________________________________________ 1.40 1.72 2.41 1.97 2.95 2.58 5.07 5.07 7.11 9.97 1.50 1.84 2.58 2.11 3.16 2.76 5.43 5.43 7.61 10.67 130 ______________________________________________________________________________________________ 131 ______________________________________________________________________________________________ 1.61 1.97 2.76 2.25 3.38 2.95 5.81 5.81 8.14 11.42 1.72 2.11 2.95 2.41 3.62 3.16 6.21 6.21 8.71 12.21 132 ______________________________________________________________________________________________ 1.84 2.25 3.16 2.58 3.87 3.38 6.65 6.65 9.32 13.07 133 ______________________________________________________________________________________________ 134 1.97 2.41 3.38 2.76 4.14 3.62 7.11 7.11 9.97 13.98 ______________________________________________________________________________________________ 2.11 2.58 3.62 2.95 4.43 3.87 7.61 7.61 10.67 14.96 135 ______________________________________________________________________________________________ 136 2.25 2.76 3.87 3.16 4.74 4.14 8.14 8.14 11.42 16.00 ______________________________________________________________________________________________ 2.41 2.95 4.14 3.38 5.07 4.43 8.71 8.71 12.21 17.12 137 ______________________________________________________________________________________________ 138 ______________________________________________________________________________________________ 2.58 3.16 4.43 3.62 5.43 4.74 9.32 9.32 13.07 18.32 2.76 3.38 4.74 3.87 5.81 5.07 9.97 9.97 13.98 19.60 139 ______________________________________________________________________________________________ 140 ______________________________________________________________________________________________ 2.95 3.62 5.07 4.14 6.21 5.43 10.67 10.67 14.96 20.97 3.16 3.87 5.43 4.43 6.65 5.81 11.42 11.42 16.00 22.44 141 ______________________________________________________________________________________________ 3.38 4.14 5.81 4.74 7.11 6.21 12.21 12.21 17.12 24.01 142 ______________________________________________________________________________________________ 143 3.62 4.43 6.21 5.07 7.61 6.65 13.07 13.07 18.32 25.69 ______________________________________________________________________________________________ 3.87 4.74 6.65 5.43 8.14 7.11 13.98 13.98 19.60 27.48 144 ______________________________________________________________________________________________ 145 4.14 5.07 7.11 5.81 8.71 7.61 14.96 14.96 20.97 29.40 ______________________________________________________________________________________________ 4.43 5.43 7.61 6.21 9.32 8.14 16.00 16.00 22.44 31.46 146 ______________________________________________________________________________________________ 147 ______________________________________________________________________________________________ 4.74 5.81 8.14 6.65 9.97 8.71 17.12 17.12 24.01 33.66 5.07 6.21 8.71 7.11 10.67 9.32 18.32 18.32 25.69 36.01 148 ______________________________________________________________________________________________ 149 ______________________________________________________________________________________________ 5.43 6.65 9.32 7.61 11.42 9.97 19.60 19.60 27.48 38.53 150 5.81 ______________________________________________________________________________________________ 7.11 9.97 8.14 12.21 10.67 20.97 20.97 29.40 41.22
7-30
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
_ ________________________________________________________________________________________ U2 U1 S3 S2 S1 F2 F1 O2 O1 W Clutter class: _ ________________________________________________________________________________________ Corr.factor Lc (dB) 0 3 8 5 11 9 19 19 24 29 _ ________________________________________________________________________________________ _ ________________________________________________________________________________________ Path loss Range _ ________________________________________________________________________________________ L(db) d(km) _ ________________________________________________________________________________________ _ ________________________________________________________________________________________ 120 _ ________________________________________________________________________________________ 0.28 0.34 0.47 0.39 0.56 0.50 0.92 0.92 1.25 1.71 0.30 0.36 0.50 0.41 0.60 0.53 0.98 0.98 1.33 1.82 121 _ ________________________________________________________________________________________ 122 _ ________________________________________________________________________________________ 0.32 0.39 0.53 0.44 0.63 0.56 1.04 1.04 1.42 1.93 0.34 0.41 0.56 0.47 0.67 0.60 1.11 1.11 1.51 2.06 123 _ ________________________________________________________________________________________ 0.36 0.44 0.60 0.50 0.72 0.63 1.18 1.18 1.60 2.19 124 _ ________________________________________________________________________________________ 125 0.39 0.47 0.63 0.53 0.76 0.67 1.25 1.25 1.71 2.33 _ ________________________________________________________________________________________ 0.41 0.50 0.67 0.56 0.81 0.72 1.33 1.33 1.82 2.48 126 _ ________________________________________________________________________________________ 127 0.44 0.53 0.72 0.60 0.86 0.76 1.42 1.42 1.93 2.63 _ ________________________________________________________________________________________ 0.47 0.56 0.76 0.63 0.92 0.81 1.51 1.51 2.06 2.80 128 _ ________________________________________________________________________________________ 129 _ ________________________________________________________________________________________ 0.50 0.60 0.81 0.67 0.98 0.86 1.60 1.60 2.19 2.98 0.53 0.63 0.86 0.72 1.04 0.92 1.71 1.71 2.33 3.17 130 _ ________________________________________________________________________________________ 131 _ ________________________________________________________________________________________ 0.56 0.67 0.92 0.76 1.11 0.98 1.82 1.82 2.48 3.37 0.60 0.72 0.98 0.81 1.18 1.04 1.93 1.93 2.63 3.59 132 _ ________________________________________________________________________________________ 0.63 0.76 1.04 0.86 1.25 1.11 2.06 2.06 2.80 3.82 133 _ ________________________________________________________________________________________ 134 0.67 0.81 1.11 0.92 1.33 1.18 2.19 2.19 2.98 4.06 _ ________________________________________________________________________________________ 0.72 0.86 1.18 0.98 1.42 1.25 2.33 2.33 3.17 4.32 135 _ ________________________________________________________________________________________ 136 0.76 0.92 1.25 1.04 1.51 1.33 2.48 2.48 3.37 4.60 _ ________________________________________________________________________________________ 0.81 0.98 1.33 1.11 1.60 1.42 2.63 2.63 3.59 4.89 137 _ ________________________________________________________________________________________ 138 _ ________________________________________________________________________________________ 0.86 1.04 1.42 1.18 1.71 1.51 2.80 2.80 3.82 5.20 0.92 1.11 1.51 1.25 1.82 1.60 2.98 2.98 4.06 5.54 139 _ ________________________________________________________________________________________ 140 _ ________________________________________________________________________________________ 0.98 1.18 1.60 1.33 1.93 1.71 3.17 3.17 4.32 5.89 1.04 1.25 1.71 1.42 2.06 1.82 3.37 3.37 4.60 6.27 141 _ ________________________________________________________________________________________ 1.11 1.33 1.82 1.51 2.19 1.93 3.59 3.59 4.89 6.67 142 _ ________________________________________________________________________________________ 143 1.18 1.42 1.93 1.60 2.33 2.06 3.82 3.82 5.20 7.09 _ ________________________________________________________________________________________ 1.25 1.51 2.06 1.71 2.48 2.19 4.06 4.06 5.54 7.54 144 _ ________________________________________________________________________________________ 145 1.33 1.60 2.19 1.82 2.63 2.33 4.32 4.32 5.89 8.03 _ ________________________________________________________________________________________ 1.42 1.71 2.33 1.93 2.80 2.48 4.60 4.60 6.27 8.54 146 _ ________________________________________________________________________________________ 147 _ ________________________________________________________________________________________ 1.51 1.82 2.48 2.06 2.98 2.63 4.89 4.89 6.67 9.08 1.60 1.93 2.63 2.19 3.17 2.80 5.20 5.20 7.09 9.66 148 _ ________________________________________________________________________________________ 149 _ ________________________________________________________________________________________ 1.71 2.06 2.80 2.33 3.37 2.98 5.54 5.54 7.54 10.28 150 1.82 _ ________________________________________________________________________________________ 2.19 2.98 2.48 3.59 3.17 5.89 5.89 8.03 10.94
November 5, 1997
7-31
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
_ _________________________________________________________________________________________ U2 U1 S3 S2 S1 F2 F1 O2 O1 W Clutter class: _ _________________________________________________________________________________________ Corr.factor Lc (dB) 0 3 8 5 11 9 19 19 24 29 _ _________________________________________________________________________________________ _ _________________________________________________________________________________________ Path loss Range _ _________________________________________________________________________________________ L(db) d(km) _ _________________________________________________________________________________________ _ _________________________________________________________________________________________ 120 _ _________________________________________________________________________________________ 0.35 0.42 0.59 0.48 0.71 0.62 1.20 1.20 1.67 2.31 0.37 0.45 0.62 0.51 0.76 0.67 1.28 1.28 1.78 2.47 121 _ _________________________________________________________________________________________ 122 _ _________________________________________________________________________________________ 0.40 0.48 0.67 0.55 0.81 0.71 1.37 1.37 1.90 2.63 0.42 0.51 0.71 0.59 0.87 0.76 1.46 1.46 2.03 2.81 123 _ _________________________________________________________________________________________ 0.45 0.55 0.76 0.62 0.92 0.81 1.56 1.56 2.16 3.00 124 _ _________________________________________________________________________________________ 125 0.48 0.59 0.81 0.67 0.99 0.87 1.67 1.67 2.31 3.20 _ _________________________________________________________________________________________ 0.51 0.62 0.87 0.71 1.05 0.92 1.78 1.78 2.47 3.42 126 _ _________________________________________________________________________________________ 127 0.55 0.67 0.92 0.76 1.13 0.99 1.90 1.90 2.63 3.65 _ _________________________________________________________________________________________ 0.59 0.71 0.99 0.81 1.20 1.05 2.03 2.03 2.81 3.90 128 _ _________________________________________________________________________________________ 129 _ _________________________________________________________________________________________ 0.62 0.76 1.05 0.87 1.28 1.13 2.16 2.16 3.00 4.16 0.67 0.81 1.13 0.92 1.37 1.20 2.31 2.31 3.20 4.44 130 _ _________________________________________________________________________________________ 131 _ _________________________________________________________________________________________ 0.71 0.87 1.20 0.99 1.46 1.28 2.47 2.47 3.42 4.74 0.76 0.92 1.28 1.05 1.56 1.37 2.63 2.63 3.65 5.06 132 _ _________________________________________________________________________________________ 0.81 0.99 1.37 1.13 1.67 1.46 2.81 2.81 3.90 5.40 133 _ _________________________________________________________________________________________ 134 0.87 1.05 1.46 1.20 1.78 1.56 3.00 3.00 4.16 5.77 _ _________________________________________________________________________________________ 0.92 1.13 1.56 1.28 1.90 1.67 3.20 3.20 4.44 6.16 135 _ _________________________________________________________________________________________ 136 0.99 1.20 1.67 1.37 2.03 1.78 3.42 3.42 4.74 6.57 _ _________________________________________________________________________________________ 1.05 1.28 1.78 1.46 2.16 1.90 3.65 3.65 5.06 7.02 137 _ _________________________________________________________________________________________ 138 _ _________________________________________________________________________________________ 1.13 1.37 1.90 1.56 2.31 2.03 3.90 3.90 5.40 7.49 1.20 1.46 2.03 1.67 2.47 2.16 4.16 4.16 5.77 8.00 139 _ _________________________________________________________________________________________ 140 _ _________________________________________________________________________________________ 1.28 1.56 2.16 1.78 2.63 2.31 4.44 4.44 6.16 8.54 1.37 1.67 2.31 1.90 2.81 2.47 4.74 4.74 6.57 9.11 141 _ _________________________________________________________________________________________ 1.46 1.78 2.47 2.03 3.00 2.63 5.06 5.06 7.02 9.73 142 _ _________________________________________________________________________________________ 143 1.56 1.90 2.63 2.16 3.20 2.81 5.40 5.40 7.49 10.39 _ _________________________________________________________________________________________ 1.67 2.03 2.81 2.31 3.42 3.00 5.77 5.77 8.00 11.09 144 _ _________________________________________________________________________________________ 145 1.78 2.16 3.00 2.47 3.65 3.20 6.16 6.16 8.54 11.84 _ _________________________________________________________________________________________ 1.90 2.31 3.20 2.63 3.90 3.42 6.57 6.57 9.11 12.64 146 _ _________________________________________________________________________________________ 147 _ _________________________________________________________________________________________ 2.03 2.47 3.42 2.81 4.16 3.65 7.02 7.02 9.73 13.49 2.16 2.63 3.65 3.00 4.44 3.90 7.49 7.49 10.39 14.40 148 _ _________________________________________________________________________________________ 149 _ _________________________________________________________________________________________ 2.31 2.81 3.90 3.20 4.74 4.16 8.00 8.00 11.09 15.37 150 2.47 _ _________________________________________________________________________________________ 3.00 4.16 3.42 5.06 4.44 8.54 8.54 11.84 16.41
7-32
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
November 5, 1997
7-33
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
7-34
November 5, 1997
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
APPENDIX B: TILTED ANTENNA RADIATION PATTERNS _ ______________________________________________________________

This appendix provides the radiation patterns for the DP601302 15.2 dBi sector antenna for a range of downtilt angles between 2 o and 14 o in steps of 2 o .
November 5, 1997
7-35
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
______________________________________________________________________________________________________
Figure 7-9. 2 DEG DOWNTILT
7-36
November 5, 1997
-8 -12 -16
-8 -12 -16
-28 -32 -28
-20 -24
-20 -24
-28 -32 -28
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
-20 -16 -12
-20 -16 -12
-24
-24
0 -4
0 -4
-8 -4
-8 -4 0
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
______________________________________________________________________________________________________
-8 -12 -16
-8 -12 -16
-28 -32 -28
-20 -24
-20 -24
-28 -32 -28
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
-20 -16 -12
-20 -16 -12
-24
-24
0 -4
0 -4
-8 -4
-8 -4 0
November 5, 1997
7-37
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
______________________________________________________________________________________________________
7-38
November 5, 1997
-8 -12 -16
-8 -12 -16
-28 -32 -28
-20 -24
-20 -24
-28 -32 -28
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
-20 -16 -12
-20 -16 -12
-24
-24
0 -4
0 -4
-8 -4
-8 -4 0
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
______________________________________________________________________________________________________
-8 -12 -16
-8 -12 -16
-28 -32 -28
-20 -24
-20 -24
-28 -32 -28
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
-20 -16 -12
-20 -16 -12
-24
-24
0 -4
0 -4
-8 -4
-8 -4 0
November 5, 1997
7-39
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
______________________________________________________________________________________________________
7-40
November 5, 1997
-8 -12 -16
-8 -12 -16
-28 -32 -28
-20 -24
-20 -24
-28 -32 -28
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
-20 -16 -12
-20 -16 -12
-24
-24
0 -4
0 -4
-8 -4
-8 -4 0
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
______________________________________________________________________________________________________
-8 -12 -16
-8 -12 -16
-28 -32 -28
-20 -24
-20 -24
-28 -32 -28
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
-20 -16 -12
-20 -16 -12
-24
-24
0 -4
0 -4
-8 -4
-8 -4 0
November 5, 1997
7-41
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
______________________________________________________________________________________________________
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
______________________________________________________________________________________________________
7-42
November 5, 1997
-8 -12 -16
-8 -12 -16
-28 -32 -28
-20 -24
-20 -24
-28 -32 -28
-12
-16
-20
-24
-28
-32
-28
-24
-20
-16
-12
-4
-8
-8
-4
-20 -16 -12
-20 -16 -12
-24
-24
0 -4
0 -4
-8 -4
-8 -4 0
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
9W537
APPENDIX C: ERLANG TABLE _ ______________________________________________________________

____________________________________ GRADE OF SERVICE = 2 % ____________________________________ TRX per TCH per Offered Traffic cell per cell E cell ____________________________________ 1 7 2.9 ____________________________________ 2 14 8.2 _ ___________________________________ 3 22 14.9 ___________________________________ _ 4 30 21.9 ____________________________________ 5 37 28.3 _ ___________________________________ 6 45 35.6 ___________________________________ _ 7 53 43 ____________________________________
Table 7-1. BLOCKING AND CAPACITY
__________________________________________________________________________________________
November 5, 1997
7-43
_ _______________________________________________________________________________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________ _ ______________________________________________________________
7
7-1 7-1 7-3 7-3 7-5 7-9 7-13 7-17 7-18 7-19 7-19 7-19 7-21 7-23 7-25 7-25 7-27 7-35 7-43
______________________________________________________________________________________________________
Contents
LESSON OVERVIEW LESSON OBJECTIVES
CASES
CASE 1 CASE 2 CASE 3 CASE 4 CASE 5 CASE 6
ANSWERS
CASE 1 CASE 2 CASE 3 CASE 4 CASE 5 CASE 6
APPENDIX A: PATH LOSS TABLES APPENDIX B: TILTED ANTENNA RADIATION PATTERNS APPENDIX C: ERLANG TABLE
November 5, 1997
7-i
ERLANG TABLES
8
8-1
Contents
ERLANG TABLES
Version 01 e
issue a
8-i
Contents
8-ii
Version 01 e
issue a
ERLANG TABLES
ERLANG TABLES
This lesson provides a selection of Erlang-B tables that can be used for calculations in trafc and engineering work assignments.
Version 01 e
issue a
8-1
ERLANG TABLES
9C500
Offered trafc in Erlang Circuits Blocking probability

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 0.001 0.001 0.046 0.194 0.439 0.762 1.146 1.579 2.051 2.557 3.092 3.651 4.231 4.831 5.446 6.077 6.722 7.378 8.046 8.724 9.411 10.108 10.812 11.524 12.243 12.969 13.701 14.439 15.182 15.930 16.684 17.442 18.205 18.972 19.743 20.517 21.296 22.078 22.864 23.652 24.444 25.239 26.037 26.837 27.641 28.447 29.255 30.066 30.879 31.694 32.512 0.002 0.002 0.065 0.249 0.535 0.900 1.325 1.798 2.311 2.855 3.427 4.022 4.637 5.270 5.919 6.582 7.258 7.946 8.644 9.351 10.068 10.793 11.525 12.265 13.011 13.763 14.522 15.285 16.054 16.828 17.606 18.389 19.176 19.966 20.761 21.559 22.361 23.166 23.974 24.785 25.599 26.415 27.235 28.057 28.882 29.708 30.538 31.369 32.203 33.039 33.876 0.005 0.005 0.105 0.349 0.701 1.132 1.622 2.157 2.730 3.333 3.961 4.610 5.279 5.964 6.663 7.376 8.100 8.834 9.578 10.331 11.092 11.860 12.635 13.416 14.204 14.997 15.795 16.598 17.406 18.218 19.034 19.854 20.678 21.505 22.336 23.169 24.006 24.846 25.689 26.534 27.382 28.232 29.085 29.940 30.797 31.656 32.517 33.381 34.246 35.113 35.982 0.010 0.010 0.153 0.455 0.869 1.361 1.909 2.501 3.128 3.783 4.461 5.160 5.876 6.607 7.352 8.108 8.875 9.652 10.437 11.230 12.031 12.838 13.651 14.470 15.295 16.125 16.959 17.797 18.640 19.487 20.337 21.191 22.048 22.909 23.772 24.638 25.507 26.378 27.252 28.129 29.007 29.888 30.771 31.656 32.543 33.432 34.322 35.215 36.109 37.004 37.901 0.020 0.020 0.223 0.602 1.092 1.657 2.276 2.935 3.627 4.345 5.084 5.842 6.615 7.402 8.200 9.010 9.828 10.656 11.491 12.333 13.182 14.036 14.896 15.761 16.631 17.505 18.383 19.265 20.150 21.039 21.932 22.827 23.725 24.626 25.529 26.435 27.343 28.254 29.166 30.081 30.997 31.916 32.836 33.758 34.682 35.607 36.534 37.462 38.392 39.323 40.255 0.030 0.031 0.282 0.715 1.259 1.875 2.543 3.250 3.987 4.748 5.529 6.328 7.141 7.967 8.803 9.650 10.505 11.368 12.238 13.115 13.997 14.885 15.778 16.675 17.577 18.483 19.392 20.305 21.221 22.140 23.062 23.987 24.914 25.844 26.776 27.711 28.647 29.585 30.526 31.468 32.412 33.357 34.305 35.253 36.203 37.155 38.108 39.062 40.018 40.975 41.933 0.050 0.053 0.381 0.899 1.525 2.218 2.960 3.738 4.543 5.370 6.216 7.076 7.950 8.835 9.730 10.633 11.544 12.461 13.385 14.315 15.249 16.188 17.132 18.080 19.031 19.985 20.943 21.904 22.867 23.833 24.802 25.773 26.746 27.721 28.698 29.677 30.657 31.640 32.624 33.609 34.596 35.584 36.574 37.565 38.557 39.550 40.545 41.540 42.537 43.534 44.533
8-2
Version 01 e
issue a
ERLANG TABLES
9C500

51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 0.001 33.332 34.153 34.977 35.803 36.630 37.460 38.291 39.124 39.959 40.795 41.633 42.472 43.313 44.156 45.000 45.845 46.691 47.540 48.389 49.239 50.091 50.944 51.799 52.654 53.511 54.369 55.227 56.087 56.948 57.810 58.673 59.537 60.402 61.268 62.135 63.003 63.872 64.742 65.612 66.484 67.356 68.229 69.103 69.978 70.853 71.729 72.606 73.484 74.363 75.242 0.002 34.716 35.558 36.401 37.247 38.094 38.942 39.793 40.645 41.498 42.353 43.210 44.068 44.927 45.788 46.650 47.513 48.378 49.243 50.110 50.979 51.848 52.718 53.590 54.463 55.337 56.211 57.087 57.964 58.842 59.720 60.600 61.480 62.362 63.244 64.127 65.011 65.896 66.782 67.669 68.556 69.444 70.333 71.222 72.113 73.004 73.895 74.788 75.681 76.575 77.469 0.005 36.852 37.724 38.598 39.474 40.351 41.229 42.109 42.990 43.873 44.757 45.642 46.528 47.416 48.305 49.195 50.086 50.978 51.872 52.766 53.661 54.558 55.455 56.354 57.253 58.153 59.054 59.956 60.859 61.763 62.668 63.573 64.479 65.386 66.294 67.202 68.111 69.021 69.932 70.843 71.755 72.668 73.581 74.495 75.410 76.325 77.241 78.157 79.074 79.992 80.910 0.010 38.800 39.700 40.602 41.505 42.409 43.315 44.222 45.130 46.039 46.950 47.861 48.774 49.688 50.603 51.518 52.435 53.353 54.272 55.191 56.112 57.033 57.956 58.879 59.803 60.728 61.653 62.579 63.506 64.434 65.363 66.292 67.222 68.152 69.084 70.016 70.948 71.881 72.815 73.749 74.684 75.620 76.556 77.493 78.430 79.368 80.306 81.245 82.184 83.124 84.064 0.020 41.189 42.124 43.060 43.997 44.936 45.875 46.816 47.758 48.700 49.644 50.589 51.534 52.481 53.428 54.376 55.325 56.275 57.226 58.177 59.129 60.082 61.036 61.990 62.945 63.900 64.857 65.814 66.771 67.729 68.688 69.647 70.607 71.568 72.529 73.490 74.452 75.415 76.378 77.342 78.306 79.271 80.236 81.201 82.167 83.133 84.100 85.068 86.035 87.003 87.972 0.030 42.892 43.852 44.813 45.776 46.739 47.703 48.669 49.635 50.602 51.570 52.539 53.508 54.478 55.450 56.421 57.394 58.367 59.341 60.316 61.291 62.267 63.244 64.221 65.199 66.177 67.156 68.136 69.116 70.096 71.077 72.059 73.041 74.024 75.007 75.990 76.974 77.959 78.944 79.929 80.915 81.901 82.888 83.875 84.862 85.850 86.838 87.826 88.815 89.804 90.794 0.050 45.533 46.533 47.534 48.536 49.539 50.543 51.548 52.553 53.559 54.566 55.573 56.581 57.590 58.599 59.609 60.619 61.630 62.642 63.654 64.667 65.680 66.694 67.708 68.723 69.738 70.753 71.769 72.786 73.803 74.820 75.838 76.856 77.874 78.893 79.912 80.932 81.952 82.972 83.993 85.014 86.035 87.057 88.079 89.101 90.123 91.146 92.169 93.193 94.216 95.240
Version 01 e
issue a
8-3
ERLANG TABLES
9C500

101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 0.001 76.122 77.003 77.884 78.766 79.649 80.532 81.416 82.301 83.186 84.072 84.959 85.846 86.734 87.622 88.511 89.401 90.291 91.181 92.073 92.964 93.857 94.750 95.643 96.537 97.431 98.326 99.222 100.117 101.014 101.911 102.808 103.706 104.604 105.503 106.402 107.302 108.202 109.102 110.003 110.904 111.806 112.708 113.611 114.514 115.417 116.321 117.225 118.130 119.035 119.940 0.002 78.364 79.260 80.157 81.054 81.951 82.850 83.748 84.648 85.548 86.448 87.350 88.251 89.154 90.056 90.960 91.864 92.768 93.673 94.578 95.484 96.391 97.297 98.205 99.113 100.021 100.930 101.839 102.749 103.659 104.569 105.480 106.392 107.303 108.216 109.128 110.041 110.955 111.869 112.783 113.697 114.612 115.528 116.444 117.360 118.276 119.193 120.110 121.028 121.946 122.864 0.005 81.829 82.748 83.668 84.588 85.509 86.431 87.353 88.275 89.198 90.121 91.045 91.970 92.895 93.820 94.746 95.672 96.599 97.526 98.454 99.382 100.310 101.239 102.168 103.098 104.028 104.958 105.889 106.820 107.752 108.684 109.616 110.549 111.482 112.416 113.349 114.283 115.218 116.153 117.088 118.023 118.959 119.895 120.832 121.769 122.706 123.643 124.581 125.519 126.457 127.396 0.010 85.005 85.946 86.888 87.830 88.773 89.716 90.660 91.604 92.548 93.493 94.438 95.384 96.330 97.277 98.223 99.171 100.118 101.066 102.015 102.964 103.913 104.862 105.812 106.762 107.713 108.664 109.615 110.566 111.518 112.470 113.423 114.376 115.329 116.282 117.236 118.190 119.144 120.099 121.054 122.009 122.964 123.920 124.876 125.832 126.789 127.746 128.703 129.660 130.618 131.576 0.020 88.941 89.910 90.880 91.850 92.821 93.791 94.763 95.734 96.706 97.678 98.651 99.624 100.597 101.571 102.545 103.519 104.493 105.468 106.443 107.419 108.395 109.371 110.347 111.323 112.300 113.278 114.255 115.233 116.211 117.189 118.167 119.146 120.125 121.104 122.084 123.063 124.043 125.023 126.004 126.984 127.965 128.946 129.928 130.909 131.891 132.873 133.855 134.837 135.820 136.803 0.030 91.784 92.774 93.765 94.756 95.747 96.738 97.730 98.722 99.715 100.708 101.701 102.694 103.688 104.682 105.676 106.670 107.665 108.660 109.655 110.651 111.646 112.642 113.639 114.635 115.632 116.629 117.626 118.623 119.621 120.619 121.617 122.615 123.614 124.612 125.611 126.610 127.610 128.609 129.609 130.609 131.609 132.609 133.610 134.610 135.611 136.612 137.613 138.615 139.616 140.618 0.050 96.265 97.289 98.314 99.339 100.364 101.390 102.415 103.441 104.468 105.494 106.521 107.548 108.575 109.602 110.630 111.658 112.685 113.714 114.742 115.771 116.799 117.828 118.857 119.887 120.916 121.946 122.976 124.006 125.036 126.066 127.097 128.128 129.159 130.190 131.221 132.252 133.284 134.315 135.347 136.379 137.411 138.443 139.476 140.508 141.541 142.574 143.606 144.640 145.673 146.706
8-4
Version 01 e
issue a
ERLANG TABLES
9C500

151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 0.001 120.846 121.752 122.659 123.566 124.473 125.381 126.288 127.197 128.105 129.014 129.924 130.833 131.743 132.654 133.564 134.475 135.387 136.298 137.210 138.123 139.035 139.948 140.861 141.775 142.689 143.603 144.517 145.432 146.347 147.262 148.178 149.093 150.010 150.926 151.843 152.760 153.677 154.594 155.512 156.430 157.348 158.267 159.185 160.105 161.024 161.943 162.863 163.783 164.703 165.624 0.002 123.783 124.702 125.621 126.541 127.461 128.381 129.302 130.223 131.144 132.065 132.987 133.910 134.832 135.755 136.678 137.601 138.525 139.449 140.373 141.298 142.223 143.148 144.073 144.999 145.925 146.851 147.777 148.704 149.631 150.558 151.486 152.414 153.342 154.270 155.198 156.127 157.056 157.985 158.915 159.845 160.775 161.705 162.635 163.566 164.497 165.428 166.359 167.291 168.223 169.155 0.005 128.334 129.274 130.213 131.153 132.093 133.033 133.974 134.915 135.856 136.797 137.739 138.681 139.623 140.565 141.508 142.451 143.394 144.338 145.281 146.225 147.169 148.114 149.058 150.003 150.948 151.894 152.839 153.785 154.731 155.677 156.624 157.570 158.517 159.464 160.412 161.359 162.307 163.255 164.203 165.151 166.100 167.048 167.997 168.946 169.896 170.845 171.795 172.745 173.695 174.645 0.010 132.534 133.492 134.451 135.409 136.368 137.328 138.287 139.247 140.207 141.167 142.128 143.088 144.049 145.010 145.972 146.933 147.895 148.857 149.819 150.781 151.744 152.707 153.669 154.633 155.596 156.559 157.523 158.487 159.451 160.416 161.380 162.345 163.310 164.275 165.240 166.205 167.171 168.136 169.102 170.068 171.035 172.001 172.968 173.934 174.901 175.868 176.835 177.803 178.770 179.738 0.020 137.786 138.769 139.752 140.736 141.720 142.704 143.688 144.672 145.657 146.641 147.626 148.611 149.596 150.582 151.567 152.553 153.539 154.525 155.511 156.498 157.484 158.471 159.458 160.445 161.432 162.419 163.407 164.395 165.382 166.370 167.358 168.347 169.335 170.323 171.312 172.301 173.290 174.279 175.268 176.258 177.247 178.237 179.226 180.216 181.206 182.196 183.187 184.177 185.168 186.158 0.030 141.620 142.622 143.624 144.627 145.629 146.632 147.635 148.638 149.641 150.644 151.648 152.651 153.655 154.659 155.663 156.667 157.672 158.676 159.681 160.686 161.690 162.695 163.701 164.706 165.711 166.717 167.723 168.728 169.734 170.740 171.747 172.753 173.759 174.766 175.773 176.779 177.786 178.793 179.800 180.808 181.815 182.822 183.830 184.838 185.845 186.853 187.861 188.869 189.878 190.886 0.050 147.739 148.773 149.807 150.840 151.874 152.908 153.943 154.977 156.011 157.046 158.080 159.115 160.150 161.185 162.220 163.255 164.291 165.326 166.361 167.397 168.433 169.469 170.504 171.540 172.576 173.613 174.649 175.685 176.722 177.758 178.795 179.832 180.869 181.905 182.942 183.980 185.017 186.054 187.091 188.129 189.166 190.204 191.241 192.279 193.317 194.355 195.393 196.431 197.469 198.507
Version 01 e
issue a
8-5
ERLANG TABLES
9C500
8-6
Version 01 e
issue a
GSM System
Network Performance Monitoring Guide
Formerly: GSM 2000 Network Capacity Monitoring and Engineering Guide - Issue a
Lucent Technologies Proprietary This document contains proprietary information of Lucent Technologies and is not to be disclosed or used except in accordance with applicable agreements Copyright 1996 Lucent Technologies Unpublished and Not for Publication All Rights Reserved Printed in U.S.A.
401-380-321 Issue 1.0 December 1996
This material is protected by the copyright and trade secret laws of the United States and other countries. It may not be reproduced, distributed or altered in any fashion by any entity, including other Lucent Technologies Business Units or Divisions, without the expressed written consent of the Customer Technical Support and Information organization. For permission to reproduce or distribute please contact: Product Development Manager +1-800-334-0404
Notice
Every effort was made to ensure that the information in this document was complete and accurate at the time of printing. However, information is subject to change.
Federal Communications Commission (FCC) Statement

None for this document but here to illustrate the feature.
Trademarks
Adobe and Acrobat are registered trademarks of Adobe Systems Incorporated FrameMaker is a registered trademark of Frame Technology Corporation. UNIX is a registered trademark of UNIX Systems Laboratories, Inc.
Warranty
Lucent Technologies provides no warranty for this product.
Contents
Introduction
s s s s s s s s
1 1 2 2 3 3 4 4 4
Reasons for Re-Issue of this Document Scope Overview of Contents Audience Reference And Supporting Documentation Ordering Information Web Access Technical Support Information
GSM Functional Overview

s s s s
1 1 1 2 5 5 6 6 6 8
Network Model Lucent Technologies GSM 5ESS-2000 Switching Subsystem Base Station System (BSS) Base Transceiver Station (BTS) BSS Central Equipment (BCE-2000) Speech Transcoding Frame (STF-2000) or Transcoding Equipment (TCE-2000) Communication Interfaces
OMC-2000
Introduction to Performance Analysis

s
1 1 1 2 2 3 3 3
Monitoring GSM Networks Quality of Service Network Capacity Network Availability
Sources of Data Optimisation Drive Test Data RF Design and Network Planning Tools
Issue 1.0
December 1996
iii
Contents
Fault Management Data Network Roll Out Plans Customer Feedback

s
3 4 4 5 5 5 6 6
Data Analysis Considerations and Limitations Amounts of Data Data Accuracy Network Operating Conditions Data Collection and Analysis Methods
5ESS-2000 and OMC-2000 Reports

s s
1 1 2 4 4 5 5 6 7 8 8 9 10 10 10 11
Introduction 5ESS-2000 Reports Format Wireless Summary (WRLSSUM) Report Wireless Handover (WRHAND) Report Home Location Register Visitor Location Register (HLRVLR) Report Trunk Group Component (TGCOMP) Report Switching Module Component (SMCOMP) Report Call Incompletion Code Summary (CICSUM) Report Signalling Link Component (SLCOMP) Report Signalling Link Set Component (SLSCOMP) Report Traffic Flow (TRAFFLOW) Report
OMC-2000 Reports of the BSS Measurement Data on the OMC-2000 Measurement Records Browser GSM OMC-2000 Basic Cell Analysis Tool
OMC-PMS Reports and Graphs

s s
1 2 4
Global Definitions Daily Operations Reports
iv
Issue 1.0
December 1996
Contents
Daily Cell TCH Report (DCTTR) Daily Cell SDCCH Report (DCCTR) Daily Cell Handover Report (DCHOR) Daily Route Traffic Report (DRTR) Daily Linkset Availability Report (DLSAR) Daily BH Linkset Utilization Report (DLSUR) Daily MSC Traffic Report (DMTR) Daily MSC Handover Report (DMHOR) Daily Network Availability Report (DCAR)
s
4 5 6 10 11 12 13 15 16 16 17 18 19 23 23 25 26 27 27 28 28
Historical (or Summary) Reports Summary Cell TCH Traffic Report (SCTTR) Summary Cell SDCCH Traffic Report (SCCTR) Summary Cell Handover Report (SCHOR) Summary BSS Cell TCH Traffic Report (SBTR) Summary Route Traffic Report (SRTR) Summary Linkset Availability Report (SLSAR) Summary BH Linkset Utilization Report (SLSUR) Summary MSC Traffic Report (SMTR) Summary MSC Handover Report (SMHOR)
Forecasting Reports Selecting the Way to View the Past Selecting the Regression Technique for Extrapolating into the Future Forecasting Cell TCH Summary Report (FCTR) Forecasting Cell TCH Historical Report (FCTHR) Forecasting Cell TCH Exhaustion Report (FCTXR) Forecasting Cell TCH Utilization Report (FCTUR) Forecasting Cell TCH Required Channels Report (FCTCR) Forecasting Route Summary Report (FRTR) Forecasting Route Historical Report (FRHR) Forecasting Route Exhaustion Report (FRXR) Forecasting Route Low Utilization Report (FRUR)
Selecting a Traffic Model and the Type of Traffic 29 30 31 32 33 35 37 38 39 40 41
Forecasting Route Required Circuits Report (FRCR) 42
Issue 1.0
December 1996
Contents
Performance Analysis
s
1 1 4 5 5 5 6 7 7
Handover Measurements Total Number of Handovers by Type Average Time Until a Handover Occurs
Miscellaneous Length of Talking Phase of a Call Operational Scenarios Capacity Issues Scenario: Higher Carried Traffic on TCH than Expected
s s
Scenario: Zero Traffic Carried for TCH and SDCCH during Normally Busy Hours 9 Scenario: Lower Carried Traffic on TCH than Expected Scenario: Not Enough Capacity to Meet Short-Term TCH demand for grade of service Forecasting future TCH demand Scenario: Higher Carried Traffic on the SDCCH than Expected Scenario: Lower Carried Traffic on SDCCH than Expected 11 12 12 13 15
Scenario: Not Enough Capacity to Meet Short-Term SDCCH Demand for Grade of Service 15 Scenario: Not Enough Capacity to Meet Short-Term CCCH Demand
s
16 17 17 18 19 19 20 21 22
Availability Issues Scenario: Monitoring TCH Availability Scenario: Monitoring SDCCH Availability
Quality of Service Issues Scenario: No Service Shown on Handset Main Indicators Scenario: Ability to Setup and Receive Calls Scenario: Ability to Maintain Calls Scenario: Ability to Perform BSS Controlled Intercell Handovers
vi
Issue 1.0
December 1996
Contents
Glossary
Abbreviations
5ESS-2000 and BSS Measurements

s s
1 2 3 3 5 6 8
5ESS-2000 Measurements 5ESS-2000 Wireless Summary (WRLSSUM) Call Setup Miscellaneous Sub Activities of Mobile Connection Procedures MSC Controlled Handovers
s s
5ESS-2000 Wireless Handover (WRHAND) Cell to Cell 12 5ESS-2000 Home Location Register and Visitor Location Register (HLRVLR) 13 HLR (Home Location Register) Authentication Events VLR (Visitor Location Register) Location Update Events IMSI Events IMEI Events 13 14 16 17 19 19 20 21 22 24 24 26 27 28 29 30
5ESS-2000 Trunk Group Component (TGCOMP) Incoming Trunk Group Outgoing Trunk Group BSSAP Trunk Group Usage Counters
5ESS-2000 Switching Module Component (SMCOMP) 26 Line and BSSAP Trunk PSTN Trunk BSSAP Trunks before Handover only BSSAP Trunks after Handover only Miscellaneous
Issue 1.0
December 1996
vii
Contents
5ESS-2000 Call Incompletion Code Summary (CICSUM)31 Basic GSM Related Incoming Call Outgoing Call Miscellaneous 31 32 33 34 37 39 39 40 40 41 41 41 43 45 47 47 48 49 50 55 59 66 68 69
5ESS-2000 Signalling Link Component (SLCOMP) Transmission Reception Signalling Link Failure Congestion Changeovers Duration
s s s s
5ESS-2000 Signalling Link Set Component (SLSCOMP) 42 5ESS-2000 Traffic Flow (TRAFFLOW) 5ESS-2000 Mobile Application PART (MAP) BSS Measurements Background BSS Counter Types BSS Measurement Categories
s s s s s s
BSS Um Connection BSS Channels BSS Handover BSS Signalling BSS Load/Time/Duration BSS Measurements Summary Table
Signaling Flow Diagrams

s
1 1 2 6 9 11 12
MSC Signaling Flow Diagrams Mobile-To-Land Call Land-To-Mobile Call Mobile Location Update BSC Controlled Handover Intra-MSC Controlled Handover
viii
Issue 1.0
December 1996
Contents
Inter-MSC Handover
s
13 15 16 18 19 20 21 22 23 24
BSS Signaling Flow Diagrams Mobile Terminating Call Dropped Calls Location Update IntraBTS TCH Handover BSC-Controlled TCH Handover MSC-Controlled TCH Handover BSC-Controlled SDCCH Handover MSC-Controlled SDCCH Handover
IN
Index to Appendix A
Issue 1.0
December 1996
ix
Contents
Issue 1.0
December 1996
Introduction
The GSM System Network Performance Monitoring Guide explains how to use the Lucent Technologies Global System for Mobile communications (GSM) performance management data for monitoring cellular network performance, and to plan for growth. Since most of the analysis presented in this document is based on the OMC-2000 Performance Management Subsystem (OMC-PMS) reports and graphs, Lucent Technologies strongly recommends that the OMC-PMS option is installed and made operational.
Reasons for Re-Issue of this Document 1

This is the second issue of this document which has been updated to include the functionality provided by GSM release 6.5. The previous issue of this document (i.e. Issue a, which was specic to GSM Release 6.0) was entitled the GSM 2000 Network Capacity Monitoring and Engineering Guide. However, since the guide is primarily intended to address performance monitoring issues rather than Engineering issues, the title of the document was changed to its current title. This issue contains the following additions:
s
Updated Reports: new counters specic to BSS release LM4 have been added to some of the BSS reports. Additionally, MSC related reports are now available as well. Updated denitions: the denitions of the MSC and BSS measurement counters have been comprehensively revised. A description of the inter-relationships between the BSS and MSC handover counters is now part of this document.
Issue 1.0
December 1996
1-1
Introduction
Scope
1
This guide is specic to GSM Release 6.5, which includes the following hardware entities and the associated software releases:
s s s
Base Station System (BSS): LM4 Mobile Switching Center (MSC): 5ESS-2000 8.1 Operations and Maintenance Center (OMC-2000): 3.5
In addition, this guide can be used for GSM Release 6.0:

s s s
Base Station System (BSS): LM3 Mobile Switching Center (MSC): 5ESS-2000 8.1 Operations and Maintenance Center (OMC-2000): 3.0
The primary differences are that the OMC-PMS Routing and Trunking Reports described in Chapter 5 are not available in Release 6.0, nor are a number of the BSS counters. The differences are noted within this document.
NOTE:
Use of this document, or the information it contains, with any conguration other than the ones above may not be valid. This guide is specic to the performance analysis of GSM networks and does not cover other aspects of network management or network engineering. This guide only takes into account the subset of the 5ESS-2000 measurement reports that pertain to managing the GSM aspects of a 5ESS-2000 switch. GSM aspects include not only wireless aspects but also interconnection aspects such as trunking and SS7 (ITU-T Signalling System No. 7) connectivity. Note that these are not the only measurement reports that an operator should be using to manage the switch.
Overview of Contents
This document contains:
s
A brief overview of the Lucent GSM system and subsystem architecture (Chapter 2) An introduction to performance analysis along with overviews of sources of data plus any limitations regarding the accuracy of data and associated analysis reports / graphs (Chapter 3) A selection of measurements and reports available from the MSC and from the BSS (Chapter 4) Details of reports available from the OMC-PMS (Chapter 5)
1-2
Issue 1.0
December 1996
Introduction
A performance analysis chapter containing a description of the inter-relationships between the BSS and MSC handover counters, along with a number of operational scenarios which may be encountered by a network operator (Chapter 6) A glossary containing comprehensive denitions of terms used within this document (Chapter 7) A listing of abbreviations used within this document (Chapter 8) A detailed listing, with associated denitions, of the MSC and BSS measurement counters that are available to monitor the GSM network (Appendix A) MSC and BSS signalling ow diagrams which indicate specic measurement triggering points within the common calling procedures (Appendix B).
s s
Audience
Lucent Technologies assumes that anyone using the information in this guide has a general familiarity with GSM networks, and has specic experience working with, and operating, the Lucent Technologies GSM system including its OMC-2000. Therefore, the audience for this guide consists of local eld support personnel, network planners, network operators, and systems engineers who work with the Lucent Technologies GSM Network and need to know how to plan and expand a GSM network using network statistics.
Reference And Supporting Documentation
The reader can use this guide in conjunction with other Lucent Technologies documentation. The following documents or document sets are the most probable additional documents that the user might need:
s
401-380-004 GSM Documentation Roadmap. This document contains a description of other documents which describe the Lucent Technologies GSM system. 401-380-103 GSM OMC -2000 System Operators Guide 401-380-151 OMC-2000 Performance Management Subsystem (PMS) guide which explains how to use the optional OMC-PMS including the Kingsher module.
s s
The following documents are produced on a per country basis. Therefore, the name of the country for which the document is desired must be included as part of the ordering information:
s s
MM06EC: 5EE 8.1 Measurements Manual CR33EG: 5EE 8.1 Commands and Reports Manual
Issue 1.0
December 1996
1-3
Introduction
Ordering Information
To order any of the documentation identied above or additional copies of this guide, contact Lucent Technologies in one of the following ways:
s
To place an order by telephone from within the continental United States, call 1-800-432-6600. To place an order by telephone from outside the continental United States, call: For Europe, Australia and New Zealand, call (International Access Code) 1-317-322-6416. For the Far East, call (International Access Code) 1-317-322-6448.
To place an order via facsimile machine within the continental United States, transmit to 1-800-566-9568. To place an order via facsimile machine outside the continental United States, transmit to (International Access Code) 1-317-322-6699.
Web Access
The latest electronic version of this document is available to Lucent Technologies personnel only. The document is available in postscript format (A4 paper size or letter size) and Adobe Acrobat format i.e., pdf. A free copy of Acrobat Reader can be downloaded from the site, if required. The document is in the Internal Technical Documents (ITD) section of the Library page at the internal Lucent Technologies web site with address: http://ns.uk.lucent.com/gsm/depts
Technical Support Information

s
For technical assistance support, telephone the GSM Customer Response Center on: voice: +49-911-526-2170 facsimile: +49-911-526-3198.
1-4
Issue 1.0
December 1996
Network Model
A GSM network is a complete communication system which complies with the ETSI/GSM Technical Specications for a Digital Cellular Radio Network. It provides advanced telecommunication services through modular and exible structures. A GSM network has three main subsystems:
s
Switching Subsystem (SSS): The SSS manages call handling, billing data, and the interface to the public switching telephone network (PSTN). Base Station Subsystem (BSS): The BSS is the physical equipment that provides radio coverage to prescribed geographical areas called cells. It contains the equipment required to communicate with the mobile station. The interface between the SSS (switching subsystem) and the BSS comply with the A-interface specied by GSM. Operation and Support System (OSS): The OSS performs the operation and maintenance activities in the network.
Lucent Technologies GSM
The Lucent Technologies GSM System is Lucent Technologies GSM system implementation. Please refer to Chapter 1, Section Scope to nd specic information about what Lucent Technologies specic products and related software releases are supported within this document. The basic architecture of the GSM consists of the following:
s
The 5ESS-2000 Switching System mainly provides the functionality of the MSC and the VLR and optionally the functionality of the HLR, EIR, and AUC. Each BSS consists of the Speech Transcoder Frame (STF-2000) or other transcoding equipment (TCE-2000), a BSS Central Equipment, and several BTS-2000s. The OMC-2000 handles the operation and maintenance requirements for the BSSs. It can be used to remotely connect to the 5ESS-2000 to perform basic switch maintenance procedures. In addition, the 5ESS-2000 passes a subset of its trafc data to the OMC-2000.
Issue 1.0
December 1996
2-1
Also available is the optional OMC-2000 Performance Management Subsystem (OMC-PMS) which provides additional analysis capabilities of performance measurement data, both BSS and 5ESS-2000.
The following gure illustrates major GSM system component relationships in the Lucent Technologies GSM Network.
AUC OMC OMC-PMS (Optional) HLR MSC HLR BTS BSC AUC MSC VLR
voice path signaling path integrated or external element
EIR
BSS MS
EIR
PSTN
Figure 2-1.
Lucent Technologies GSM System
5ESS-2000 Switching Subsystem
The MSC provides service to subscribers through the BSS. The MSC and BSS communicate using the standard GSM A-interface. The 5ESS-2000 Switch MSC communicates through the MAP interface with external MSCs, VLRs, HLRs and EIRs. The 5ESS-2000 Switch MSC and its integrated VLR can interact with other vendors equipment to the extent that the vendors comply to the GSM specications of the open interfaces. In addition, the 5E uses the standard MAP interface for internal communication among its internal VLR, HLR, EIR and MSC. Basic 5ESS-2000 Switch capabilities are not impacted by the wireless capabilities of the MSC. The MSC hardware modules consist of standard 5ESS-2000 Switch modules since there are no hardware modications required for the GSM application.
2-2
Issue 1.0
December 1996
The MSC architecture as implemented by the 5ESS-2000 Switch is represented in the gure below.
5ESS-2000 Switch MSC
AM CM
WSM
WSM
WGSM
PSTN Global SM
SM
SM
BSS
BSS
PSTN
voice path signaling path
Figure 2-2.
5ESS-2000 Switch Architecture The 5ESS-2000 hardware modules are described briey:
s
Administrative Module (AM): The AM provides the administrative functionality for the 5ESS-2000 including the local maintenance personnel interface, data storage, trunk routing, and the interfaces to the Operations and Maintenance Center and Billing Center. Communication Module (CM): The CM is responsible for Time Multiplexed Call Switching between modules, network synchronization, and intra-MSC communication between switching modules and the AM. Switching Modules (SM):
s
Wireless Switching Module (WSM) - The WSM provides the Base Station System (BSS) voice and signaling link terminations and storage of Home Location Register (HLR), Visitor Location Register (VLR), Equipment Identity Register (EIR), and Authentication Center (AUC). Nailed-up connections between the WSM and the WGSM through the CM are provided to terminate the signaling links at the WGSM. The WSM also supports voice trunks to the PSTN.
Issue 1.0
December 1996
2-3
Wireless Global Switching Module (WGSM) - The WGSM provides the terminations for the SS7 connections from the BSSs. Switching Modules (SMs) - These SMs provide voice trunk connections to the PSTN. SS7 connections can be terminated on these SMs. In such cases, these signaling connections need to be nailed-up through the CM and terminated at the PSTN-Global SM. PSTN-Global Switching Module (PSTN-Global SM) - The PSTNGlobal SM provides the terminations for theSS7 connections from the PSTN and processes the SS7 signalling information.
Trafc measurement related events are recorded and kept by the various 5ESS-2000 components and subsystems. Periodically, the AM collects the trafc data and sends the raw data in binary format to an OSS where it can be displayed in ASCII formatted reports on local and remote printers. The OSS also saves this data on disk so that an operator can later issue a system command to display a report on a terminal. In addition, much of the data identied in the 5ESS-2000 reports shown in Chapter 4 are sent to the OMC-2000 and ultimately to the OMC-PMS.
2-4
Issue 1.0
December 1996
Base Station System (BSS)
According to GSM terminology, the BSS consists of the Base Transceiver Station (BTS) and Base Station Controller (BSC). The Lucent Technologies GSM System product family includesthe BTS 900 and BTS 2000. The BSC is split into the following components:
s s
BSS central equipment (BCE-2000) Speech transcoding frame (STF-2000) or transcoding equipment (TCE-2000)
The following gure shows the general structure of the BSS and its connections to the MSC and the OMC-2000. Um
MS BTS
(remote)
BSC
Um
Abis M
MS BTS
(remote)
BCE
STF or TCE
(to MSC)
Um
MS BTS
(co-located)
(to OMC)
Figure 2-3.
Structure of a BSS Looking at the gure, one can see the three building blocks that comprise a BSS: the BTS, STF-2000 or TCE-2000 and BCE-2000.
Base Transceiver Station (BTS)
The BTS is made up of all the radio equipment for a single radio cell identied by a particular cell identier.
Issue 1.0
December 1996
2-5
BSS Central Equipment (BCE-2000)
The BCE-2000 is the central control module in the BSS and provides the interfaces with the BTS, STF-2000 or TCE-2000, and OMC. All central parts of the BCE-2000 are duplicated to allow a fault tolerant operation. The BCE-2000 administers the radio resources and radio frequencies and controls the internal digital switch which is the heart of the system.
Speech Transcoding Frame (STF-2000) or Transcoding Equipment (TCE-2000)
For each trafc channel, this equipment adapts the different transmission rates for speech and data calls on the radio side to the standardized 64 kbit/s transmission rate at the network side of the system. It also maps between the different speech coding algorithms used within the xed network and on the radio interface.
Communication Interfaces
The BTS 900/BTS 2000, BCE-2000 and STF-2000 or TCE-2000 may either be separated, or partially or completely co-located. In any case, the components are interconnected by the following standard interfaces: Interface A Abis M O Um Description The interface between the MSC and BSS. The interface between the BCE-2000 and BTS. An internal interface between the BCE-2000 and the TCE-2000. A standard packet switched network interface for connecting the BSS and OMC. The GSM-defined 900 MHz radio interface connecting mobiles to the network.
A Interface The A interface is the interface to the MSC as specied in GSM Recommendations of the 08-series. It consists of trafc channels and signaling links in the Common Channel Signaling System No. 7 (CCSS7). Abis Interface The Abis interface exists between the BCE-2000 and BTS. It is based on the concept specied by GSM Recommendation 08.51 to 08.60. Physical transmission is based on 2048 kbit/s. PCM time slot 0 is always used for synchronization. All other time slots can be used in either of the following ways:
s s
Signaling channel (64 kbit/s) Trafc channels (4 x 16 kbit/s sub-multiplexed)
2-6
Issue 1.0
December 1996
M Interface The M interface is an internal interface between the BCE-2000 and the TCE-2000. It is based on standard PCM transmission with a rate of 2048 kps. Sub-multiplexing of trafc channels (4 x 16 kbit/s onto one 64 kbit/s channel) is always applied. O Interface The O interface is a standard packet switched network interface for the connecting the BSS and OMC. It is based on the X.25 interface specication of the CCITT and GSM Recommendation 12.20. Um Interface The Um interface is the GSM dened 900 MHz radio interface connecting mobile stations to the network.
Um Interface Logical Channels

The Um interface consists of several logical channels. These channels are used to carry the voice and signalling information between the BTS and mobile stations. TCH (Trafc Channel) A TCH contains speech information or data information. CCH (Control Channel) Signaling information is divided into major channel groups: Broadcast Channels (BCH), Common Control Channels (CCCH), and Dedicated Control Channels (DCCH).
s
BCH (Broadcast Channels) BCHs are solely used by the BTS to provide downlink information for all MSs camping on a cell. They are Broadcast Control Channel (BCCH), Frequency Correction Channel (FCCH), and Synchronization Channel (SCH).
s
BCCH (Broadcast Control Channel) The BCCH provides general information concerning network, serving cell and adjacent cells (i.e. country, network operator, location area, technical parameters used for BTS to mobile communication). They are vital for the mobile to get to the idle mode. FCCH (Frequency Correction Channel) The FCCH contains a frequency correction burst. After being switched on, the mobile scans the downlink frequency range in order to detect this known burst type and to align its receiver to this master frequency. Normally, the mobile chooses the FCCH with the highest eld strength. SCH (Synchronization Channel) The SCH is used for mobile synchronization purposes. It contains the number of the actual TDMA frame and a brief network identication, the so called Base Station Identity Code (BSIC).
CCCH (Common Control Channels) CCCHs are used by several MSs simultaneously. They exist either uplink or downlink. They are Access Grant Channel (AGCH), Random Access Channel (RACH) and the Paging Channel (PCH).
s
AGCH (Access Grant Channel) The AGCH allocates dedicated signaling capacity to perform registration, call setup, and so on.
Issue 1.0
December 1996
2-7
RACH (Random Access Channel) The RACH is used by the mobile when responding to a paging request or if it needs to initiate communications to the network. PCH (Paging Channel) The PCH is used by the BTS to call a mobile station that is in idle mode.
DCCH (Dedicated Control Channels) DCCHs are allocated to MSs with a certain time limitation. They are used in uplink and downlink communication. They consist of Stand-alone Dedicated Control Channel (SDCCH), Slow Associated Control Channel (SACCH), and Fast Associated Control Channel (FACCH).
s
SDCCH (Stand-alone Dedicated Control Channel) The mobile and BTS use a SDCCH for signaling information concerning different procedures such as authentication, location update, dialing, and so on. SACCH (Slow Associated Control Channel) The SACCH is used every 480 ms during communication providing uplink measurement reports (receive level receive quality) on the active and adjacent cells and downlink timing advance or power control. FACCH (Fast Associated Control Channel) A FACCH is allocated when spontaneous signaling is needed during active communication, such as during handover, service mode modication, or connection release.
OMC-2000
The Lucent Technologies OMC is an operation and support system that is used for the conguration management, fault management, and performance management of a GSM network. The Lucent Technologies GSM OMC supports operations, administration, and maintenance functions for the BSS network elements. In addition, the OMC has a cut-through interface to the MSC (Lucent Technologies 5ESS-2000 switch) which allows the user to perform basic system functions on the 5ESS-2000 from the OMC. The MSC uses FTAM to send selected trafc measurement les to the OMC which in turn passes them to the OMC-PMS. Some typical tasks performed on the OMC include provisioning and reconguration of BSS equipment, adjusting cell parameters, monitoring network alarms and events, and monitoring network performance.
2-8
Issue 1.0
December 1996
Remote Systems (e.g., dial-in modem)
Remote Networks
Terminal Server
Printer
Router
Ethernet LAN
Console
Tape Drive
OMC Workstation
PC X-Terminal OMC Server X.25 Links
GSM OMC
Printer
PMS Router to remote OMCs External Systems (e.g., MSC) BSS-n
PMS Workstation
PMS Server
BSS-1
CO-LOCATED OMC-PMS
Figure 2-4. Example OMC Conguration The OMCs network performance monitoring capability utilises the measurements obtained from the BSSs. It does not currently have the ability to view 5ESS-2000 measurement data. The OMC initiates the collection of BSS measurements by creating measurement objects on the BSS. These measurement objects activate the collection of measurements and the transfer of the measurement results to the OMC. The OMC saves these measurement results. The 5ESS-2000 transfers measurement les to the OMC after each reporting interval. The OMC forwards both sets of measurements to the optional OMC Performance Management Subsystem (OMC-PMS) via TCP/IP. Chapters 5 and 6 of this guide assume that the optional OMC-PMS has been installed in the network
Issue 1.0
December 1996
2-9
The OMC-PMS provides access to measurements generated by the BSS and a selected subset of measurements generated by the 5ESS-2000. The OMC-PMS is based on the GSM data analysis product Metrica NPR/AG from Metrica, Ltd. which has been customized for Lucent Technologies. The OMC-PMS gives an operator the ability to look at the measurement results in graphs or reports, using raw or summary measurement results. With the OMC-PMS, an operator can better observe current network performance and work actively to properly plan for network growth. The pre-dened reports are identied in Chapter 5.
2-10
Issue 1.0
December 1996
This chapter introduces the concept of performance analysis in GSM networks. It begins with some basic guidelines for analyzing performance data from a GSM network. Next, there is a section that identies sources of information that can be used to supplement and verify OMC-PMS or OMC-2000 output. The chapter ends with a discussion of performance analysis considerations and limitations.
Monitoring GSM Networks
In monitoring a GSM network, the user should track three different aspects of the GSM network:
s s s
Quality of service Network capacity Network availability
Although there is some overlap in the above areas, each affects the overall operation of the network in a unique way. Each of these areas is described on the pages that follow.
Quality of Service
Quality of service is dened here as the end-users perception of the offered cellular service. From a network operators point of view, monitoring quality of service means not only monitoring network performance, but also monitoring customer feedback. For the purpose of this guide, monitoring quality of service implies monitoring network performance that is perceived by the end-user. In doing this, the monitoring of network performance can give an indication of the overall quality of service.
Note that it is possible to have excellent quality of service measurements from the network performance point of view, while at the same time having very low overall quality of service as perceived by the subscribers.
Issue 1.0
December 1996
3-1
To measure the quality of service, the analysis information in Chapter 6 reviews measurements which describe issues such as:
s s s
The ability to register to the network. The ability to setup and receive calls. The ability to maintain calls.
Network Capacity
Call Capacity is the maximum trafc that can be supported by the network while maintaining a desired grade of service (GOS). The GOS is a measure of adequacy identifying the acceptable number of busy hour call attempts that can fail due to actual demand exceeding network capacity. After the resources are installed, an operator monitors the usage of those resources to ensure their proper utilization. For example, network resources that are underutilized (i.e., usage does not even approach the GOS), might be removed to save on costs. On the other hand, if the resources are consistently overused (i.e., the GOS is exceeded), additional resources might be added so as to re-establish the desired grade of service. Network capacity issues are related to quality of service. Obviously network capacity problems as evidenced by the overuse of resources are perceived by subscribers when they are unable to access the network. The Capacity Issues section in Chapter 6 gives hints about how to answer questions related to carried trafc, such as:
s s s
What could be the reason for unexpected high carried trafc? Is the planned grade of service being met? Is there a need for expanding the network?
Network Availability
Availability can be more easily dened by looking at unavailability (see Glossary for denitions). The reason that the factors that cause unavailability can be dened. Therefore, network availability is determined by subtracting unavailability from full availability. Events and limitations which cause unavailability are:
s s
Failure of a network component (perhaps due to external causes) Removal of a network component from service, for example for maintenance Failure due to interference Limit of coverage Terrain or topography limitations
s s s
The availability analysis section of Chapter 6 covers measurements that indicate whether all installed components were in-service for a period of time or whether
3-2
Issue 1.0
December 1996
there were outages. The possible reasons for the outages and the signs pointing to indicators are also given.
Sources of Data
The following chapters in this guide address data produced from the OMC-2000 and the OMC-PMS. It is also important to consider data from other sources for a complete understanding of the performance of the network. Such data includes, but is not limited to, the following plus any other available local information:
s s s s s
Optimisation Drive Test Data RF and Network Planning Tools Fault Management Data Network Roll Out Plans Customer Feedback
Optimisation Drive Test Data
Probably the most important source of additional data is that gathered by drive tests of the operational network. This data can be used to identify exactly where problems are occurring within the network (e.g., interference problems, handover problems). The operator can use the data from the OMC-PMS and the OMC-2000 to help identify the areas in which drive testing should be concentrated.
RF Design and Network Planning Tools
The RF Design and Network Planning tools, which clearly show where RF problems may occur, provide information to better understand some of the data produced from the OMC-PMS and the OMC-2000. For example when the OMC-PMS data identies a cell having a high number of dropped calls, the RF tool could show the cause being that the cell is located on the edge of present coverage. In addition, the Network Planning tool could be used to help locate the source of other problems. For example if the OMC-2000 data for several BTSs is missing, the Planning tool might show that a common element to these BTSs such as a microwave link was down for a time. Not only is information from these RF Design and Planning tools useful in understanding the OMC-2000 and OMC-PMS data, but so is the reverse. That is, design engineers should use the information produced by the OMC-2000 and OMC-PMS about the existing network when they are planning future cell deployments.
Fault Management Data
When analysing performance data it is essential to have access to any record of fault and maintenance activities. This data can be used to determine if any equipment was faulty or being maintained during the period of analysis. Faults on
Issue 1.0
December 1996
3-3
adjacent network elements should also be considered as they may explain changing patterns such as increased trafc load.
Network Roll Out Plans
During the rst few years of any network, there is typically signicant network growth. This growth usually brings problems as exemplied by the difculty in bringing all of the sites in a particular area into service at the same time. This happens because some sites are easier to acquire and build than others. Such situations can lead to irregular patterns in the performance data. Also as the network becomes more and more dense, a missing cell site can cause interference and capacity problems. These issues should be taken into consideration when addressing network growth.
Customer Feedback
A very valuable source of data is customer feedback or complaints. Several complaints in a particular location usually point to a problem being experienced by many people who dont bother to register a complaint. Where possible a structured log of all complaints including the nature of the problem, location, equipment involved and the solution should be maintained.
3-4
Issue 1.0
December 1996
Data Analysis Considerations and Limitations
When analysing large volumes of data, it is important to remember that many variables can affect your results. Such variables include, but are not limited to:
s s s s
Amount of Data Data Accuracy Network Operating Conditions Data Collection and Analysis Methods
Amounts of Data
When analysing the performance data, the user must take into account the amount of data with which the user is dealing. This becomes particularly important when the user is trying to forecast network activity. Note that data that spans several weeks, or even months, is required before the user can start to correctly identify any trends. Smaller quantities may or may not correctly reect the long-term status of the network. The more historical data that is available, the better the prediction. For example before adding an extra radio to a cell, data gathered over at least two or three weeks should be analysed.
Data Accuracy
The data that is collected for monitoring network status is generated by the individual network elements or the OMC-2000. These statistical counters accurately reect the activity of the network. However, certain conditions can cause data inconsistencies (for example, the maintenance of an element), or even gaps in the collected data (for example, if a network element is down for a period of time). This can affect the accuracy of the analysis. It is desirable that these anomalies be removed and/or ignored during the analysis phase. The OMC-PMS has the ability to ll in the gap in the coverage of the data. (Note that the OMC-2000 itself does not have such a capability.) The OMC-PMS does this by interpolating the data based on counts before and after the missing data. Interpolation of missing counts only works when a small number of counts are missing. When large amounts of data are missing, interpolation is not possible because there is no way to accurately estimate how the network was performing during that time. (The OMC-PMS has created the term minimum data coverage to indicate the minimum amount of data that must be valid before it will attempt to ll in the gaps.)
Issue 1.0
December 1996
3-5
Network Operating Conditions
When considering the validity of the data being analysed, a network analyst must consider the stability of the network conguration and the activity of the subscribers. This does not concern the accuracy of the data, but how accurately the data depicts the normal operating conditions. Attempting to analyze data from a cell while several neighboring cells are being installed could be difcult (if not impossible) due to the trafc uctuations caused by the deployment of new cells. Also, if a local event is occurring in the region, the data would be skewed because many more subscribers would be accessing the network than during normal times. This abnormal data is valuable, and should be used when planning the network, but it should not be an indicator for normal network operation conditions.
Data Collection and Analysis Methods
To properly analyze network data, the user must be aware of both the collection methods and the analysis methods that are used. The collection methods vary depending on the measurement. Most measurements are peg counters which are triggered by certain network events (e.g., number of handovers, number of dropped calls, etc.) Another major category of measurements are intensity (e.g., usage) counters. These counters are used to determine averages over some period of time. For these measurements, a sampling interval must be used to calculate this average. Nothing happens concerning these counters except at the end of each sampling interval. At that time, the network element determines the current state of the resource (e.g. how many trunks are currently in use) and records that information. There are many sampling intervals for every recording interval. In some instances, this sampling interval must be small (for example, ve seconds) while in other instances larger sampling intervals may be sufcient (for example, 100 seconds). If a network condition occurs and returns to the original state before a sample is taken, this condition will not be represented in the sampled measurement. When evaluating sampling based measurements, the user must be aware of this type of condition. In addition to collection methods, the user must consider the analysis methods that are being used. For example, when analyzing the network capacity, the current growth trend of the network is used. Certain conditions may cause variance in this trend. These variances may be caused by valid growth activities, or they may have other causes such as a problem with a neighbor cell. During analysis, the user must be aware of these variances and make the proper adjustments as needed to minimize the effects of unwanted conditions during growth planning.
3-6
Issue 1.0
December 1996
Introduction
This chapter identies the reports that are produced by the OMC-2000 and the 5ESS-2000 switch that can be used in monitoring the GSM network. Chapter 5 identies a large number of additional reports that also can be used to monitor a GSM network, but they are provided through the optional OMC-PMS system. This chapter does not include all the reports that are available from the 5ESS-2000 switch, but only those that are specically related to wireless communications. The service provider should use other reports to monitor other aspects of its network. For example, the 5ESS-2000s MHQLPS report should be used to monitor the performance of the Quad-Link Packet Switch Message Handler. The rst section of this chapter shows the format of the 5ESS-2000 reports that can be used to analyze the performance of the wireless aspects of the switch. These reports are shown as they would be viewed through the 5ESS-2000 Multi Function Operations System (MFOS) system. The denitions of most of the trafc measurements that are contained within these reports are listed in Appendix A. The second section of this chapter shows the format of the reports that the OMC-2000 can produce concerning BSS trafc data. Complete denitions of the BSS trafc measurements also appear in Appendix A. The analysis of this 5ESS-2000 and BSS data is more efcient when the user utilizes the OMC-PMS.
Issue 1.0
December 1996
4-1
5ESS-2000 Reports Format
This section shows the printed format of the MSC reports. For more information on other reports, reference the 5EE 8.1 Commands and Reports Manual. The reports listed use the following keys: a. b. c. d. e. f. g. h. i. j. k. l. m. number of this part number of parts in report report date (yy-mm-dd) measurement program identier measurement program start date (yy-mm-dd) measurement program end date (yy-mm-dd) measurement period identier measurement period start time (hh:mm) measurement period end time (hh:mm) collection interval identier collection interval start time (hh:mm) collection interval end time (hh:mm) a number 1-7 that indicates condition for invalidity 1. The measurement clock was manually altered during the collection interval. 2. The measurement subsystem database transactions were faulty. 3. Some messages were lost from SMs (switching modules). 4. The previous collection interval report data was invalid. 5. Processor is in min-mode. 6. Initialization occurred in the report interval. 7. Selectivity database transactions were faulty. n. o. units used to express usage (ALL USAGE IN CCS or ALL USAGE IN ERLANGS x 100) average 100-second scans
In addition, within the report layouts: * (an asterisk) indicates the location of actual counter data when a user runs a report. In addition, the user can nd a description of the counter in Appendix A. (a dash) also indicates the location of actual counter data. However, in this case the counter is not covered within this document. For more information on such counters, please refer to the 5EE 8.1 Measurements Manual.
4-2
Issue 1.0
December 1996
On the pages that follow are the formats of the following reports, all of which are shown without data.
s s s s s s s s s
Wireless Summary Report (WRLSSUM) Wireless Handover Report (WRHAND) Home Location Register/Visitor Location Register Report (HLRVLR) Trunk Group Component Report (TGCOMP) Switching Module Component Report (SMCOMP) Call Incompletion Code Summary Report (CICSUM) Signalling Link Component Report (SLCOMP) Signalling Link Set Component Report (SLSCOMP) Trafc Flow Report (TRAFFLOW)
Issue 1.0
December 1996
4-3
Wireless Summary (WRLSSUM) Report
This report identies the total wireless call and handover activity as seen by the 5ESS-2000 switch.
OP TRFMR WRLSSUM DATE PROGRAM PERIOD INTERVAL c ID d g j START e h k
PART a OF b END f i l
DATA (IS VALID|MAY BE INVALID [m]) WIRELESS SUMMARY REPORT MMCLLA * MLCLLA * LMCLLA * MMSCLLA * MLSCLLA * PAGATT * TMSIAT * MAPFOR * CINCFWD * PART a OF b c ID d g j START e h k END f i l LMSCLLA * PAGATTS * TMSIFL * MAPFORS * MMECALL * AVGTPG *
MLECALL LMECALL MOBURLS FORCRLS * * * * AUTATT * AUTHFL * CIPATT * CIPHFL *
IMEIBLR IMEIATS IMEIGLR IMEIWLR * * * * OROAM * TROAM * OALTRK * ITALTRK *
OP TRFMR WRLSSUM DATE PROGRAM PERIOD INTERVAL
DATA (IS VALID|MAY BE INVALID [m]) WIRELESS SUMMARY REPORT HOREQI * HOREQT * HOCOMNC * HOICOM * HOREQF * HOREJI * HOCOMI * HOFC * HOCOMT * HOSC * HOCOMF * HOBSC * HOCOMR *
ITRAHOAT ITRAHOCO ITERHOAT ITERHOCO * * * *
Wireless Handover (WRHAND) Report
This report only identies the number of MSC controlled handovers on a per BSC basis. That is, it identies the number of handovers the MSC received from and sent to each BTS connected to it through a BSC.
OP TRFWH WRHAND DATE PROGRAM PERIOD INTERVAL c ID d g j START e h k
DATA (IS VALID|MAY BE INVALID [m]) WIRELESS HANDOVER REPORT LAC * CELL_ID * IIBTSHO * OIBTSHO *
4-4
Issue 1.0
December 1996
Home Location Register Visitor Location Register (HLRVLR) Report
This report is concerned with activity at the HLR, VLR, AUC and EIR when they are resident on the 5ESS-2000. The VLR is always resident on the 5ESS-2000, but all of the others need not be which implies that the associated counters would be zero.
OP TRFMR HLRVLR DATE PROGRAM PERIOD INTERVAL c ID d g j START e h k
DATA (IS VALID|MAY BE INVALID [m]) HOME LOCATION REGISTER AND VISITOR LOCATION REGISTER SRGVLR * HLRTRMM * RSRGVLR * RCVAUT * MSRNALS * AUCVR * PLOCUP * VLRTRMM * HLRLUR * RCVAUTS * IMEIATR * AUCVRS * GLOCUP * PLCUFL * GLCUFL * IMSIATF * SSOHLRS * HLRINT * IMEIBLS * IMSIATT * SRGHLR * GLOUPI * SENALT * DELVLR * IMSIDET * HLRROM * GLUFLI * MSRNAL *
HLRTRCH VLRTRCH * * SHLRLUR SSOHLR * * AUTVRA * AUTVRAS *
IMEIGLS IMEIWLS * *
Trunk Group Component (TGCOMP) Report
This report is the basic 5ESS-2000 trunking report. That is, it identies the usage of the trunks connected to the 5ESS-2000. In addition, a few special measurements are made for the wireless aspects of BSSAP trunks.
OP TRFTR TGCOMP DATE PROGRAM PERIOD INTERVAL c ID d g j START e h k
DATA (IS VALID|MAY BE INVALID [m]) n AVG 100-SECOND SCANS o ALL TRUNK GROUP DATA TGN * TGN * TGN * TGN * TGN * ISEIZE * OATTMPT * TOTUSG * INSVC * MATTMPT * IROUTE * OVFL * MTUSG * OOSMTCE * MOVFL * ISETUP * OSEIZE * IANSUSG * OOS * MSEIZE * ISATTMP * OARR OANSUSG * TRANBID IANS * OSATTMP * BWINCU * ITRANSZ * ICONGES * OANS * BWOUTU * DBLSZR *
Issue 1.0
December 1996
4-5
Switching Module Component (SMCOMP) Report
This report identies trafc, primarily trunk trafc, on an SM basis. Also, a number of wireless only aspects are included such as number of handovers coming into an SM.
OP TRFSR SMCOMP DATE PROGRAM PERIOD INTERVAL c ID d g j START e h k
DATA (IS VALID|MAY BE INVALID [m]) n AVG 100-SECOND SCANS o SWITCHING MODULE DATA SM * SM * SM * LOAD * DTD INCRD MHMSG DTDSS INCRDSS MHBLCYC TDAD SIGLINK OCCUP * TDADSS PUQOVFL TERMINATING ANS USAGE * * OUTGOING SEIZE * USAGE * SEIZE * REOVLD * TTAD CONCBLK TTADSS -
SM *
ORIGINATING USAGE SEIZE * * INCOMING USAGE *
SEIZE *
SM * WIRELESS SWITCHING MODULE DATA
SM * SM *
MSGDEL * VEC0 *
ORIGINATING USAGE SEIZE * * HNDUSG * HNDOVER *
TERMINATING ANS USAGE * * HNDUSG *
SEIZE * HNDOVER *
4-6
Issue 1.0
December 1996
Call Incompletion Code Summary (CICSUM) Report
This is the standard Call Incompletion Code report of the 5ESS-2000 switch. There are included a number of GSM specic codes which are identied in Appendix A.
OP TRFMR CICSUM DATE PROGRAM PERIOD INTERVAL c ID d g j DATA (IS VALID|MAY BE INVALID [m]) START e h k
CALL INCOMPLETION CODE SUMMARY REPORT TLREQ * ICA * HWDFA * TMTL RUNFN * SNAN SNALINC IFS * TCL * ANSTO * OUTER * FCOBCA * NANSTO * TSUCC * IPS SCO * CONTFL CONG * ADMNBLK * RFN * IPDA * INVCRCV * OSF UNF * LOSN * PROERR * IPDTO * ALTRK * OPCAN FCO * ADI * NPROERR * PART a OF b c ID d g j DATA (IS VALID|MAY BE INVALID [m]) START e h k END f i l AAA * CONTO * INCER * CRBRD * BARRN * RESFA * NTMG * SBYOS *
OP TRFMR CICSUM DATE PROGRAM PERIOD INTERVAL
CALL INCOMPLETION CODE SUMMARY REPORT OCA * LOSTERM * WRPRERR * AUTOSF OFS SUBSTR * NORESP * OPDA SBSTERM * AUTHFL * OPDTO SNATERM * CIPHFL * OPS UTS * TMSIFL * SNAORIG * ISPRERR IMEIFL *
Issue 1.0
December 1996
4-7
Signalling Link Component (SLCOMP) Report
This report records information about the SS7 links between the 5ESS-2000 and the BSSs as well as the PSTN.
M OP TRFSL SLCOMP DATE PROGRAM PERIOD INTERVAL PART a OF b c START e h k END f i l ID d g j DATA (IS VALID|MAY BE INVALID [m]) SIGNALING LINK MEASUREMENTS TYPE TYPE TYPE TYPE TYPE TYPE TYPE TYPE TYPE GSM GSM GSM GSM GSM GSM GSM GSM GSM SET SET SET SET SET SET SET SET SET MEM MEM MEM MEM MEM MEM MEM MEM MEM NSUE * EDLA * DSLU * CDOC * MDSC * TCONG SLTH1 * LEMDO LACO *
NSFR * EERR * DSLA * NSFX * CRMSUL * RCONG SLTH2 REMDO LACB *
NRBO FEDC * INLM * MSUX * STPM RMCONG * SLTH3 NACK * LMCO *
SFAR * ALFL * INRM * MSUR * MRTR * TBCONG EMRI ORTR * DSLULF *
Signalling Link Set Component (SLSCOMP) Report
This report records information about the SS7 link sets between the 5ESS-2000 and the BSSs as well as the PSTN.
OP TRFLS SLSCOMP DATE PROGRAM PERIOD INTERVAL c ID START d e g h j k DATA (IS VALID|MAY BE INVALID [m])
SIGNALING LINK SET MEASUREMENTS TYPE GSM SET -
DSLS *
NISL -
NUSL -
ILSDPOL -
4-8
Issue 1.0
December 1996
Trafc Flow (TRAFFLOW) Report
This report has many subparts. Only the four subparts that are of interest to the OMC-PMS are shown here.
M OP TRFMR TRAFFLOW DATE PROGRAM PERIOD INTERVAL
ID START d e g h j k DATA (IS VALID|MAY BE INVALID [m]) n AVG 100-SECOND SCANS o
ORIGINATING - TERMINATING USAGE ATTMPTS * * BEHAV EXFLT * * SNAL UNAL * * ORIGINATING - OUTGOING USAGE ATTMPTS * * BEHAV EXFLT * * PDA PDTO * *
SEIZE * ERROR * LOS * SEIZE * ERROR *
ANS * ADMIN *
BUSY * EXRES *
SATTMPT ADMIN *
ANS * EXRES *
BSN * NOCKT *
INCOMING - TERMINATING USAGE * BEHAV * SNAL * INCOMING - OUTGOING USAGE * BEHAV * PDA *
ATTMPTS * EXFLT * UNAL * ATTMPTS * EXFLT * PDTO *
SEIZE * ERROR * LOS * SEIZE * ERROR *
ANS * ADMIN * TRAN * SATTMPT ADMIN *
BUSY * EXRES *
ANS * EXRES *
BSN * NOCKT *
Issue 1.0
December 1996
4-9
OMC-2000 Reports of the BSS
BSS measurements are sent to the OMC-2000 via measurement events. The OMC-2000 parses these measurement events and stores the results in les at the OMC-2000. Each measurement le contains all the measurement results from every BSS that is generating measurement events for one hours worth of time. The OMC-2000 provides the ability to generate reports that contain basic statistical information about the BSC and its associated BTSs. For those networks which have an optional OMC-PMS installed, these measurement result les are sent periodically to the OMC-PMS for post-processing.
Measurement Data on the OMC-2000
There are two ways to view BSS measurement data on the OMC-2000: using the Measurement Records Browser or viewing the output with the Basic Analysis Tool. Both are highlighted below, but for more detailed information and operating instructions, refer to the OMC-2000 System Operators Guide.
Measurement Records Browser
The Measurement Records Browser allows one to view the results of any measurement for a given BTS within a given time frame. These results are the raw counters as provided by the BSS (that is, no post-processing is performed on the results). A user can use this browser to look for specic measurement results on a specic BTS. However, if a user needs to compare the results from several BTSs, then he/ she should use the Basic Analysis Tool or, preferably, the OMC-PMS.
4-10
Issue 1.0
December 1996
GSM OMC-2000 Basic Cell Analysis Tool
The Basic Cell Analysis Tool gives the user the ability to generate a report at the OMC-2000 that indicates some of the basic statistics for every cell that is producing measurement results. This OMC-2000 operator can use this report to verify that the cells in the network are operating as expected. He/she can generate the report for either one hours worth of data or else for one days worth of data
Example Report Heading
GSM OMC Report p. 1 Hourly Cell Statistics 96/05/01 from 20:00-20:59 --TCH-InInStd Srv (#) (%) ----Out BSC H/0 Fail Att (%) ----------
BTS Name -------------
Intvl Reprts Rec'vd ------
Att TCH Seiz ------
Num TCH Blocks ------
Num TCH RF Losses ------
Traffic in Erlangs -------
Calculations
Interval Reports Received Installed TCHs % TCHs In Service Attempted TCH Seizures Number TCH Blocks Number TCH RF Losses Outgoing Handover Attempts Outgoing Handover Failure Percentage This column gives an indication of the number of interval reports that were used to generate the report. Number of Installed TCHs. Percentage of Installed TCHs actually in service. meanAndDelaySeizTCH.totalNoOfTCHSeiz <Attempted_TCH_Seizures> * trafcChannCongestTime.fullRate / (duration * 60) noRadioFreqLosses noAttOutIntercellBssHo.fullRate + noAttIncIntercellBssHo.SDCCH 100 * (<Outgoing_Handover_Attempts> - (noSucOutIntercellBssHo.fullRate + noSucOutIntercellBssHo.SDCCH)) / <Outgoing_Handover_Attempts>
Duration for BSS measurements is 15 minutes.
Issue 1.0
December 1996
4-11
4-12
Issue 1.0
December 1996
The OMC-2000 Performance Management Subsystem (OMC-PMS) is an optional package which is available with the standard Lucent Technologies GSM System. It provides a standard set of predened reports and graphs based on trafc measurement data generated by the Lucent GSM network elements. In addition, the OMC-PMS system provides an ad-hoc query tool that allows the user to create customized reports and graphs. This chapter identies the pre-dened reports available through the OMC-PMS for GSM Release 6.5. In addition, it shows the source of the data that appears in these reports. For example, the Daily Cell TCH Trafc Report lists the number of TCH Seizure Attempts per BTS (i.e. sector). This chapter shows that the values for this eld are taken from the BSS measurement meanAndDelaySeizTCH.totalNoOfTCHSeiz. The reader can nd the precise denition of this BSS measurement as well as all other BSS measurements and 5ESS-2000 measurements in Appendix A. The intent here is to give the reader the ability to determine the precise meaning of the report outputs of the OMC-PMS. Since the majority of the information displayed in the standard graphs is the same as that from the BSS standard reports, this guide does not address the output from the graphs. The standard OMC-PMS reports and graphs are accessed via three modules within that system: daily operations, historical (or summary) and forecasting.
s
Daily Operations: The reports and graphs in the daily operations module are based on the standard raw data as provided by the network elements. For example, currently the BSS produces measurement results every 15 minutes; reports and graphs based on this 15-minute data will be presented in this module. Due to the volume of this data, it is only stored in the OMC-PMS for a period of 60 days.
This document can also be used for systems on Release 6.0. The reports and the columns that are new to Release 6.5 (i.e., columns that did not appear in reports supporting Release 6.0) are identied. However, no attempt is made to identify what columns were deleted from Release 6.0 to Release 6.5. Note that no Release 6.0 reports were deleted. None of the 5ESS-2000 data gets sent to the OMC-2000 in Release 6.0. Therefore, it is only with Release 6.5 that the 5ESS-2000 data is available on the OMC-PMS.
Issue 1.0
December 1996
5-1
Historical (or Summary): For this module, all graphs and reports use aggregate data. This data contains both the period totals and the busy hours data, where the period can be daily, weekly, or monthly. This aggregate is stored in the OMC-PMS for a period of two years. Forecasting: The forecasting module is used to give long-term statistics of TCHs based on the weekly aggregate data. Included in these statistics are predictions of future TCH exhaustion and underutilization.
Each OMC-PMS report is shown in this Chapter by an example of its output format followed immediately by a Calculations section that identies the source of each eld in the report. Fields are largely based on BSS and 5ESS-2000 measurements which are dened in Appendix A of this guide. However, very often it is easier to show a eld as being based on other elds within the same report. Therefore, in the tables under the headingsCalculations, the technique of enclosing a value within < and > is used to refer to another heading in the same report. In addition, there are a few denitions that are used often (see the Global Denitions section below) and so are identied by the eld name and the < and > being in bold. Most measurements are basic peg counters. That is, they just count the number of times an event occurs (e.g. call originations). However, some measurements represent average values (e.g.Average Number of In Service TCHs) or Usage values (typically trunks). In such cases, the average counter typically represents the value times 100. That is, a counter of 353 means a value of 3.53. In the Calculations sections that follow, dividing by 100 is done to convert the counter value (e.g. 353) to its true value (i.e., 3.53). The automatic group of BSS measurements must be activated to provide enough data for the standard graphs and reports in the OMC-PMS. Although the OMC-PMS also collects and provides basic functionality for monitoring manual group measurements, these are not required for performing basic analysis. In addition, all the BSS and 5ESS-2000 measurements are available to the user through the Kingsher module which provides the ability to generate customized graphs and reports. Refer to Metrica Ltds Kingsher Users Guide and Kingsher Reference Manual for additional information about that product.
Global Denitions
A BTS can be one or more transceivers all sharing a common Broadcast Channel. Therefore, a typical three sector site can also be referred to as containing three BTSs. Within this document, a cell is the same as a BTS is the same as a sector.
5-2
Issue 1.0
December 1996
There are a few elds that appear often within the reports. These are dened here so as to avoid explaining them multiple times. The denitions of these elds are enclosed in < and > when they appear in the Calculations sections, but they also appear bold and italicized to distinguish them from references made to other entries in the same report which are enclosed in unhighlighted < and >. The eld names and their associated denitions are as follows: <duration> Time interval over which the associated counters were collected. Typically this interval is 15 minutes.
<TCHATTEMPTS>
Number of attempts to seize a TCH. = meanAndDelaySeizTCH.totalNoOfTCHSeiz.
This counter represents the number of TCH/F seizure attempts.
<TCHBLOCKS>
Number of attempts to seize a TCH that is blocked. = meanAndDelaySeizTCH.totalNoOfTCHSeiz * trafcChannCongestTime.fullRate / (<duration> * 60)
Since the BSS measures the amount of time that assignments are blocked, the number of assignment attempts meeting all TCH busy (i.e., blocked) is estimated as the product of the total number of TCH assignment attempts and the percentage of time that the channels were congested. This effectively assumes that all TCH blocks are spread evenly over the 15 minute recording interval.
<TCHSEIZURES>
Number of successful TCH seizures.
LM3
= meanAndDelaySeizTCH.totalNoOfTCHSeiz * (1- trafcChannCongestTime.fullRate / (<duration> * 60))
Note that meanAndDelaySeizTCH.totalNoOfTCHSeiz is the total number of seizure attempts while <TCHSEIZURES> is a count of the number of successful seizures. In LM3 environments , the number of successful seizures is estimated by taking the number of assignment attempts minus the number of blocked assignments. Since there is no TCH assignment queuing in LM3, all blocked assignments are lost and all successful assignments cause the mobile to proceed to seize the channel. Note that this mapping assumes that all mobile seizures are successful, that is, that no mobile fails to seize the channel once the BCE-2000 has assigned it a channel. LM4
= (averageNoSimultCalls.fullRate) * (<duration> * 60) / meanTchHoldingTimeAbis
Because queuing may be enabled in LM4 environments, the number of blocked assignment attempts should not be used to estimate the number of actual TCH seizures since an assignment meeting all TCH busy may, after a delay, result in a successful TCH seizure. Instead, the number of successful seizures is estimated from the total number of seconds that TCHs are active divided by the mean holding time.
Issue 1.0
December 1996
5-3
Daily Operations Reports
These reports are based on the standard raw data produced by the network elements.
Daily Cell TCH Report (DCTTR)
This report shows key cell TCH trafc statistics for a set of cells in a selected time period. The report can be generated for the cell busy hour, a selected hour, for the entire day or for a single measurement interval. Data can be thresholded by % Data Availability, maximum and minimum Trafc, % Blocking and % Dropped Calls and sorted by Trafc, % Blocking or % Dropped Calls.
Report Heading
DAILY CELL TCH TRAFFIC REPORT ON 96/05/01 FOR ALL CELLS (BUSY HOUR VALUES) Min. Max. Min. Min. Max. Min. Traffic (E) Traffic (E) % Blocking % Dropped Calls Mean Holding Time % Data Coverage : : : : : :
Cell Busy Channels ----- TCH Seizures ---Blocking Dropped Traffic MHT Id. Hour Def. Avail. Attempts Blocks Dropped (%) (%) (E) (s) ------------------------------------------------------------------------------------------------
Calculations
Busy Hour Channels Dened Channels Available TCH Seizure Attempts TCH Seizure Blocks TCH Seizures Dropped Blocking Percentage Dropped Percentage Trafc in Erlangs Mean Holding Time The hour segment which has the largest value for TCH trafc based on a 15 minute sliding window. Channels.InstalledTCH / 100 Channels.InServiceTCH / 100
<TCHATTEMPTS> <TCHBLOCKS>
noRadioFreqLosses 100 * <TCHBLOCKS> /<TCHATTEMPTS> 100 * <TCH_Seizures_Dropped> / (<TCH_Seizure_Attempts> - <TCH_Seizure_Blocks>) averageNoSimultCalls.fullRate /100 meanTchHoldingTimeAbis/100
This only includes RF losses. It is not the total number of dropped calls. This column is only available with GSM Release 6.5.
5-4
Issue 1.0
December 1996
Daily Cell SDCCH Report (DCCTR)
This report shows key cell SDCCH trafc statistics for a set of cells in a selected time period. The report can be generated for the cell busy hour (based on cell TCH trafc), a selected hour, for the entire day or for a single measurement interval. Data can be thresholded by % Data Availability, maximum and minimum Trafc, % Blocking and % Dropped Calls and sorted by Trafc, % Blocking or % Dropped Calls.
Report Heading
DAILY CELL SDCCH TRAFFIC REPORT ON 96/05/01 FOR ALL CELLS (BUSY HOUR VALUES)
Min. Max. Min. Min. Max. Min.
Traffic (E) Traffic (E) % Blocking % Dropped Calls Mean Holding Time % Data Coverage
: : : : : :
TCH Cell Busy Channels ---- SDCCH Seizures --- Blocking Dropped Traffic MHT Id. Hour Def. Avail. Attempts Blocks Dropped (%) (%) (E) (s) ----------------------------------------------------------------------------------------------
Calculations
Busy Hour Channels Dened Channels Available SDCCH Seizure Attempts SDCCH Seizure Blocks SDCCH Seizures Dropped Blocking Percentage Dropped Percentage Trafc in Erlangs Mean Holding Time
The hour segment which has the largest value for TCH trafc based on a 15 minute sliding window. Channels.InstalledSDCCH/100 Channels.InServiceSDCCH/100 noAccessSuccessfResultProc.RACH + noIncomInterCellHandover.SDCCH attemptSDCCHSeizMeetAllBusy noRadioFreqLossesSDCCH + <SDCCH_Seizure_Attempts> - <SDCCH_Seizure_Blocks> -noSuccessfSDCCHSeiz 100 *<SDCCH_Seizure_Blocks>/ <SDCCH_Seizure_Attempts> 100 * noRadioFreqLossesSDCCH / noSuccessfSDCCHSeiz occupanGroupSDCCH / 100 (occupanGroupSDCCH / 100) * <duration> * 60 / noSuccessfSDCCHSeiz
This column is only available with GSM Release 6.5
Issue 1.0
December 1996
5-5
Daily Cell Handover Report (DCHOR)
This report shows handover performance for a set of cells. The report is split into three optional parts: cell (i.e., BTS or sector) handover performance, cell handover causes and cell-cell handover. The rst report shows the performance of intra-cell handovers (i.e., intraBTS handovers) and outgoing internal and external inter-cell handovers (i.e., BSC Controlled handovers). The second report shows all the handover causes for BSC Controlled handovers. The third report shows cell to neighbor cell handover performance for BSC Controlled handovers. The reports can be generated for the cell busy hour (based on cell TCH trafc), a selected hour, for the entire day or for a single measurement interval. The rst report can be thresholded by any of the handover attempts and by percent handover failure categories plus minimum data coverage (see Glossary for denition) and sorted by the corresponding handover attempts or percent handover failure. The second report can be thresholded on uplink level, quality, downlink level, quality, power budget, percentage handover attempts plus minimum data coverage and sorted by either the total handover attempts or one of the handover cause categories that can be thresholded. The third report can be thresholded by incoming or outgoing handover attempts, percentage failures and minimum data coverage and sorted by incoming or outgoing handover attempts and percentage failure.
5-6
Issue 1.0
December 1996
Report Heading: cell handover performance

DAILY CELL HANDOVER REPORT ON 96/05/01 FOR ALL CELLS (BUSY HOUR VALUES)
PER CELL HANDOVER SUMMARY Sorting & Thresholding Min. Handover Attempts Min. % Failure Min. Data Coverage on Internal Handover : : :
------- Outgoing Inter-Cell Handover ------------ Intra-cell --------- Internal ---------- External -----Cell Atts. Fails. Failure Atts. Fails. Failure Successful Id. (%) (%) --------------------------------------------------------------------------------------------Busy Hour
Calculations
Busy Hour Intracell Attempts Intracell Failures Intracell Failure Percentage Internal Attempt Internal Failure The hour segment which has the largest value for TCH trafc based on a 15 minute sliding window. noAttIntraCellBssHo.fullRate <Intracell_Attempts> - noSucIntraCellBssHo.fullRate 100 * <Intracell_Failures> / <Intracell_Attempts> noAttOutIntercellBssHo.fullRate + noAttOutIntercellBssHo.SDCCH <Intercell_Incoming_Attempts> - (noSucOutIntercellBssHo.fullRate + noSucOutIntercellBssHo.SDCCH) 100 * <Intercell Failures> / <Intercell Attempts> (noOutgoInterCellHandover.fullRate + noOutgoInterCellHandover.SDCCH) - (noSucOutInterCellBssHo.fullRate + noSucOutInterCellBssHo.SDCCH)
Internal Failure Percentage External Successful
Issue 1.0
December 1996
5-7
Report Heading: cell handover causes

HANDOVER CAUSES SUMMARY Sorting & Thresholding on Uplink Quality Min. % Handover Attempts : Min. Data Coverage :
Uplink Downlink Cell Busy Total Qual. Level Qual. Level Dist. Power Id. Hour HO (%) (%) (%) (%) (%) (%) ------------------------------------------------------------------
Calculations
Busy Hour Total HO The hour segment which has the largest value for TCH trafc based on a 15 minute sliding window. noAttHoByCause.ULqual + noAttHoByCause.ULlevel + noAttHoByCause.DLqual + noAttHoByCause.DLlevel + noAttHoByCause.dist + noAttHoByCause.pwr 100 * noAttHoByCause.ULqual / <Total HO> 100 * noAttHoByCause.ULlevel / <Total HO> 100 * noAttHoByCause.DLqual / <Total HO> 100 * noAttHoByCause.DLlevel / <Total HO> 100 * noAttHoByCause.dist / <Total HO> 100 * noAttHoByCause.pwr / <Total HO>
Uplink Quality % Uplink Level % Downlink Quality % Downlink Level % Distance % Power %
5-8
Issue 1.0
December 1996
Report Heading: cell-cell handover

CELL-CELL DETAILS Sorting & Thresholding Min. Handover Attempts Min. % Failure Min. Data Coverage on Incoming Handovers : : :
Source Target -------- Incoming --------- -------- Outgoing --------Cell Cell Busy Handover Handover Failure Handover Handover Failure Id. Id. Hour Attempts Failures (%) Attempts Failures (%) -------------------------------------------------------------------------------------------------
Calculations
Busy Hour Incoming Attempts Incoming Failures The hour segment which has the largest value for TCH trafc based on a 15 minute sliding window. trFlowAttIncInterCellBssHo.fullRate + trFlowAttIncInterCellBssHo.SDCCH <Incoming_Attempts> - (trFlowSucIncInterCellBssHo.fullRate + trFlowSucIncInterCellBssHo.SDCCH) 100 * <Incoming_Failures> / <Incoming_Attempts> trFlowAttOutInterCellBssHo.fullRate + trFlowAttOutInterCellBssHo.SDCCH <Outgoing_Attempts> - (trFlowSucOutInterCellBssHo.fullRate + trFlowSucOutInterCellBssHo.SDCCH) 100 * <Outgoing_Failures> / <Outgoing_Attempts>
Incoming Failure Percentage Outgoing Attempts Outgoing Failures
Outgoing Failure Percentage
This section of the report is only available with GSM Release 6.5
Issue 1.0
December 1996
5-9
Daily Route Trafc Report (DRTR)
This report (which is only available with GSM Release 6.5) shows key route trafc statistics for either all routes or all routes in a specied region or all routes from a specied MSC or all routes of a certain type during a selected time period. The report can be generated for the route busy hour, a selected hour, for the entire day or for a single measurement interval. Data can be thresholded by trafc, % congestion and minimum data coverage (see Glossary for denition) and sorted by trafc or % congestion. The report can be set to just use incoming trafc, outgoing trafc or bothway trafc.
Report Heading
DAILY ROUTE TRAFFIC REPORT ON 96/08/20 FOR ALL ROUTES (BUSY HOUR VALUES)
Min. Traffic (E) : Min. % Congestion : Min. % Data Coverage : Bothway Traffic Route Route Busy Circuits ASR Congestion Traffic Id. Type Hour Def. Avail. Calls (%) (%) (E) -----------------------------------------------------------------------------------
Calculations
Route Id Route Type Busy Hour Circuits Dened Circuits Available Calls TGCOMP.TGN Incoming, Outgoing, 2-way, or BSSAP. The hour having the greatest value for Bothway trafc which is TGCOMP.BWINCU + TGCOMP.BWOUTU TGCOMP.INSVC + TGCOMP.OOS + TGCOMP.OOSMTCE TGCOMP.INSVC Incoming PSTN: Outgoing PSTN: Bothway PSTN: BSSAP: TGCOMP.ISEIZE; TGCOMP.OSEIZE; TGCOMP.ISEIZE + TGCOMP.OSEIZE; TGCOMP.MATTMPT
Answer Seize Ratio %
Incoming PSTN: 100 * TGCOMP.IANS/TGCOMP.ISEIZE; Outgoing PSTN: 100 * TGCOMP.OANS/TGCOMP.OSEIZE; Bothway PSTN: 100 * (TGCOMP.IANS + TGCOMP.OANS) / (TGCOMP.ISEIZE + TGCOMP.OSEIZE); BSSAP: 100 * TGCOMP.OANS/TGCOMP.MATTMPT Outgoing & BSSAP: 100 * TGCOMP.OVFL / TGCOMP.OATTMPT Incoming: Not Applicable Incoming: Outgoing: Bothways: TGCOMP.BWINCU/100; TGCOMP.BWOUTU/100; (TGCOMP.BWINCU+TGCOMP.BWOUTU)/100
Congestion % Trafc
5-10
Issue 1.0
December 1996
Daily Linkset Availability Report (DLSAR)
This report (which is only available with GSM Release 6.5) shows the availability of a set of linksets. It shows the % availability of the linkset, the unavailable duration, the number of link failures and the total link unavailability of the constituent links. The report can be generated for a selected hour, for the entire day or for a single measurement interval. Data can be thresholded by linkset unavailability, total link failures and minimum data coverage (see Glossary for denition) and sorted by linkset unavailability or total link failures.
Report Heading
DAILY LINKSET AVAILABILITY REPORT ON 96/08/20 FOR ALL LINKSETS (DAILY TOTALS/AVERAGES)
Min. Linkset Unavailability (s) : Min. Total Link Failures : Min. % Data Coverage :
Linkset Linkset Link Links Linkset In-Service Unavailable Failures Unavailable Id. Links (%) (s) (s) ----------------------------------------------------------------------------------------------
Calculations
Links % Linkset In-Service Linkset Unavailable Link Failures Links Unavailable Number of links making up the Linkset 100 * (1 - SLSCOMP.DSLS/<duration>) SLSCOMP.DSLS Sum of SLCOMP.SFAR of links in linkset. Sum of SLCOMP.DSLU of links in linkset.
Issue 1.0
December 1996
5-11
Daily BH Linkset Utilization Report (DLSUR)
This report (which is only available with GSM Release 6.5) shows the utilization of a set of linksets through the trafc carried on their constituent links. The report shows for both TX and RX trafc, the busy hour, the number of MSUs sent and /or received, the number of SIF/SIO octets sent and/or received, the Erlang occupancy of the entire linkset and the calculated usage of each link. The report is only generated for the linkset TX & RX busy hours. Data can be thresholded by TX linkset usage, RX link usage and minimum data coverage (see Glossary for denition) and sorted by TX linkset usage or RX linkset usage.
Report Heading
DAILY LINKSET UTILISATION REPORT ON 96/08/20 FOR ALL LINKSETS (TX/RX BUSY HOURS)
Min. TX Usage (E) : Min. RX Usage (E) : Min. % Data Coverage : -------------- TX ----------------------------- RX ---------------Linkset Busy MSUS SIF/ Usage Link Busy MSUS SIF/ Usage Link Id. Links Hour SIO (E) Avg. Hour SIO (E) Avg. -----------------------------------------------------------------------------------------------------------
Calculations
Links TX Busy Hour TX MSUS TX SIF/SIO Octets TX Usage TX Average per Link RX Busy Hour RX MSUS RX SIF/SIO Octets RX Usage RX Average per Link Number of links in the Linkset The busy hour of the TX linkset calculated from the aggregated trafc on all constituent links SUM of (SLCOMP.MSUX + SLCOMP.MRTR) for all links in linkset SLCOMP.NSFX for all links in linkset. 8 * (SLCOMP.NSFX+(6 *<TX MSUS>)) / (Interval * data rate) aggregated over all links in linkset Average of <TX Usage> for all links in linkset The busy hour of the RX linkset calculated from the aggregated trafc on all constituent links SUM of SLCOMP.MSUR for all links in linkset Sum of SLCOMP.DSLU of links in linkset. 8 * (SLCOMP.NSFX+(6 *<RX MSUS>)) / (Interval * data rate) aggregated over all links in linkset Average of <RX Usage> for all links in linkset
5-12
Issue 1.0
December 1996
Daily MSC Trafc Report (DMTR)
This report (which is only available with GSM Release 6.5) shows key switched trafc statistics for a single MSC or all MSCs in a region or all MSCs in the network during a selected time period. The report is in two parts. Part one is the Summary Switched Trafc, and part two is the Detailed Trafc by Type. The report can be generated for the switch busy hour, a selected hour, for the entire day or for a single measurement interval. Data can be thresholded by minimum data coverage (see Glossary for denition) and sorted by trafc or % failure.
Report Heading Part 1: Summary Switched Trafc

DAILY MSC SWITCHED TRAFFIC REPORT ON 96/08/20 FOR ALL MSC (BUSY HOUR VALUES) Min. % Data Coverage : SUMMARY SWITCHED TRAFFIC MSC Busy Attempts Calls Failures Failure Answered Answered Traffic Id. Hour (%) (%) (E) --------------------------------------------------------------------------------
Calculations
Busy Hour The busy hour of the switch is the hour having the maximum average value of TRAFFLOW.USAGE/100 summed for selected switch trafc categories. Sum of TRAFFLOW.ATTMPTS for selected switched categories. Sum of TRAFFLOW.SEIZE for selected switched categories Sum of (TRAFFLOW.ADMIN + TRAFFLOW.ERROR + TRAFFLOW.EXFLT+ TRAFFLOW.EXRES + TRAFFLOW.BUSY + TRAFFLOW.LOS + TRAFFLOW.NOCKT + TRAFFLOW.BSN + TRAFFLOW.BEHAV + TRAFFLOW.PDA + TRAFFLOW.PDTO + TRAFFLOW.SNAL + TRAFFLOW.UNAL + TRAFFLOW.TRAN) for selected switched categories 100 * (<Switched Failures> / <Switched Calls>) Sum of TRAFFLOW.ANS for selected switched categories 100 * (<Switched Answered> / <Switched Calls> ) Sum of TRAFFLOW.USAGE/100 for selected switched categories
Switched Attempts Switched Calls Switched Failures
Switched Failure % Switched Answered Switched Answered % Switched Trafc
The selected switched categories are: INC-OUT: Incoming Outgoing INC-TERM: Incoming Terminating ORIG-OUT: Originating Outgoing ORIG-TERM: Originating Terminating, also called Internal
Issue 1.0
December 1996
5-13
Report Heading Part 2: Detailed Trafc by Type

DETAILED TRAFFIC BY TYPE
MSC Busy Traffic Attempts Calls Failures Failure Answered Answered Traffic Id. Hour Type (%) (%) (E) ---------------------------------------------------------------------------------------------------
Calculations
Busy Hour The busy hour of the switch is the hour having the maximum average value of TRAFFLOW.USAGE/100 summed for selected switch trafc categories. Incoming, Outgoing or 2-way Sum of TRAFFLOW.ATTMPTS for selected switched categories. Sum of TRAFFLOW.SEIZE for selected switched categories Sum of (TRAFFLOW.ADMIN + TRAFFLOW.ERROR + TRAFFLOW.EXFLT+ TRAFFLOW.EXRES + TRAFFLOW.BUSY + TRAFFLOW.LOS + TRAFFLOW.NOCKT + TRAFFLOW.BSN + TRAFFLOW.BEHAV + TRAFFLOW.PDA + TRAFFLOW.PDTO + TRAFFLOW.SNAL + TRAFFLOW.UNAL + TRAFFLOW.TRAN) for selected switched categories 100 * (< Failures> / < Calls>) Sum of TRAFFLOW.ANS for selected switched categories 100 * (< Answered> / <Calls>) Sum of TRAFFLOW.USAGE/100 for selected switched categories
Trafc Type Attempts Calls Failures
Failure % Answered Answered % Trafc
The selected switched categories are: INC-OUT: Incoming Outgoing INC-TERM: Incoming Terminating ORIG-OUT: Originating Outgoing ORIG-TERM: Originating Terminating, also called Internal
5-14
Issue 1.0
December 1996
Daily MSC Handover Report (DMHOR)
This report (which is only available with GSM Release 6.5) shows handover performance at the MSC level for either all MSCs in a region or all MSCs in the network during a selected time period. The report shows intra-MSC handover attempts and failures, in addition to incoming and outgoing inter-MSC handover attempts and failures. The report can be generated for the switch busy hour, a selected hour, for the entire day or for a single measurement interval. Data can be thresholded by minimum data coverage (see Glossary for denition) and sorted by % failure.
Report Heading
DAILY MSC HANDOVER REPORT ON 96/08/20 FOR ALL MSC (BUSY HOUR VALUES)
Min. % Data Coverage : ----------------- Inter-MSC --------------------- Inter-cell --------- Incoming ---------- Outgoing -----MSC Busy Atts. Fails. Failure Atts. Fails. Failure Atts. Fails. Failure Id. Hour (%) (%) (%) ---------------------------------------------------------------------------------------
Calculations
Busy Hour
The busy hour of the switch is the hour having the maximum average value of TRAFFLOW.USAGE summed for all switch trafc categories. WRLSSUM.ITERHOAT + WRLSSUM.ITRAHOAT (WRLSSUM.ITERHOAT + WRLSSUM.ITRAHOAT) (WRLSSUM.ITERHOCO + WRLSSUM.ITRAHOCO) <Inter-cell Failures> / <Inter-cell Attempts> WRLSSUM.HOREQT WRLSSUM.HOREQT - WRLSSUM.HOCOMT <Incoming Failures> / <Incoming Attempts> WRLSSUM.HOREQI WRLSSUM.HOREQI - WRLSSUM.HOCOMI <Outgoing Failures> /<Outgoing Attempts>
Inter-cell Attempts Inter-cell Failures Inter-cell % Failures Incoming Attempts Incoming Failures Incoming % Failures Outgoing Attempts Outgoing Failures Outgoing % Failures
Issue 1.0
December 1996
5-15
Daily Network Availability Report (DCAR)
This report attempts to show cell availability information for a number of cells for a single day. One type of outage is distinguished: cell down outage which is derived from the number of 15-minute measurement results received about the cell. It is assumed that a missing report implies that the cell is down. The report is always generated for the entire day. Data can be thresholded by % TCH availability and data coverage and sorted by % TCH availability.
Report Heading
DAILY CELL AVAILABILITY REPORT ON 96/05/01 FOR ALL CELLS
Max. % TCH Availability Max. % Data Coverage :
------------ Cell TCH ------------Cell Average Average Avail. Total Id. Defined Avail. (%) Incidents --------------------------------------------------------------
Calculations
TCH Average Dened TCH Average Available TCH Available Percentage TCH Total Incidents daily_average(Channels.InstalledTCH / 100) daily_average(Channels.InServiceTCH / 100) daily_average(100 * Channels.InServiceTCH / Channels.InstalledTCH) The number of times that the value of Channels.InServiceTCH (i.e., available TCHs) has decreased during the day. Each decrease is identied as an incident but there can only be one incident per 15 minute interval.
Historical (or Summary) Reports
All these reports are based on aggregate data. That is, they contain data that is produced by the OMC-PMS by adding network element measurements into daily, weekly or monthly totals.
5-16
Issue 1.0
December 1996
Summary Cell TCH Trafc Report (SCTTR)
This report shows key cell TCH trafc statistics for a set of cells in a selected time period. The report can be generated for the daily, weekly or monthly cell busy hour or for the period total. Data can be thresholded by minimum and maximum Trafc, % Blocking, % Dropped Calls, % Utilization, grade of service and % Data Availability and sorted by Trafc, % Blocking, % Dropped Calls, % Utilization or grade of service.
Report Heading
SUMMARY CELL TCH TRAFFIC REPORT DAY OF 96/08/19 FOR ALL CELLS (BUSY HOUR VALUES)
Min. Max. Min. Min. Min. Min. Min. Max.
Traffic (E) : Traffic (E) : % Blocking : % Dropped Calls : % Utilisation : % Data Coverage : Grade of Service : Mean Holding Time:
Erlang B (GOS=0.01)
Cell Busy Channels Blocking Dropped Traffic Util. GOS MHT Id. Hour Def. Avail. Attempts (%) (%) (E) (%) (s) --------------------------------------------------------------------------------------------
Calculations
Channels Dened Channels Available Attempts Blocking Percentage Dropped Percentage Trafc in Erlangs Utilization Percentage Grade of Service Mean Holding Time Busy hour value or average of Channels.InstalledTCH / 100 Busy hour value or average of Channels.InServiceTCH / 100 Busy hour value or total of <TCHATTEMPTS> Busy hour value or average of 100 * <TCHBLOCKS> / <TCHATTEMPTS> Busy hour value or average of 100 * noRadioFreqLosses /<TCHSEIZURES> Busy hour value or total of averageNoSimultCalls.fullRate / 100 Busy hour value of the utilization calculated as the offered trafc as a percentage of the critical trafc level. Busy hour value of the grade of service calculated from the offered trafc and Channels.InServiceTCH . Busy Hour Value of MeanTchHoldingTimeAbis/100
Issue 1.0
December 1996
5-17
Summary Cell SDCCH Trafc Report (SCCTR)
This report shows key cell SDCCH trafc statistics for a set of cells in a selected time period. The report can be generated for the daily, weekly or monthly cell busy hour or for the period total. Data can be thresholded by Trafc, % Blocking, % Dropped and % Data Availability and sorted by Trafc, % Blocking or % Dropped Calls.
Report Heading
SUMMARY CELL SDCCH TRAFFIC REPORT DAY OF 96/08/19 FOR ALL CELLS (BUSY HOUR VALUES)
Min. Max. Min. Min. Min.
Traffic (E) Traffic (E) % Blocking % Dropped Calls % Data Coverage
: : : : :
TCH Cell Busy Channels Blocking Dropped Traffic Id. Hour Def. Avail. Attempts (%) (%) (E) -----------------------------------------------------------------------
Calculations
Busy Hour Channels Dened Channels Available Attempts Hour with the maximum average value of TCH trafc. Busy hour value or average of Channels.InstalledSDCCH/100 Busy hour value or average of Channels.InServiceSDCCH/100 Busy hour value or total of noAccessSuccessfResultProc.RACH + noIncomInterCellHandover.SDCCH Busy hour value or average of 100 * attemptSDCCHSeizMeetAllBusy / <Attempts> Busy hour value or average of: 100 * noRadioFreqLossesSDCCH /noSuccessfSDCCHSeiz Busy hour value or total of: occupanGroupSDCCH /100
Blocking Percentage Dropped Percentage Trafc
5-18
Issue 1.0
December 1996
Summary Cell Handover Report (SCHOR)
This report shows handover performance for a set of cells. The report is split into three optional parts: cell handover performance, cell handover causes and cellcell handover. The rst report shows the performance of intra-cell handover and outgoing internal and external inter-cell handover. The second report shows all the handover causes. The third report shows cell to neighbor cell handover performance. The rst and third reports can be generated for the daily, weekly or monthly cell busy hour (based on cell TCH trafc) or for the period total. The second report can only be generated for the period total. The rst report data can be thresholded by any of the handover attempts and by % handover failure categories plus minimum data coverage and sorted by the corresponding handover attempts or % handover failure. The second report can be thresholded on uplink level, quality, downlink level, quality, power budget, percentage handover attempts plus minimum data coverage and sorted by either the total handover attempts or one of the handover cause categories that can be thresholded. The third report can be thresholded by incoming or outgoing handover attempts, percentage failures and minimum data coverage and sorted by incoming or outgoing handover attempts and percentage failure.
Issue 1.0
December 1996
5-19
Report Heading: cell handover performance

CELL HANDOVER REPORT SUMMARY ON 96/05/01 FOR ALL CELLS (BUSY HOUR VALUES)
PER CELL HANDOVER SUMMARY Sorting & Thresholding Min. Handover Attempts Min. % Failure Min. Data Coverage on Internal Handover : : :
------- Outgoing Inter-Cell Handover ------------ Intra-cell --------- Internal ---------- External -----Cell Atts. Fails. Failure Atts. Fails. Failure Successful Id. (%) (%) --------------------------------------------------------------------------------------------Busy Hour
Calculations:
Busy Hour Intracell Attempts Intracell Failures Intracell Failure Percentage Internal Attempts The hour segment which has the largest value for TCH trafc based on a 15 minute sliding window. Busy hour value or total of: noAttIntraCellBssHo.fullRate Busy hour value or total of: <Intracell_Attempts> - noSucIntraCellBssHo.fullRate Busy hour value or average of: 100 * <Intracell_Failures> / (<Intracell_Attempts>) Busy hour value or total of: noAttOutIntercellBssHo.fullRate + noAttOutIntercellBssHo.SDCCH Busy hour value or total of: <Internal_Attempts> - (noSucOutIntercellBssHo.fullRate + noSucOutIntercellBssHo.SDCCH) Busy hour value or average of: 100 * <Internal Failures> / <Internal Attempts> Busy hour value or total of: (noOutgoInterCellHandover.fullRate + noOutgoInterCellHandover.SDCCH) - (noSucOutInterCellBssHo.fullRate + noSucOutInterCellBssHo.SDCCH)
Internal Failures
Internal Failure Percentage External Successful
5-20
Issue 1.0
December 1996
Report Heading: cell handover causes

HANDOVER CAUSES SUMMARY Sorting & Thresholding on Uplink Quality Min. % Handover Attempts : Min. Data Coverage :
Uplink Downlink Cell Busy Total Qual. Level Qual. Level Dist. Power Id. Hour HO (%) (%) (%) (%) (%) (%) ------------------------------------------------------------------
Calculations:
The values for the elds below represent the total values for the day, week or month depending on what was requested. Note that busy hour values are not available on this report. Busy Hour Total HO The hour segment which has the largest value for TCH trafc based on a 15 minute sliding window. noAttHoByCause.ULqual + noAttHoByCause.ULlevel + noAttHoByCause.DLqual + noAttHoByCause.DLlevel + noAttHoByCause.dist + noAttHoByCause.pwr 100 * noAttHoByCause.ULqual/ <Total HO> 100 * noAttHoByCause.ULlevel / <Total HO> 100 * noAttHoByCause.DLqual / <Total HO> 100 * noAttHoByCause.DLlevel/ <Total HO> 100 * noAttHoByCause.dist / <Total HO> 100 * noAttHoByCause.pwr / <Total HO>
Uplink Quality % Uplink Level % Downlink Quality % Downlink Level % Distance % Power %
Issue 1.0
December 1996
5-21
Report Heading: cell-cell handover
CELL-CELL DETAILS Sorting & Thresholding Min. Handover Attempts Min. % Failure Min. Data Coverage on Incoming Handovers : : :
Source Target -------- Incoming --------- -------- Outgoing --------Cell Cell Busy Handover Handover Failure Handover Handover Failure Id. Id. Hour Attempts Failures (%) Attempts Failures (%) -------------------------------------------------------------------------------------------------
Calculations:
Busy Hour Incoming Attempts The hour segment which has the largest value for TCH trafc based on a 15 minute sliding window. Busy hour value of or total of trFlowAttIncInterCellBssHo.fullRate + trFlowAttIncInterCellBssHo.SDCCH Busy hour value of or total of (trFlowAttIncInterCellBssHo.fullRate + trFlowAttIncInterCellBssHo.SDCCH) - (trFlowSucIncInterCellBssHo.fullRate + trFlowSucIncInterCellBssHo.SDCCH) Busy hour value of or average of 100 * <Incoming_Failures> / (<Incoming_Attempts> Busy hour value of or total of trFlowAttOutInterCellBssHo.fullRate + trFlowAttOutInterCellBssHo.SDCCH Busy hour value of or total of (trFlowAttOutInterCellBssHo.fullRate + trFlowAttOutInterCellBssHo.SDCCH) - (trFlowSucOutInterCellBssHo.fullRate + trFlowSucOutInterCellBssHo.SDCCH) Busy hour value of or average of 100 * <Outgoing_Failures> / (<Outgoing_Attempts>
Incoming Failures
Incoming Failure Percentage Outgoing Attempts
Outgoing Failures
Outgoing Failure Percentage
5-22
Issue 1.0
December 1996
Summary BSS Cell TCH Trafc Report (SBTR)
This report shows key cell TCH trafc statistics aggregated over a BSS in a selected time period. The report can be generated for the daily, weekly or monthly BSS or system busy hour. Data can be thresholded by Trafc, % Blocking, % Dropped Calls and % Data Availability and sorted by Trafc, % Blocking or % Dropped Calls.
Report Heading
SUMMARY BSS CELL TCH TRAFFIC REPORT DAY OF 96/08/19 FOR ALL BSC (BUSY HOUR VALUES)
Min. Min. Min. Min.
Traffic (E) % Blocking % Dropped Calls % Data Coverage
: : : :
BSC Busy Channels Blocking Dropped Traffic Id. Hour Def. Avail. Attempts (%) (%) (E) ------------------------------------------------------------------------
Calculations
Channels Dened Channels Available Attempts Blocking Percentage Dropped Percentage Busy hour value of (Channels.InstalledTCH /100) totalled for all cells in the BSS Busy hour value of (Channels.InServiceTCH /100) totalled for all cells in the BSS. Busy hour value of <TCHATTEMPTS> totalled for all cells in the BSS. Busy hour value of 100 * <TCHBLOCK> / <TCHATTEMPT> averaged for all cells in the BSS. Busy hour value of 100 * noRadioFreqLosses / <TCHSEIZURE> averaged for all cells in the BSS. Busy hour value of averageNoSimultCalls.fullRate / 100 totalled for all cells in the BSS.
Trafc
Summary Route Trafc Report (SRTR)
This report (which is only available with GSM Release 6.5) shows key route trafc statistics for either all routes or all routes in a region or all routes from a specied MSC or all routes of a certain type during a selected time period. The report can be generated for the daily, weekly or monthly route busy hour, node busy hour or system busy hour. Data can be thresholded by trafc, % congestion, % utilization % data coverage and sorted by trafc, % congestion, % utilization or grade of
Issue 1.0
December 1996
5-23
service. The report can be set to just use incoming trafc, outgoing trafc or bothway trafc.
Report Heading
SUMMARY ROUTE TRAFFIC REPORT DAY OF 96/08/19 FOR ALL ROUTES (BUSY HOUR VALUES)
Min. Min. Min. Min. Min.
Traffic (E) % Congestion % Utilisation % Data Coverage Grade of Service
: : : : : Bothway Traffic
Erlang B (GOS=0.008)
Route Route Busy Circuits ASR Congestion Traffic Util. GOS Id. Type Hour Def. Avail. Calls (%) (%) (E) (%) -------------------------------------------------------------------------------------------------
Calculations
Busy Hour Circuits Dened Circuits Available Calls The hour having the greatest value for Bothway trafc which is TGCOMP.BWINCU + TGCOMP.BWOUTU Busy Hour value of TGCOMP.INSVC + TGCOMP.OOS + TGCOMP.OOSMTCE Busy Hour value of TGCOMP.INSVC Busy Hour value of trunk seizures. Incoming PSTN: TGCOMP.ISEIZE; Outgoing PSTN: TGCOMP.OSEIZE; Bothway PSTN: TGCOMP.ISEIZE + TGCOMP.OSEIZE; BSSAP: TGCOMP.MATTMPT Busy Hour value for: Incoming PSTN: 100 * TGCOMP.IANS/TGCOMP.ISEIZE; Outgoing PSTN: 100 *TGCOMP.OANS/TGCOMP.OSEIZE; Bothway PSTN: 100 * (TGCOMP.IANS + TGCOMP.OANS) / (TGCOMP.ISEIZE + TGCOMP.OSEIZE); BSSAP: 100 * TGCOMP.OANS/TGCOMP.MATTMPT Busy Hour value for: Outgoing & BSSAP: 100 * TGCOMP.OVFL / TGCOMP.OATTMPT Busy Hour value for: Incoming: TGCOMP.BWINCU/100; Outgoing: TGCOMP.BWOUTU/100; Bothways: (TGCOMP.BWINCU+TGCOMP.BWOUTU)/100 The busy hour value of the utilization calculated as the offered trafc as a percentage of the capacity. The busy hour value of the grade of service calculated from the offered trafc and the number of circuits.
Answer Seize Ratio %
Congestion % Trafc
Utilization % GOS
5-24
Issue 1.0
December 1996
Summary Linkset Availability Report (SLSAR)
This report (which is only available with GSM Release 6.5) shows the availability of a set of linksets, and it shows the number of failures and the time that the constituent links are unavailable during the time period. The report can be generated only for daily, weekly or monthly period totals/averages. Data can be thresholded by linkset unavailability, total link failures and minimum data coverage and sorted by linkset unavailability or total link failures.
Report Heading
SUMMARY LINKSET AVAILABILITY REPORT DAY OF 96/08/19 FOR ALL LINKSETS (DAILY TOTAL)
Min. Linkset Unavailability (s) : Min. Total Link Failures : Min. % Data Coverage :
Linkset Linkset Link Links Linkset In-Service Unavailable Failures Unavailable Id. Links (%) (s) (s) ----------------------------------------------------------------------------------------------
Calculations
Links % Linkset In-Service Linkset Unavailable Link Failures Links Unavailable Number of links making up the Linkset 100 * (1 - SLSCOMP.DSLS/<duration>) SLSCOMP.DSLS Sum of SLCOMP.SFAR of links in linkset. Sum of SLCOMP.DSLU of links in linkset.
Issue 1.0
December 1996
5-25
Summary BH Linkset Utilization Report (SLSUR)5

This report (which is only available with GSM Release 6.5) shows the utilization of a set of linksets through the trafc carried on their constituent links. The report is only generated for the linkset TX & RX busy hours. Data can be thresholded by TX linkset usage, RX link usage and minimum data coverage and sorted by TX linkset usage or RX linkset usage.
Report Heading
SUMMARY LINKSET UTILISATION REPORT DAY OF 96/08/19 FOR ALL LINKSETS (BUSY HOUR)
Min. TX Usage (E) : Min. RX Usage (E) : Min. % Data Coverage : -------------- TX ----------------------------- RX ---------------Linkset Busy MSUS SIF/ Usage Link Busy MSUS SIF/ Usage Link Id. Links Hour SIO (E) Avg. Hour SIO (E) Avg. -----------------------------------------------------------------------------------------------------------
Calculations
Links TX Busy Hour TX MSUS TX SIF/SIO Octets TX Usage TX Average per Link RX Busy Hour RX MSUS RX SIF/SIO Octets RX Usage RX Average per Link Number of links in the Linkset. The busy hour of the TX linkset calculated from the aggregated trafc on all constituent links. The TX Busy Hour value of the SUM of (SLCOMP.MSUX + SLCOMP.MRTR) for all links in linkset. The TX Busy Hour value of SLCOMP.NSFX for all links in linkset. The TX Busy Hour value of (aggregated over all links in linkset) 8 * (SLCOMP.NSFX+(6 *<TX MSUS>)) / (Interval * data rate) The TX Busy Hour value of the Average of <TX Usage> for all links in linkset. The busy hour of the RX linkset calculated from the aggregated trafc on all constituent link The RX Busy Hour value of the SUM of SLCOMP.MSUR for all links in linkset. The RX Busy Hour value of SLCOMP.NSFR for all links in linkset. The RX Busy Hour value of (aggregated over all links in linkset) 8 * (SLCOMP.NSFX+(6 *<RX MSUS>)) / (Interval * data rate) The RX Busy Hour value of Average of <RX Usage> for all links in linkset.
5-26
Issue 1.0
December 1996
Summary MSC Trafc Report (SMTR)
This report (which is only available with GSM Release 6.5) shows key switched trafc statistics for a single MSC or all MSCs in the network during a selected time period. The report is in two parts: a summary part and a detailed part. The report can be generated for the daily, weekly and monthly MSC or system busy hour or the period total. Data can be thresholded by % data coverage and sorted by trafc or % failure. Please refer to the Daily MSC Trafc Report (DMTR) for the Report Heading of SMTR. They are effectively identical in format.
Summary MSC Handover Report (SMHOR)
This report (which is only available with GSM Release 6.5) shows handover performance at the MSC level for either all MSCs in a region or all MSCs in the network during a selected time period. The report can be generated for the daily, weekly or monthly MSC or system busy hour or the period total. Data can be thresholded by % data coverage and sorted by % failure. Please refer to the Daily MSC Handover Report (DMHOR) for the Example Report Heading of SMHOR. They are effectively identical in format.
Issue 1.0
December 1996
5-27
Forecasting Reports
Forecasting Reports/Graphs make trafc projections. That is, a service provider can use these reports/graphs to anticipate when different parts of its network may exhaust giving them adequate time to plan and build out their network. These Forecasting Reports are based on weekly aggregate data like that presented in the Summary Reports. That is, they are not based in any way on marketing data nor do they take into consideration any growth that is already planned, rather they are driven from the data that is passed from the OMC to the OMC-PMS which reects actual trafc carried by the network.
The decisions a user makes in generating the Forecasts are as follows: 1. 2. 3. Select a Grade of Service (often 2%), Decide which Trafc Model should be used. Select which view of past data should be used in producing the forecasts. Also decide if rather than using the raw data (called Carried Trafc), the more desirable Offered Trafc should be used. Select a regression technique for extrapolating into the future.
4.
Selecting the Way to View the Past
The OMC-PMS system gives the user the ability to select different subsets of the OMC-PMS data each time he/she wishes to generate a Forecast. Each subset of data can result in the OMC-PMS generating a different output, a different Forecast. Therefore the user must select one of the alternative views of the data. The view choices are:
s
Busy Day Busy Hour: The user can select the data associated with the day and time of the busiest hour of the week or month. (The title of this entry could be thought of as Busy Hour of the Week/Month since the desired hour is the busiest hour during the interval whether that interval be a day, a week or a month). This means that data from all other times of the day, week and month are ignored in generating the Forecast. 3-DAV & 5-DAV: The user can also select data based on either the three day average trafc or the ve day average trafc. 3-DAV and 5-DAV are measures of trafc that attempt to avoid some of the unusual trafc peaks by basing the parameter on the weekly average busy hour rather than just a daily busy hour. That is, it should ideally represent the peak trafc carried under normal conditions. The value is calculated as follows: 1. The trafc is computed for each hour and each day of the week. 2. The average for each hour over the seven days is computed. The hour of the day over the seven days that has the highest average is picked as the busy hour. For example, if the hour between 8:15 am and 9:15 am has the highest average usage of any hour during the whole week, then it is picked as the busy hour.
5-28
Issue 1.0
December 1996
3. The three largest values of the seven values for the busy hour selected in step 2 are then averaged to yield the 3-DAV. Similarly, the ve largest values of the seven values for the busy hour selected in step 2 are also averaged to yield the 5-DAV. The recommended view is the 3-DAV. The term Carried Trafc is used to dene the trafc that is based on the the view of the past utilizing only actual historical data. There is an alternative view of past trafc called Offered Trafc that is computed from the Carried Trafc, the number of dened channels and the Trafc Model,. Offered Trafc is dened in the next section.
Selecting a Trafc Model and the Type of Trafc
Grade of Service, Channels Dened and Blocking are interrelated such that, utilizing a trafc model, given two of them, the third can be determined. In addition, there are different Trafc Models that can be used in determining the third variable.
s
The two Trafc Model choices provided by the OMC-PMS for dealing with cells are the Erlang B and the Erlang C tables. For cells, Erlang B is recommended unless queued TCH assignments are enabled (available in LM4) in which case Erlang C could be used. When in doubt, use Erlang B. For Routes and Trunks the two choices are Erlang B and TC4. Erlang B should be used unless a more conservative approach is required in overload conditions in which case TC4 (denition of TC4 can be found in the Glossary) could be used.
Each time the user executes the OMC-PMS to generate a Forecast Report/ Graph, he/she rst has to select one of the Trafc Models. The OMC-PMS uses this selection in determining the Critical Trafc as well as the Offered Trafc.
s
Critical Trafc is the number of Erlangs identied by the Trafc Model when given the dened number of circuits and the desired Grade of Service. When Carried Trafc exceeds Critical Trafc, the blocking in the network element will exceed the desired Grade of Service. At this point, the network will need to grow to reclaim the desired Grade of Service.
The user must decide if the Carried Trafc or the Offered Trafc is to be used as the basis for generating the Forecasts Reports/Graphs.
s
Carried Trafc is the actual amount of trafc carried. It corresponds directly to the values in the data base.
At this time, the general belief is that the TC4 Trafc Model does not yield as usable a result as the other techniques. Therefore, we recommend that TC4 not be used at this time.
Issue 1.0
December 1996
5-29
Offered Trafc is the amount of trafc that the resource would have carried if no blocking had been experienced.Offered Trafc is preferred over Carried Trafc since it represents the trafc actually presented to the system.
Offered Trafcis determined from the Carried Trafc and the Channels Dened using one of the Trafc Models. For example (using the Erlang B tables), if the number of dened channels is 7, and the Carried Trafc is 4.0 Erlangs, then the Offered Trafc is 4.357 Erlangs. This relationship is more easily understood by looking at it in reverse, that is by determining the Carried Trafc from the Offered Trafc. Using the Erlang B tables, a resource consisting of 7 members that experiences an offered load of 4.357 Erlangs, will encounter a blocking rate of 8.198%. Since the Carried Trafc is the Offered Trafc minus what is blocked, the Carried Trafc = (100% - 8.198%) * 4.357 Erlangs = 4.00 Erlangs.
Selecting the Regression Technique for Extrapolating into the Future
The choices for extrapolating into the future are based on the following regression techniques:
s s s
Linear Regression Exponential Regression Logarithmic Regression
Not all Reports/Graphs can necessarily use all of the regression techniques. The OMC-PMS allows the user to select one and only one entry at a time from the list of valid regression techniques prior to generating a Forecast Report or Graph. Normally, each regression technique produces a different output. One main output of any Report/Graph generation is the Correlation Coefcient. This Correlation Coefcient gives an indication of how good the trafc projection is. If the absolute value of this Coefcient is not at least 0.8, then the results should not be used. An absolute value of the Correlation Coefcient below 0.8 indicates that there is insufcient data to make a good projection. The higher the absolute value of the Correlation Coefcient, the better the projection. Therefore, it is best for the user to run all of the possible regressions and to select the one with the greatest absolute value of the Correlation Coefcient. Over time, the user will discover which regression technique yields the best results so that all techniques will not need to be run all of the time.
Real Offered Trafc is not considered since it often has some anomalies in it (e.g., spikes due to increased trafc when an automobile trafc accident occurs). The Correlation Coefcient has a range of -1.0 to +1.0. The worst value is zero which means there is no correlation. A value of +1.0 and -1.0 indicate the highest possible correlation between the inputted data and the projection. Positive values result when there is growth (i.e., the values are increasing), whereas negative value indicate decreasing needs.
5-30
Issue 1.0
December 1996
Forecasting Cell TCH Summary Report (FCTR)
This report shows key cell TCH trafc statistics for a set of cells in a selected time period. The report is always generated with weekly busy hour values. Strictly speaking, this is not a true Forecast since it does not include any projections into the future.
Report Heading
SUMMARY CELL TCH TRAFFIC REPORT WEEK OF 96/08/05 FOR ALL CELLS
Traffic (E) Lost Traffic (E) % Utilisation % Data Coverage Grade of Service
: : : : :
Erlang B (GOS=0.01)
Cell ---- BDBH ---Channels Blocking --------- BDBH ---------- -- Weekly -- Util. GOS Id. Day Hour Def. Avail. (%) Carr. Offer Lost Crit. 3-DAV 5-DAV (%) ---------------------------------------------------------------------------------------------------------
Calculations
Channels Dened Channels Available Blocking % Carried Trafc Offered Trafc Busy hour value of (Channels.InstalledTCH /100) Busy hour value of (Channels.InServiceTCH /100) Busy hour value of 100 * <TCHBLOCKS> / <TCHATTEMPTS> Busy hour value of averageNoSimultCalls.fullRate /100 Busy hour value of the offered trafc calculated from <Carried_Trafc> and <Channels_Available> using either the Erlang-B or the Erlang-C Trafc Model. <Offered_Trafc> - <Carried_Trafc> Busy hour value of the critical trafc level calculated from the design Grade of Service and <Channels_Available> using either the Erlang-B or the Erlang-C Trafc Model. The weekly three day average of <Carried_Trafc>. The weekly ve day average of <Carried_Trafc>. Busy hour value of 100 * <Offered_Trafc>/<Critical_Trafc>. Busy hour value of the grade of service calculated from <Offered_Trafc> and <Channels_Available> using either the Erlang-B or the Erlang-C Trafc Model.
Lost Trafc Critical Trafc
3-DAV Trafc 5-DAV Trafc Utilization % GOS (Grade of Service)
Issue 1.0
December 1996
5-31
Forecasting Cell TCH Historical Report (FCTHR) 5

This report shows key cell TCH trafc statistics for a single cell over all the weeks in the forecast base range. The report is always generated with weekly busy hour values. Strictly speaking, this is not a true Forecast since it does not include any projections into the future.
Report Heading
HISTORICAL CELL TCH TRAFFIC REPORT FOR CELL CI-0005421280 FROM WEEK OF 96/04/21 TO 96/08/19
Min. % Data Coverage
Erlang B (GOS=0.01)
Week ---- BDBH ---Channels Blocking --------- BDBH ---------- -- Weekly -- Util. GOS Of Day Hour Def. Avail. (%) Carr. Offer Lost Crit. 3-DAV 5-DAV (%) ---------------------------------------------------------------------------------------------------
Calculations
Channels Dened Channels Available Blocking Percentage Carried Trafc Offered Trafc Busy hour value of (Channels.InstalledTCH /100) Busy hour value of (Channels.InServiceTCH /100) Busy hour value of 100 * <TCHBLOCKS> / <TCHATTEMPTS> Busy hour value of averageNoSimultCalls.fullRate /100 Busy hour value of the offered trafc calculated from <Carried_Trafc> and <Channels_Available> using either the Erlang-B or the Erlang-C Trafc Model. <Offered_Trafc> - <Carried_Trafc> Busy hour value of the critical trafc level calculated from the design Grade of Service and <Channels_Available> using either the Erlang-B or the Erlang-C Trafc Model. The weekly three day average of <Carried_Trafc>. The weekly ve day average of <Carried_Trafc>. Busy hour value of 100 * <Offered_Trafc>/<Critical_Trafc>. Busy hour value of the grade of service calculated from <Offered_Trafc> and <Channels_Available> using either the Erlang-B or the Erlang-C Trafc Model.
Lost Trafc Critical Trafc
3-DAV Trafc 5-DAV Trafc Utilization Percentage GOS (Grade of Service)
5-32
Issue 1.0
December 1996
Forecasting Cell TCH Exhaustion Report (FCTXR)
This report shows all cells that will reach exhaustion in the specied forecast. A threshold correlation coefcient can be specied for the report. Only cells which show a better correlation of the dimensioning parameter with time will be selected in the report. In addition, an option is provided to allow cells that have already exhausted to be included in the report. The report is always generated with weekly busy hour values. Data can be thresholded on the correlation coefcient and already exhausted cells can be ignored. The data is always sorted by exhaustion date.
Issue 1.0
December 1996
5-33
Report Heading
90-DAY CELL TCH EXHAUSTION REPORT FORECAST FROM 96/04/21 TO 96/08/19 FOR ALL CELLS
Dimensioning Parameter Regression Type Min. Correlation Min. % Data Coverage
: : : :
Erlang B (GOS=0.01) Sorted by Exhaustion Date
---------- Latest BDBH ----------Dimension ---------- Forecast ---------Cell Carried Blocking Util. GOS Lost Parameter Capacity Sample Corr. Growth Exhaust Id. (E) (%) (%) (E) (E) (E) Size E/week On ---------------------------------------------------------------------------------------------------------
Calculations
Carried Trafc Blocking % Utilization % GOS (Grade of Service Lost Trafc Dimensioning Parameter Capacity (i.e., Critical Trafc in the Busy Hour) Sample Size Correlation Growth Exhaust On Busy hour value of averageNoSimultCalls.fullrate / 100 Busy hour value of 100 * <TCHBLOCKS> / <TCHATTEMPTS> Busy hour value of the utilization calculated as the offered trafc as a percentage of the critical trafc level. Busy hour value of the Grade of Service calculated from the Offered Trafc and Channels Available using either the Erlang-B or the Erlang-C Trafc Model. Offered Trafc minus Carried Trafc Either BDBH trafc, 3-DAV trafc, or 5-DAV trafc in Erlangs. Busy hour value of the Critical Trafc level calculated from the design Grade of Service and Channels Available using either the Erlang-B or the Erlang-C Trafc Model. The number of samples in the regression (that is, the number of weeks for which there is data). The Pearson Correlation of the dimensioning parameter to time for linear regression, or else the Spearman rank correlation. The growth in Erlangs per week for Linear Regression. The projected date when the cell will reach capacity (i.e., when the dimensioning parameter will cross the capacity).
5-34
Issue 1.0
December 1996
Forecasting Cell TCH Utilization Report (FCTUR)5

This report shows all cells that will remain consistently underutilized in the forecast period (that is, start off with low utilization and nishes with low utilization). The report shows data for the most recent actual busy hour. A threshold Correlation Coefcient can be specied for the report. Only cells which show a better correlation of the dimensioning parameter with time will be selected in the report. The current low utilization threshold and the nal utilization threshold can also be specied. The report is always generated with weekly busy hour values. The data is always sorted by nal utilization.
Issue 1.0
December 1996
5-35
Report Heading
90-DAY CELL TCH LOW UTILISATION REPORT FORECAST FROM 96/04/21 TO 96/08/19 FOR ALL CELLS
Dimensioning Parameter : Offered 3-DAV Traffic Regression Type : Linear Min. Correlation : Max. Current Utilisation : 25.00 Max. Future Utilisation : 25.00 Min. % Data Coverage :
Erlang B (GOS=0.01)
Sorted by Future Utilisation
---------- Latest BDBH ----------Dimension Current ----- Forecast ---Cell Carried Blocking Util. GOS Lost Parameter Capacity Util. Sample Corr. Util. Id. (E) (%) (%) (E) (E) (E) (%) Size (%) ---------------------------------------------------------------------------------------------------
Calculations
Carried Trafc Blocking % Utilization % GOS (Grade of Service Lost Trafc Dimensioning Parameter Capacity (i.e., Critical Trafc in the Busy Hour) Current Utilization Percentage Sample Size Correlation Final Utilization Busy hour value of averageNoSimultCalls.fullRate / 100 Busy hour value of 100 * <TCHBLOCKS> /<TCHATTEMPTS> Busy hour value of the utilization calculated as the Offered Trafc as a percentage of the Critical Trafc. Busy hour value of the Grade of Service calculated from the Offered Trafc and Channels Available using either the Erlang-B or the Erlang-C Trafc Model. Offered Trafc minus <Carried_Trafc> Either BDBH trafc, 3-DAV trafc, or 5-DAV trafc. Busy hour value of the Critical Trafc calculated from the design Grade of Service and Channels Available using either the Erlang-B or the Erlang-C Trafc Model. The percent utilization in the latest week based on the dimensioning parameter. The number of samples in the regression (that is, the number of weeks for which there is data). The Pearson correlation of the dimensioning parameter to time for Linear regression, or else the Spearman rank correlation. The forecast utilization at the end of the forecast period.
5-36
Issue 1.0
December 1996
Forecasting Cell TCH Required Channels Report (FCTCR)
For all selected cells, this report (which is only available with GSM Release 6.5) shows the forecast channel requirements at periods of N1, N2 and N3 days ahead where the user can congure N1, N2 and N3 but default to 60, 90 and 120. The forecast can be dimensioned using BDBH, 3-DAV or 5-DAV values of carried or offered trafc. Data can be thresholded on the correlation coefcient and percentage data coverage. Cells which do not require any extra capacity can optionally be ignored. The data is always sorted by the number of additional required channels at the end of the forecast period.
Report Heading
CELL TCH REQUIRED CHANNELS REPORT FORECAST FROM 96/04/21 TO 96/08/19 FOR ALL CELLS ON BSC JAGFLD-BSS:19
Dimensioning Parameter : Offered 3-DAV Traffic Regression Type : Linear Min. Correlation : Min. % Data Coverage :
Erlang B (GOS=0.01) Sorted by Required Extra Capacity
-- Latest --- 060 days --- 090 days --- 120 days -Cell Sample Actual Reqd Fcast Reqd Fcast Reqd Fcast Reqd Fcast Extra Id. Size Corr. Chans Chans (E) Chans (E) Chans (E) Chans (E) Chans ---------------------------------------------------------------------------------------------------
Calculations
Dimensioning Parameter Sample size Correlation Actual Channels Required Channels Forecast
Latest BDBH, 3-DAV or 5-DAV Offered or Carried Trafc The number of samples in the regression (that is, the number of weeks for which there is data). The Pearson correlation of the dimensioning parameter to time for Linear regression, or else the Spearman rank correlation. Number of Dened Channels in the latest busy hour. Number of channels required to carry the trafc given by the dimensioning parameter. The number of Erlangs yielded by the dimensioning parameter. Absolute number of channels required to carry the N-day forecast trafc at the current design GOS. Forecast trafc value N days ahead. The number of additional channels required to carry the forecast trafc at the end of the forecasting period.
N-day forecast channels N-day forecast trafc

Extra Channels
Issue 1.0
December 1996
5-37
Forecasting Route Summary Report (FRTR)
This report (only available with GSM Release 6.5) shows key route trafc statistics for a set of routes in a selected time period. It is always generated with weekly busy hour values. Data can be thresholded by Trafc, Lost Trafc, % Utilization, grade of service; sorted by Trafc, Lost Trafc, % Utilization or GOS. This is not a true Forecast since it does not include any projections into the future.
Report Heading
SUMMARY ROUTE TRAFFIC REPORT WEEK OF 96/08/05 FOR ALL ROUTES
Traffic (E) : Lost Traffic (E) : % Utilisation : % Data Coverage : Grade of Service :
Route ---- BDBH ---Circuits Congestion --------- BDBH ---------- -- Weekly -- Util. GOS Id. Day Hour Def. Avail. (%) Carr. Offer Lost Crit. 3-DAV 5-DAV (%) ---------------------------------------------------------------------------------------------------
Calculations
Busy Day Busy Hour
The busy hour of the route calculated as the hour in the week that after averaging has the maximum value of TGCOMP.BWINCU/100+TGCOMP.BWOUTU/100. Busy hour value of TGCOMP.INSVC + TGCOMP.OOS + TGCOMP.OOSMTCE Busy hour value of TGCOMP.INSVC Busy hour value of 100*TGCOMP.OVFL/TGCOMP.OATTMPT Busy hour value of TGCOMP.BWINCU/100 + TGCOMP.BWOUTU/100 Busy hour value of the Offered Trafc calculated from <Dened Circuits> and <Carried_Trafc> <Offered Trafc> - <Carried trafc>. Busy hour value of the Critical Trafc or TC4 value calculated from the design Grade of Service and <Dened Circuits> The weekly three day average trafc. The weekly ve day average trafc. <Offered trafc> / <Critical trafc> Busy hour value of the Grade of Service calculated from the <Offered Trafc> and <Dened Circuits>
Dened Circuits Available Circuits % Congestions Carried Trafc Offered Trafc Lost Trafc Critical Trafc Weekly 3-DAV Trafc Weekly 5-DAV Trafc % Utilization Grade of service
5-38
Issue 1.0
December 1996
Forecasting Route Historical Report (FRHR)
This report (which is only available with GSM Release 6.5) shows key route trafc statistics for a single route over all the weeks in the forecast base range. The report is always generated with weekly busy hour values. Strictly speaking, this is not a true Forecast since it does not include any projections into the future.
Report Heading
HISTORICAL ROUTE TRAFFIC REPORT FOR ROUTE IHMSC0-TG:10 FROM WEEK OF 96/04/21 TO 96/08/19
Min. % Data Coverage
Week ---- BDBH ---Circuits Congestion --------- BDBH ---------- -- Weekly -- Util. GOS Of Day Hour Def. Avail. (%) Carr. Offer Lost Crit. 3-DAV 5-DAV (%) ---------------------------------------------------------------------------------------------------
The contents of this report is effectively identical to report FRTR. Please refer to that report for eld denitions.
Issue 1.0
December 1996
5-39
Forecasting Route Exhaustion Report (FRXR)
This report (which is only available with GSM Release 6.5) shows all routes that will reach exhaustion in the specied forecast. The report is always generated with weekly busy hour values. Data can be thresholded on the correlation coefcient and already exhausted routes can be ignored. The data is always sorted by exhaustion date.
Report Heading
90-DAY ROUTE EXHAUSTION REPORT FORECAST FROM 96/04/21 TO 96/08/19 FOR ALL ROUTES
Dimensioning Parameter : Offered 3-DAV Traffic Regression Type : Linear Min. Correlation : Min. % Data Coverage :
Erlang B (GOS=0.008) Sorted by Exhaustion Date
---------- Latest BDBH ----------Dimension ---------- Forecast ---------Route Carried Cong. Util. GOS Lost Parameter Capacity Sample Corr. Growth Exhaust Id (E) (%) (%) (E) (E) (E) Size E/week On ---------------------------------------------------------------------------------------------------
Calculations
Carried Trafc % Congestion % Utilization Grade of Service The busy hour value of TGCOMP.BWINCU/100 + TGCOMP.BWOUTU/100. Busy hour value of 100*TGCOMP.OVFL/TGCOMP.OATTMPT Busy hour value of the utilization calculated as the Offered Trafc as a percentage of the Critical Trafc. Busy hour value of the Grade of Service calculated from the Offered Trafc and TGCOMP.INSVC + TGCOMP.OOS + TGCOMP.OOSMTCE. Offered Trafc minus Carried Trafc. Either BDBH trafc, 3-DAV trafc or 5-DAV trafc in Erlangs. Busy hour value of the Critical Trafc or TC4 value calculated from the design Grade of Service and TGCOMP.INSVC + TGCOMP.OOS + TGCOMP.OOSMTCE The number of weeks for which there is data. The Pearson correlation of the dimensioning parameter to time for Linear regression else the Spearman rank correlation. The growth in Erlangs per week for Linear regression. The date when the route will reach capacity.
Lost Trafc Dimensioning Parameter. Critical Trafc (Capacity) Samples Correlation. Growth (E/Week) Exhaust On
5-40
Issue 1.0
December 1996
Forecasting Route Low Utilization Report (FRUR) 5

This report (which is only available with GSM Release 6.5) shows all routes that will remain consistently underutilized in the forecast period (i.e., start off with low utilization and nish with low utilization). The report is always generated with weekly busy hour values. The data is always sorted by nal utilization.
Report Heading
90-DAY ROUTE LOW UTILISATION REPORT FORECAST FROM 96/04/21 TO 96/08/19 FOR ALL ROUTES
Dimensioning Parameter Regression Type Min. Correlation Min. % Data Coverage Max. Current Utilisation Max. Future Utilisation
: : : : : :
Offered 3-DAV Traffic Linear
25.00 25.00
Erlang B (GOS=0.008) Sorted by Future Utilisation
---------- Latest BDBH ----------Dimension Current ----- Forecast ---Route Carried Cong. Util. GOS Lost Parameter Capacity Util. Sample Corr. Util. Id. (E) (%) (%) (E) (E) (E) (%) Size (%) ---------------------------------------------------------------------------------------------------
Calculations
Carried Trafc % Congestion % Utilization Grade of service The busy hour value of TGCOMP.BWINCU/100 + TGCOMP.BWOUTU/100. Busy hour value of 100*TGCOMP.OVFL/TGCOMP.OATTMPT Busy hour value of the utilization calculated as the Offered Trafc as a percentage of the Critical Trafc. Busy hour value of the Grade of Service calculated from the Offered Trafc and TGCOMP.INSVC + TGCOMP.OOS + TGCOMP.OOSMTCE. Offered Trafc minus Carried Trafc. Either BDBH trafc, 3-DAV trafc or 5-DAV trafc. Busy hour value of the Critical Trafc or TC4 value calculated from the design Grade of Service and TGCOMP.INSVC + TGCOMP.OOS + TGCOMP.OOSMTCE The % utilization in the latest week based on the dimensioning parameter. The number of weeks for which there is data. The Pearson correlation of the dimensioning parameter to time for Linear regression else the Spearman rank correlation. The forecast utilization at the end of the forecast.
Lost Trafc Dimensioning Parameter. Critical Trafc (Capacity). The Current Utilization. Samples Correlation. Final Utilization.
Issue 1.0
December 1996
5-41
Forecasting Route Required Circuits Report (FRCR)
This report (which is only available with GSM Release 6.5) shows the forecast circuit requirements for a set of routes for three different forecast periods. For all selected routes, the report shows data for periods of N1, N2 and N3 days ahead where the user can congure N1, N2 and N3 but default to 60, 90 and 120. The forecast can be dimensioned using BDBH, 3-DAV or 5-DAV values of carried or offered trafc. Data can be thresholded on the correlation coefcient and percentage data coverage. Routes which do not require any extra capacity can optionally be ignored. The data is always sorted by the number of additional required circuits at the end of the forecast period.
Report Heading
ROUTE REQUIRED CIRCUITS REPORT FORECAST FROM 96/04/21 TO 96/08/19 FOR ALL ROUTES
Dimensioning Paramet : Offered 3-DAV Traffic Regression Type : Linear Min. Correlation : Min. % Data Coverag :
Erlang B (GOS=0.008) Sorted by Required Extra Capacity
-- Latest --- 060 days --- 090 days --- 120 days -Route Sample Actual Reqd Fcast Reqd Fcast Reqd Fcast Reqd Fcast Extra Id. Size Corr. Circs Circs (E) Circs (E) Circs (E) Circs (E) Circs ---------------------------------------------------------------------------------------------------
Calculations
Dimensioning Parameter Sample size Correlation. Latest BDBH, 3-DAV or 5-DAV offered or carried trafc. Number of weeks of data on which the forecast is based. The Pearson correlation of the dimensioning parameter to time for Linear regression else the Spearman rank correlation. Number of dened circuits in the latest busy hour. Number of circuits required to carry the trafc given by the dimensioning parameter Absolute number of circuits required to carry the N-day forecast trafc calculated using either the current design GOS or TC4. Forecast trafc value N days ahead The number of additional circuits required to carry the forecast trafc at the end of the forecasting period.
Actual circuits Required circuits N-day forecast circuits (repeated for N1, N2, N3) N-day forecast trafc (repeated for N1, N2, N3) Extra Circuits
5-42
Issue 1.0
December 1996
This chapter describes the relationships among the MSC and BSS handover measurements. It also presents a number of operational scenarios which may be encountered by a network operator. These scenarios are not meant to be an exhaustive collection, but rather a starting point to guide network operators in the management of operational networks.
Handover Measurements
Clear denitions help signicantly in understanding trafc measurements. In order to support clear denitions of handover related measurements, it is useful to separate handovers into four categories. The intent here is that each handover falls into one and only one of these categories. The denitions of the handover counters that appear in Appendix A make use of these denitions. The four OMC-2000 categories are: intraBTS: These handovers are always controlled by the BSC but are within a given BTS. The handover can be between time slots of the same transceiver or it can be between transceivers in the same BTS.
BSCcontrolled: These include all BSC controlled handovers except for those included in intraBTS. It would exclude all MSC controlled handovers including any intra-BSC handover that is controlled by the MSC. intraMSCcontrolled: These exclude any intraBTS and BSCcontrolled handovers, and any handovers between MSCs. However, it could include a handover where the old BTS and the new BTS are on the same BSC. This can happen when the BSC passes control of the handover to the MSC because the rst entry in the handover list is on a different BSC, but a subsequent entry in the list identies a BTS connected to the original BSC. interMSCcontrolled: These are only handovers between MSCs.
It is important to note that some 5ESS-2000 documentation makes references to interBSC and intraBSC handovers. These terms can cause confusion due to this MSCcontrolled intraBSC handover possibility. Therefore, for claritys sake, it is best to think of 5ESS-2000s interBSC handovers as referring to MSCcontrolled handovers and 5ESS-2000s intraBSC handovers as referring to BSCcontrolled handovers.
Version 1.0
December 1996
6-1
It is convenient to dene two additional terms: MSCcontrolled: This is the sum of intraMSCcontrolled and interMSCcontrolled.
allBSCcontrolled: This is the sum of intraBTS and BSCcontrolled. Each handover attempt can be successful or unsuccessful. That is, the sum of successful plus unsuccessful is equal to the total number of handover attempts. In addition, the 5ESS-2000 identies another category of unsuccessful handovers called rejected. From the BSC point of view, rejected handovers are still unsuccessful handovers. Therefore, the total number of unsuccessful handovers as seen by the 5ESS-2000 must include rejected handovers. All MSCcontrolled handovers are pegged in multiple BCE-2000s. That is, whereas the 5ESS-2000 might peg a handover only once, the involved BCE-2000s would each be pegging a counter. Since it is possible to have an MSC controlled, intraBSC handover, both sets of incremented BCE-2000 counters could be in the same BCE-2000. The table on the following page gives the denition of the handover counters found in the BCE-2000 and the 5ESS-2000. More importantly, it identies for which handover group the counter is incremented. The meaning of the column entries are as follows: (*) A S U R means that the measurement became available with LM4. Attempts Successful attempts Unsuccessful attempts MSC Rejected handover attempt. Such attempts are not included as part of any other MSC counter.
In addition, a number of the 5ESS-2000 related counters are identied as being incremented on the MSC when the MSC is playing a particular role in the handover. That is, the 5ESS-2000 may be Initiating the handover, it may be the Target of the handover, or it may be the Controlling MSC for the call in which case it is just Facilitating the handover.
Please see the Glossary or Appendix A, Section 5ESS-2000 Wireless Summary (WRLSSUM), Subsection MSC Controlled Handovers for complete denitions.
6-2
Version 1.0
December 1996
MS Cco ntro lle
BSC con troll e
BTS
Intra
noAttIntraCellBssHo noSucIntraCellBssHo noUnsIntraCellBssHoLossRL(*) noAttHoByCause noSucHoByCause noAttIncInterCellBssHo trFlowAttIncInterCellBssHo(*) noSucIncInterCellBssHo trFlowSucIncInterCellBssHo(*) noAttOutInterCellBssHo trFlowAttOutInterCellBssHo(*) noSucOutInterCellBssHo trFlowSucOutInterCellBssHo(*) noUnsOutBssHoSucReturn(*) noUnsIncBssHo(*) noUnsOutBssHoLossRL(*) noIncomInterCellHandover noOutgoInterCellHandover noAttSdcchSssHo(*) noSucSdcchSssHo(*) HOREQI HOREJI ITRAHOAT ITRAHOCO HOCOMR HOICOM HOCOMNC (non-Controlling MSC) HOFC HOSC HOBSC HOCOMI (Initiating MSC) ITERHOAT (Controlling MSC) ITERHOCO (Controlling MSC) HOREQ (Target MSC) HOCOMT (Target MSC) HOREQF (Facilitating MSC) HOCOMF (Facilitating MSC)
A S U A S A A S S A A S S S U U S S S S A S A R S S S S S S S S S S S S S S S S S A S A S A S A S S S A S A R
intra
Measurement Name
Inte rMc o
ntro
lled
it
Version 1.0
December 1996
6-3
The values for attempted and successful handovers of each type can be determined from the following peg counters:
intraBTS attempts: intraBTS successes: BSCcontrolled attempts: BSCcontrolled successes: allBSCcontrolled attempts: allBSCcontrolled successes: MSCcontrolled attempts: MSCcontrolled successes: intraMSCcontrolled attempts: intraMSCcontrolled successes: interMSCcontrolled attempts interMSCcontrolled successes: noAttIntraCellBssHo noSucIntraCellBssHo noAttIncInterCellBssHo noSucIncInterCellBssHo noAttIntraCellBssHo + noAttIncInterCellBssHo noSucIntraCellBssHo + noSucIncInterCellBssHo, or HOCOMR HOREQI HOICOM + HOCOMI ITRAHOAT - HOCOMR HOICOM HOREQI - HOREJI - (ITRAHOAT - HOCOMR) HOCOMI
The following statements show some of relationships among the peg counters:
s s s
noUnsIncBssHo = noAttIncInterCellBssHo - noSucIncInterCellBssHo HOREQI = HOICOM + HOCOMI + HOREJI + Unsuccessful HO When the BSS asks the MSC to control a handover, one of three things happens: The MSC immediately rejects the handover. One reason for doing so is that the MSC will not control SDCCH handovers (HOREJI). The handover is successful (HOICOM or HOCOMI). The handover is unsuccessful.
HOICOM + HOCOMI = HOFC + HOSC + HOBSC; If a handover attempt fails at one BTS, then the MSC can try others. The total number of successful intraMSC handovers plus interMSC handovers equals the sum of handovers that succeeded at the rst BTS plus those that succeeded at the second BTS plus those that succeeded beyond that point. SUM(3 noAttIncInterCellBssHo counters) = SUM(3 noAttOutInterCellBssHo counters) = SUM(6 noAttHoByCause counters) SUM(3 noSucIncInterCellBssHo counters) = SUM(3 noSucOutInterCellBssHo counters) = SUM(6 noSucHoByCause counters)
Total Number of Handovers by Type
In order to get a picture of the number and types of handovers in a network, it is desirable to merge numbers from the MSC and the BSSs. The section above indicates which counters can be used to get the total number of handovers and how to identify the number of handovers of each type. The counters in the MSC and the BSS do relate to each other but are not identical due to variations in the way that counters actually get incremented. Therefore, it would be best to scale the 5ESS-2000 numbers and the BSS numbers so that they take into account any type of variations. The recommended ratio to use is:
(noSucIntraCellBssHo + noIncomInterCellHandover)/(HOCOMR + HOICOM + HOCOMI)
6-4
Version 1.0
December 1996
Average Time Until a Handover Occurs
The average amount of time that a trunk is held before a handover occurs can be determined by looking at the usage of BSSAP trunks and dividing that by the number of handovers. The total usage of BSSAP trunks can be determined by adding up TGCOMP.BWINCU plus TGCOMP.BWOUTU over only the BSSAP trunk groups. The total number of successful handovers equals WRLSSUM.ITRAHOCO plus WRLSSUM.ITERHOCO.
Miscellaneous
Length of Talking Phase of a Call
6
6
The number of originating calls that are answered is given in SMCOMP.O_ANS. This includes both wireless calls as well as wireline calls. Unfortunately there is no equivalent for terminating calls that are answered. Part of the number is available in that the number of wireless terminating calls that are answered is given by WRLSSUM.MMECALL plus WRLSSUM.LMECALL. However, there is nothing that gives the number of wireline terminating calls that are answered. Nevertheless, if the number of wireline calls in the switch are few (perhaps even zero) such that their effect can be ignored, then the following can be stated: The time spent in the talking phase of a call can be approximated as follows:
s
The number of Erlangs spent in the talking phase (i.e., [TGCOMP.IANSUSG + TGCOMP.OANSUSG]/2) divided by the total number of answered or established calls (i.e., SMCOMP.O_ANS + WRLSSUM.MLECALL). When this is applied to BSSAP trunk groups, then the result is the length of a call segment (i.e., length of the call before handover occurs). When applied to PSTN trunk groups, the result is the length of the call.
Version 1.0
December 1996
6-5
Operational Scenarios
Throughout the following sections, each scenario is described by its subsection header, and if needed, a brief denition of the issue or problem may follow. Other scenario information appears in tabular form, as follows:
Main indicator
- Describes what an operator has available to indicate the problem from the network point of view. Possible Causes Description of one or more conditions that could be causing the indicated problem. Related Indicators List of further indicators referring to the possible cause. Proposals / Solutions
Possible actions to be taken to react on the issue or problem.
When possible, references are made to specic reports which could help pinpoint network problems. For MSC data, the reports are usually spooled to a ROP; additionally, reports are sent to the OMC-2000 using FTAM from where they are subsequently passed to the OMC-PMS. For BSS data, the reports of the OMC-PMS are referenced. In addition to these BSS reports, references are also made to specic BSS counters. These can be accessed via the Daily Module of the OMC-PMS under the menu item Display. The scenarios that follow are presented within the following sections:
s s s
Capacity Issues Availability Issues Quality of Service Issues.
6-6
Version 1.0
December 1996
Capacity Issues
Scenario: Higher Carried Trafc on TCH than Expected Main indicators
6 6
The OMC-PMS report Daily Cell TCH (DCTTR) shows a high amount of carried trafc or a high number of seizure attempts. The OMC-PMS report Summary Cell TCH (SCTTR) shows an unexpected increase of the carried trafc or the number of seizure attempts. Possible Causes Localized events, promotions, exhibitions, etc. Related Indicators Observe announcements, local papers, etc. Proposals / Solutions Try to get advance information on events and customize the network accordingly. Continue with the section Lower carried trafc on the TCH than expected for the neighbor cell. Continue with the section Monitoring of TCH availability for the neighbor cell. Consult RF Planning group.
Neighbor cell may have problems, that is, observed cell has to take over trafc from neighbor cell.
The carried TCH values of the neighbor cell are unexpectedly low.
The TCH Availability values of a neighbor cell are unexpectedly low. Related to RF Planning / cell site selection (for example, very high antennas, sites, power, etc.) Observed cell size differs from planned cell size shown by drive tests. Check handover causes with OMC-PMS report Daily Cell Handover (DCHOR). Handover cause Distance could indicate a problem with an over-sized cell coverage area. Inappropriate cell selection and reselection parameters. Check the following cell selection and reselection parameters:
RXLEV_ACCESS_MIN, MS_TXPWR_MAX_CCH, CELL_RESELECT_HYSTERESIS
Make the necessary corrections to parameter values.
Inappropriate handover parameters in the cell or the serving cell.
Observe the number of incoming handovers against the outgoing handovers shown by the OMC-PMS report Daily Cell Handover (DCHOR).
Check / correct the handover control parameters of the BTS objects ADJCELL and HOCTRL .
Version 1.0
December 1996
6-7
Possible Causes Changed subscriber behavior (longer calls than expected)
Related Indicators Check average bills of subscribers. The mean holding time for answered calls can be calculated per trunk group using the following 5EE counters: MHT = TGCOMP.OANSUSG * samples / TGCOMP.OANS (note: this is only true for outgoing trunk groups) where samples is the number of 100 second scans performed to obtain TGCOMP.OANSUSG. The value of samples would typically be 36.
Proposals / Solutions Adapt growth planning to subscribers new behavior.
Growth of the subscriber base
The TCH utilization values shown by the OMC-PMS report Summary Cell TCH (SCTTR) follow the trend. The 5EE measurements HLRVLR.SRGVLR and HLRVLR.RSRGVLR indicate a corresponding growth of the active subscribers for the complete MSC area.
Add more radio transmitters or new BTSs, based on these values: consult RF Planning and Network Planning groups.
6-8
Version 1.0
December 1996
Scenario: Zero Trafc Carried for TCH and SDCCH during Normally Busy Hours 6 Main Indicators
The OMC-PMS reports Daily Cell TCH (DCTTR) and Daily Cell SDCCH (DCCTR) show no carried trafc for the TCH and SDCCH. Possible Causes Faulty components inside the BSS, (such as BTS, BCE, Abis-interface, antenna, etc.) Related Indicators The OMC-PMS report Daily Network Availability (DCAR) shows the unavailability of the cell. The OMC-PMS reports Daily Cell TCH (DCTTR) and Daily Cell SDCCH (DCCTR) show unavailable TCH or SDCCH channels. Alarm messages from the BSS can be observed. Faulty components inside the SSS subsystem such as MSC, VLR, HLR, A interface, etc.) Incorrect cell parameters Check alarm messages from related objects. Check CICSUM report counters. No faulty component could be observed, and the BTS never carried trafc before. After modifying cell parameters the BTS does not carry trafc any more. Cell not selected by mobile stations but BCCH frequency of the cell is on air (shown by drive tests) No SDCCH seizure attempts shown by the OMC-PMS report Daily Cell SDCCH (DCCTR). No attempts for incoming handovers shown by OMC-PMS report Daily Cell Handover (DCHOR). Locate and repair equipment problems: consult SSS support group as necessary. Check / correct cell parameters such as BSIC, CELL_BAR_ACCESS, ACCESS_CLASS_RESTRI CTED, RXLEV_ACCESS_MIN, MS_TXPWR_MAX_CCH, CI, LAC, MCC, MNC Note: Some of these parameters have to be set in the MSC, as needed. Proposals / Solutions Locate and repair equipment problems.
Refer also to section Monitoring of TCH availability.
Version 1.0
December 1996
6-9
Possible Causes Related to RF Planning
Related Indicators The BTS never carried trafc, but no faulty component or incorrect parameter settings can be found. After taking a new neighbor cell into service, the observed cell does not carry trafc any more.
Proposals / Solutions Check RF coverage area of the neighbor cells with drive tests.
Check whether neighbor cells carry more trafc than expected. See section Higher carried trafc on TCH than expected.
6-10
Version 1.0
December 1996
Scenario: Lower Carried Trafc on TCH than Expected Main Indicators
6 6
The OMC-PMS report Daily Cell TCH (DCTTR) shows a reduced amount of carried trafc. The OMC-PMS report Summary Cell TCH (SCTTR) shows an unexpected decrease of the carried trafc. Possible Causes Faulty components (BTS, BCE, MSC, Interfaces, Antenna) Related Indicators The OMC-PMS report Daily Cell SDCCH (DCCTR) shows also a low amount of carried trafc. Observe alarm messages from related objects. Related to RF Planning or cell parameter settings. Neighbor cells of the observed cell carry more trafc than expected as shown by the function Daily Cell TCH (DCTTR). Observe alarm messages from related objects. Check whether related objects were deactivated by the operators Basic SDCCH signaling functionality not available Refer to section Monitoring SDCCH availability to check the availability of the SDCCH channels. Refer to section Not enough capacity to meet short-term SDCCH demand for grade of service. No faulty components or incorrect cell parameters are found. No neighbor cell shows an unexpected high amount of carried trafc. The basic signaling functionality is not congested or unavailable. If forecasting Cell TCH Exhaustion (FCTXR) does not show an exhaustion on the TCH channels in the near future take RTs out of service to reduce interference probability: consult RF Planning group. Refer also to section Forecasting future TCH demand. Consult RF Planning group; also check and correct cell parameters. Proposals / Solutions Locate and repair equipment problems.
Maintenance activity at the BTS.
Check TCH capacity issues again after the end of the maintenance activities.
Basic SDCCH signaling functionality congested
Cell is over-dimensioned
Version 1.0
December 1996
6-11
Scenario: Not Enough Capacity to Meet Short-Term TCH demand for grade of service Main Indicators
6 6
The OMC-PMS report Daily Cell TCH (DCTTR) shows a percentage of blocked calls higher than the specied grade of service. The OMC-PMS report Summary Cell TCH (SCTTR) shows a Utilization Percentage higher than 100% or a grade of service higher than the specied. Possible Causes Not all installed TCH are in service Related Indicators The OMC-PMS report Daily Network Availability (DCAR) shows that not all dened TCHs are in service. Proposals / Solutions Refer to section Monitoring of TCH availability.
The demand for the TCH is higher than expected.
Refer to section Higher carried trafc on the TCH than expected.
Forecasting future TCH demand Main Indicators
6 6
The OMC-PMS report Forecasting Cell TCH Exhaustion (FCTXR) indicates that the observed cell will reach the capacity within a given time period. Possible Causes Not all neighbor cells planned by the RF planning group are installed and running. Related Indicators Comparisons between the data from the RF planning group and the actually installed cells show differences either in the installed cells or their capacity. Proposals / Solutions After taking all cells with their planned capacity into service the forecast has to be checked again.
6-12
Version 1.0
December 1996
Possible Causes The growth of the subscriber base and their air time requires additional network capacity.
Related Indicators The mean holding time for answered calls can be calculated per outgoing trunk group using the following 5EE counters: MHT = TGCOMP.OANSUSG * samples / TGCOMP.OANS where samples is the number of 100 second scans performed to obtain TGCOMP.OANSUSG. The 5EE measurements HLRVLR.SRGVLR and HLRVLR.RSRGVLR indicate a corresponding growth of the active subscribers for the complete MSC area.
Proposals / Solutions Consult RF Planning group to establish whether just adding TCHs (by adding new RTs) is sufcient or whether the offered trafc has to be distributed to new cells. In both cases the RF planning group should be consulted to check the frequencies used for possible interference.
Scenario: Higher Carried Trafc on the SDCCH than Expected Main Indicators
6 6
The OMC-PMS reports Daily Cell SDCCH (DCCTR) and Summary Cell SDCCH (SCTTR) show a higher carried trafc on the SDCCH than expected. Possible Causes Localized events or promotions Neighbor cell problems RF Planning Invalid cell selection parameters Related Indicators Proposals / Solution
Refer to section Higher carried trafc on the TCH than expected.
Version 1.0
December 1996
6-13
Possible Causes More location updates by mobile stations than expected.
Related Indicators Compare the number of Busy Hour location updates shown by the 5EE counters HLRVLR.GLOCUP and HLRVLR.GLOUPI with the number of active subscribers in the network as shown in HLRVLR.SRGVLR. An objective for the ratio of geographic location updates to VLR entries is 2:1. Check number of location updates for highways and main travel routes by performing drive tests.
Proposals / Solution Increase time between periodic location updates. Optimize location area planning to get fewer normal location updates. If other actions do not x the problem, enlarge the SDCCH capacity by exchanging a TCH against a SDCCH if possible according to the BSS conguration rules.
Growth of subscriber base or changed subscriber behavior (for example, extensive use of SMS)
The 5EE measurements HLRVLR.SRGVLR, HLRVLR.RSRGVLR, and HLRVLR.DELVLR indicate a corresponding growth of the subscribers for the complete MSC area. The more extensive use of SMS can be observed by the 5EE counters WRLSSUM.MAPFOR and WRLSSUM.MAPFORS.
Enlarge the SDCCH capacity by exchanging a TCH against a SDCCH if possible according to the BSS conguration rules.
6-14
Version 1.0
December 1996
Scenario: Lower Carried Trafc on SDCCH than Expected Main Indicators
6 6
The OMC-PMS report Daily Cell SDCCH (DCCTR) shows a lower amount of carried trafc on the SDCCH than expected. Possible Causes Faulty components Poor RF planning or parameter settings Maintenance activity at the BTS. Number of SDCCH channels is over-dimensioned None of the above mentioned reasons is true. Related Indicators Proposals / Solutions
Refer to section Lower carried trafc on the TCH than expected.
No action required. Consideration can be given to reducing the number of SDCCHs. However, since SDCCHs come in groups of 8 (or in one case, 4) care should be taken to ensure that excessive conversion of SDCCHs to TCHs is avoided.
Scenario: Not Enough Capacity to Meet Short-Term SDCCH Demand for Grade of Service 6 Main Indicators
The OMC-PMS reports Daily Cell SDCCH (DCCTR) or Summary Cell SDCCH (SCCTR) show a blocking percentage higher than the planned grade of service. Possible Causes Not all installed SDCCH are in service. The demand for the SDCCH channels is higher than expected. Related Indicators The above reports show differences between Channels dened and Channels available. Proposals / Solutions Refer to section Monitoring of SDCCH availability. Refer to section Higher carried trafc on the SDCCH than expected.
Version 1.0
December 1996
6-15
Scenario: Not Enough Capacity to Meet Short-Term CCCH Demand Main Indicators
6 6
The BSS measurement noLostCallsNoAGCH displays calls lost caused by no AGCH available. High percentage of accesses on the RACH that can not be decoded, probably caused by collisions due to high load on the RACH. Possible Causes Installed channel combination BCCHB can not serve the amount of trafc for the CCCH channels Installed channel combination BCCH (on RT 0) and SDCCH (on RT 1) can not serve the amount of trafc for the CCCH channels. Related Indicators Proposals / Solutions Switch over from channel combination BCCHB to channel combinations BCCH and SDCCH by observing the BTS conguration rules. Install additional channel combination CCCH on time slot 2 of RT 0.
6-16
Version 1.0
December 1996
Availability Issues
Scenario: Monitoring TCH Availability Main Indicators
6
6 6
The OMC-PMS report Daily Network Availability (DCAR) shows unavailability of TCH channels. The OMC-PMS report Daily Cell TCH (DCTTR) shows differences in dened and in-service TCH channels. The function Cell Idle TCH from the Display menu show unexpected high number of idle TCH channels in interference bands 2-5. Possible Causes Some of the BSS related components are out of service due to maintenance activities inside the BSS (for example, load of new SW releases, exchange of HW components, etc.) Some of the BSS related components are out of service due to problems of the links or equipment failures. Frequencies used by a neighboring cell cause interference in the observed cell. Related Indicators Check the administrative states of related components. Proposals / Solutions Observe the TCH availability after the end of the maintenance activities.
Observe alarm messages sent by the BSS.
Analyses the alarm messages and rectify the faults accordingly
High number of intra-cell handovers or intercell handovers with causes uplink or downlink quality shown by the OMC-PMS report Daily Cell Handover (DCHOR)
If possible from the capacity point of view, take single frequencies out of service to determine whether these frequencies are the interfered ones. Perform drive tests to see which frequency causes the interference. Create a corrected frequency plan according the interference situation: consult the RF Planning group.
Version 1.0
December 1996
6-17
Scenario: Monitoring SDCCH Availability Main Indicators
6 6
The OMC-PMS report Daily Cell SDCCH (DCCTR) shows differences in dened and in-service SDCCH channels. Possible Causes Some of the BSS-related components are out of service due to maintenance activities inside the BSS (for example, load of new SW releases, exchange of HW components, and so on.) Some of the BSS related components are out of service due to problems of the links or equipment faults Related Indicators Check the administrative states of related components. Proposals / Solution Observe the SDCCH availability after the end of the maintenance activities.
Observe alarm messages sent by the BSS.
Analyses the alarm messages and rectify the faults accordingly.
6-18
Version 1.0
December 1996
Quality of Service Issues

Scenario: No Service Shown on Handset Main Indicators
Customers complain on not being able to get into the network. Drive tests show the unavailability of the network in certain regions. Zero trafc carried for TCH and SDCCH during busy hour. . Possible Causes The cell can not be used by any subscriber. The service is not available in certain areas caused by no RF coverage. The service is not available in certain areas caused by high interference with neighbor cells. Incorrect cell parameters. Drive tests show lack of RF coverage. Mobile stations display a high receive level. Related Indicators Proposals / Solutions Refer to section Zero trafc carried for TCH and SDCCH during normally busy hours. Consult RF Planning group to establish if area should be covered. Consult RF Planning group.
RF without interference available but certain mobile stations do not select the cell.
Check / correct C1=hcriteria parameters (RXLEV_ACCESS_MIN, MS_TXPWRMAX_CCCH). Check / correct cell access parameters.
Service not allowed for particular subscribers.
No abnormal values displayed for authentication, ciphering, or equipment validation failures. These failures can be seen in the following 5EE measurements: WRLSSUM.AUTHFL, WRLSSUM.CIPHFL, WRLSSUM.IMEIBLR, WRLSSUM.IMEIGLR.
Normal situation - no action required.
Not enough CCCH channels to fulll service requests
Refer to the section Not enough capacity to meet short-term CCCH demand
Version 1.0
December 1996
6-19
Possible Causes Not enough SDCCH channels to fulll service requests
Related Indicators
Proposals / Solutions Refer to the section Not enough capacity to meet short-term SDCCH demand
Scenario: Ability to Setup and Receive Calls Main Indicators
6 6
Customers complain about not being able to setup or receive calls after selecting the network. Possible Causes Not enough CCCH channels to fulll service requests. Not enough SDCCH channels to fulll service requests. Not enough TCH channels to fulll service requests. Related Indicators Proposals / Solutions Refer to the section Not enough capacity to meet short-term CCCH demand. Refer to the section Not enough capacity to meet short-term SDCCH demand. Refer to the section Not enough capacity to meet short-term TCH demand.
6-20
Version 1.0
December 1996
Scenario: Ability to Maintain Calls Main Indicators
6 6
The OMC-PMS reports Daily Cell TCH (DCTTR) and Daily Cell SDCCH (DCCTR) show a high percentage of dropped calls. The percentage of dropped calls determined according to the calculation FORCRLS / (LMSCLLA+MLSCLLA+MMSCLLA) indicated by the MSC-wide measurement report WRLSSUM is unusually high. Many customers complain about dropped calls. Possible Causes The RF coverage area is not sufcient and the mobile station moves outside the coverage area. Related Indicators Drive tests show no RF coverage. The situation is not optimum, but is not getting worse as indicated by the OMC-PMS reports Summary Cell TCH (SCTTR) and Summary Cell SDCCH (SCCTR). Proposals / Solutions Check BTS parameters (power, minimum receive level for mobile station.) Check HW (antenna system, TRX of RBS, and so on) Correct RF planning if required: consult RF Planning group. Check / correct the parameters of the neighbor cell in the object ADJCELL. Check / correct parameter PLMN_PERMITTED. Check / correct the accuracy of the HF of the neighbor cell Check / correct handover parameters of observed cell (for example, intercell handover enabled). Check / correct the parameters of the neighbor cell in the object ADJCELL
Mobile station can not synchronize to neighbor cells (SCH of neighbor cell not decodable).
RF coverage of neighbor cells available (shown by drive tests). Test mobile stations indicate no available neighbor cell in areas with coverage of the neighbor cell. No outgoing intercell handover attempt indicated by the report Daily Cell Handover (DCHOR).
Mobile station can synchronize to neighbor cell, but handover was not attempted.
No outgoing intercell handover attempt indicated by the OMC-PMS report Daily Cell Handover (DCHOR). Test mobile stations indicate the availability of neighbor cells. Protocol tester traces indicate mobile station measurement reports from the neighbor cells.
Version 1.0
December 1996
6-21
Possible Causes Bad handover success rates.
Related Indicators Observe the handover failure values indicated by the OMC-PMS report Daily Cell Handover (DCHOR).
Proposals / Solutions Refer to the section Ability to perform BSS controlled intercell handovers
Scenario: Ability to Perform BSS Controlled Intercell Handovers Main Indicators
6 6
The OMC-PMS report Daily Cell Handover (DCHOR) displays unexpected high handover failure rate for outgoing or incoming intercell-handovers.
NOTE:
A handover failure rate for incoming-handovers does not automatically indicate a handover was not performed, since the BSS may have performed a handover to a second cell. If a second choice cell is not available, then of course a handover was not performed. Possible Causes No handover possible; caused by incorrectly dened neighbor cells. Related Indicators The OMC-PMS report Daily Cell Handover (DCHOR) displays a high handover failures rate for outgoing handovers for the observed cell. The OMC-PMS report Daily Cell Handover (DCHOR) also displays a high handover failures rate for incoming handovers at cells which are not neighbor cells of the observed cell. The mobile station can not access the new cell; caused by its low output power (for example, 2W Handy). The OMC-PMS report Daily Cell Handover (DCHOR) displays a high handover failures rate for outgoing handovers for the observed cell. The OMC-PMS report Daily Cell Handover (DCHOR) also displays a high handover failures rate for incoming handovers at neighbor cells of the observed cell. Check / correct parameters of the observed cell contained in the BTS object ADJCELL. Proposals / Solutions Modify neighbor cell denitions (for example, modify BCCH frequency / BCC planning)
6-22
Version 1.0
December 1996
Possible Causes The target cell is overloaded and as a result, an intercell-handover into this cell is not possible.
Related Indicators The OMC-PMS report Daily Cell Handover (DCHOR) displays a high handover failures rate for incoming handovers at the observed cell. The OMC-PMS report Daily Cell TCH (DCTTR) displays a high load situation or congestion state for the observed cell.
Proposals / Solutions Refer to the section Higher trafc on the TCH than expected to check whether actions are required. Note: As mentioned above a handover could be performed instead into a cell of the second choice. Refer to section Higher trafc on the TCH than expected to check whether actions are required from the capacity point of view. Compare the counters attempted outgoing intercell handovers with causes with the counters successful outgoing intercell handovers with causes to see whether there were a lot of connection survival handovers which could not be performed or more better cell handovers
A handover could not be performed; caused by a overload situation in all possible neighbor cells.
The sum of the counters attempted outgoing intercell handovers with causes is higher than the counter attempted outgoing intercell handovers. The OMC-PMS report Daily Cell TCH (DCTTR) displays a high load situation or congestion state for the neighbor cells of the observed cell
Version 1.0
December 1996
6-23
6-24
Version 1.0
December 1996
Glossary
A
accumulation counter Accumulation counters are counters which are incremented as a particular event happens. An example would be the number of attempted TCH seizures; for each seizure request, an accumulation counter is incremented. The correct interpretation of these counters is closely linked with the measurement collection interval. answer bid ratio The answer bid ratio on a route or a destination code basis and during a specied time period is the ratio of the number of bids that result in an answer signal to the total number of bids. (per ITU-T Recommendation E.600) answer seizure ratio The answer seizure ratio on a route or a destination code basis and during a specied time interval is the ratio of the number of seizures that result in an answer signal to the total number of seizures. ((per ITU-T Recommendation E.600) availability The availability of a network resource is the amount of time the resource is usable. Instead of observing the availability of network resources, the unavailability of the resource is often monitored. (See unavailability.)
B
bids A bid is a single attempt to obtain the use of a resource of the type under consideration. In a network management context, the absence of a qualication implies a bid to a circuit group, a route, or a destination. (per ITU-T Recommendation E.600) blocked call attempt A blocked call attempt is a call attempt that is rejected due to a lack of resources in the network. (per ITU-T Recommendation E.600) BSCcontrolled Handover This includes all BSC controlled handovers except for those included in intraBTS. It would exclude all MSC controlled handovers including any intra-BSC handover that is controlled by the MSC. BTS A BTS is one or more transceivers all sharing the same Broadcast Channel. This is often called a sector.
Issue 1.0
December 1996
7-1
Glossary
busy hour The continuous one-hour period lying entirely in the time interval concerned for which the trafc or the number of call attempts is greatest. (per ITU-T Recommendation E.600). It does not necessarily begin on the hour. As an example, the busy hour could be from 10:15 to 11:15. busy day/busy hour The busy day/busy hour is obtained by calculating the busy hour of each day of the observation period (usually a week or a month) and then selecting the busiest hour of all these busy hours. It could be argued that a better name for this would have been Busy Hour of the Week/Month since the desired hour is the busiest hour during the interval whether that interval be a day, a week or a month.
C
call attempt A call attempt is an attempt to achieve a connection to one or more devices attached to a telecommunications network. At a given point in the network a call attempt is manifested by a single unsuccessful, or a successful, bid and all subsequent activity related to the establishment of the connection. (per ITU-T Recommendation E.600) call build-out The switch has successfully connected to the calls destination terminating ofce. In the case of a BSSAP trunk, it means that the switch is successfully connected to the BSC to which the mobile is currently connected. capacity The maximum capacity of a resource is the number of circuits available on the resource. For example, if seven trafc channels are available on a BTS, the maximum capacity of that BTS is seven Erlangs if all channels are busy for one hour. In reality, the usage of a resource rarely reaches its maximum. carried trafc The carried trafc is the trafc served by a pool of resources. (per ITU-T Recommendation E.600) cell Within this document a cell is the equivalent of a BTS. A cell site refers to a single site that often contains multiple BTSs or sectors. collection interval The collection interval is the time period over which the measurement is being calculated/ monitored. For example, the OMC-2000 sets the collection interval on the BSS to be 15 minutes. The BSS produces measurement counters at the end of every 15 minute interval. The collection interval is sometimes referred to as the recording interval. congestion Congestion occurs when all the resources of a portion of the network are fully utilized. Any further attempts to seize the resource will fail due to a blocking condition. controlling MSC This MSC is the MSC that a call originates on. Before the rst inter-MSC handover occurs, it is the only MSC involved in processing the call. critical trafc The critical trafc level of a resource is the maximum amount of carried trafc that will still maintain the grade of service standard of the network. When the network is at the critical trafc level, any increase in trafc will result in the grade of service not being maintained.
7-2
Issue 1.0
December 1996
Glossary
D
dropped call A dropped call is one that is unexpectedly terminated. An example of a dropped call is a mobile station leaving a cells coverage area when no other cell is close enough to facilitate a handover. In such cases, the call is dropped due to radio frequency loss.
E
Erlang One Erlang of trafc is equal to one circuit or channel being busy for an entire hour.
F
facilitating MSC This MSC is the same as the Controlling MSC, except that the term is limited to the context of a handover. If a call has been handed off from MSC1 (necessarily the Controlling MSC) to MSC2, and now MSC2 wants to hand off the call to MSC3, then MSC2 and MSC3 communicate via MSC1. That is why MSC1, the Controlling MSC, is called the Facilitating MSC within the context of a handover.
G
grade of service (GOS) The grade of service consists of a number of trafc engineering variables used to provide a measure of adequacy of a group of resources under specied conditions; these grade of service variables may be probability of loss, dial tone delay, and so on The parameter values assigned as objectives for grade of service variables are called grade of service standards. The values of grade of service parameters achieved under actual conditions are called grade of service results. (per ITU-T Recommendation E.600) The grade of service standard is also referred to as the designed grade of service.
H
holding time The holding time is the amount of time that the resource is in use per activation. For example, if a call lasts three minutes, the holding time of the trafc channel is three minutes.
I
initiating MSC This term is only used within the context of a handover. It identies the MSC that is connected to the mobile via the BSC before the handover. intensity counters Intensity counters are counters which indicate a rate or a percentage value. An example counter is the average number of simultaneous calls; this counter gives the average number of simultaneous calls throughout the measurement collection interval. These counters can be interpreted regardless of the collection interval.
Issue 1.0
December 1996
7-3
Glossary
intraBTS Handover Handovers that are always controlled by the BSC but are within a given BTS. The handover can be between time slots of the same transceiver or it can be between transceivers in the same BTS.
M
minimum data coverage The OMC-PMS system maintains with each row of data, a count of the number of minutes of data loaded for the day. All OMC-PMS reports support thresholds on the percent of data available for the day (i.e., the data coverage). Daily totals and busy hours will use interpolation to ll in missing data so that a person can compare one day with the next. However, a large quantity of missing data can be very misleading. So, for example, setting a minimum data coverage of 75% ensures that the report only includes cells where 18 hours of data are available. MSCcontrolled Handover This does not include any intraBTS nor BSC controlled handovers. However, it could include a handover where the old BTS and the new BTS are on the same BSC. This can happen when the BSC passes control of the handover to the MSC because the rst entry in the handover list is on a different BSC, but a subsequent entry in the list identies a BTS connected to the original BSC.
N
non-controlling MSC This is any MSC other than the controlling MSC. Therefore, if a call does not experience an interMSC handover, the call would not involve a non-controlling MSC.
O
offered trafc The trafc that would be carried by an innitely large pool of resources. (per ITU-T Recommendation E.600). That is, the amount of trafc that would be carried when no blocking is encountered. As expected, it is derived from the carried trafc. However, the actual blocking encountered is not used in the derivation.
P
peg counts A peg count is the same as an accumulation counter. That is, a peg counter gets incremented by one each time an event occurs.
The minimum data coverage option is not available with GSM Release 6.0. It is important to note that some 5ESS-2000 documentation makes references to interBSC and intraBSC handovers. These terms can cause confusion due to this MSCcontrolled intraBSC handover possibility. Therefore, for clarity sake, it is best to think of 5ESS-2000s interBSC handovers as referring to MSCcontrolled handovers and 5ESS-2000s intraBSC handovers as referring to BSC controlled handovers.
7-4
Issue 1.0
December 1996
Glossary
Q
quality of service (QOS) Quality of service consists of any performance variables, such as congestion, delay, and so on, which can be perceived by a user (per ITU-T Recommendation E.600).
R
raw data Raw data are the measurement results as collected by the network elements. This is the data prior to any analysis or correlation of the counters. recording interval This is the interval of time over which a single value of a counter is collected. This is always set to 15 minutes by the OMC-2000 for the BSS. For the 5ESS-2000, the user can set this to 15 minutes, 30 minutes or 60 minutes. For the 5ESS-2000 and the BSS, the 15 minute interval always begins on the quarter hour, that is, it is always on the hour, or at 15, 30 or 45 minutes after the hour. reporting intervall The reporting interval denes the times at which the measurement results collected during the recording interval are sent to the requester. In the case of the OMC-2000 and the BSS, recording interval is set to 15 minutes where the reporting interval is set to one hour. In this setup, the BSS will send the results of four collection intervals to the OMC-2000 each hour. In the case of the 5ESS-2000, the 5ESS-2000s Administrative Module (i.e., AM) collects the measurements from its SMs after every recording interval. Typically, it will send the appropriate measurements immediately on to the OMC-2000.
S
sampling Sampling is a method of producing intensity counter results. A sample is taken on the measured resource several times during the collection (i.e., recording) interval. The average of the samples is produced at the end of the recording interval. sector The equivalent of a BTS. segmentation Segmentation is the process of taking raw counter data and generating values for each possible hour segment of the day. For example, the OMC-PMS uses 15-minute segmentation, which results in hour values being generated for 00:00 to 01:00, 00:15 to 01:15, and so on. The results of segmentation are used to determine the busy hour for resources. seizure A seizure is a bid that obtains the use of a resource of the type under consideration. (per ITU-T Recommendation E.600)
T
target MSC This term is only used within the context of a handover. It identies the MSC that would be connected to the mobile via a BSC if the handover attempt is successful.
Issue 1.0
December 1996
7-5
Glossary
TC4 This is the three criteria table 4 full availability capacity trafc model. The TC4 trafc level is dened as that level of offered load that: provides a GOS of 0.008 at nominal load provides a GOS of 0.02 at 10% overload, and provides a GOS of 0.05 at 20% overload. TC4 tends to identify a trafc level that is less than the critical trafc after 30 or so circuits as the 2nd and 3rd criteria start to limit the value as the number of circuits increases.
U
unavailability The unavailability of a network resource is the amount of time the resource is not usable. The resource may be unavailable for a number of reasons, such as maintenance activities, component failures, and so on. utilization The utilization of a resource is the ratio of offered trafc to critical trafc expressed as a percentage. Since an element may handle trafc beyond its designed capacity, this gure can potentially be greater than 100%.
7-6
Issue 1.0
December 1996
Abbreviations
Numerics
5ESS No. 5 Electronic Switching System
A
AGCH Access grant channel AM Administrative module AUC Authentication center
B
BCE BSS central equipment BCH Broadcast channel BSC Base station controller BSS Base station system BTS Base transceiver station
C
CCCH Common control channel
Issue 1.0
December 1996
8-1
Abbreviations
CCH Control channel CM Communication module
D
DCCH Dedicated control channels
E
EIR Equipment identity register ETSI European telecomunications standards institute
F
FACCH Fast associated control channel FCCH Frequency correction channel FTAM File transfer and access method
G
GOS Grade of service GSM Global system for mobile communications
H
HLR Home location register
M
MAP Mobile application part MSC Mobile-services switching center
8-2
Issue 1.0
December 1996
Abbreviations
O
OMC Operation and maintenance center OMC-PMS Operation and maintenance center - Performance management subsystem OSS Operation and support system
P
PCH Paging channel PMS Performance management subsystem PSTN Public switched telephone network
R
RACH Random access channel RF Radio frequency
S
SACCH Slow associated control channel SCH Synchronization channel SDCCH Stand-alone dedicated control channel SM Switching module SSS Switching subsystem STF Speech transcoder frame Speech transcoding frame
Issue 1.0
December 1996
8-3
Abbreviations
T
TCE Transcoding equipment TCH Traffic channel TCP/IP Transmission control protocol/Internet protocol
V
VLR Visitor location register
W
WGSM Wireless global switching module WSM Wireless switching module
8-4
Issue 1.0
December 1996
This Appendix provides a list of the 5ESS-2000 and the BSS measurements that are available to monitor the wireless aspects of a service providers GSM network. Each measurement is identied by name and is followed by its denition. The measurements are not listed in alphabetical order but rather are grouped logically. To nd a specic counter, the reader should look up the counter name in the Index to Appendix A which will direct them to the page containing the desired denition. The measurements are ordered logically so that the reader can easily see measurements that are related to each other. All the measurements identied in this Appendix are passed from the OMC-2000 to the OMC-PMS and are available for the predened OMC-PMS reports (as dened in Chapter 5) and graphs. In addition, the user has the ability to create new OMC-PMS reports and graphs using the OMC-PMS Kingsher module. In addition, there is slightly different terminology used by the 5ESS-2000, the BSS and the OMC-2000 in describing how the measurements are collected. For the sake of consistency, the terminology used in this document shall be as follows:
Recording interval: This is the interval of time over which a single value of a counter is collected. This is always set to 15 minutes by the OMC-2000 for the BSS. For the 5ESS-2000, the user can set this to 15 minutes, 30 minutes or 60 minutes. For the 5ESS-2000 and the BSS, the 15 minute interval always begins on the quarter hour, that is, it is always on the hour, or at 15, 30 or 45 minutes after the hour. The 5ESS-2000 does allow the 30 or 60 minute interval to begin on any of the four quarter hours. In order to keep a consistent granularity of recording intervals, the user should set the 5ESS-2000 interval to 15 minutes. This would result in all counters going to the OMC-PMS having the same granularity. Reporting interval: The reporting interval denes the times at which the measurement results collected during the recording interval are sent to the requester. In the case of the OMC-2000 and the BSS, recording intervals are set to 15 minutes where the reporting interval is set to one hour. In this setup, the BSS will send the results of four collection intervals to the OMC-2000 each hour. In the case of the 5ESS-2000, its Administrative Module (i.e., AM) collects the measurements from its SMs after every recording interval.
Issue 1.0
December 1996
A-1
5ESS-2000 Measurements
The 5ESS-2000 provides a signicant number of trafc measurements of which only a subset are related to wireless communications. The 5ESS-2000 counters that are related to wireless communications are identied and dened in this Appendix. Chapter 4 contains a general description of the 5ESS-2000 reports whose measurement counters are described in this Appendix. A general description of all 5ESS-2000 trafc measurements can be found in the 5EE 8.1 Trafc Measurement Dictionary. The 5ESS-2000 collects related measurements and places them into specic reports. For example, measurements specic to an SM processor can be found in the SMCOMP report. There are also different types of reports. Summary reports provide measurements which are for the entire exchange and component reports are for a specic physical or logical component such as a trunk group. These reports are available through the 5ESS-2000 MFOS system. The measurements identied in this Appendix are also available through the OMC-PMS. Every 15 minutes the OMC-2000 initiates an FTAM request to the 5ESS-2000 which normally will then send the latest measurements to the OMC-2000. The OMC-2000 then immediately attempts to transfer these measurements to the Metrica system. If the transfer is successful, the les are immediately deleted on the OMC-2000. If the transfer is not successful, the OMC-2000 keeps the le for a maximum of two days. The OMC-2000 will continue to attempt to transfer the measurement to the OMC-PMS every 15 minutes. All the 5ESS-2000 trafc measurement reports identied in this document belong to the 5ESS-2000s C-Interval recording interval (sometimes called the collection interval). The length of this interval can be set to 15, 30, or 60 minutes using an ofce parameter. The time boundary can be set via a different ofce parameter and can have the value of 0, 15, 30, or 45 minutes after the hour. For example, if the C-interval is set to a length of 30 minutes with a 15 minute time boundary, measurements for C-interval reports are collected at 15 minutes and 45 minutes after the hour. The following pages of this Appendix identify the specic 5ESS-2000 reports that have counters that are of interest. The report is identied and then some or all of its associated counters are dened. These reports are either standard or recommended for GSM 5ESS-2000 installations. The list of reports appears in the index at the end of the book.
NOTE:
The counters listed on the pages that follow may not be all the counters that can be found in each report. Only the counters that are specically related to wireless communications are identied in this document.
Note that there are no tools on the OMC-2000 to view the 5ESS-2000 measurements.
A-2
Issue 1.0
December 1996
5ESS-2000 Wireless Summary (WRLSSUM)
These measurements reect the MSCs view of trafc. That is, they identify the number of calls, call releases, paging activity, MSC call setup related activities, and MSC controlled handover counts.
Call Setup
MLCLLA
Mobile to Land Call Attempts
This measurement is the total number of mobile-to-land call attempts identied by the MSC. It is pegged whenever an INTENDED ROUTING DETERMINED event is received by the MSC and the dest_type eld indicated the call is an originating mobile-to-land call attempt. MLSCLLA
Mobile to Land Successful Call Attempts
This measurement is the total number of mobile-to-land successful call attempts identied by the MSC. It is pegged whenever a SEIZURE/SET-UP COMPLETE event is detected by the MSC for a mobile-to-land call attempt. MLECALL
Mobile to Land Established Calls
This measurement is the total number of mobile-to-land calls answered. It is pegged by the MSC whenever the MSC detects that a mobile to land call has reached an ANSWER RECOGNISED event (that is, the SM call record indicated that the MSC has recognized an answer signal from the forward exchange). LMCLLA
Land to Mobile Call Attempts
This measurement is the total number of land-to-mobile call attempts identied by the MSC. It is pegged whenever an INTENDED ROUTING DETERMINED event is received by the MSC and the dest_type eld indicated the call is a land-to-mobile call attempt. LMSCLLA
Land to Mobile Successful Call Attempts
This measurement is the total number of land-to-mobile successful call attempts identied by the MSC. It is pegged whenever a SEIZURE/SET-UP COMPLETE event is detected by the MSC for a Land to Mobile call attempt. LMECALL
Land to Mobile Established Calls
This measurement is the total number of land to mobile calls being answered. It is pegged whenever the MSC detects a call from the land network to a mobile reaches an ANSWER RECOGNISED event.
Issue 1.0
December 1996
A-3
MMCLLA
Mobile to Mobile Call Attempts
This measurement is the total number of mobile-to-mobile call attempts identied by the MSC. It is pegged whenever an INTENDED ROUTING DETERMINED event is received by the MSC and the dest_type eld indicated the call is a mobile-to-mobile call attempt. It is pegged for intra-MSC calls and inter-MSC calls on an originating MSC that can access the HLR of the terminating mobile station. A mobile to mobile call is only pegged on the originating MSC, that is, it is not pegged on the terminating MSC. MMSCLLA
Mobile to Mobile Successful Call Attempts
This measurement is the total number of mobile-to-mobile successful call attempts identied by the MSC. It is pegged whenever a SEIZURE/SET-UP COMPLETE event is detected by the MSC for a mobile-to-mobile call attempt. It is pegged for intra-MSC calls and inter-MSC calls on an originating MSC that can access the HLR of the terminating mobile. A mobile to mobile call is only pegged on the originating MSC, that is, it is not pegged on the terminating MSC. MMECALL
Mobile to Mobile Established Calls
This measurement is the total number of mobile-to-mobile answered calls. It is pegged whenever MSC call processing detects a mobile-to-mobile call is being answered, meaning the B-side has reached an ANSWER RECOGNISED event. It is pegged for intra-MSC calls and inter-MSC calls on an originating MSC that can access the HLR of the terminating mobile. A mobile to mobile call is only pegged on the originating MSC, that is, it is not pegged on the terminating MSC. PAGATT
Paging Attempts
This is the total number of paging attempts by the MSC. Paging attempts per location area can be derived from the BSS counter totalNoAccessByProcedure.PCH. Note that MSC measurement PAGATT is not pegged for retries while the BSS counter totalNoAccessByProcedure.PCH would be pegged on retries. PAGATTS
Successful Paging Attempts
This is the number of times the paging procedure (as measured in PAGATT) is successful. It is pegged only in the MSC where the page response is received. AVGTPG
Average Time of Paging Procedure in Milliseconds
This is the average time spent for a successful paging procedure. Paging time is the interval between when the MSC receives a page request to the time when the MSC receives the page response message from the BSC. For a call, multiple paging procedures may be involved before a paging response is received. Unsuccessful paging procedures are not included in the calculation for this
A-4
Issue 1.0
December 1996
measurement. AVGTPG is the total time spent on successful paging attempts divided by the number of successful paging attempts.
Miscellaneous
OROAM
Roamer Originated Calls
This measurement provides the number of roamer originated calls in the MSC (i.e., roamers making a mobile call attempt). Used with MMCLLA and MLCLLA, the service provider can determined the percentage of call attempts that roamers originate. TROAM
Roamer Terminated Calls
This measurement provides the number of roamer terminated calls in the MSC. It is pegged on the MSC when a roamer terminates a call. Used with MMCLLA and LMCLLA, the service provider can determined the percentage of call attempts that are destined for roamers. CINCFWD
Completed Incoming Calls Forwarded for Mobile Subscribers
This measurement provides the number of incoming calls to mobile subscribers that were forwarded and subsequently answered. It is pegged when the ANSWER RECOGNISED event occurs for an incoming call to a mobile subscriber that is forwarded for any avor of call forwarding. MOBURLS
Mobile Unit Release
This measurement is the total number of normal call releases initiated by mobile stations. The release is initiated by the mobile in a DTAP message it sends to the MSC via the BSS. The MSC then sends a CLEAR COMMAND to the BSS to release the radio resource. It is at this point that the MSC pegs the counter. Later the BSS sends a CLEAR COMPLETE message back to MSC when the radio channel is released or the guard timer expires. FORCRLS
Forced Release
This is the total number of radio resource releases initiated by a CLEAR REQUEST from the BSS to the MSC specifying a failure reason. The most common reason is anticipated to be due to the loss of radio transmission between the BSS and the mobile. Other CLEAR REQUEST failure reasons can be radio interface message failure, operation and maintenance intervention, equipment failure, ciphering algorithm not supported, protocol error between BSC and MSC, and so on.
Issue 1.0
December 1996
A-5
OALTRK
Mobile Originating All Trunks Busy
This measurement provides the number of mobile originated calls that could not originate because all trunks between the MSC and BSS were busy. This measurement provides information about wireless origination failures with respect to trunk availability. ITALTRK
Mobile Terminating All Trunks Busy
This measurement provides the number of mobile terminated calls that failed to connect because all trunks between the MSC and BSS were busy. This measurement provides the number of wireless termination failures with respect to trunk availability.
Sub Activities of Mobile Connection Procedures A

AUTATT
Mobile Authentication Attempts
This measurement is pegged when the MSC sends an AUTHENTICATION REQUEST message to the mobile station during a mobile origination, termination, or location update. AUTHFL
Authentication Failures
This measurement is pegged when the MSC receives the AUTHENTICATION RESPONSE message from the mobile and the SRES value contained in the message does not match the expected SRES value thus indicating authentication failure. AUTHFL/AUTATT gives the service provider the percent of authentication checks that fail. CIPATT
Ciphering Attempts
This measurement is pegged when the MSC sends a CIPHER MODE COMMAND to the BSS to initiate ciphering for either a mobile origination, termination or location update. CIPHFL
Ciphering Failures
This measurement is pegged when the MSC receives the CIPHER MODE COMPLETE message from the BSS and the Chosen Encryption Algorithm parameter indicates that no encryption is being used. CIPHFL/CIPATT gives the service provider the percent of ciphering attempts that fail.
A-6
Issue 1.0
December 1996
TMSIA
TMSI Reallocation Attempts
This measurement is pegged when the MSC sends a TMSI REALLOCATION COMMAND to the mobile during an origination, termination, or location update. TMSIFL
TMSI Reallocation
This measurement is pegged when the TMSI reallocation procedure returns not OK for either a mobile origination, termination, or location update. Note that the TMSI REALLOCATION COMPLETE message dened in GSM 04.08 never returns a failure condition. TMSIFL/TMSIAT gives the service provider the percent of TMSI reallocation attempts that fail. IMEIATS
IMEI Check Attempt Requests Sent
This measurement is pegged by the MSC when the MSC sends an IDENTITY REQUEST message to the mobile with identity type set to IMEI. IMEIWLR
IMEI Valid List Results Received - White List
This measurement is pegged by the MSC when an IMEI valid list is received from the EIR during IMEI checking for a mobile origination or termination. IMEIGLR
IMEI Monitored List or Unknown IMEI Results Received - Grey List)
This measurement is pegged by the MSC when an IMEI monitored list result or unknown IMEI is received from the EIR during IMEI checking for a mobile origination or termination. There is an exchange option available to the service provider allowing them to choose whether these calls should be allowed or not. IMEIBLR
IMEI Prohibited List Results Received - Black List
This measurement is pegged by the MSC when an IMEI prohibited list result is received from the EIR during IMEI checking for a mobile origination or termination. MAPFOR
Attempted MT/PP and MO/PP Forwarding
This measurement provides the number of invoked forward short message MAP operations sent for Mobile-Terminating (MT) and Mobile-Originating (MO) Point-to-Point (PP) SMS messages. MAPFORS
Successful MT/PP and MO/PP Forwarding
This measurement provides the number of forward short message MAP operations sent which receive positive results for Mobile-Terminating (MT) and Mobile-Originating (MO) Point-to-Point (PP) SMS messages. MAPFORS/ MAPFOR gives the service provider the percent of operations that succeed.
Issue 1.0
December 1996
A-7
MSC Controlled Handovers
In order to fully appreciate the denitions of the inter-MSC Handover Measurements contained in this section, the reader needs to understand the MSC types dened here. The types correspond to the different roles that a given MSC plays in an inter-MSC handover scenario. The MSC types are:
Controlling MSC. This MSC is the MSC that the call originated on. Before the rst inter-MSC handover occurs, it is the only MSC involved in processing the call. non-Controlling MSC. This is any MSC other than the Controlling MSC. Therefore, if a call does not experience an inter-MSC handover, the call would not involve a non-Controlling MSC. Initiating MSC. This term is only used within the context of a handover. It identies the MSC that is connected to the mobile via the BSC before the handover. Target MSC. This term is only used within the context of a handover. It identies the MSC that would be connected to the mobile via a BSC if the handover attempt is successful. For intra-MSC handovers, the Initiating MSC and the Target MSC are the same MSC. Facilitating MSC. This MSC is the same as the Controlling MSC, except that the term is limited to the context of a handover. If a call has been handed off from MSC1 (necessarily the Controlling MSC) to MSC2, and now MSC2 wants to hand off the call to MSC3, then MSC2 and MSC3 communicate via MSC1. That is why MSC1, the Controlling MSC, is called the Facilitating MSC within the context of a handover.
HOREQI
Handover Requests Received by Initiating MSC
This measurement is immediately pegged by the Initiating MSC whenever it receives a BSSMAP HANDOVER REQUIRED message from the BSS for either an Intra-MSC Controlled handover or an Inter-MSC Controlled handover. Therefore, this measurement reects all MSC Controlled handover requests made by BSSs of Initiating MSCs. However, it does not reect all Handover attempts (as viewed by the 5ESS-2000) since some attempts are immediately rejected as indicated by measurement HOREJI. HOREJI
Handover Requests Rejected Immediately by Initiating MSC
After HOREQI gets pegged, this measurement will also be pegged if the Initiating MSC immediately rejects the HANDOVER REQUIRED message from the BSC. It can be used to detect a potential incompatibility with the BSC. (That is, the BSC is asking for a handover and the call is not in the correct state.) This counter gets incremented when the MSC does not support SDCCH handovers and the BSS request such a handover of the MSC.
A-8
Issue 1.0
December 1996
ITRAHOAT
Attempted Intra-MSC Controlled Handovers plus Successful intra-BTS Handovers
This measurement is pegged by the Initiating MSC whenever an Intra-MSC HANDOVER REQUEST is sent from the MSC to the new BSS. It includes intraMSC handover attempts when the MSC is a Controlling MSC or a non-Controlling MSC. This means that the counter is always pegged on the MSC that executed the handover. In addition, this measurement is pegged when the directly connected MSC receives the HANDOVER PERFORMED message after a BSC completes either a BSC Controlled handover or an intraBTS handover. This event is also pegged in MSC measurement HOCOMR. This measurement is the sum of all Intra-MSC controlled attempts plus BSS successful attempts. Note, this counter does not reect all handover attempts within the MSC and associated BSCs nor does it reect all successful handovers in the MSC and associated BSCs. However, ITRAHOAT minus HOCOMR does yield a useful value in that it results in the number of Intra-MSC Controlled attempts. ITRAHOCO
Successfully Completed Intra-MSC Handovers
This measurement is the sum of measurements HOCOMR and HOICOM. That is, this measurement is the total number of successful intra-MSC handovers within a given MSC and all BSCs connected to that MSC whether the MSC is a Controlling MSC or a non-Controlling MSC. It does not include any inter-MSC handovers. HOCOMR
Successfully Completed Intra-BSC Handovers
This measurement is pegged on an MSC when it receives a HANDOVER PERFORMED message from a directly connected BSC after the BSC successfully completes either a BSC Controlled handover or an intraBTS handover. HOICOM
Successfuly Completed Intra-MSC Controlled Handovers
This measurement is pegged by the Initiating MSC whenever an Intra-MSC handover is successfully completed by the Initiating MSC. It includes intraMSC handover attempts when the MSC is either a Controlling MSC or a non-Controlling MSC. This means that the counter is always pegged on the MSC that executed the handover. It is the total number of HANDOVER COMPLETE messages received by the Initiating MSC for Intra-MSC Controlled handovers. It does not include any BSC Controlled handovers.
Issue 1.0
December 1996
A-9
HOCOMNC
Successfully Completed Intra-MSC Controlled Handovers on Non-Controlling MSC, Pegged on Controlling MSC
This measurement is basically the same as measurement HOICOM except that it is only pegged when the Initiating MSC is a non-Controlling MSC. In addition, this measurement is not pegged on the Initiating MSC but rather it is pegged on the Controlling MSC. The Controlling MSC pegs this counter after it receives the message from the Initiating MSC (i.e., the non-Controlling MSC in this case) that reports the successful intra-MSC handover. Note this counter also gets incremented for BSC Controlled handovers in the Non-controlling MSC. HOFC
Successfully Completed MSC Controlled Handovers to First Choice
This measurement is pegged on the Initiating MSC when the MSC Controlled handover is completed successfully to the rst candidate on the list of possible handover choices. It includes both interMSC handovers and intraMSC handovers. HOSC
Successfully Completed MSC Controlled Handovers to Second Choice
This measurement is pegged on the Initiating MSC when the MSC Controlled handover is completed successfully to the second candidate on the list of possible handover choices. It includes both interMSC handovers and intraMSC handovers. HOBSC
Successfully Completed MSC Controlled Handovers to Beyond Second Choice
This measurement is pegged on the Initiating MSC when the MSC Controlled handover is completed successfully to a candidate beyond the second in the list of possible handover choices. It includes both interMSC handovers and intraMSC handovers. HOCOMI
Successfully Completed Inter-MSC Handovers by Initiating MSC
This measurement is pegged by the Initiating MSC when an Inter-MSC handover is successfully completed. (Does not include intra-MSC handovers.) The associated number of inter-MSC handover attempts as seen by an Initiating MSC is equal to: HOREQI: the total number of request the number of requests rejected by the 5ESS-2000 the number of requests that were intraMSC requests
minus HOREJI:
minus (ITRAHOAT - HOCOMR):
A-10
Issue 1.0
December 1996
ITERHOAT
Attempted Inter-MSC Handovers by Controlling MSC
This measurement is pegged on the Controlling MSC when an Inter-MSC handover request is performed. It gets pegged whether the Controlling MSC is acting as the Initiating MSC, Target MSC or whether it is acting as the Facilitating MSC. ITERHOCO
Successfully Completed Inter-MSC Handovers by Controlling MSC
This measurement is pegged on the Controlling MSC when an Inter-MSC handover is successfully completed. It gets pegged whether the Controlling MSC is acting as the Initiating MSC, Target MSC or whether it is acting as the Facilitating MSC. HOREQT
Attempted Inter-MSC Handover by Target MSC
This measurement is pegged on the Target MSC when an Inter-MSC handover request is received by the Target MSC HOCOMT
Successfully Completed Inter-MSC Handovers Completed by Target MSC
This measurement is pegged on the Target MSC when an Inter-MSC handover is successfully completed by the Target MSC. HOREQF
Attempted Inter-MSC Handover by Facilitating MSC
This measurement is pegged on the Facilitating MSC when an Inter-MSC handover request is received by the Facilitating MSC. If the Controlling MSC has already handed over the call to MSC2, and now MSC2 needs to hand over the call to MSC3, then the Controlling MSC (i.e., the Facilitating MSC within the context of the handover) will increment this counter for each handover attempt. If the rst handover attempt fails and a second must be attempted, then this counter would get incremented again. This counter is only incremented when the Controlling MSC is identied as a Facilitating MSC. That is, when the Controlling MSC is involved in the handover as the Initiating MSC or as the Target MSC, this counter is not incremented. HOCOMF
Successfully Completed Inter-MSC Handovers by Facilitating MSC
This measurement is pegged on the Facilitating MSC when an Inter-MSC handover is successfully completed by the Facilitating MSC.
Issue 1.0
December 1996
A-11
5ESS-2000 Wireless Handover (WRHAND) Cell to Cell
For each cell supported by this MSC, the measurements listed below are generated. WRHAND data is collected in the C-interval le. CELL_ID
Cell Identier
The cell identier. IIBTSHO

Successful Incoming MSC Controlled Handovers
This measurement is pegged on the Target MSC for Intra-MSC handovers and Inter-MSC handovers whenever a HANDOVER COMMAND generated by the MSC results in a HANDOVER COMPLETE message coming from the destination BSS. The measurement is further qualied by the Cell identity. That is, this measurement gives the number of Successful MSC Controlled Handovers directed toward the BTS identied by CELL_ID which is the new or terminating BTS. The MSC will update the appropriate counter corresponding to the BTS associated with the received HANDOVER COMPLETE message. This measurement only includes MSC Controlled handovers, that is, it excludes BSC Controlled and intraBTS handovers. OIBTSHO
Successful Outgoing MSC Controlled Handovers
This measurement is pegged on the Initiating MSC for Intra-MSC handovers and Inter-MSC handovers whenever it sends a CLEAR COMMAND to the originating BTS after having received a HANDOVER COMPLETE message from the destination BSS. This measurement is further qualied by CELL_ID which is the old or originating BTS. This measurement only includes MSC Controlled handovers, that is, it excludes BSC Controlled and intraBTS handovers.
A-12
Issue 1.0
December 1996
5ESS-2000 Home Location Register and Visitor Location Register (HLRVLR)
The HLRVLR measurements summarize the type and frequency of accesses to the HLR, VLR, AUC and EIR entities. HLRVLR data is collected in the C-interval.
HLR (Home Location Register)

SRGHLR
Number of Subscriber Records in the HLR
This measurement provides a running count of subscriber records in the HLR. The HLR increments the associated counter whenever an HLR record is created for a subscriber via RC/V and decrements it whenever an HLR record is deleted for a subscriber via RC/V. Its value at the end of the reporting interval is what is recorded. HLRROM
Number of HLR Inter-PLMN Roamers
This measurement is a count of home subscribers visiting other PLMNs, that is, the HLR subscribers which are roaming in a PLMN outside the home PLMN. The counter is updated during the Location Registration event when the HLR is updated to indicate the HLR subscriber is roaming in another PLMN. Its value at the end of the reporting interval is what is recorded. This measurement supports a service providers ability to evaluate subscriber usage patterns of the mobile network. HLRINT
HLR Terminating Call Interrogations
This measurement provides the number of terminating calls that resulted in HLR interrogations. It is pegged when the HLR receives the MAP SEND ROUTING INFORMATION service request or a MAP SEND INFO FOR INCOMING CALL service request. HLRTRCH
HLR Transactions Resulting from Call Handling
This measurement is a count of transactions at the HLR resulting from call handling. It is pegged whenever the HLR receives a message which is the result of a call handling event. This includes HLR messages received for call handling events associated with MAP SEND ROUTING INFORMATION service request, MAP Supplementary Services request (activation and deactivation), MAP Handover service request, MAP PROVIDE ROAMING NUMBER service request, MAP SEND INFO FOR INCOMING CALL service request, and MAP SEND INFO FOR OUTGOING CALL service request. Transactions at the HLR regarding the generation of authentication vectors are not included since they are considered as resulting from mobility management.
Issue 1.0
December 1996
A-13
HLRTRMM
HLR Transactions Resulting from Mobility Management
This measurement is a count of transactions at the HLR resulting from mobility management. This measurement is pegged whenever the HLR receives a message which is the result of a mobility management event. This includes HLR messages received for mobility management associated with Location management services and Authentication Management services. Also included are transactions at the HLR made for IMSI attach and detach events and Short Message Service processing. SENALT
Sent Alerts
This measurement provides the number of alerts from HLRs to be relayed toward the Short Message Service Centers. It is the number of MAP ALERT SERVICE CENTRE messages sent. Therefore, this measurement indicates MAP activity related to short message service. SSOHLR
Invoked SS Operations to the HLR
This measurement provides a count of MAP Supplementary Service (SS) operations which are received by the HLR. It includes all SS operations (for example, SS registrations, SS erasures, SS activations, SS deactivations, SS interrogations) and SS password registrations. It provides the ability to quantify the HLR activity related to SS operations. SSOHLRS
Successful Invoked SS Operations to the HLR
This measurement provides a count of Supplementary Service (SS) operations which are successfully performed in the HLR. It reects the successful completion of operations counted in measurement SSOHLR.
Authentication Events
AUTVRA
Authentication Vector Retrieval Attempts by the VLR
This measurement is pegged within the VLR whenever an attempt is made to retrieve authentication vectors from the HLR. This measurement is pegged only once per request, meaning that the request may be for up to ve vectors. AUTVRAS
Successful Authentication Vector Retrieval by the VLR
This measurement is pegged whenever the VLRs attempt to retrieve authentication vectors from the HLR (as measured by AUTVRA) is successful. This measurement is pegged only once per retrieval, meaning that the response may include up to ve vectors. This measurement along with AUTVRA provides the administration with information about potential network problems associated with retrieving authentication vectors from the HLR.
A-14
Issue 1.0
December 1996
RCVAUT
Received Authentication Vector Requests by the HLR
This measurement provides the number of authentication vector requests which are received by the HLR. It is the number of send parameter operations with parameter authentication set received by the HLR. This measurement is pegged only once per request, meaning that it may be for up to ve vectors. RCVAUTS
Successful Received Authentication Vector by the HLR
This measurement provides the number of successful authentication vector requests fullled by the HLR. This is the number of positive results of the activity measured by RCVAUT. This measurement is pegged only once when an authentication set is sent successfully, meaning that it may include up to ve vectors. AUCVR
Authentication vectors the HLR requested from the AUC
This measurement provides the number of vectors the HLR requested from the authentication centre (AUC). However, since multiple vectors can be requested through the use of the send parameter operation with parameter authentication set received by the HLR, the number of calls the HLR makes of the AUC can be much less. This measurement applies whether the AUC is integrated with the HLR or the AUC is a separate entity. Note that this counter is pegged differently than RCVAUT since RCVAUT gets pegged only once for each request (which can contain multiple vectors) whereas AUCVR gets pegged for each authentication vector the HLR requests of the AUC. AUCVRS
Authentication vectors the HLR received from the AUC
This measurement provides the number of vectors requested from the HLR of the authentication centre (AUC) that were successful. It is pegged for each authentication vector the HLR receives from the AUC, which may be integrated with the HLR or may be a separate entity. Measurement AUCVR allows the administration to monitor the HLR demand for vectors placed on the AUC, and can be used as a basis for comparison with measurement AUCVRS to identify deciencies in AUC effectiveness. When measurement AUCVR does not match measurement AUCVRS, the AUC is stressed beyond its capabilities. When an AUC deciency is identied for vector generation via MD-PHs or the SM, additional occupancy and overload information can be obtained from the PH or SM reports. When an AUC deciency is identied for vector retrieval via a separate AUC entity, re-engineering between the HLR and AUC can be performed.
Issue 1.0
December 1996
A-15
VLR (Visitor Location Register)

SRGVLR
Number of Subscribers Registered in the VLR
This measurement provides a running count of subscribers registered in the VLR including roamers. The VLR increments this measurement whenever it creates a VLR record for a subscriber and decrements it whenever it deletes a VLR record for a subscriber. Its value at the end of the reporting interval is what is recorded. This measurement allows the service provider to monitor VLR use and evaluate subscriber usage patterns of the mobile network. RSRGVLR Number of Roamers Registered in the VLR This measurement provides a running count of visiting subscribers (inter-network roamers) registered in the VLR. The VLR increments this measurement whenever it creates a VLR record for a visiting subscriber and decrements it whenever it deletes a visiting subscriber VLR record. Its value at the end of the reporting interval is what is recorded. A visiting subscriber is dened as a subscriber whose MCC (Mobile Country Code) and MNC (Mobile Network Code) are different than the MCC and MNC of the PLMN that this MSC is part of. This measurement along with SRGVLR allows the administration to monitor VLR use. Furthermore, it provides insight into the mix of home and visitor subscribers on each VLR. DELVLR Subscribers Deleted from the VLR This measurement provides the number of subscribers deleted from the VLR as a result of the VLR being full. That is, when the VLR is full, it will peg this measurement each time it deletes a subscriber record to add a new subscriber record. This measurement should generally be equal to zero unless there is a problem with data base engineering. This measurement along with SRGLVR and RSRGVLR allows the administration to monitor the VLR use. MSRNAL
Attempted MSRN Allocations
This measurement provides the number of attempts to allocate an MSRN by a VLR. It is based on the VLR receiving a MAP PROVIDE ROAMING NUMBER request from an HLR. This measurement indicates the number of times an MSRN allocation is requested. MSRNALS
Successful MSRN Allocations
This measurement indicates the number of times the VLR successfully fullled the request for an MSRN allocation. It is based on the successful result of the operation measured by MSRNAL.
A-16
Issue 1.0
December 1996
VLRTRCH
VLR Transactions Resulting from Call Handling
This measurement is a count of transactions at the VLR resulting from call handling. This measurement is pegged whenever the VLR is accessed as the result of a call handling event. This includes VLR messages received for call handling events associated with Mobile Termination, Mobile Origination, Provide Roam Number Request, Supplementary Services, Terminating Call Information Retrieval, and Originating Call Information Retrieval. Transactions which are the result of call handling events include those transactions required to complete a handover and supplementary service activations and deactivations. Transactions at the VLR regarding the generation of authentication vectors are considered as resulting from mobility management and are therefore not included here. VLRTRM
VLR Transactions Resulting from Mobility Management
This measurement is a count of transactions at the VLR resulting from mobility management. This measurement is pegged whenever the VLR receives a message which is the result of a mobility management event. This includes VLR messages received for mobility management associated with Location Registration/ Update and Authentication Vector Requests. Also included are transactions at the VLR made for IMSI Attach and Detach events and Short Message Service processing.
Location Update Events

HLRLUR
Location Update Requests Received at the HLR
This measurement provides a count of Location Update requests received at the HLR. It is pegged each time a location update or registration request (successful or unsuccessful) is received at the HLR. This measurement provides the service provider with the ability to determine if an excessive number of location updates are occurring. SHLRLU
Successful Location Update Performed at the HLR
This measurement provides a count of successful Location Update requests at the HLR. This measurement is pegged each time a successful location update or registration request is performed at the HLR. SHLRLUR/HLRLUR is the percent of successful Location Update Requests processed by the HLR.
Issue 1.0
December 1996
A-17
PLOCUP
Periodic Location Updates Performed at the VLR
This measurement provides a count of periodic Location Update requests. This measurement is pegged each time a location update request is received from a mobile as a result of the expiration of timer T3212 (as dened in GSM 04.08) in the mobile station. There is one value of T3212 for each MSC and its value is set by the network operator. The BSSs connected to that MSC will broadcast this value of timer T3212 in SYSTEM INFORMATION TYPE 3 message on the BCCH to all mobiles. This measurement with GLOCUP and GLOUPI allows the service provider to determine if an excessive number of periodic location updates are occurring at the MSC. PLCUFL
Failed Periodic Location Updates Attempted at the VLR
This measurement is a count of periodic Location Update requests which failed. That is, it is a count of the number of attempts as recorded in counter PLOCUP that failed. GLOCUP
Geographic Location Updates, Intra-VLR
This measurement provides a count of Intra-VLR geographic Location Update requests. This measurement is pegged each time an Intra-VLR location update request is received from a mobile station as the result of the mobile determining that it has entered a new location area. (That is, the new Location Area ID is within the same VLR as the old Location Area ID.) GLCUFL
Geographic Location Update Failures, Intra-VLR
This measurement is a count of Intra-VLR geographic Location Update requests which failed. That is, it is a count of the number of attempts as recorded in measurement GLOCUP that failed. GLOUPI
Geographic Location Updates, Inter-VLR)
This measurement provides a count of Inter-VLR geographic Location Update requests. It is pegged at the new VLR each time an Inter-VLR location update request is received from a mobile station as the result of the mobile determining that it has entered a new location area. (That is, the old Location Area ID is either null or the new Location Area ID is not in the same VLR as the old Location Area ID.) GLUFLI
Geographic Location Update Failures, Inter-VLR
This measurement is a count of Inter-VLR geographic Location Update requests which failed. That is, it is a count of the number of attempts as recorded in measurement GLOUPI that failed.
A-18
Issue 1.0
December 1996
IMSI Events
IMSIATT
IMSI Attach
This measurement is pegged whenever an IMSI attach event occurs. Since, the service provider has the ability to allow or prevent MSs from issuing IMSI Attach and IMSI Detach operations, this count could be zero. IMSIATF
IMSI Attach Failures
This measurement is pegged whenever an IMSI attach event fails. That is, it reects how many of the IMSIATT events failed. IMSIDET
IMSI Detach
This measurement is pegged whenever an IMSI detach event occurs. Since there is a parameter broadcast out the BCCH that tells MSs whether or not they should perform IMSI Attach and Detach, this value could be zero. Also, since an IMSIDET does not occur when a mobile drives out of coverage but an IMSIATT does occur when the mobile powers up, there can be a wide discrepancy between the values of IMSIATT and IMSIDET.
IMEI Events
IMEIATR
IMEI Check Attempt Requests Received
This measurement is pegged when an IMEI check request is sent to the EIR. This measurement provides the service provider with information about the number of times the MSC is performing IMEI checks. IMEIATR is equal to the sum of IMEIBLS plus IMEIGLS plus IMEIWLS. IMEIWLS
IMEI Valid List Results Sent
This measurement is pegged when an IMEI valid list result is sent from the EIR to the MSC during IMEI checking indicating that the IMEI is valid. IMEIGLS
IMEI Monitored List or Unknown IMEI Results Sent
This measurement is pegged when an IMEI monitored list result or unknown IMEI error is sent to the MSC during IMEI checking indicating a potential problem with this mobile. There is an MSC option available to the service provider that lets them select whether such calls should be allowed or prevented.
Issue 1.0
December 1996
A-19
IMEIBLS
IMEI Prohibited List Results Sent
This measurement is pegged when an IMEI prohibited list result is sent from the EIR to the MSC during IMEI checking indicating that the IMEI is on the black list and so it should not and does not receive service.
5ESS-2000 Trunk Group Component (TGCOMP)
The TGCOMP measurements provide call activity and performance data on individual trunk groups. TGCOMP data is collected in the C-interval. TGN
Trunk Group Number
The Trunk Group number to which the Trunk Group measurements apply. INSVC
Trunks in Service
This count provides the number of trunks in the trunk group that are in service at the time of C-Interval data collection. OOSMTCE
Trunks Out of Service Maintenance Disabled
This measurement provides a count of the number of trunks which are out of service due to maintenance reasons, both manual and automatic. Trunks out of service for reasons such as awaiting connection by another administration are not included in this count because they would be in another qualied state, such as out of service blocked. Only trunks in the out of service (OOS) state with qualier maintenance (MTCE) and with operational restriction disabled (DSBLD) are included in this count. OOS
Trunks Out of Service
This measurement provides the number of trunks in the trunk group that are out of service for reasons other than being made maintenance disabled manually or automatically at the time of C-interval data collection. This measurement is a count of all the trunks out of service minus those trunks which are Out Of Service Maintenance Disabled (i.e., OOSMTCE).
A-20
Issue 1.0
December 1996
Incoming Trunk Group

ISEIZE
Seizure of an Incoming Trunk
This measurement provides the number of times any member of a trunk group is seized by an incoming call. Since BSSAP trunks are always outgoing trunks, their activity is not reected in the Incoming Trunk Group Measurements. The sum of this measurement over all trunk groups is roughly the same as SMCOMP.IN_SEIZE over all SMs. IROUTE
Incoming Seizures for which Required Information to Setup a Through Connection is Available
This measurement provides the total number of incoming seizures for which the required information to set up a through connection is available in the MSC. This measurement refers to all incoming calls, both calls that terminate in this MSC and calls that are directed out of this MSC to terminate elsewhere. This measurement is the number of incoming seizures which have reached the INTENDED ROUTING DETERMINED event. This measurement will be set to 0 for outgoing trunk groups including BSSAP trunk groups. ISETUP
Incoming Seizures for which the Seizing Signal or Corresponding Address Information is Sent to the Subsequent Exchange
This measurement provides the total number of incoming seizures for which sufcient address information (e.g. Initial Address Message) has been received, which are addressed to a certain outgoing circuit group and for which the seizing signal or the corresponding address information is sent to the subsequent exchange or to BSCs. This measurement is only intended for calls that originate from the PSTN and terminate outside this MSC or calls that will be directed to mobiles through BSSAP trunks. This measurement is the number of incoming seizures for which SEIZURE/SET-UP COMPLETE has occurred. ISATTMP
Incoming Seizures which have been Built Up Into the Outgoing Network
This measurement provides the total number of incoming seizures for which the originating terminal process receives a message from the terminating terminal process to indicate completion of outpulsing. This measurement is the number of incoming seizures for which CALL BUILD-UP COMPLETE has occurred for the outgoing part of the call. This measurement is intended for calls that terminate outside this MSC or calls that will be directed to mobiles through BSSAP trunks. IANS
Incoming Answer
This measurement provides the number of Incoming Calls which are answered. The count applies only to incoming trunks or incoming calls on two-way trunks.
Issue 1.0
December 1996
A-21
ICONGES
Number of Incoming Call Attempts Lost due to Internal Congestion
This measurement provides a summary per incoming and bothway trunk group of the ineffective incoming call attempts which occur due to internal congestion as dened in ITU-T Recommendation E.502 Section 4.2.2. This measurement is provided for incoming and bothway trunk groups. For outgoing trunk groups it will be set to 0. According to the TSS denition of this measurement in ITU-T Recommendation E.502 Section 4.2.2, internal congestion includes blocking through the switching network, unavailability of common resources, and system faults. This measurement should be pegged for all call incompletion reasons accounted for by the following call incompletion codes: Failure to Obtain Switch Resources (i.e., CICSUM.RESFA), Switch Hardware Failure (i.e., CICSUM.HWDFA), and Transient Call Lost (i.e., CICSUM.TCL) ITRANSZ
Incoming Transit Seizures
This measurement is the total number of incoming seizures for which the routing has been determined to be a transit call. That is, the number of calls associated with incoming PSTN trunks that have reached the INTENDED ROUTING DETERMINED event and the state of the call has been identied as transit. This counter does not include PSTN incoming calls directed to BSSAP trunks.
Outgoing Trunk Group

OATTMPT
Trunk Group Outgoing Attempts
This measurement provides the number of times an attempt is made to nd an outgoing trunk in a given trunk group. The count only applies to outgoing or two-way trunk groups. In addition to outgoing inter-exchange call attempts, this counter includes wireless mobile originating, terminating, and handovers utilizing BSSAP trunk groups. OVFL
Trunk Group Overow
This measurement provides the number of times an attempt made to access a trunk group for an outgoing call (as reected by measurement OATTMPT) was unsuccessful because no available trunk could be found in a given trunk group.
A-22
Issue 1.0
December 1996
OSEIZE
Seizure of an Outgoing Trunk
This measurement provides the number of outgoing trunks that have been seized. It is pegged when port activation for the trunk has occurred. For inband signalling, port activation is when the seizure signal is sent, and for CCS it is when the IAM is sent. This measurement is pegged even if a double seizure occurs, since the trunk was seized. In addition to outgoing inter-exchange call seizures, this counter includes mobile originating calls, mobile terminating calls, and handovers utilizing BSSAP trunks. The sum of this measurement over all trunk groups is roughly the same as the following summed over all SMs: SMCOMP.OUT_SEIZE + SMPCOMP.WO_SEIZE + SMCOMP.WT_SEIZE + SMCOMP.WO_HNDSEIZE + SMCOMP.WT_HNDSEIZE OSATTMP
Outgoing Seizures which have been Built-Up into the Network
This measurement provides the number of outgoing seizures which have been built-up into the network. For inband signalling this occurs when the B signal (the called party status indicator) or equivalent is received, and for CCS it is when the ACM (i.e., address complete message) is received. For mobile terminating calls, it occurs when the MSC receives the ALERTING message from the mobile. For mobile originating calls it occurs twice, once for the BSSAP trunk and once for the outgoing trunk. For the BSSAP trunk, it occurs just before the MSC sends an Assignment Request message to the BSS. For the outgoing trunk, it occurs with the reception of the ACM message. For handovers it occurs when the MSC receives the Handover Request Acknowledgment message from the new BSS. The count only applies to outgoing trunks (including BSSAP trunks) or two-way trunk groups. OANS
Outgoing Answer
This measurement provides the number of calls over the outgoing trunk group that are answered. It includes mobile originating calls, mobile terminating calls, and successful handovers on BSSAP trunks. The count only applies to outgoing or two-way trunk groups. DBLSZR
Double Seizure
This measurement provides the number of double seizures (glare) on a trunk group basis. The count only applies to outgoing two-way trunks utilizing inband signalling or Common Channel Signalling. The count is incremented each time a double seizure occurs whether or not the exchange is the controlling exchange and regardless of whether the call fails or is retried.
Issue 1.0
December 1996
A-23
BSSAP Trunk Group

MATTMPT
Mobile Originating Trunk Group Attempts
This measurement provides the number of attempts to nd an outgoing trunk in a BSSAP trunk group for an originating mobile or for an A-party mobile that is involved in a MSC Controlled handover. It is pegged each time a BSSAP trunk group is hunted on behalf of an A-party mobile subscriber. A-party call origination and A-party handovers are included. Comparison with total outgoing attempts (i.e., OATTMPT) for a BSSAP trunk group can yield non A-party trunk group activity. MSEIZE
Mobile Originating Trunk Group Seizure
This measurement provides the number of BSSAP trunks that have been seized (MATTMPT reects the number of associated attempts) on behalf of an A-party mobile subscriber. It is pegged when port activation for the BSSAP trunk has occurred for an A-party mobile subscriber, including call origination and handovers. Comparison with total outgoing seizures (i.e., OSEIZE) for a BSSAP trunk group provides non A-party trunk group activity. The sum of this measurement over all trunk groups is roughly the same as: SMCOMP.WO_SEIZE plus SMCOMP.WO_HNDSEIZE over all SMs. MOVFL
Mobile Originating Trunk Group Overow
This measurement provides the number of attempts to access an outgoing BSSAP trunk group (as indicated by measurement MATTMPT) for an A-party mobile subscriber that were unsuccessful because no available trunk could be found in a given BSSAP trunk group. A-party call origination and A-party handovers are included. Comparison with total outgoing overows (i.e., OVFL) for a BSSAP trunk group provides non A-party trunk group activity.
Usage Counters
BWINCU
Incoming Usage
This measurement provides the usage for incoming trafc on bothway trunks, incoming trunks, and for A-party trafc (i.e., mobile originated both before and after a handover) on BSSAP trunks. It is approximated by scanning every one hundred seconds to determine if the call type is incoming. This measurement is provided in Erlangs (or CCS) times 100. The sum of this measurement over all trunk groups is roughly the same as: SMCOMP.O_USAGE plus SMCOMP.IN_USAGE over all SMs.
A-24
Issue 1.0
December 1996
IANSUSG
Incoming Answered Call Usage
This measurement provides the usage for incoming trafc on bothway trunks, incoming trunks, and for A-party trafc (i.e., mobile originated both before and after a handover) on BSSAP trunks for calls that are in the talking state. It is approximated by scanning every one hundred seconds to determine if the call type is incoming and in the talking state. This measurement is provided in Erlangs (or CCS) times 100. BWOUTU
Outgoing Usage
This measurement provides the usage for outgoing trafc on bothway trunks, outgoing trunks, and for B-party trafc (i.e., mobile terminated both before and after a handover) on BSSAP trunks. It is approximated by scanning every one hundred seconds to determine if the call type is outgoing. This measurement is provided in Erlangs (or CCS) times 100. The sum of this measurement over all trunk groups is roughly the same as: SMCOMP.T_USAGE plus SMCOMP.OUT_USAGE over all SMs. OANSUSG
Outgoing Answered Call Usage
This measurement provides the usage for outgoing trafc on bothway trunks, outgoing trunks, and for B-party trafc (i.e., mobile terminated both before and after a handover) on BSSAP trunks for calls that are in the talking state. It is approximated by scanning every one hundred seconds to determine if the call type is outgoing and in the talking state. This measurement is provided in Erlangs (or CCS) times 100. MTUSG
Trunk Group Maintenance Usage
This measurement provides the usage generated on the trunks which are disabled for maintenance. It excludes trunks out of service for reasons other then maintenance, for example, trunks awaiting connection by another administration. This measurement is provided in Erlangs (or CCS) times 100. TOTUSG
Trunk Group Total Usage
This measurement provides the sum of trafc usage and maintenance usage for the trunk group. It does not include the usage for trunks which are out of service for reasons other than maintenance. For example, it does not include trunks which are out of service awaiting connection by another administration would not be included in this measurement. This measurement is provided in Erlangs (or CCS) times 100. In many cases TOTUSG will equal the sum of: BWINCU plus BWOUTU plus MTUSG.
Issue 1.0
December 1996
A-25
5ESS-2000 Switching Module Component (SMCOMP)
The SMCOMP measurements provide activity and performance data on individual Switching Modules. SMCOMP data is collected in the C-interval. The trunking measurements that appear here are broken out on an SM basis whereas TGCOMP measurements provide trunking data on a trunk group basis. All USAGE values are produced on an SM (Switching Module) basis and are approximated by scanning the call record every 100 seconds. The USAGE measurement is provided in Erlangs or CCS times 100. SM
Switching Module Identity
The Switching Module number to which the measurements apply.
Line and BSSAP Trunk
This group of counters include activity both before and after a handover. O_USAGE
Originating Usage
This measurement provides the trafc usage generated for the registered originating Half Calls. This includes wireline as well as mobile originated calls. It also includes usage associated with mobile originated calls that have been handed off to trunks connected to this SM. That is, it includes all usage on BSSAP trunks for calls associated with the A-party mobile. Therefore, it includes the sum of: any originating wireline usage plus WO_USAGE plus WO_HNDUSG. This measurement is provided in Erlangs (or CCS) times 100. O_SEIZE
Originating Seizures
This measurement provides the total number of times the system initiates action leading to a readiness to receive customer digits, or to process a call for which no digits are required. This includes wireline as well as mobile originated calls. Therefore, it includes the sum of: the number of originating wireline calls plus SMCOMP.WO_SEIZE. For mobile originated calls, it is pegged by the MSC upon receiving the SETUP message from the mobile.
A-26
Issue 1.0
December 1996
O_ANS
Originating Calls Answered
This measurement provides the number of calls answered per SM and is pegged on the SM on which the call originates. It provides the number of calls on a given SM which originated on that particular SM and reached the ANSWERED RECOGNISED event. This is based upon the answer event being reported to the call record. Therefore, it includes the sum of: the number of answered wireline calls plus SMCOMP.WO_ANS. For mobile originated calls, the counter is not actually pegged upon receipt of the ANSWER RECOGNISED event but rather after the succeeding event of when the MSC receives the CONNECT ACKNOWLEDGEMENT message from the mobile. T_USAGE
Terminating Usage
This measurement provides the trafc usage generated for the registered Terminating Calls. This includes wireline as well as mobile terminated calls. It also includes usage associated with mobile terminated calls that have been handed off to trunks connected to this SM. That is, it includes all usage on BSSAP trunks for calls associated with the B-party mobiles. Therefore, it includes the sum of: any terminating wireline usage plus SMCOMP.WT_USAGE plus SMCOMP.WT_HNDUSG. This measurement is provided in Erlangs (or CCS) times 100. T_SEIZE
Terminating Seizures
This measurement provides the number of Terminating Half Calls. It includes wireline as well as mobile terminated calls. Therefore, it includes the sum of the number of terminating wireline calls plus SMCOMP.WT_SEIZE. Calls to a busy line do not require a terminal process and so are not included in this counter. For mobile terminating calls, this counter is pegged just before the MSC sends the SETUP message to the mobile.
PSTN Trunk
IN_USAGE
Incoming Usage
This measurement provides the trafc usage generated for the registered Incoming Half Calls through the PSTN trunks connected to this SM. It does not include BSSAP trunks. This measurement is provided in Erlangs (or CCS) times 100. IN_SEIZE
Incoming Seizures
This measurement provides the number of incoming calls from the PSTN to this SM. The sum of this measurement over all SMs is roughly the same as TGCOMP.ISEIZE over all trunk groups.
Issue 1.0
December 1996
A-27
OUT_USAGE
Outgoing Usage
This measurement provides the trafc usage generated for the registered Outgoing Half Calls through the PSTN trunks connected to this SM. It does not include BSSAP trunks. This measurement is provided in Erlangs (or CCS) times 100. OUT_SEIZE
Outgoing Seizures
This measurement provides the number of outgoing calls to the PSTN from this SM that have seized an outgoing circuit. The sum of this measurement over all SMs is only a part of what is included in TGCOMP.OSEIZE over all trunk groups.
BSSAP Trunks before Handover only

MSGDEL
Wireless Setup Message Delays
This measurement is the number of mobile terminating calls for which the allowable time between the sending of a SETUP message to the mobile station and the return of an ALERTING or CALL PROCEEDING message has been exceeded. This measurement is pegged after the SEIZURE SETUP COMPLETE event (thus indicating that the MSC is alerting the terminating mobile) and timer T303 has expired. Timer T303 for mobile terminating calls can be set via recent change. Note that Timer T303 for mobile originating calls is in the mobile and is set to 30 seconds per GSM 04.08. MSGDEL does not record the expiration of T303 when it is in the mobile for mobile originating calls and so does not include call setup delays for originating mobiles. WO_USAGE
Wireless Originating Usage
This measurement provides the trafc usage generated for all mobile originated calls where the call originated on a BSSAP trunk connected to this SM and was not the result of the call being handed off into this SM. This value is included as part of O_USAGE. This measurement is provided in Erlangs (or CCS) times 100. WO_SEIZE
Wireless Originating Seizures
This measurement provides the number of originating attempts which have successfully seized MSC resources which occurs when the MSC has received a SETUP message from the mobile. This measurement is pegged during the SEIZURE RECOGNISED event. Note, this counter does not get pegged for calls that are handed over into this SM. This value is included as part of O_SEIZE. The average holding time per seizure (i.e., WO_USAGE divided by WO_SEIZE) is expected to be much shorter than the equivalent on the Terminating side due to the numerous reasons the A-party may prematurely end the call.
A-28
Issue 1.0
December 1996
WO_ANS
Wireless Originating Calls Answered
This measurement provides the number of mobile originated calls that are answered and it is pegged on the SM on which the call originates. This measurement provides the number of mobile calls which originated on a particular SM and reached the ANSWER RECOGNISED event. This is based upon the answer event being reported to the call record. This value is included as part of O_ANS. In addition, this value added up over all SMs should equal: WRLSSUM.MMECALL plus WRLSSUM.MLECALL. WT_USAGE
Wireless Terminating Usage
This measurement provides the trafc usage generated for all mobile terminated calls where the call initially terminated on a BSSAP trunk connected to this SM and was not the result of the call being handed off into this SM. This value is included as part of T_USAGE. This measurement is provided in Erlangs (or CCS) times 100. WT_SEIZE
Wireless Terminating Seizures
This measurement provides the number of terminating seizures to mobile subscribers who are initially connected to the BSSAP trunks connected to this SM. This measurement is pegged for all mobile terminating calls that have reached the SEIZURE/SET-UP COMPLETE event. Note that this counter does not include calls that are handed over into this SM. This value is included as part of T_SEIZE. The average holding time per seizure (i.e., WT_USAGE divided by WT_SEIZE) before a handover is expected to be longer than the equivalent after a handover since the probability of hanging up a call in the rst few seconds is less than at any other time of a call.
BSSAP Trunks after Handover only

WO_HNDSEIZE
Trunk Seizures due to Handover of a Wireless Originating Call
This measurement provides the number of mobile originating calls that are handover into this SM. This measurement is pegged when this SM sends a HANDOVER COMPLETE message to the original SM for a call that is a mobile originating call. Note that this measurement does not count call originations and so is not included as part of O_SEIZE. WO_HNDUSG
Trunk Usage for Wireless Originating Calls after Handovers
This measurement provides the trunk usage for the mobile originating calls that are handover into this SM as pegged in measurement WO_HNDSEIZE. That is, this counter only reects the usage generated after a handover. This value is also included as part of O_USAGE. This measurement is provided in Erlangs (or CCS) times 100.
Issue 1.0
December 1996
A-29
WT_HNDSEIZE
Trunk Seizures due to Handover of a Wireless Terminating Call
This measurement provides the number of mobile terminating calls that are handover into this SM. This measurement is pegged when this SM sends a HANDOVER COMPLETE message to the original SM for a call that is a mobile terminating call. This measurement is always pegged on a non-controlling MSC for intra-MSC handovers (i.e., call was already handed over to a 2nd MSC which then performed an intraMSC handover), regardless of whether the handed over mobile was originating or terminating on the controlling MSC. Note that this measurement does not count call terminations and so is not included as part of T_SEIZE. WT_HNDUSG
Trunk Usage for Wireless Terminating Calls after Handovers
This measurement provides the trunk usage for the mobile terminating calls that are handover into this SM as pegged in measurement WT_HNDSEIZE. That is, this counter only reects the usage generated after a handover. This value is also included as part of T_USAGE. This measurement is provided in Erlangs (or CCS) times 100.
Miscellaneous
LOAD
Processor Load
This measurement provides the number of terminal processes created for line completion, trunk origination or trunk termination. OCCUP
Processor Occupancy
The MSC maintains a counter that identies the total time (in seconds) the processor is doing essential work, such as processing calls. This measurement translates this total time to a percentage (0 to 100) of time that the processor is busy (i.e., not idle). REOVLD
Calls Blocked During AM Overload
This measurement provides the number of calls that failed in the Switching Module, resulting in reorder, because the route request could not be sent to the Administrative Module because the Administrative Module was in overload.
A-30
Issue 1.0
December 1996
VEC0
Zero vectors retrieved by the HLR for an authentication vector request
This measurement is the number of times the HLR found zero authentication vectors available to satisfy a request for vectors. This measurement is pegged regardless of whether the HLR successfully requests a vector from the AUC after detecting an empty vector set for a subscriber. When no vectors are available for SM2000 where the HLR and AUC are integrated, a vector is generated in SM real-time if no overload condition exists. The service provider can use this measurement in estimating the portion of SM occupancy used for authentication vector generation. It also allows one to identify AUC capacity problems when a large number of empty vector sets exist in the HLR.
5ESS-2000 Call Incompletion Code Summary (CICSUM)
The CICSUM measurements provide information about how calls terminate. The total number of calls is reected in CICSUM measurement TLREQ. Each of these calls will result in one and only one of the other CICSUM measurements being incremented by one. In addition, all call incompletion codes are mapped into exactly one CICSUM measurement (not counting TLREQ), although more than one incompletion code may be included in a CICSUM measurement (e.g., UNF). CICSUM data is collected in the C-interval.
Basic
TLREQ
Total Count of Requests
This measurement provides the total count (for the exchange) of the number of requests as determined by the total number of call records created during the measurement interval. TLREQ should equal the sum of all other counters in the CICSUM report. TSUCC
Number of Successful Calls
This measurement provides the number of calls that were successful in that no Call Incompletion Code was written into the call record. This counter gets pegged when the call is released. Note that many normal calls are unsuccessful including calls to mobiles not responding to paging messages, calls to busy subscribers, calls abandoned during ringing, etc.
Issue 1.0
December 1996
A-31
GSM Related
NORESP
No Response to Paging
This measurement provides the number of calls that were incomplete because the mobile station did not respond to the MSCs page request. Even when the 5ESS-2000 pages the mobile multiple times for a single call attempt, this counter is pegged only once. There are two main reasons why the mobile might not respond to a page. 1. When the 5ESS-2000s IMSI attach/detach capability is activated, the mobile should detach itself from the network whenever the user turns the mobile off. This tells the 5ESS-2000 that the mobile is powered down and therefore the 5ESS-2000 will not even attempt paging the mobile when it is detached. However, sometimes when the user of the mobile drives out of coverage, the mobile will not be able to issue the IMSI DETACH INDICATION message. In this case, a mobile terminated call to this user will result in the 5ESS-2000 attempting to page the mobile but the mobile obviously does not respond. Therefore, this counter would be incremented. When the 5ESS-2000s IMSI attach/detach capability is deactivated, then all mobile terminated calls will result in a page message, and for those mobiles that are powered down or out of coverage, there will be no page response and so this counter will get incremented.
2.
WRPRERR
Wireless Protocol Error
This measurement provides the number of calls that were incomplete because missing or incorrect information was received in the IE (information element) of a DTAP or BSSAP message. TMSIFL
TMSI Failures
This measurement provides the number of calls that were incomplete because a TMSI failure occurred during a mobile origination, termination, or location update. AUTHFL
Authentication Failures
This measurement provides the number of calls that were incomplete because an authentication failure occurred during a mobile origination, termination, or location update. CIPHFL
Ciphering Failures
This measurement provides the number of calls that were incomplete because a ciphering failure occurred during a mobile origination, termination, or location update.
A-32
Issue 1.0
December 1996
IMEIFL
IMEI Failures
This measurement provides the number of calls that were incomplete because an IMEI failure occurred during a mobile origination or termination.
Incoming Call
IFS
Incoming False Start
This measurement provides the number of incoming calls that were incomplete because a Clear Forward signal was recognized after trunk seizure and prior to receipt of digits or determination that digits were not required. IPDTO
Incoming Partial Dial Time-out
This measurement provides the number of incoming calls that were incomplete because an insufcient number of digits (based either on translation table information and digit analysis or on backward signalling messages) was received, (inter digital timing was exceeded) given that at least one digit and no Clear Forward signal was recognized. IPDA
Incoming Partial Dial Abandon
This measurement provides the number of incoming calls that were incomplete because a CLF (Clear Forward) signal was recognized after receipt of one digit and prior to receipt of a complete set of digits (based on translation table information plus digit analysis). ICA
Incoming Call Abandon
This measurement provides the number of incoming calls that had not yet completed call Build-Up and were incomplete due to recognition of a Clear Forward signal after receipt of a complete set of digits (based on translation table information plus digit analysis). UTS
Unallocated Local Terminating Subscriber
This measurement provides the number of incoming calls that were incomplete because the intended destination was an unallocated subscriber number.
Issue 1.0
December 1996
A-33
LOSTERM
Local Terminating Subscriber's Line Out of Service
This measurement provides the number of incoming calls that were incomplete because the intended local terminating subscriber was out of service. SNATERM
Service Not Available to the Terminating Subscriber
This measurement provides the number of incoming calls that were incomplete because the requested service was either denied, not available to or incompatible with the intended local terminating subscriber. This measurement includes Denied Termination Call. SBSTERM
Local Terminating Subscriber Busy
This measurement provides the number of incoming calls that were incomplete because the intended local terminating subscriber was busy. SUBSTR
Terminating Subscriber Transferred
This measurement provides the number of incoming calls that were incomplete because the intended local terminating subscriber was transferred. NANSTO
Answer Time Out from Network
This measurement provides the number of calls that completed call setup but were incomplete because an answer was not recognized prior to expiration of the time-out period from the network.
Outgoing Call
SNAORIG
Service Not Available to Originating Subscriber
This measurement provides the number of originating calls which were incomplete because the requested service was either denied, not available to or incompatible with the local originating subscriber. This measurement includes Denied Originator call incompletion.
A-34
Issue 1.0
December 1996
INVCRCV
Invalid Code Received
This measurement provides the number of calls that were incomplete because of one of the following reasons:
s
the call could not be routed because an insufcient number of digits were received from the mobile or an insufcient number of digits were received before the last digit indication for a wireline call. a complete address was received but it contained an invalid code which prevented proper routing. Invalid codes include unallocated prexes, country codes, or exchange codes (not including unallocated subscriber codes). a DPN (Digital Path Not Provided Signal) backward failure message was originated due to the digital connectivity feature not being provided or digital paths not being provided.
CRBRD
Circuit Barred
This measurement provides the number of calls (associated with the Call Barring feature) that are selectively prevented from accessing particular outgoing trunk groups based on the combinations of the incoming trunk group the call arrived on and the destination (country) code and time-of-day in some applications. OCA
Originating Call Abandon
This measurement provides the number of originating calls that had not yet completed Call Build-Up and were incomplete due to recognition of originating subscriber on--hook after receipt of a complete set of an expected set of digits. RFN
Routing Failure from Network
This measurement provides the number of calls that were incomplete because they could not be routed through the network. ALTRK
All Trunks Busy
This measurement provides the number of outgoing calls that were incomplete because after the intended routing was determined, no idle trunk circuit could be found. This measurement corresponds to the exchange resources call incompletion category for mobile origination and termination. CONG
Congestion
This measurement provides the number of calls that completed call setup within the exchange but were incomplete due to recognition of a congestion indication from the network.
Issue 1.0
December 1996
A-35
ADI
Address Incomplete from Network
This measurement provides the number of outgoing calls that were incomplete because an Address Incomplete or Insufcient Digits message was received from the network after the outgoing trunk was seized. RUNFN
Unallocated Number from the Network
This measurement provides the number of originating calls that were incomplete because an Unallocated/Unobtainable Number or equivalent Backward Failure Indication was received from the network. LOSN
Line Out-of-Service from Network
This measurement provides the number of calls that completed call Build-Up into the network but were incomplete due to receipt of a Line Out-of-Service message from the network. BARRN
Network Access Barred
This measurement provides the number of calls that completed call setup within the exchange but were incomplete due to recognition of an Access Barred or comparable message from the network. ANSTO
Answer Time-out
This measurement provides the number of calls that completed call setup but were incomplete because an answer signal was not recognized prior to expiration of the answer time-out period of the exchange. AAA
Awaiting Answer Abandon
This measurement provides the number of calls that completed call Build-Up but were incomplete because the switch recognized a disconnect signal or on-hook signal from the A-side before either the expiration of the switch's answer time-out period or before the switch recognition of answer. SBYOS
Subscriber Busy from Network
This measurement provides the number of outgoing calls that completed call Build-Up but were incomplete because a Subscriber Busy indication was received from the network.
A-36
Issue 1.0
December 1996
Miscellaneous
ADMNBLK
Failure Due to Switch Administration
This measurement provides the number of calls that were incomplete due to the administration of the exchange. CONTO
Continuity Time-out
This measurement provides the number of incoming calls on trunks utilizing Common Channel Signalling where continuity test is expected but were incomplete due to a Time out waiting for a Forward COT (Continuity Signal). FCOBCA
Facility Cut-off Before Call Build-Up Complete A-Side
This measurement provides the number of calls that had not yet completed call Build-Up into the network and were incomplete due to a problem associated with facilities external to the switch. FCO
Facility Cut-off After Call Build-Up Complete
This measurement provides the number of calls that completed call Build-Up into the network but were incomplete due to a problem associated with facilities external to the switch. FCO includes interruptions of E1s connected directly to the switch as well as E1s at the A-bis and the Mlink. In addition, FCO includes reset circuit messages for SS7, some DTAP message failures as well as some RF dropped calls. HWDFA
Switch Hardware Failure
This measurement provides the number of calls that had not yet completed call Build-Up into the network and were incomplete due to a hardware failure within the exchange. INCER
Incoming/Originating Error
This measurement provides the number of incoming calls that had not yet completed call Build-Up into the network and were incomplete due to an error on the incoming trunk or Originating Terminal Process. OUTER
Outgoing/Terminating Error
This measurement provides the number of calls that had not yet completed call Build-Up into the network and were incomplete due to an error on or associated with the outgoing trunk, or with the Terminating Terminal Process.
Issue 1.0
December 1996
A-37
NPROERR
Protocol Error from Network
This measurement provides the number of calls that were incomplete because a protocol error indication was received from the network. NTMG
Network Management Cancel
This measurement provides the number of outgoing calls that were incomplete due to cancellation by an active network management control. The count is pegged if a call fails due to network management trunk control, or due to a blocked network. PROERR
Protocol Error
This measurement provides the number of calls that were incomplete because a protocol error indication was detected by the switch. RESFA
Failure to Obtain Switch Resources
This measurement provides the number of calls that were incomplete because the switch did not have sufcient internal resources that are related to the engineering of the exchange. That is, the service provider has the ability to prevent such failures in the future by increasing the available resources. TCL
Transient Call Lost
This measurement provides the number of calls that had not yet completed call Build-Up into the network and were incomplete because the internal software resources required by the switch were not available. This measurement only includes call incompletions caused by problems which cannot be alleviated by changes in the exchange's administration nor engineering. SCO
Switch Cutoff Stable Call
This measurement provides the number of calls that completed call Build- Up Complete into the network but were incomplete because an internal problem in the switch caused the call to be terminated before an Intended Call Tear-Down could occur. For SS7, there are cases where the state of a call cannot be determined. These cases have been identied as internal errors. However, the state and therefore the stage of the call is not known.
A-38
Issue 1.0
December 1996
UNF
Uncategorized Network Failure
This measurement provides the number of calls that completed call Build- Up Complete into the network but were incomplete because of a failure in the network that is not categorized under another Call Incompletion Summary measurement. The following Call Incompletion codes peg this count: BUSYFL - Busy Flash, CFL - Call Failure from Network, EUM - Extended Unsuccessful Message from Network, SENDSIT - Send Special Information Tone, UNF - Uncategorised Network Failure.
5ESS-2000 Signalling Link Component (SLCOMP) A

The SLCOMP measurements summarize the activity on the SS7 signalling links that are connected to the 5ESS-2000.
Transmission
NSFX
Number of SIF and SIO Transmitted
This measurement provides the number of SIF (Signalling Information Field) and SIO (Service Information Octets) transmitted. NACK
Number of Negative Acknowledgment Received
This measurement provides the number of negative acknowledgment messages received on a per PH channel basis. ORTR
Number of Octets Retransmitted on a per PH Channel Basis
This measurement provides the number of octets retransmitted on a per PH channel basis. MSUX
Message Signalling Units Transmitted per SL
This measurement provides the number of MSUs (Message Signalling Units) that are transmitted the rst time. That is, it does not include retransmitted MSUs. MRTR
Number of Messages Retransmitted
This measurement provides the number of messages that were retransmitted per Signalling Link. It is pegged whenever an MSU (Message Signal Unit) is retransmitted from Level 2. This count plus Q.791 item 3.3 gives the total MSU trafc at Level 1 for this Signalling Link. This measurement represents the MSU trafc on the link due to the bit errors at Level 1.
Issue 1.0
December 1996
A-39
MDSC
Message Signalling Units Discarded
This measurement provides the number of Message Signalling Units that were discarded due to signalling link congestion.
Reception
NSFR
Number of SIF and SIO Received
This measurement provides the number of SIF (Signalling Information Field) and SIO (Service Information Octets) received. MSUR
Message Signalling Units Received Per Signalling Link
This measurement provides the number of MSUs (Message Signalling Units) that are received per Signalling Link. NSUE
Number of Signalling Units Received in Error
This measurement provides the number of Signalling Units received in error.
Signalling Link Failure

SFAR
Signalling Link Failures
This measurement provides the number of times a Signalling Link failure occurred. This measurement is pegged for a Signalling Link Failure regardless of reason. EDLA
Signalling Link Failure - Excessive Delay of Acknowledgement
This measurement provides the number of times there is a Signalling Link failure due to an excessive delay in the receipt of an acknowledgment. This measurement is pegged whenever the acknowledgment for a transmitted message is not received within a specied time period. EERR
Signalling Link Failure - Excessive Error Rate
This measurement provides the number of times a Signalling Link failure occurs due to an excessive error rate. FEDC
Signalling Link Failure - Excessive Duration of Congestion
This measurement provides the number of times there is a Signalling Link failure due to congestion lasting an excessive amount of time. This count is incremented whenever a receive buffer is in congestion for an extended period of time.
A-40
Issue 1.0
December 1996
ALFL
Signalling Link Alignment or Proving Failure
This measurement provides a count of the number of times a Signalling Link Alignment or Proving Failure occurs for any reason.
Congestion
SLTH1
Number of Times Congestion Level One has been Exceeded
This measurement provides the number of times Congestion Level One has been exceeded on a Signalling Link. CRMSUL
Number of Congestion Events Resulting in MSU Loss
This measurement provides the number of Signalling Network congestion events that result in the loss of an MSU (Message Signal Unit). RMCONG
CCITT7 Remote Congestion
This measurement provides the number of times that the remote exchange has sent a SIB (Status Indication Busy) to this exchange as a result of the remote exchange being in reception congestion.
Changeovers
LACO
Number of Local Automatic Changeovers on a per Signalling Link Basis
This measurement provides the number of Local Automatic Changeovers on a per signalling link basis. LMCO
Number of Local Manual Changeovers on a Per Signalling Link Basis
This measurement provides the number of Local Manual Changeovers on a per signalling link basis. LACB
Number of Local Automatic Changebacks on a per Signalling Link
This measurement provides the number of Local Automatic Changebacks on a per signalling link basis.
Duration
DSLA
Duration of Signalling Link Availability
This measurement provides the time duration in seconds that a signalling link is in the in-service state.
Issue 1.0
December 1996
A-41
DSLU
Duration of Signalling Link Unavailability
This measurement provides the time duration in seconds that a signalling link is found to be unavailable for any reason. DSLULF
Duration of Signalling Link Unavailability due to a Link Failure
This measurement provides the duration in seconds of signalling link unavailability due to a link failure. INLM
SL Inhibit Duration due to Local Management Action
This measurement provides the number of seconds a SL (Signalling Link) is inhibited from carrying trafc due to local management action. INRM
SL Inhibit Duration due to Remote Management Action
This measurement provides the number of seconds a SL (Signalling Link) is inhibited from carrying trafc due to remote management action. CDOC
Duration of SL (Signalling Link) Congestion
This measurement provides the duration in seconds that a signalling link is in congestion.
5ESS-2000 Signalling Link Set Component (SLSCOMP)
The SLSCOMP measurements summarize the activity on the SS7 signalling link sets that are connected to the 5ESS-2000. DSLS
Duration of Unavailability of Signalling Link Set
This measurement provides the duration in seconds that a signalling link set is unavailable. That is, that all links in the set are unavailable.
A-42
Issue 1.0
December 1996
5ESS-2000 Trafc Flow (TRAFFLOW) A

All of the TRAFFLOW measurements are collected over multiple switched categories. For example, SEIZE is collected in 13 different switched categories. However, only four of all the categories are actually passed to the OMC-PMS. They are:
s s s s
INC-OUT > Incoming Outgoing INC-TERM > Incoming Terminating ORIG-OUT > Originating Outgoing ORIG-TERM > Originating Terminating
In spite of the fact that there could be up to four counters for each measurement, only one denition is given here for each of the TRAFFLOW measurements that are used in generating OMC-PMS reports. Complete descriptions are available from 5ESS-2000 documentation. ADMIN (Number of counters: 4)
Ineffective Call Attempts due to Administrative Action
Each ADMIN measurement is the result of administrative action resulting in the call attempt being ineffective before the B side of the call is determined. ANS (Number of counters: 4)
Call Attempts Answered
These measurements provide the number of answered calls. They are pegged when an backward answer signal is received. ATTMPTS (Number of counters: 4)
Call Attempts
These measurements provide the number of incoming call attempts. They are pegged once the B side of the call is determined. BEHAV (Number of counters: 4)
Ineffective Call Attempts due to "A Side" Behavior
These measurements count the number of call attempts that successfully seized a circuit but received no answer before A side behavior terminated the call. BSN (Number of counters: 2)
Ineffective Attempts due to Receipt of a Backward Signal Indicating Failure in the Network
These measurements are pegged for call attempts when a backward signal is received from the network indicating the impossibility of setting up a call. These backward signals typically are: congestion signals, subscriber line busy signals, signals dened as part of the UBM (Unsuccessful Backward setup information message) group of messages in SS7.
Issue 1.0
December 1996
A-43
BUSY (Number of counters: 2)

Ineffective Call Attempts due to Called Party Busy
These measurements provide the number of attempts which were incomplete because the terminating subscriber line was busy. ERROR (Number of counters: 4)
Ineffective Call Attempts Due to Facility, Signaling or Setup Errors
These measurements provide an exchange summary of the ineffective call attempts which occur and can be attributed to facility, signaling or setup errors. EXFLT (Number of counters: 4)
Ineffective Call Attempts due to Exchange Faults
These measurements provide an exchange summary of the ineffective call attempts which can be attributed to 5ESS-2000 Switch faults. EXRES (Number of counters: 4)
Ineffective Call Attempts due to Lack of Exchange Resources
These measurements provide an exchange summary of the ineffective call attempts which can be attributed to a lack of engineerable resources that could be corrected through load balancing or other engineering actions. LOS (Number of counters: 2)
Ineffective Call Attempts because the Subscriber Line was Out of Service
These measurements provide the number of ineffective call attempts because the line was out of service. NOCKT (Number of counters: 2)
Ineffective Attempts due to No Outgoing Circuit Available
These measurements are pegged for call attempts that were incomplete because no idle outgoing trunk could be found. PDA (Number of counters: 2)
Ineffective Attempts due to "A Side" Partial Dial Abandon
These measurements reect the number of calls that were incomplete because a clear forward signal was received from the incoming network or an originating subscriber on-hook was recognized prior to receipt of a complete set of expected digits. PDTO (Number of counters: 2)
Ineffective Call Attempts due to "A Side" Partial Dial Time Out
These measurements reect the number of calls that were incomplete because an insufcient number of digits were received
A-44
Issue 1.0
December 1996
SEIZE (Number of counters: 4)

Seizures
These measurements are pegged for call attempts that have seized outgoing resources. SNAL (Number of counters: 2)
Ineffective Call Attempts because the Service was Not Available to the Subscriber
These measurements provide the number of ineffective call attempts that resulted because the service was not available to the local terminating subscriber or to the local originating subscriber. TRAN (Number of counters: =1)
Ineffective Call Attempts because the Called Subscriber Number was Transferred
This measurement provides the number of incoming terminating call attempts which were ineffective because the intended terminating subscriber number was changed (transferred) to a different number. UNAL (Number of counters: 2)
Ineffective Call Attempts due to an Unallocated Number Dialed
This count is pegged for calls which were ineffective because a valid code was dialed but the code was not assigned to a subscriber. USAGE (Number of counters: 4)
Call Attempt Usage
These measurements provide the exchange trafc usage for call attempts. This measurement is approximated by scanning the call record every one hundred seconds.
5ESS-2000 Mobile Application PART (MAP) A

FLMGRCV
MAP Failure Messages Received
This measurement provides a count of MAP failure messages received by a given entity. The count of MAP failure messages received is dened to be all return error components, reject components or abort messages received as a result of MAP request messages sent. This measurement is to be used to monitor MAP failure messages received by a given entity. FLMGSNT
MAP Failure Messages Sent
This measurement provides a count of MAP operation failures. The count of MAP operation failures is dened to be all return error components, reject components or abort messages sent as a result of MAP request messages received from TCAP. This measurement is to be used to monitor MAP failure messages sent by a given entity.
Issue 1.0
December 1996
A-45
FLTMOUT
MAP Failures due to Timeout
This measurement provides a count of MAP failures due to time-out. This measurement is pegged upon expiration of the timer associated with the MAP message. Time-outs for invokes for which no response is expected are not included here, since these will always result in a time-out. TCAP requires that a timer be sent for each invoke component sent. Some of the MAP invoke components sent will never receive a response which would cancel the invoke timer, thus, for these components, the timer will always expire. Since these time-outs do not represent an error situation, they are not counted. For GSM, the component time-outs that are not counted are: BeginSubscriberActivity, ForwardSsNotication, ProcessAccessSignalling, ForwardAccessSignalling, Reset, ForwardCheckSsIndication, NoteInternalHandover, NoteMsPresent and AlertServiceCentre. RQMGRCV
MAP Request Messages Received
This measurements provides a count of MAP request messages received by a given entity. The count of MAP request messages received is dened to be all invoke components received except BeginSubscriberActivity components. This measurement is to be used to monitor MAP message trafc received by a given entity. RQMGSNT
MAP Request Messages Sent
This measurement provides a count of the MAP request messages sent by a given entity. The count of MAP request messages sent is dened to be all invoke components sent except BeginSubscriberActivity components. This measurement can be used to monitor MAP message trafc sent by a given entity. In most cases a single component is sent in a MAP message. Thus, generally counting components is identical to counting messages. One exception is the BeginSubscriberActivity component. This component is always sent in the same message with an OperateSS or RegisterPassword component. Thus, counting both the BeginSubscriberActivity and OperateSS or RegisterPassword would be double counting. Also, the purpose of the BeginSubscriberActivity component is information transfer only. No processing is required by the receiving entity. In other cases where components may be optionally combined in the same message, both components require processing and thus, must both be counted.
A-46
Issue 1.0
December 1996
BSS Measurements
The LM4 version of the BSS supports 47 different measurement types. In addition, there is measurement type Channel which is generated by the OMC-2000. In most cases, the BSS produces these measurements on a per cell (i.e., per BTS or per sector) basis. The exceptions are the Signalling measurements and the CPU load measurement. Many of these BSS measurements have multiple counters associated with them. In such cases, the BSS counters are referenced in this document by the measurement type and counter name in the form: <type>.<counter> For example, counter number one of measurement type Total Number of CCCH Accesses by Procedure is represented as totalNoAccessByProcedure.AGCH When measurement data is stored in the OMC-2000, the BSS measurement name that appears in this Appendix is not included. Instead a BSS Type Number is associated with each measurement type and it is that number that is stored with the BSS measurement data. This BSS Type Number appears with its associated measurement name in the denitions that appear in this Appendix in the form: Measurement Name: BSS Type Number (Number of Counters)
Background
The service operator can activate or deactivate each of the 47 BSS measurements through the OMC-2000 on a per BSS basis. In addition, during creation of the measurement object, the OMC-2000 operator can specify which cells are to be measured. The BSS periodically sends the measurement results for the active measurements to the OMC-2000 based upon the BSS reporting interval. For BSS measurements, the recording interval is always 15 minutes (except for totalBscCpuLoad which is recorded every 5 minutes) and the reporting interval is always 60 minutes. In addition, the reporting of each measurement type is staggered throughout the 60 minute time frame to reduce the load on the
The LM3 version of the BSS only supports 27 different measurement types. The denitions for these 27 measurements that appear on the following pages include the specication that they are valid for LM3 as well as LM4. The measurements that are required in the generation of the OMC-PMS predened reports should always be made active by the service operator. The denition in this Appendix of each BSS measurement states when it is required by the OMC-PMS predened reports. It is important to remember that an ofce might or might not have the hardware that some of the counters reference. For example, for those ofces without half-rate TCHs, the associated half-rate counters would necessarily equal zero.
Issue 1.0
December 1996
A-47
OMC-2000. The OMC-2000 saves the measurement results in les for a period of 14 days. A validity ag comes with each BSS measurement. This ag, also known as the local abnormal ag, indicates whether the measurement results are valid. Whenever the BSS determines that a measurement result may not be correct due to any problem encountered during the collection interval, the abnormal ag is set to indicate invalid data. This possibly erroneous data is saved on the OMC-2000. Therefore, the user needs to consider the effect of this bad data in any analysis he/she might perform on the data while it resides on the OMC-2000. However, all such data is deleted by the OMC-PMS and so does not appear in its data base or in its reports and graphs. The OMC-2000 transfers these BSS measurement results to the OMC-PMS every hour (assuming an OMC-PMS is active and is connected to the OMC-2000). The OMC-PMS saves these raw BSS measurements for a period of 60 days. In addition, daily, weekly, and monthly aggregates are formed on the trafc related counters. This aggregate information is maintained in the OMC-PMS for a period of two years.
BSS Counter Types

There are four basic BSS counter types: 1.
An accumulation counter, also called a peg counter, is incremented each time the event occurs. For example, totalNoAccessByProcedure.AGCH gets incremented by one each time this event occurs. A counter that is incremented elsewhere (e.g., in the BTS) and sent to the BSC where it is added into the current value of the counter. totalNoAccessByProcedure.RACH is an example of such a counter. A counter such as noAccessSuccessfResultProc.AGCH, which is computed from other counters. A counter type is needed to generate average values or usage measurements (identical to the 5ESS-2000s trunk usage counters). Since integer values of averages and usage measurements do not provide the desired accuracy, the counters are typically set up to record accuracy to two decimal places. This is accomplished by having the counter record the desired value times 100. For example, a value of 5.66 for averageNoSimultCalls.fullRate is recorded in the associated counter as 566. This is why many counters in this document are multiplied or divided by 100.
2.
3. 4.
GSM Release 6.0 does not delete this data and so the data is passed on to the OMC-PMS. The OMC-PMS available with GSM Release 6.5 has the ability to ll in missing data. That is, if it is missing some interval of data, rather than just assuming this data is zero in its reports and graphs, it will ll in the missing data using an extrapolation technique. OMC-PMS will do this only if the OMC has passed it a minimum amount of data. This minimum amount is specied by the user to the OMC-PMS in its minimum data coverage input eld that appears as an input to the reports and graphs
A-48
Issue 1.0
December 1996
BSS Measurement Categories
BSS measurements are divided into 5 categories:

s
Connection Measurements: These measurements deal with the success and failure in accessing and maintaining an air channel connection. Channel Measurements: These measurements track the seizure attempts and usage of TCHs and SDCCHs. Handover Measurements: All BSS measurements concerning handovers are covered here. Signalling Measurements: These measurements are concerned with the A-interface SS7 connection from the BSS side. Load/Time/Duration Measurements: Currently this only includes measurements for CPU load and for the average holding time of calls over the A-bis interface.
Issue 1.0
December 1996
A-49
BSS Um Connection
total number of CCCH accesses by procedure (i.e., channel type) This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
totalNoAccessByProcedure: 8 (Number of counters: 4)
Counter 1: totalNoAccessByProcedure.AGCH Unit of measure: Peg counter. This counter is incremented every time the BSC sends an IMMEDIATE ASSIGNMENT COMMAND message (as dened in GSM 08.58) to the associated BTS. Counter 2: totalNoAccessByProcedure.PCH Unit of measure: Peg counter. This counter is incremented every time the BSC sends a PAGING COMMAND message (as dened in GSM 08.58) to the associated BTS. Counter 3: totalNoAccessByProcedure.RACH Unit of measure: Incremented Counter. This measurement counts all of the RACH accesses for a given BTS that are above a minimum threshold. This threshold is set by the user through the OMC in a eld titled Thresh RACH Busy Count. This measurement counts not only the RACH accesses that the BTS could decode but also those that it was unable to decode. The actual counting of the RACH accesses is done in the BTS. The BTS reports the value of its internal counter to the BSC in the CCCH_LOAD_INDICATION message. Upon receipt of the CCCH_LOAD_INDICATION message, the BSC updates totalNoAccessByProcedure.RACH by the value received in the message. The frequency with which the BTS sends the CCCH_LOAD_INDICATION message to the BSC is specied by the user through the OMC in a eld titled Period RACH Busy Count. Since the timing of the sending of the CCCH_LOAD_INDICATION message is not tied to the 15 minute recording interval, a given 15 minute recording interval could record more than 15 minutes worth of RACH accesses, or less than 15 minutes of RACH accesses. Counter 4: totalNoAccessByProcedure.pagebuf Unit of measure: Computed Average. This counter reects the paging buffer space within a given BTS. It appears that this counter is useless. It is only provided to be GSM compliant.
A-50
Issue 1.0
December 1996
noAccessSuccessfResultProc: 11 (Number of counters: 2)

number of CCCH accesses with successful results by procedure This measurement is available in LM3 as well as LM4. Measurement is required by predened OMC-PMS Reports.
Counter 1: noAccessSuccessfResultProc.AGCH Unit of measure: Computed counter. This counter reects the number of IMMEDIATE ASSIGNMENT messages (as dened in GSM 04.08) that were transmitted out the Um-interface. It is computed by the BSC by subtracting two internal counters that gives the same result as subtracting counter noLostCallsNoAGCH from totalNoAccessByProcedure.AGCH. Counter 2: noAccessSuccessfResultProc.RACH Unit of measure: Incremented counter. This counter reects the number of successful accesses of the RACH as determined by the BTS. It uses the same technique as the counter totalNoAccessByProcedure.RACH except that it only increments the associated counter for RACH accesses that it was able to decode. The mobile will send up MAXRETRANS+1 CHANNEL REQUEST messages up the RACH for each actual attempt to connect to the network. The mobile should stop sending these messages when it receives an IMMEDIATE ASSIGNMENT or IMMEDIATE ASSIGNEMENT REJECT message over the BCCH. However, in a situation where the BSC does not respond quickly enough to the mobile, the mobile will send up another request. If these requests get to the BSC, the BSC will see them as new requests and does not associate them with any previous request. Therefore, an mobiles single attempt to connect to the network could result in counter noAccessSuccessfResultProc.RACH being incremented more than once. The actual counting of the successful RACH accesses is done in the BTS. The BTS reports the value of its internal counter to the BSC in the CCCH_LOAD_INDICATION message. Upon receipt of the CCCH_LOAD_INDICATION message, the BSC updates noAccessSuccessfResultProc.RACH by the value received in the message. The frequency with which the BTS sends the CCCH_LOAD_INDICATION message to the BSC is specied by the user through the OMC in a eld titled Period RACH Busy Count. Since the timing of the sending of the CCCH_LOAD_INDICATION message is not tied to the 15 minute recording interval, a given 15 minute recording interval could record more than 15 minutes worth of successful RACH accesses, or less than 15 minutes of successful RACH accesses. noDiscPagingCommands: 32 (Number of counters: 1)
number of discarded paging commands
Unit of measure: Incremented counter. Whenever a BTS must discard a paging message, it increments this counter. At the end of each reporting interval as known by the BSC, the BSC requests the
Issue 1.0
December 1996
A-51
BTS to transmit this counter to it. After the BTS does so, it zeroes out the associated counter it keeps in its memory. noLostCallsNoAGCH: 20 (Number of counters: 1)
number of lost calls due to no capacity left on AGCH This measurement is available in LM3 as well as LM4.
Unit of measure: Peg counter. This counter reects the number of DELETE INDICATION messages that the BSC had received from the associated BTS in the preceding recording interval. The DELETE INDICATION message is sent from the BTS to the BSC to indicate that the BTS had to delete an access grant message (i.e., IMMediate ASSIGN) due to an overload condition on the downlink CCCH. averageAGCHQueueLength: 4 (Number of counters: 1)
average AGCH queue length
Unit of measure: Average Number of Entries * 100. Every 5 seconds, the BTS increments an internal counter by the total number of entries in the AGCH that are queued. Upon request from the BSC, the BTS multiplies this internal counter by 100, divides it by the number of samples to determine the average AGCH queue length and sends the result to the BSC. The BSC will make this request of each BTS once every reporting interval. noRadioFreqLosses: 3 (Number of counters: 1)
number of TCH radio frequency losses This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
Unit of measure: Peg Counter. This counter is intended to identify the number of calls that terminate due to radio link failure. It is incremented whenever the BSC terminates a TCH connection due to receiving one of the following messages from the BTS:
s
The CONNECTION FAILURE INDICATION message with cause eld set to radio link failure. This failure occurs when the radio link failure is based on the success rate in decoding messages on the uplink SACCH as dened in GSM 05.08. It also is sent when the signal quality or the signal strength of the uplink is below a specied level (by the user from the OMC-2000) for a specied interval (by the user from the OMC-2000). The LINK RELEASE INDICATION message. This message is the result of the mobile determining that the call should be terminated. One way the mobile makes such a determination is by applying the radio link failure criteria as dened in GSM 05.08 on the downlink SACCH. The LINK ERROR INDICATION message with cause indicating radio link release which includes: timer T200 expiring, unsolicited DM response, sequence error and SABM with information not allowed.
A-52
Issue 1.0
December 1996
noRadioLinkFailWarnings: 31 (Number of counters: 1)

number of TCH/SDCCH radio link failure warnings This measurement is available in LM3 as well as LM4.
Unit of measure: Peg Counter.
noRadioLinkFailWarnings is based on noRadioFreqLosses. That is, this counter is incremented whenever the BSC receives a CONNECTION FAILURE INDICATION message from the BTS (whether for an SDCCH channel or a TCH channel) with the difference being that the cause has been set to radio link fail warning rather than radio link failure. The difference is that the thresholds for generating the fail warning message are generally less restrictive than those used for the failure message. The user can set the thresholds from the OMC-2000. In the fail warning case, the connection is not immediately released but the transmission power is increased to its maximum value in an attempt to save the connection. Since the connection is not dropped in the fail warning case, it is possible that the same connection could experience multiple fail warnings and so one connection could increment this counter more than once.
noRadioFreqLossesSDCCH: 27 (Number of counters: 1)
number of SDCCH radio frequency losses This measurement is available in LM3 as well as LM4. Measurement is required by predened OMC-PMS Reports.
Unit of measure: Peg Counter. This counter is identical to noRadioFreqLosses except it performs the count for SDCCH channels rather than TCH channels.
Issue 1.0
December 1996
A-53
meanNoIdleTCHPerIfBand: 30 (Number of counters: 10)

mean number of idle TCHs per interference band This measurement is available in LM3 as well as LM4.
meanNoIdleTCHPerIfBand.fullRate[1:5]: Full-rate TCHs meanNoIdleTCHPerIfBand.halfRate[1:5]: Half-Rate TCHs Unit of measure: Average Number of TCHs * 100 These counters give an indication of how much interference a BTS is experiencing. When a given TCH time slot is in idle mode (i.e., TCH is currently not assigned to a call), a BTS can measure the strength of the incoming signals (i.e., necessarily interferers) on the uplink for each TCH (the signal strength level is saved in RXLEV format as dened in GSM 05.08). On a regular interval (as dened by the user through the OMC), the BTS cycles through the TCHs and for each, uses its last available incoming signal strength value (of the interferers) to select one of the ve interference bands. If a BTS has 15 TCH/F time slots, then the sum of the ve full rate counters will be 15. The BTS then reports these counters to the BSC. Every 5 seconds, the BSC adds the BTSs most recently reported values of these counters to its own internal counters. At the end of the recording interval, the BSC multiplies each counter by 100 and divides by the number of samples. This yields the average number of idle trafc channels per band. The OMC-2000 has the user specify the band with the greatest amount of interference. Given this one band, the OMC-2000 will automatically generate the other four bands. The OMC-2000 has the user specify a single RXLEV value from which Band ve is assumed to include this RXLEV value to the RXLEV value of 63. Therefore, when the user species an RXLEV value of 34, he/she is, in effect, stating that band ve is any signal strength greater than -76 dBm (which corresponds to an RXLEV value of 34). The OMC-2000 then attempts to spread the other four bands over the remaining RXLEV bands which in this case has a signal strength span of -76dBm to -110dBm. The OMC-2000 algorithm and an example of its application is shown below. Band
1 2 3 4 5
Equation
RXLEV 0 to RXLEV ((user input - 2) / 4)
Example
-110 dBm to -102 dBm
RXLEV ((user input - 2) / 4) to RXLEV ((user input -1) / 2) -102 dBm to -93.5 dBm RXLEV ((user input -1) / 2) to RXLEV ((3/4) * user input) RXLEV ((3/4) * user input) to RXLEV (user input) RXLEV (user input) RXLEV 63 -93.5 dBm to -84.5 dBm -84.5 dBm to -76 dBm -76 dBm to -48 dBm
GSM 05.08 states that the measured signal level shall be mapped to an RXLEV value between 0 and 63, as follows: RXLEV 0 = less than -110 dBm. RXLEV 1 = -110 dBm to -109 dBm. RXLEV 2 = -109 dBm to -108 dBm. : : RXLEV 62 = -49 dBm to -48 dBm. RXLEV 63 = greater than -48 dBm.
A-54
Issue 1.0
December 1996
BSS Channels
Channels: 500 (Number of counters: 4)
Average number of Installed and In Service Channels This measurement, which is generated by the OMC-2000, is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports
Channels.InstalledTCH: Average number of dened/installed TCHs. Channels.InServiceTCH: Average number of available/in service TCHs. Channels.InstalledSDCCH: Average number of dened/installed SDCCHs. Channels.InServiceSDCCH: Average number of available/in service SDCCHs. Unit of measure: Average Number of Channels * 100 This measurement is generate by the OMC-2000 and not by the BSS. These counters are calculated by sampling the state of the OMC-2000 MIB. An in-service channel is one that has an enabled operation state and an unlocked administrative state. An installed channel is one that has any operational state and any administrative state. averageNoSimultCalls: 0 (Number of counters: 2)
Average number of simultaneous calls on TCHs This measurement is available in LM3 as well as LM4. Measurement is required by predened OMC-PMS Reports.
averageNoSimultCalls.fullRate: Full-rate TCHs averageNoSimultCalls.halfRate: Half-Rate TCHs Unit of measure: Average Number of TCHs * 100 The BSC determines the number of assigned TCHs in each of its associated BTSs every 5 seconds. For each BTS it adds this value to an internal counter and also increments a counter representing the number of samples. At the end of the reporting interval, the BSC computes the average number of assigned TCHs for each BTS. meanAndDelaySeizTCH: 2 (Number of counters: 4)
Provides data on TCH seizures and TCH queues Counter 4 of this measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
Counter 1: meanAndDelaySeizTCH.avgQlen
Average TCH queue length
Unit of measure: Number of TCH requests queued * 100 At a predened sampling interval, the BSC increments an internal counter by the total number of TCH requests that are queued (half-rate and full-rate requests are in the same queue). At the end of the reporting interval, the BSC multiplies this internal counter by 100 and divides by the number of sampling intervals to determine the average TCH queue length for each BTS.
Issue 1.0
December 1996
A-55
Counter 2: meanAndDelaySeizTCH.Threshold
entry added exceeding TCH queue threshold
Unit of measure: Peg Counter. This counter is incremented whenever the BSC adds an entry to the TCH queue and there are already exactly n entries in the queue where n equals a threshold value set from the OMC-2000. That is, the counter is pegged only when the threshold is passed. This means that this counter will not be pegged again until some time after the queue length drops below the threshold. Counter 3: meanAndDelaySeizTCH.deleted
TCH queue entries Deleted due to expired timer
Unit of measure: Peg Counter. This counter is incremented whenever the BSC deletes an entry from the TCH queue due to the expiry of timer T11 or Tqho, which are MAP-Timers T11 and T20 dened within the OMCs BSC object. Counter 4: meanAndDelaySeizTCH.totalNoOfTCHSeiz
Total number of TCH seizure attempts
Unit of measure: Peg Counter. This counter is slightly misnamed since it does not represent the number of successful TCH seizures but rather it represents the number of TCH seizure attempts (both half-rate and full-rate). It is incremented for each ASSIGNMENT REQUEST message and each HANDOVER REQUEST message received by the BSC from the MSC. In addition, it is incremented for all BSC Controlled handovers (including intraBTS). That is, it is incremented for each ASSIGNMENT REQUEST message generated by the BSC to initiate an intraBTS handover and for each HANDOVER REQUEST message generated by the BSC to initiate a BSC Controlled handover. trafcChanCongesTime: 1 (Number of counters: 2)
Trafc channel congestion time This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
TrafcChanCongesTime.fullRate: Full-rate TCHs TrafcChanCongesTime.halfRate: Half-Rate TCHs Unit of measure: time in seconds Every 5 seconds, the BSC determines whether every TCH in a BTS is busy. If so, it increments an internal counter. At the end of the measurement interval, the BSC multiplies this internal counter by the measurement interval to determine the congestion time for each BTS.
The associated OMC-2000 input eld is titled Threshold AGCH Queue and is actually specied as a percentage. n is computed by applying this percentage to the maximum length of the AGCH Queue.
A-56
Issue 1.0
December 1996
noAttemptSDCCHSeizure: 15 (Number of counters: 1)

Number of times that an SDCCH Seizure resulted in all SDCCHs being assigned. This measurement is available in LM3 as well as LM4.
Unit of measure: Peg Counter. This counter reects the number of times that a request for an SDCCH was satised by taking the last available SDCCH in a BTS. In other words, any future request for an SDCCH will be blocked unless an SDCCH is rst made available. noSuccesfSDCCHSeiz: 25 (Number of counters: 1)
Number of successful SDCCH seizures This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
Unit of measure: Peg Counter. This measurement counts the number of calls that were successfully assigned an SDCCH. It is incremented every time the BSC receives an ESTABLISH INDICATION message (see GSM 08.58) from the BTS. The basic assumption is that all connections are initially established as SAPI 0 connections on an SDCCH. (SMS requires a SAPI 3 connection which can only be established if there already exists an established main signalling link on SAPI 0.) Also, since the ESTABLISH INDICATION message is utilized in a handover situation, this counter reects all assignments of an SDCCH to a call including an SDCCH handover. attemptSDCCHSeizMeetAllBusy: 16 (Number of counters: 1)
Seizure attempts rejected due to all SDCCHs being busy This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
Unit of measure: Peg Counter. This counter reects the number of times that a request for an SDCCH could not be fullled because they were all in use. It is important to note that the value for attemptSDCCHSeizMeetAllBusy could be greater than the number of times that an mobile was unsuccessful in getting an SDCCH. If the BSC does not respond quickly enough to the mobile when it requests an SDCCH, the mobile will send up another request. (The number of such subsequent requests is limited by the BTS parameter MAXRETRANS.) The BSC sees these subsequent requests as new requests and does not associate them with any previous request.
Issue 1.0
December 1996
A-57
occupanGroupSDCCH: 14 (Number of counters: 1)

Average number of assigned SDCCHs for each BTS This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
Unit of measure: Average Number of SDCCHs * 100. The BSC determines the number of assigned SDCCHs in each of its associated BTSs every 5 seconds. For each BTS it adds this value to an internal counter and also increments a counter representing the number of samples. At the end of the sampling interval, the BSC computes the average number of assigned SDCCHs for each BTS. sDCCHCongestTime: 26 (Number of counters: 1)
Total period that SDDCHs for a BTS are all busy This measurement is available in LM3 as well as LM4.
Unit of measure: time in seconds. Every 5 seconds, the BSC determines whether every SDCCH in a BTS is busy. If so, it increments an internal counter. At the end of the sampling interval, the BSC multiplies this internal counter by the sampling interval to determine the congestion time for each BTS.
A-58
Issue 1.0
December 1996
BSS Handover
It is important to be clear in the following denitions of BSS handover counters, under what circumstances the counters get incremented. To enhance this ability, the following handover categories are dened: intraBTS: Handovers that are always controlled by the BSC but are within a given BTS. The handover can be between time slots of the same transceiver or it can be between transceivers in the same BTS.
BSCcontrolled: This includes all BSC controlled handovers except for those included in intraBTS. It would exclude all MSC controlled handovers including any intraBSC handover that is controlled by the MSC. MSCcontrolled: This includes any handover where the MSC actively controls the handover. It does not include any intraBTS handovers nor BSCcontrolled handovers. It does include all interBSC handovers as well as the few intraBSC handovers where the BSC passes control of the handover to the MSC. noAttIntraCellBssHo: 44 (Number of counters: 2)
Number of attempted intraBTS handovers This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
noAttIntraCellBssHo.fullRate: Full-rate TCHs noAttIntraCellBssHo.halfRate: Half-Rate TCHs Unit of measure: Peg Counter. This counter is only incremented for intraBTS handovers. That is, handovers between timeliest within a transceiver or between transceivers in the same BTS. The counter is incremented after the BSC sends an ASSIGNMENT COMMAND to the BTS to initiate an intraBTS handover. noSucIntraCellBssHo: 54 (Number of counters: 2)
Number of successful intraBTS handovers This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
noSucIntraCellBssHo.fullRate: Full-rate TCHs noSucIntraCellBssHo.halfRate: Half-Rate TCHs Unit of measure: Peg Counter. This counter is only incremented for intraBTS handovers. That is, handovers between time-slots within a transceiver or between transceivers in the same BTS. The counter is incremented after the BSC receives an ASSIGNMENT COMPLETE message from the BTS thus completing the intraBTS handover. noUnsIntraCellBssHoLossRL: 64 (Number of counters: 1)
Number of unsuccessful intraBTS handovers
Unit of measure: Peg Counter.
Issue 1.0
December 1996
A-59
This counter is only incremented for intraBTS handovers. That is, handovers between time-slots within a transceiver or between transceivers in the same BTS. The counter is incremented if one of the following occurs:
s
One timer (T3107) expires before the expected ASSIGNMENT COMPLETE message arrives from the mobile and another timer (T10) expires that guards the channel release procedure on the old channel. An intracell handover needs to be performed utilizing an assignment procedure since some mobiles will not accept handover commands when the target is the same cell. The BSC receives a CONNECTION FAILURE INDICATION message with cause set to Radio Link Failure for the old channel.
noAttHoByCause: 40 (Number of counters: 6)

Number of attempted outgoing BSC Controlled handovers by cause This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
noAttHoByCause.dist: Attempted due to distance. noAttHoByCause.DLlevel: Attempted due to downlink signal level. noAttHoByCause.DLqual: Attempted due to downlink signal quality. noAttHoByCause.pwr: Attempted due to power budget/better cell. noAttHoByCause.ULlevel: Attempted due to uplink signal level. noAttHoByCause.ULqual: Attempted due to uplink signal quality. Unit of measure: Peg Counter. These counters do not include MSC controlled handovers nor do they include intraBTS handovers. They only count BSC controlled outgoing handovers that are not intraBTS. For these handovers, one of the six counters (i.e., the counter associated with the cause that is triggering the handover) is incremented whenever the BSC sends a HANDOVER REQUIRED message to itself. Therefore, these counters include full rate handovers, half rate handovers and SDCCH handovers. noSucHoByCause: 50 (Number of counters: 6)
Number of successful BSC Controlled outgoing handovers by cause This measurement is available in LM3 as well as LM4.
noSucHoByCause.dist: Successful handovers initiated due to distance. noSucHoByCause.DLlevel: Successful handovers due to downlink signal level. noSucHoByCause.DLqual: Successful handovers due to downlink signal quality. noSucHoByCause.pwr : Successful handovers due to power budget/better cell. noSucHoByCause.ULlevel: Successful handovers due to uplink signal level. noSucHoByCause.ULqual: Successful handovers due to uplink signal quality. Unit of measure: Peg Counter. These counters do not include MSC controlled handovers nor do they include intraBTS handovers. They only count BSC controlled outgoing handovers that are not intraBTS. For these handovers, one of the six counters (i.e., the counter associated with the cause that is triggering the handover) is incremented whenever the handover is successfully completed. Therefore, these counters include full rate handovers, half rate handovers and SDCCH handovers.
A-60
Issue 1.0
December 1996
noAttIncInterCellBssHo: 41 (Number of counters: 3)

Number of attempted incoming BSC controlled handovers This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
noAttIncInterCellBssHo.fullRate: Number of attempted full rate handovers. noAttIncInterCellBssHo.halfRate: Number of attempted half rate handovers. noAttIncInterCellBssHo.SDCCH: Number of attempted SDCCH handovers. Unit of measure: Peg Counter. These counters do not include MSC controlled handovers nor do they include intraBTS handovers. They only count BSC controlled handovers that are not intraBTS. For these handovers, one of the three counters (i.e., the counter associated with the proper channel type) is incremented whenever the handover is attempted. The appropriate counter is incremented when the BSC processes a HANDOVER REQUEST message for the BSC controlled handover. trFlowAttIncInterCellBssHo: 45 (Number of counters: 5)
Number of attempted incoming BSC controlled handovers per neighbor pair Measurement is required by pre-dened OMC-PMS Reports.
trFlowAttIncInterCellBssHo.LAC: Location Area of neighbor cell. trFlowAttIncInterCellBssHo.cellID: Cell ID of neighbor cell. trFlowAttIncInterCellBssHo.fullRate: Number of attempted full rate handovers. trFlowAttIncInterCellBssHo.halfRate: Number of attempted half rate handovers. trFlowAttIncInterCellBssHo.SDCCH: Number of attempted SDCCH handovers. Unit of measure: Peg Counter. This counter is functionally the same as noAttIncInterCellBssHo. The difference is that this counter only records the number of incoming handover requests that a BTS has received from one other BTS (i.e., its neighbor as identied by LAC and cellID) rather than all other BTSs. noSucIncInterCellBssHo: 51 (Number of counters: 3)
Number of successful incoming BSC controlled handovers This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
noSucIncInterCellBssHo.fullRate: Number of successful full rate handovers. noSucIncInterCellBssHo.halfRate: Number of successful half rate handovers. noSucIncInterCellBssHo.SDCCH: Number of successful SDCCH handovers. Unit of measure: Peg Counter. These counters do not include MSC controlled handovers nor do they include intraBTS handovers. They only count BSC controlled handovers that are not intraBTS. For these handovers, one of the three counters (i.e., the counter associated with the proper channel type) is incremented whenever the handover is successful. The appropriate counter is incremented when the BSC processes a HANDOVER COMPLETE message for the BSC controlled handover.
Technically LAC and cellID are not counters but instead identify the neighbor cell.
Issue 1.0
December 1996
A-61
trFlowSucIncInterCellBssHo: 55 (Number of counters: 5)

Number of successful incoming BSC controlled handovers per neighbor pair Measurement is required by pre-dened OMC-PMS Reports.
trFlowSucIncInterCellBssHo.LAC: Location Area of neighbor cell. trFlowSucIncInterCellBssHo.cellID: Cell ID of neighbor cell. trFlowSucIncInterCellBssHo.fullRate: Number of attempted full rate handovers. trFlowSucIncInterCellBssHo.halfRate: Number of attempted half rate handovers. trFlowSucIncInterCellBssHo.SDCCH: Number of attempted SDCCH handovers. Unit of measure: Peg Counter. This counter is functionally the same as noSucIncInterCellBssHo. The difference is that this counter only records the number of successful incoming handovers between this BTS and one other BTS (i.e., its neighbor as identied by LAC and cellID) rather than all other BTSs. noUnsIncBssHo: 61 (Number of counters: 1)
Number of unsuccessful Incoming BSC controlled handovers due to Trr3 timer
Unit of measure: Peg Counter. This counter does not include MSC controlled handovers nor does it include intraBTS handovers. It only counts BSC controlled handovers that are not intraBTS. This counter is incremented whenever the handover completion timer Trr3 expires. Trr3 is a special timer not dened by GSM that guards the channel access within the handover resource allocation. noAttOutInterCellBssHo: 42 (Number of counters: 3)
Number of attempted outgoing BSC controlled handovers This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
noAttOutInterCellBssHo.fullRate: Number of attempted full rate handovers. noAttOutInterCellBssHo.halfRate: Number of attempted half rate handovers. noAttOutInterCellBssHo.SDCCH: Number of attempted SDCCH handovers. Unit of measure: Peg Counter. These counters do not include MSC controlled handovers nor do they include intraBTS handovers. They only count BSC controlled handovers that are not intraBTS. For these handovers, one of the three counters (i.e., the counter associated with the proper channel type) is incremented whenever the handover is attempted. The appropriate counter is incremented when the BSC processes a HANDOVER COMMAND message for the BSC controlled handover. trFlowAttOutInterCellBssHo: 46 (Number of counters: 5)
Number of attempted outgoing BSC controlled handovers per neighbor Measurement is required by pre-dened OMC-PMS Reports.
Technically LAC and cellID are not counters but instead identify the neighbor cell. Technically LAC and cellID are not counters but instead identify the neighbor cell.
A-62
Issue 1.0
December 1996
trFlowAttOutInterCellBssHo.LAC: Location Area of neighbor cell. trFlowAttOutInterCellBssHo.cellID: Cell ID of neighbor cell. trFlowAttOutInterCellBssHo.fullRate: Number of attempted full rate handovers. trFlowAttOutInterCellBssHo.halfRate: Number of attempted half rate handovers. trFlowAttOutInterCellBssHo.SDCCH: Number of attempted SDCCH handovers. Unit of measure: Peg Counter. This counter is functionally the same as noAttOutInterCellBssHo. The difference is that this counter only records the number of outgoing handover attempts between this BTS and one other BTS (i.e., its neighbor as identied by LAC and cellID) rather than all other BTSs. noSucOutInterCellBssHo: 52 (Number of counters: 3)
Number of successful outgoing BSC controlled handovers This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
noSucOutInterCellBssHo.fullRate: Number of successful full rate handovers. noSucOutInterCellBssHo.halfRate: Number of successful half rate handovers. noSucOutInterCellBssHo.SDCCH: Number of successful SDCCH handovers. Unit of measure: Peg Counter. These counters do not include MSC controlled handovers nor do they include intraBTS handovers. They only count BSC controlled handovers that are not intraBTS. For these handovers, one of the three counters (i.e., the counter associated with the proper channel type) is incremented whenever the handover is successful. The appropriate counter is incremented when the BSC processes an RF CHANNEL RELEASE message with cause set to HANDOVER SUCCESSFUL for the BSC controlled handover. trFlowSucOutInterCellBssHo: 56 (Number of counters: 5)
Number of successful outgoing BSC controlled handovers per neighbor Measurement is required by pre-dened OMC-PMS Reports.
trFlowSucOutInterCellBssHo.LAC: Location Area of neighbor cell. trFlowSucOutInterCellBssHo.cellID: Cell ID of neighbor cell. trFlowSucOutInterCellBssHo.fullRate: Number of attempted full rate handovers. trFlowSucOutInterCellBssHo.halfRate: Number of attempted half rate handovers. trFlowSucOutInterCellBssHo.SDCCH: Number of attempted SDCCH handovers. Unit of measure: Peg Counter. This counter is functionally the same as noSucOutInterCellBssHo. The difference is that this counter only records the number of successful outgoing handovers between this BTS and one other BTS (i.e., its neighbor as identied by LAC and cellID) rather than all other BTSs.
Technically LAC and cellID are not counters but instead identify the neighbor cell.
Issue 1.0
December 1996
A-63
noUnsOutBssHoSucReturn: 60 (Number of counters: 1)

Number of unsuccessful outgoing BSC controlled handovers with a successful return
Unit of measure: Peg Counter. This counter does not include MSC controlled handovers nor does it include intraBTS handovers. It only counts BSC controlled handovers that are not intraBTS. This counter is incremented whenever the BSC receives a HANDOVER FAILURE message from the mobile. This necessarily happens after the mobile has failed in its attempt to change to the new channel and has successfully reconnected to the old channel. noUnsOutBssHoLossRL: 63 (Number of counters: 1)
Number of unsuccessful outgoing BSC controlled handovers with loss of the Radio Link
Unit of measure: Peg Counter. This counter does not include MSC controlled handovers nor does it include intraBTS handovers. It only counts BSC controlled handovers that are not intraBTS. This counter is incremented whenever timer Trr3 (Trr3 is a special timer not dened by GSM that guards the access to the new channel within the handover resource allocation procedure) expires and one of the following also occurs:
s
The BSC receives a CONNECTION FAILURE INDICATION message with cause eld set to radio link failure. concerning the old channel. Expiration of timer T8. The BSC starts timer T8 upon receipt of a BSSMAP HANDOVER COMMAND message, whereupon the BSC sends the HANDOVER COMMAND message to the mobile. Normally upon receipt of a CLEAR COMMAND from the MSC or a BSC internal channel release message, the BSC would terminate timer T8 and release all involved resources that were allocated to the mobile.
noIncomInterCellHandover: 5 (Number of counters: 3)

Number of successful MSC controlled and BSC controlled incoming handovers This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
noIncomInterCellHandover.fullRate: Number of successful full rate handovers. noIncomInterCellHandover.halfRate: Number of successful half rate handovers. noIncomInterCellHandover.SDCCH: Number of successful SDCCH handovers. Unit of measure: Peg Counter. These counters include all handovers except for intraBTS handovers. One of the three counters (i.e., the counter associated with the proper channel type) is incremented whenever the BSC receives from a mobile a HANDOVER COMPLETE message associated with an inter BTS handover.
A-64
Issue 1.0
December 1996
noOutgoInterCellHandover: 6 (Number of counters: 3)

Number of successful MSC controlled and BSCcontrolled outgoing handovers This measurement is available in LM3 as well as LM4. Measurement is required by pre-dened OMC-PMS Reports.
noOutgoInterCellHandover.fullRate: Number of successful full rate handovers. noOutgoInterCellHandover.halfRate: Number of successful half rate handovers. noOutgoInterCellHandover.SDCCH: Number of successful SDCCH handovers. Unit of measure: Peg Counter. These counters include all handovers except for intraBTS handovers. One of the three counters (i.e., the counter associated with the proper channel type) is incremented:
s
on an MSC controlled handover, the BSC receives from the MSC a CLEAR COMMAND message with Cause indicating Handover successful, or on a BSS controlled handover (non-intraBTS), as the BSC initiates the procedure to release the old channel.
noAttSdcchSssHo: 43 (Number of counters: 1)

Number of attempted MSC controlled SDCCH handovers This measurement is available in LM3 as well as LM4.
Unit of measure: Peg Counter. This counter only includes MSC controlled handovers. It is incremented whenever the BSC supports an SDCCH channel handover by sending a HANDOVER REQUIRED message to the MSC. noSucSdcchSssHo: 53 (Number of counters: 1)
Number of successful MSC controlled SDCCH handovers This measurement is available in LM3 as well as LM4.
Unit of measure: Peg Counter. This counter only includes MSC controlled handovers. It is incremented whenever the BSC receives a CLEAR COMMAND from the MSC indicating Handover successful of an SDCCH channel. It should be noted that an MSC may not support SDCCH handovers in which case this counter would always be zero.
Issue 1.0
December 1996
A-65
BSS Signalling
noSignUnitInError: 70 (Number of counters: 1)
Number of signalling units indicating errors
Unit of measure: Peg Counter. When the BSCs MTP software identies a signalling unit as being in error, it increments this counter. noMsuDiscarded: 71 (Number of counters: 1)
Number of MSUs discarded
Unit of measure: Peg Counter. When the BSCs MTP software must discard an MSU due to congestion on the signalling link, it increments this counter. noRetransmittedOctets: 72 (Number of counters: 1)
Number of retransmitted octets
Unit of measure: Peg Counter. When the BSCs MTP software retransmits octets to the MSC, it increments this counter by the number of octets that were retransmitted. noRoutingFailUnequippedUser: 75 (Number of counters: 2)
Number of routing failures
noRoutingFailUnequippedUser.noRecMsgInterfN noRoutingFailUnequippedUser.noRecMsgInterfM Unit of measure: Peg Counter. When the BSCs SCCP software is unable to deliver a message (connection or connectionless) received from the MSC because the BSC user identied in the message can not be found, the message is discarded and counter noRoutingFailUnequippedUser.noRecMsgInterfN is incremented. When the BSCs SCCP software is unable to deliver a message to MTP for delivery to the MSC due to the connection being down (e.g., MSC SS7 connection is inactive), the message is discarded and counter noRoutingFailUnequippedUser.noRecMsgInterfM is incremented noRoutingFailSyntaxError: 76 (Number of counters: 1)
Number of routing fail syntax errors
Unit of measure: Peg Counter. When the BSCs SCCP software is unable to deliver a message (connection or connectionless) because the message contains syntax errors, the message is discarded and this counter is incremented.
A-66
Issue 1.0
December 1996
noRoutingFailUnknownReason: 77 (Number of counters: 1)

Number of routing failures for unknown reasons
Unit of measure: Peg Counter. When the BSCs SCCP software is unable to deliver a message (connection or connectionless) due to any unspecied reason, the message is discarded and this counter is incremented. noMessagesSentSccpClass0: 78 (Number of counters: 1)
Number of messages sent SCCP Class 0
Unit of measure: Peg Counter. The SCCP software increments this counter whenever it sends a connectionless message to the MSC. noMessagesReceivedSccpClass0: 79 (Number of counters: 1)
Number of messages received SCCP Class 0
Unit of measure: Peg Counter. The SCCP software increments this counter whenever it receives a connectionless message from the MSC
Issue 1.0
December 1996
A-67
BSS Load/Time/Duration
totalBscCpuLoad: 90 (Number of counters: 1)
Total BSS central controller CPU load
Unit of measure: percent * 100 (e.g., value of 2000 means 20%) For the BCE-2000, this counter reects the load that the BCC (i.e., BSS Central Controller) has experienced over the recording interval. meanTchHoldingTimeAbis: 95 (Number of counters: 1)
Mean total A-bis channel holding time Measurement is required by predened OMC-PMS Reports.
Unit of measure: Number of Seconds * 100 This counter reects the average holding time in hundredths of seconds of all connections seen by a BTS. Note that this is not call holding time since a call experiencing two handovers will yield three separate TCH holding time values. Whenever the BSC sends a CHANNEL ACTIVATION message (with channel type set to TCH) to the BTS, the BSC records the current system time as the start time. When the BSC subsequently receives an RF CHANNEL RELEASE ACKNOWLEDGE message that corresponds to the RF CHANNEL RELEASE message it had previously sent to the BTS, the BSC uses the difference between the current time and the previously recorded start time to get the connect time in seconds. The BSC does this regardless of whether or not the mobile successfully accessed the channel. At this point, a counter reecting the number of connections is incremented by one, and this connect time is added to a total holding time counter. At the end of the recording interval, the total holding time counter is divided by the total number of connections and this result is multiplied by 100 to give the average holding time in hundredths of seconds. Note that even though the average is given in hundredths of seconds, each individual connection is only recorded to the nearest second.
A-68
Issue 1.0
December 1996
BSS Measurements Summary Table

Table A-1.
BSS Measurement attemptSDCCHSeizMeetAllBusy averageAGCHQueueLength averageNoSimultCalls Channels
Counter Names if more than one.
BSS Type # 16 4
Required by OMC-PMS Yes No Yes Yes
fullRate, halfRate
0 500
InstalledTCH,
InServiceTCH, InstalledSDCCH, InServiceSDCCH
meanAndDelaySeizTCH
avgQlen, Threshold, deleted, totalNoOfTCHSeiz fullRate, halfRate AGCH, RACH dist, DLlevel, DLqual, pwr, ULlevel, ULqual fullRate, halfRate, SDCCH fullRate, halfRate fullRate, halfRate, SDCCH
Yes
meanNoIdleTCHPerIfBand meanTchHoldingTimeAbis noAccessSuccessfResultProc noAttemptSDCCHSeizure noAttHoByCause
30 95 11 15 40
No Yes Yes No Yes
noAttIncInterCellBssHo noAttIntraCellBssHo noAttOutInterCellBssHo noAttSdcchSssHo noDiscPagingCommands noIncomInterCellHandover noLostCallsNoAGCH noMessagesReceivedSccpClass0 noMessagesSentSccpClass0 noMsuDiscarded noOutgoInterCellHandover noRadioFreqLosses noRadioFreqLossesSDCCH noRadioLinkFailWarnings noRetransmittedOctets noRoutingFailSyntaxError
41 44 42 43 32
Yes Yes Yes No No Yes No No No No Yes Yes Yes No No No
fullRate, halfRate, SDCCH
5 20 79 78 71
fullRate, halfRate, SDCCH
6 3 27 31 72 76
Issue 1.0
December 1996
A-69
Table A-1.
Counter Names if more than one. noRecMsgInterfN, noRecMsgInterfM BSS Type # 75 77 70 25 dist, DLlevel, DLqual, pwr, ULlevel, ULqual fullRate, halfRate, SDCCH fullRate, halfRate fullRate, halfRate, SDCCH 50 Required by OMC-PMS No No No Yes Yes
BSS Measurement noRoutingFailUnequippedUser noRoutingFailUnknownReason noSignUnitInError noSuccesfSDCCHSeiz noSucHoByCause
noSucIncInterCellBssHo noSucIntraCellBssHo noSucOutInterCellBssHo noSucSdcchSssHo noUnsIncBssHo noUnsIntraCellBssHoLossRL noUnsOutBssHoLossRL noUnsOutBssHoSucReturn occupanGroupSDCCH sDCCHCongestTime totalBscCpuLoad totalNoAccessByProcedure trafficChanCongesTime trFlowAttIncInterCellBssHo
51 54 52 53 61 64 63 60 14 26 90
Yes Yes Yes No No No No No Yes No No Yes Yes Yes
AGCH, PCH, RACH, pagebuf fullRate, halfRate LAC, cellID, fullRate, halfRate, SDCCH LAC, cellID, fullRate, halfRate, SDCCH LAC, cellID, fullRate, halfRate, SDCCH LAC, cellID, fullRate, halfRate, SDCCH
8 1 45
trFlowAttOutInterCellBssHo
46
Yes
trFlowSucIncInterCellBssHo
55
Yes
trFlowSucOutInterCellBssHo
56
Yes
A-70
Issue 1.0
December 1996
The following signaling ow diagrams indicate specic measurement triggering points relative to the common messages used in a GSM network. These diagrams are not intended to represent all the counters, but only to give an indication of what is measured during common calling procedures. In each diagram, measurement trigger points are indicated by a black circle. Each circle represents one or more measurement counters and is associated with a network element that is collecting the measurement(s). Appendix A contains denitions for all of the measurement counters that appear in these Signaling Flow Diagrams. The reader can use the Index to quickly locate the denition of any 5ESS-2000 or BSS measurement in Appendix A.
MSC Signaling Flow Diagrams
In the MSC signaling ow diagrams, the MSC measurement counters are identied by their measurement counter name and the report they can be found in. The following format is used in these diagrams: measurement_counter_name (report_names) where: measurement_counter_name is the name of the 5ESS-2000 measurement counter report_names is a comma-separated list of reports which contain the counter. The following scenarios are described in this section:
s s s s s s
Mobile-to-land call Land-to-mobile call Mobile location update BSC Controlled handover Intra-MSC Controlled handover Inter-MSC Controlled handover
Issue 1.0
December 1996
B-1
Mobile-To-Land Call
The mobile-to-land call ow diagrams provide a scenario that describes MSC trafc measurement counters that are pegged for a mobile-to-land call that reaches the answered state. The following steps are highlighted in this scenario:
s s s s s s
Request for service by the mobile station Authentication of the mobile station Ciphering of the channel Equipment validation Call setup with the mobile Call setup with the land network
BSS
MSC
Service Request Service Request
VLR
Figure B-1.
Service Request
B-2
Issue 1.0
December 1996
BSS
MSC
VLR
HLR
AuC
AUTVRA (HLRVLR) VLRTRMM (HLRVLR)
Authentication Parameters Request ACUVR (HLRVLR) HLRTRMM (HLRVLR) RCVAUT (HLRVLR)
Authentication Parameters Request Authentication Parameters
AUCVRS (HLRVLR) RCVAUTS (HLRVLR) Authentication Parameters Authenticate Mobile Station Authenticate Mobile Station Authentication Response AUATT (WRLSSUM) - AUTHFL (WRLSSUM)* Authentication Response AUATT (WRLSSUM) AUTVRAS (HLRVLR)
* The number of signaling ows that reach this point can be calculated using the specied formula of counters.
Figure B-2.
Authentication Of A Mobile Station (optional)
BSS
MSC
Set Ciphering CIPATT (WRLSSUM) Encipher Command Encipher Complete
VLR
CIPATT (WRLSSUM) - CIPHFL (WRLSSUM)*
Figure B-3.
Ciphering Of A Channel (optional)
Issue 1.0
December 1996
B-3
MS
IMEI Request IMEI Response
MSC
IMEIATS (WRLSSUM)
EIR
Check IMEI IMEIATR (HLRVLR) IMEIWLS (HLRVLR) IMEI Check Results IMEIWLR (WRLSSUM)
Figure B-4.
Equipment Validation
MS
Call Setup Request
BSS
MSC
VLR
MLCLLA (WRLSSUM) SEIZE (SMCOMP,WRLS,ORIG)
Access Subscriber Data Subscriber Data VLRTRCH (HLRVLR)
Call Proceeding Assign Trunk and Radio Assign Radio Channel Radio Channel Assigned Trunk and Radio Assigned MLSCLLA (WRLSSUM) MSEIZE (TGCOMP) MATTMP (TGCOMP)
Figure B-5.
Call Setup With Mobile Station
B-4
Issue 1.0
December 1996
MS
MSC
OATTMPT (TGCOMP) land OSEIZE (TGCOMP) land SEIZE (SMCOMP,OUT) land Network Setup Network Alerting OSATTMP (TGCOMP) land
PSTN
Alerting Connect (answer) OANS (TGCOMP) land Connect Connect Acknowledgment ANS (SMCOMP,WRLS,ORIG) MLECALL (WRLSSUM) OANS (TGCOMP) MS
Figure B-6.
Call Setup With Land Network
Issue 1.0
December 1996
B-5
Land-To-Mobile Call
The land-to-mobile call diagrams provide a scenario that describes the MSC trafc measurement counters that are pegged for a land-to-mobile call that reaches the answered state. The following steps comprise this scenario:
s s s s s s s
Request for service Paging Authentication of the mobile station Ciphering of the channel Equipment validation Call setup with the mobile station Call setup with the land network
PSTN
Incoming Call
MSC
HLR
VLR
ISEIZE (TGCOMP) land LMCLLA (WRLSSUM) SEIZE (SMCOMP,INCOMING)
Get Route HLRINT (HLRVLR) HLRTRCH (HLRVLR)
Routing Information Incoming Call
VLRTRCH (HLRVLR) Perform Page
Figure B-7.
Request For Service
Refer to ow diagram B-2 since same procedure is used. Refer to ow diagram B-3 since procedure is identical. Refer to ow diagram B-4 since identical procedure.
B-6
Issue 1.0
December 1996
BSS
MSC
PAGATT (WRLSSUM)
VLR
Perform Page Page Response
PAGATTS (WRLSSUM) Page Response
Figure B-8.
Paging
MS
BSS
MSC
LMSCLLA (WRLSSUM) SEIZE (SMCOMP, WRLS, TERM)
Call Setup Request Call Setup Conrm
Assign Trunk and Radio Assign Radio Channel Radio Channel Assigned Trunk and Radio Assigned
OATTMPT (TGCOMP) MS
Figure B-9.
Call Setup With Mobile Station
Issue 1.0
December 1996
B-7
MS
MSC
PSTN
Mobile Alerting
OSATTMP (TGCOMP) MS Network Alerting Connect (off-hook) LMECALL (WRLSSUM) OANS (TGCOMP) MS Connect Connect Acknowledge
Figure B-10. Call Setup With Land Network
B-8
Issue 1.0
December 1996
Mobile Location Update
The mobile location update ow diagrams depict a scenario that shows when and which MSC trafc measurement counters get pegged during a location update request. The following steps comprise this scenario:
s s s s s
Request for service Authentication of the mobile station Location updated Ciphering of the channel TMSI reallocation
MS
BSS
MSC
New VLR
Location Update Request Location Update Request GLOUPI (HLRVLR) Request IMSI Request IMSI IMSI Acknowledge IMSI Acknowledge
Figure B-11. Request for Service
Refer to ow diagram B-2 since the procedure is identical. Refer to ow diagram B-3 for identical procedure.
Issue 1.0
December 1996
B-9
New VLR
HLR
Old VLR
Update Location Insert Subscriber Data Insert Subscriber Data Result Location Updated IMSIATT (HLRVLR) HLRTRMM(HLRVLR) for IMSIDET Delete IMSIDET (HLRVLR) Deleted HLRTRMM (HLRVLR) HLRLUR (HLRVLR) SHLRULR (HLRVLR)
Figure B-12. Location Updated
MS
BSS
MSC
New VLR
Location Update Accept
TMSIAT (WRLSSUM) Location Update Accept Location Update Complete TMSIAT (WRLSSUM) - TMSIFL (WRLSSUM)* Clear Signaling Connection Clear Complete
Figure B-13. TMSI Reallocation
B-10
Issue 1.0
December 1996
BSC Controlled Handover
The MSC is not involved in any aspect of a BSC Controlled handover. However, the BSC does report the completion of the handover to the directly connected MSC after any successful BSC Controlled handover. In addition, the directly connected MSC will report the successful handover to the Controlling MSC whenever the handover occurs on a non-Controlling MSC. In this case, the Controlling MSC increments measurement HOCOMNC(WRLSSUM).
BSS
MSC
Handover Performed HOCOMR (WRLSSUM) ITRAHOCO (WRLSSUM)
Figure B-14. BSC Controlled Handover
Issue 1.0
December 1996
B-11
Intra-MSC Controlled Handover
The intra-MSC Controlled handover ow diagram depicts a scenario that shows when and which MSC trafc measurement counters get pegged during an intra-MSC Controlled handover.
MS
Old BSS
Handover Required
MSC
New BSS
HOREQI (WRLSSUM) MATTMPT (TGCOMP) for originating OATTMPT (TGCOMP) for terminating ITRAHOAT (WRLSSUM) Handover Request Handover Request Acknowledge MSEIZE (TGCOM) for originating OSATTMP (TGCOMP) for terminating
Handover Command Handover Command Handover Access Physical Channel Information
Handover Detected Handover Complete Handover Complete IIBTSHO (WRHAND) HNDOVER (SMCOMP, WRLS, ORIG) for originating HNDOVER (SMCOMP, WRLS, TERM) for terminating HOFC (WRLSSUM) or HOSC (WRLSSUM) or HOBSC (WRLSSUM) HOICOM (WRLSSUM) ITRAHOCO (WRLLSUM) OIBTSHO (WRHAND) Release Radio Channel Radio Channel Released
Figure B-15. Intra-MSC Controlled Handover
B-12
Issue 1.0
December 1996
Inter-MSC Handover
The inter-MSC Controlled handover ow diagrams depict a scenario that shows when and which MSC trafc measurement counters get pegged during an inter-MSC Controlled handover. This is a handover that takes place between two BSSs (BSS A and BSS B) and between two MSCs (the Initiating MSC and the Target MSC). These ow diagrams show the counters assuming that both MSCs are 5ESS-2000s. The following steps comprise this scenario:
s s
Inter-MSC Controlled handover setup Inter-MSC Controlled handover completion
BSS A
Initiating MSC
Target MSC
BSS B
Target VLR
Handover Required HOREQI (WRLSSUM) Perform Handover HOREQT (WRLSSUM) Allocate Handover Number Handover Number Allocated VLRTRCH (HLRVLR)
MATTMPT (TGCOMP) for originating OATTMPT (TGCOMP) for terminating Handover Request Handover Request Acknowledged Perform Handover Acknowledge Network Setup Setup Complete Handover Command MSEIZE (TGCOMP) for originating OSATTMP (TGCOMP) for terminating
Figure B-16. Inter-MSC Controlled Handover Setup
Note that this does not show the case requiring a Facilitating MSC.
Issue 1.0
December 1996
B-13
MS
BSS A
Handover Access Physical Channel Information
Initiating MSC
Target MSC
BSS B
Handover Detected Handover Complete Handover Complete
IIBTSHO (WRHAND) HNDOVER (SMCOMP, WRLS, ORIG) for originating HNDOVER (SMCOMP, WRLS, TERM) for terminating HOCOMT (WRLSSUM) Send End Signal Answer HOCOMI (WRLSSUM) OIBTSHO (WRHAND) Release Radio Channel Radio Channel Released
Figure B-17. Inter-MSC Handover Controlled Completion
B-14
Issue 1.0
December 1996
BSS Signaling Flow Diagrams
In the BSS signaling ow diagrams, the BSS measurement counters are identied by the measurement type and the counter name as they appear in Appendix A. The following format is used in these diagrams:
measurement_type.counter_name
where: measurement_type is the name of the measurement type counter_name is the name of the counter. Many counters in the following diagrams have additional information associated with them. These counters are referenced with a letter at the end of the name. The following key should be used for all diagrams: a. b. c. d. e. f. g. h. i. The internal counter used for the calculation of the measurement is incremented. The internal counter used for the calculation of the measurement is decremented. Incremented in the case of occupation of the last free SDCCH. Incremented in case of all SDCCH channels busy. The system would react by sending an Immediate Assign Reject message. Sent by the CCCH Load Indication message to the BCE-2000. In case of not being able to send the Immediate Assign message to the mobile, the BTS sends the Delete Indication Message to the BSC. Done by the calculation: noSuccessResulProc.AGCH = totalNoAccessByProcedure.AGCH - noLostCallsNoAGCH Triggered after the detection of the need for a handover in the outgoing cell. Triggered with the Internal Handover Request message before allocation/ activation of a TCH for the incoming cell.
The following scenarios are described in this section:

s s s s s s s s
Mobile terminating call Dropped call Location update IntraBTS TCH handover BSC-controlled TCH handover MSC-controlled TCH handover BSC-controlled SDCCH handover MSC-controlled SDCCH handover
Issue 1.0
December 1996
B-15
Mobile Terminating Call
The mobile terminating call ow diagrams depicts a scenario that shows when and which BSS trafc measurement counters get pegged for a call that is terminating at the mobile station. The following steps comprise this scenario:
s s s
Call setup Trafc channel setup Call completion
MS
Logical Channel
BTS
BSC
Paging Paging Command
MSC/VLR
Mobile Terminating Call
PCH RACH
Paging Request
totalNoAccessByProcedure.PCH
noDiscPagingCommands
Channel Request
noSuccessResulProc.RACHe
totalNoAccessByProcedure.RACHe Channel Required noAttemptedSDCCHSeizuresc attemptSDCCHSeizMeetAllBusyc Channel Activation occupanGroupSDCCHa

Channel Activation Ack
sDCCHCongestTimea
AGCH SDCCH
Immediate Assign SABM (Layer 2) UA (Layer 2)
Immediate Assign Command totalNoAccessByProcedure.AGCH averageAGCHQueueLength averageAGCHQueueLength (Delete Indication) noLostCallsNoAGCHf noSuccessResulProc.AGCHg Establish Indication
noSuccessSDCCHSeiz
Complete L3 Information
SDCCH
Authentication (opt.) / Ciphering (opt.) / CC Messages
Figure B-18. Call Setup
B-16
Issue 1.0
December 1996
MS
Logical Channel
BTS
BSC
MSC/VLR
Assignment Request
meanAndDelaySeizTCH.totalNoOfTCHSeiz
Channel Activation Channel Activation Ack.
averageNoSimultCalls.fullRatea trafficChannCongestTime.fullRatea meanTchHoldingTimeAbis
SDCCH FACCH(TCH)
Assignment Command Assignment Complete Assignment Complete RF Channel Release (SDCCH) RF Channel Release Ack.
occupanGroupSDCCHb sDCCHCongestTimeb
FACCH/TCH
CC Messages (Alert / Connect) / Speech
Figure B-19. Trafc Channel Setup (without queueing)
MS
Logical Channel
BTS
BSC
MSC/VLR
Clear Command
FACCH(TCH)
DISC (Layer 2) UA (Layer 2)
Channel Release Deactivate SACCH
Release Indication RF Channel Release (TCH) RF Channel Release Ack.
averageNoSimultCalls.fullRateb trafficChannCongestTime.fullRateb meanTchholdingTimeAbis Clear Complete
Figure B-20. Call Completion
Issue 1.0
December 1996
B-17
Dropped Calls
The dropped call diagram provides a scenario that illustrates the BSS trafc measurement counters that are pegged for a call that is dropped by the mobile station.
MS
Logical Channel
BTS
BSC
MSC/VLR
Radio Link Failure Warning Connection Failure Indication (Cause: Radio Link Failure Warning) noRadioLinkFailWarnings BS Power Control MS Power Control
SACCH
Radio Link Time-out Connection Failure Indication (Cause: Radio Link Time-out)
noRadioFreqLosses or noRadioFreqLossesSDCCH
Clear Request Clear Command
FACCH (TCH)
No Response from MS
Channel Release Deactivate SACCH
RF Channel Release
RF Channel Release Ack. .
averageNoSimultCalls.fullRateb b trafficChannCongestTime.fullRate or b occupanGroupSDCCH sDCCHCongestTimeb MeanTchHoldingTimeAbis

Clear Complete
Figure B-21. Dropped Call
B-18
Issue 1.0
December 1996
Location Update
The location update diagram provides a scenario that illustrates the BSS trafc measurement counters that are pegged during a mobile station location update.
MS
Logical Channel
BTS
Channel Request
BSC
MSC/VLR
RACH
totalNoAccessByProcedure.RACHe
Channel Required Channel Activation Channel Activation Ack Immediate Assign Command
noSuccessResulProc.RACHe
noAttemptedSDCCHSeizuresc attemptSDCCHSeizMeetAllBusyd occupanGroupSDCCHa sDCCHCongestTimea
AGCH
Immediate Assign
totalNoAccessByProcedure.AGCH
averageAGCHQueueLength
(Delete Indication)
SDCCH
SABM (Layer 2) UA (Layer 2) Establish Indication
noLostCallsNoAGCHf noSuccessResulProc.AGCHg
noSuccessSDCCHSeiz
Complete L3 Information (Location Update Request)
SDCCH
Authentication (opt.) / Ciphering (opt.) / CC Messages Location Update Accept Location Update Accept TMSI Reallocation Complete TMSI Reallocation Complete Clear Command Channel Release Deactivate SACCH DISC (Layer 2) UA (Layer 2) Release Indication RF Channel Release (SDCCH) occupanGroupSDCCHb sDCCHCongestTimeb RF Channel Release Ack. Clear Complete
Figure B-22. Location Update
Issue 1.0
December 1996
B-19
IntraBTS TCH Handover
This diagram provides a scenario that illustrates the BSS trafc measurement counters that are pegged during an intraBTS TCH handover.
MS
Logical Channel
BTS
Measurement Report Measurement Report Measurement Result Measurement Result
BSC
MSC/VLR
SACCH SACCH
Handover Decision by BSC Channel Activation (TCH) averageNoSimultCalls.fullRatea trafficChannCongestTime.fullRatea Channel Activation Ack. meanTchHoldingTimeAbis
FACCH FACCH
Immediate Assign SABM (Layer 2) Establish Indication
noAttIntraCellBssHo.fullRate
FACCH FACCH
UA (Layer 2) Assignment Complete
noSucIntraCellBssHo.fullRate
Handover Performed RF Channel Release (TCH) . Channel Release Ack. RF .
averageNoSimultCalls.fullRateb trafficChannCongestTime.fullRateb meanTchHoldingTimeAbis
Figure B-23. IntraBTS TCH Handover
B-20
Issue 1.0
December 1996
BSC-Controlled TCH Handover
This diagram provides a scenario that illustrates the BSS trafc measurement counters that are pegged during a BSC Controlled handover.
MS
Logical Channel
BTS old
BTS new
BSC
SACCH SACCH
Measurement Report Measurement Report
Measurement Result Measurement Result Handover Decision by BSC
noAttHoByCause.<reason>h noAttIncInterCellBssHo.fullRatei
Channel Activation (TCH) Channel Activation Ack.
trFlowAttincInterCellBSSHo.fullrate
meanAndDelaySeizTCH.totalNoOfTCHSeiz averageNoSimultCalls.fullRatea trafficChannCongestTime.fullRatea meanTchHoldingTimeAbis noAttOutInterCellBssHo.fullRate trFlowAttOutInterCellBssHo.fullRate
FACCH FACCH FACCH FACCH FACCH FACCH
Handover Command Handover Access
Handover Command
Handover Detect Physical Information SABM (Layer 2) Establish Indication UA (Layer 2) Handover Complete Handover Complete
noIncomInterCellHandover.fullRate noSucIncInterCellBssHo.fullRate
Handover Performed
RF Channel Release (TCH)
averageNoSimultCalls.fullRateb trafficChannCongestTime.fullRateb noSucHoByCause.<reason> noSucOutInterCellBssHo.fullRate noSucIncInterCellBssHo.fullRate trFlowSucOutInterCellBssHo.fullrate trflowSucIncInterCellBssHo.fullrate meanTchHoldingTimeAbis
. .
RF Channel Release Ack.
Figure B-24. BSC-Controlled TCH Handover
Issue 1.0
December 1996
B-21
MSC-Controlled TCH Handover
This diagram provides a scenario that illustrates the BSS trafc measurement counters that are pegged during an MSC-controlled TCH handover. In the case when the rst handover choice given to the MSC fails, and the MSC attempts to handover to a second or a third choice, this later choice could be a new BTS connected to the old BSC. In such a case, the old BSC and the new BSC are the same BSC. Counters would be incremented as shown below. Even though this handover would be within the same BSC, it is still an MSC Controlled handover.
MS
BTS new
BSC new
BTS old
BSC old
MSC
Measurement Result Measurement Result Handover Decision by MSC Handover Required Handover Request
meanAndDelaySiezTCH.totalNoOfTCHSeiz
Channel Activation Channel Activation Ack.
averageNoSimultCalls.fullRatea trafficChannCongestTime.fullRatea meanTchHoldingTimeAbis

Handover Request Ack. Handover Command Handover Command Handover Command
Handover Access Physical Information SABM (Layer 2) UA (Layer 2) Handover Complete Establish Indication Handover Complete Handover Detect
noIncomInterCellHo.fullRate
Handover Complete
noOutgoInterCellHandover.fullRate
RF Channel Release
Clear Command
averageNoSimultCalls.fullRateb trafficChannCongestTime.fullRateb
RF. Channel Release Ack. .
Clear Complete
meanTch HoldingTime Abis
Figure B-25. MSC-Controlled TCH Handover
B-22
Issue 1.0
December 1996
BSC-Controlled SDCCH Handover
This diagram provides a scenario that illustrates the BSS trafc measurement counters that are pegged during an interBTS BSC-controlled SDCCH handover.
Logical Channel
MS
BTS old
BTS new
BSC
SACCH SACCH
Measurement Result Measurement Result
Handover Decision by BSC
noAttHoByCause.<reason>h noAttIncInterCellBssHo.SDCCHi attemptSDCCHSeizMeetAllbusyd

Channel Activation (SDCCH) Channel Activation Ack.
trFlowAttIncInterCellBssHo.SDCCH
noAttemptSDCCHSeizurec occupanGroupSDCCHa sDCCHCongestTimea noAttOutInterCellBssHo.SDCCH

trFlowAttOutInterCellBssHo.SDCCH
FACCH FACCH FACCH FACCH FACCH FACCH
Handover Command Handover Access
Handover Command
Handover Detect Physical Information SABM (Layer 2) Establish Indication UA (Layer 2) Handover Complete Handover Complete
noSuccessSDCCHSeiz
noIncomInterCellHandover.SDCCH noSucIncInterCellBssHo.SDCCH
Handover Performed
RF Channel Release (TCH)
occupanGroupSDCCHb sDCCHCongestTimeb noSucHoByCause.<reason> noSucOutInterCellBssHo.SDCCH noSucIncInterCellBssHo.SDCCH

trFlowSucIncInterCellBssHo.SDCCH trFlowSucOutInterCellBssHo.SDCCH
Figure B-26. BSC-Controlled SDCCH Handovers
Issue 1.0
December 1996
B-23
MSC-Controlled SDCCH Handover
This diagram provides a scenario that illustrates the BSS trafc measurement counters that are pegged during an inter-BSS MSC-controlled SDCCH handover.
MS
BTS new
BSC new
BTS old
BSC old
MSC
Measurement Result Measurement Result Handover Decision by MSC Handover Required
noAttSdcchSssHo
Handover Request (Handover Request Reject) attemptSDCCHSeizMeetAllBusyd Channel Activation
occupanGroupSDCCHa sDCCHCongestTimea noAttemptSDCCHSeizurec
Channel Activation Ack. Handover Request Ack. Handover Command Handover Command Handover Access Physical Information SABM (Layer 2) UA (Layer 2) Handover Complete Establish Indication Handover Complete Handover Detect Handover Command
noSuccessSDCCHSeiz noIncomInterCellHo.sDCCH
Handover Complete
noOutgoInterCellHandover.sDCCH noSucSdcchSssHo
RF Channel Release
Clear Command
occupanGroupSDCCHb sDCCHCongestTimeb
Clear Complete
Figure B-27. MSC-Controlled SDCCH Handover
B-24
Issue 1.0
December 1996
Index to Appendix A
C B
BSS, 47 attemptSDCCHSeizMeetAllBusy, 57 averageAGCHQueueLength, 52 averageNoSimultCalls, 55 Channels, 55 meanAndDelaySeizTCH, 55 meanNoIdleTCHPerIfBand, 54 meanTchHoldingTimeAbis, 68 noAccessSuccessfResultProc, 51 noAttemptSDCCHSeizure, 57 noAttHoByCause, 60 noAttIncInterCellBssHo, 61 noAttIntraCellBssHo, 59 noAttOutInterCellBssHo, 62 noAttSdcchSssHo, 65 noDiscPagingCommands, 51 noIncomInterCellHandover, 64 noLostCallsNoAGCH, 52 noMessagesReceivedSccpClass0, 67 noMessagesSentSccpClass0, 67 noMsuDiscarded, 66 noOutgoInterCellHandover, 65 noRadioFreqLosses, 52 noRadioFreqLossesSDCCH, 53 noRadioLinkFailWarnings, 53 noRetransmittedOctets, 66 noRoutingFailSyntaxError, 66 noRoutingFailUnequippedUser, 66 noRoutingFailUnknownReason, 67 noSignUnitInError, 66 noSuccesfSDCCHSeiz, 57 noSucHoByCause, 60 noSucIncInterCellBssHo, 61 noSucIntraCellBssHo, 59 noSucOutInterCellBssHo, 63 noSucSdcchSssHo, 65 noUnsIncBssHo, 62 noUnsIntraCellBssHoLossRL, 59 noUnsOutBssHoLossRL, 64 noUnsOutBssHoSucReturn, 64 occupanGroupSDCCH, 58 sDCCHCongestTime, 58 totalBscCpuLoad, 68 totalNoAccessByProcedure, 50 trafficChanCongesTime, 56 trFlowAttIncInterCellBssHo, 61 trFlowAttOutInterCellBssHo, 62 trFlowSucIncInterCellBssHo, 62 trFlowSucOutInterCellBssHo, 63 CICSUM, 31 AAA, 36 ADI, 36 ADMNBLK, 37 ALTRK, 35 ANSTO, 36 AUTHFL, 32 BARRN, 36 CIPHFL, 32 CONG, 35 CONTO, 37 CRBRD, 35 FCO, 37 FCOBCA, 37 HWDFA, 37 ICA, 33 IFS, 33 IMEIFL, 33 INCER, 37 INVCRCV, 35 IPDA, 33 IPDTO, 33 LOSN, 36 LOSTERM, 34 NANSTO, 34 NORESP, 32 NPROERR, 38 NTMG, 38 OCA, 35 OUTER, 37 PROERR, 38 RESFA, 38 RFN, 35 RUNFN, 36 SBSTERM, 34 SBYOS, 36 SCO, 38 SNAORIG, 34 SNATERM, 34 SUBSTR, 34 TCL, 38 TLREQ, 31 TMSIFL, 32 TSUCC, 31 UNF, 39 UTS, 33 WRPRERR, 32
H
HLRVLR, 13 AUCVR, 15 AUCVRS, 15 AUTVRA, 14 AUTVRAS, 14
Issue 1.0
December 1996
IN-1
Index to Appendix A
DELVLR, 16 GLCUFL, 18 GLOCUP, 18 GLOUPI, 18 GLUFLI, 18 HLRINT, 13 HLRLUR, 17 HLRROM, 13 HLRTRCH, 13 HLRTRMM, 14 IMEIATR, 19 IMEIBLS, 20 IMEIGLS, 19 IMEIWLS, 19 IMSIATF, 19 IMSIATT, 19 IMSIDET, 19 MSRNAL, 16 MSRNALS, 16 PLCUFL, 18 PLOCUP, 18 RCVAUT, 15 RCVAUTS, 15 RSRGVLR, 16 SENALT, 14 SHLRLU, 17 SRGHLR, 13 SRGVLR, 16 SSOHLR, 14 SSOHLRS, 14 VLRTRCH, 17 VLRTRM, 17
M
MAP FLMGRCV, 45 FLMGSNT, 45 FLTMOUT, 46 RQMGRCV, 46 RQMGSNT, 46
LACO, 41 LMCO, 41 MDSC, 41 MRTR, 39 MSUR, 40 MSUX, 39 NACK, 39 NSFR, 40 NSFX, 39 NSUE, 40 ORTR, 39 RMCONG, 41 SFAR, 40 SLTH1, 41 SLSCOMP DSLS, 42 SMCOMP, 26 IN_SEIZE, 27 IN_USAGE, 27 LOAD, 30 MSGDEL, 28 O_ANS, 27 O_SEIZE, 26 O_USAGE, 26 OCCUP, 30 OUT_SEIZE, 28 OUT_USAGE, 28 REOVLD, 30 SM, 26 T_SEIZE, 27 T_USAGE, 27 VEC0, 31 WO_ANS, 29 WO_HNDSEIZE, 29 WO_HNDUSG, 29 WO_SEIZE, 28 WO_USAGE, 28 WT_HNDSEIZE, 30 WT_HNDUSG, 30 WT_SEIZE, 29 WT_USAGE, 29
T S
SLCOMP ALFL, 41 CDOC, 42 CRMSUL, 41 DSLA, 41 DSLU, 42 DSLULF, 42 EDLA, 40 EERR, 40 FEDC, 40 INLM, 42 INRM, 42 LACB, 41 TGCOMP, 20 BWINCU, 24 BWOUTU, 25 DBLSZR, 23 IANS, 21 IANSUSG, 25 ICONGES, 22 INSVC, 20 IROUTE, 21 ISATTMP, 21 ISEIZE, 21 ISETUP, 21 ITRANSZ, 22 MATTMPT, 24 MOVFL, 24
IN-2
Issue 1.0
December 1996
Index to Appendix A
MSEIZE, 24 MTUSG, 25 OANS, 23 OANSUSG, 25 OATTMPT, 22 OOS, 20 OOSMTCE, 20 OSATTMP, 23 OSEIZE, 23 OVFL, 22 TGN, 20 TOTUSG, 25 TRAFFLOW ADMIN, 43 ANS, 43 ATTMPTS, 43 BEHAV, 43 BSN, 43 BUSY, 44 ERROR, 44 EXFLT, 44 EXRES, 44 LOS, 44 NOCKT, 44 PDA, 44 PDTO, 44 SEIZE, 45 SNAL, 45 TRAN, 45 UNAL, 45 USAGE, 45
HOSC, 10 IMEIATS, 7 IMEIBLR, 7 IMEIGLR, 7 IMEIWLR, 7 ITALTRK, 6 ITERHOAT, 11 ITERHOCO, 11 ITRAHOAT, 9 ITRAHOCO, 9 LMCLLA, 3 LMECALL, 3 LMSCLLA, 3 MAPFOR, 7 MAPFORS, 7 MLCLLA, 3 MLECALL, 3 MLSCLLA, 3 MMCLLA, 4 MMECALL, 4 MMSCLLA, 4 MOBURLS, 5 OALTRK, 6 OROAM, 5 PAGATT, 4 PAGATTS, 4 TMSIA, 7 TMSIFL, 7 TROAM, 5
W
WRHAND, 12 CELL_ID, 12 IIBTSHO, 12 OIBTSHO, 12 WRLSSUM, 3 AUTATT, 6 AUTHFL, 6 AVGTPG, 4 CINCFWD, 5 CIPATT, 6 CIPHFL, 6 FORCRLS, 5 HOBSC, 10 HOCOM, 8 HOCOMF, 11 HOCOMI, 10 HOCOMNC, 10 HOCOMR, 8 HOCOMT, 11 HOFC, 10 HOICOM, 9 HOREJI, 8 HOREQ, 8 HOREQF, 11 HOREQT, 11
Issue 1.0
December 1996
IN-3
Index to Appendix A
IN-4
Issue 1.0
December 1996

Optimisation OF GSM

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Optimisation OF GSM

Hochgeladen von

Copyright:

Verfügbare Formate

COURSE WL9016 GSM Mobile Network Optimization STUDENT GUIDE

WL9016 Version 01 e Issue c February 1998

Mandatory Customer Information

Lucent Technologies Proprietary See notice on rst page

Table of Contents WL9016 - ST.e.3 GSM Mobile Network Optimization

CELLULAR NETWORK OPTIMIZATION OVERVIEW

LESSON INTRODUCTION LESSON OBJECTIVES

OPTIMIZING THE NETWORK

WHAT IS OPTIMIZATION WHY OPTIMIZATION Accuracy of Radio Planning Implementation Environment

NETWORK OPTIMIZATION PROCESS

NETWORK OPTIMIZATION PARAMETERS

ENABLE/DISABLE GSM FEATURES Discontinuous Transmission Frequency Hopping Power Control

BSS PARAMETERS NEIGHBOR CELL LISTS Definition Optimization Impact Scenarios

Lucent Technologies Proprietary See notice on rst page

ANTENNA PARAMETERS FREQUENCY CHANGES

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

INTRODUCTION TO NETWORK OPTIMIZATION

At the end of this lesson, participants will be able to:

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

Coverage denition Trafc forecast

Coverage Interference Handover behavior Trafc distribution

ENDLESS CYCLE OF NETWORK PLANNING AND OPTIMIZATION

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

OPTIMIZING THE NETWORK

Design Phase Coverage definition Traffic forecast

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

Accuracy of Radio Planning

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

Sources Physical environment Body loss

Building penetration loss

Vehicle penetration loss Diversity gain

Frequency hopping gain Handset antenna efciency

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

Check Network Administration

Identify Stable Regions

Sub-Network Definition Phase

Perform Functional Tests

Quality Assessment Phase

Perform Detailed Measurements in those Locations

Identify Optimization Problem

Suggest Solutions and Predict Effects

Implementation of Solution Chosen

NETWORK OPTIMIZATION PROCESS

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

NETWORK OPTIMIZATION PROCESS

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW

Lucent Technologies Proprietary See notice on rst page

CELLULAR NETWORK OPTIMIZATION OVERVIEW