You are on page 1of 41

Root Cause Analysis of

Dropped Calls and Bad Call


Setups in GSM Systems

This document presents results of the root cause analysis of dropped calls and
bad call setups in operational GSM systems. The analysis is based on call
trace data from actual dropped calls and bad call setups that occurred in the
field. This document presents the methodology used and describes the main
classification criteria used by the Analysis Software. Three operational
Motorola GSM systems were evaluated and the resulting pareto charts can
better direct research efforts to solve the failures related to the main root
causes.

Version 2.01

Benedito J. B. Fonseca Jr.


July, 2000

Motorola Labs
1421 W. Shure Drive
Arlington Heights, Illinois 60004
Telephone: 847 632 2170
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

0. Revisions

th
V1.0 May 10 , 2000:
Initial version
th
V1.1 May 11 , 2000:
Revision of average call lengths
Bad_UL_no_info class included in RF-related causes
V2.0 September 29th, 2000:
Classification criteria and Pareto charts updated to consider new information
about Neighbor lists (NLIST), this new information improved the classification of
the classes where Handover was not triggered.
Classification criteria and Pareto charts updated to consider new information
about the behavior of the Handover Algorithm. This new information improved
the classification of the classes where Handover was not triggered and classes
where Handover was delayed.
Margins for variation were added in the Pareto charts. New appendix was
added in the document, explaining how these margins were determined.
Description of signal treatment in RXQUAL Uplink.
Call failures from the microcellular layer in the Vienna system were
incorporated in the results and Pareto charts.

2
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

1.0 Introduction It is important to mention that current


This document presents results of the root system diagnostic tools usually consider
cause analysis of dropped calls and failed only immediate causes as the cause of a
call setups in operational GSM Cellular dropped call or bad call setup. For
Systems using Motorola infrastructure. example, RF Loss is considered the
cause for many dropped calls. The idea of
This analysis is part of the research project this project is to analyze the call failure in
that aims to reduce dropped calls and bad more depth, looking for the root cause.
call setups in order to improve Motorola
systems availability towards 5NINES Possible root causes can be found by
(99.999%). looking at what could possibly go wrong in
each step of the handover or call setup
The goal of this analysis is to obtain Pareto process. The root cause would be the one
charts showing the root cause distribution with a negative answer to the question:
of setup and handover failures. These would the call have dropped if this specific
charts will help Motorola direct its research system procedure or characteristic wasnt
efforts to solve the failures related to the imperfect or didnt fail? For example, GSM
main root causes. systems use averaging mechanisms that
The analysis is based on call trace data can delay the transmission of a Handover
collected from actual dropped calls and bad Command to the MS. In fast changing
call setups that occurred in the field. environments, e.g. environments with
microcells, the MS may have already lost
This document describes the methodology
contact with the BS by the time the
used in the analysis and the main criteria
handover command was transmitted. While
used in the classification of the dropped
system diagnostics might classify this
calls and bad call setups. Software tools
dropped call as a RF loss, the present
used in the analysis are also described
analysis rather classifies it as a dropped
along with details of implementation.
call due to signal averaging in handover
Pareto charts summarizing the root causes procedure, causing delay in the Handover
of dropped calls and bad call setups found Command. Note that if the averaging
in 3 operational GSM systems are process were not present, the handover
presented. It is important to observe that, command might have been sent earlier, the
although the results presented are fairly MS might have received it and the dropped
reliable, since limited information is call might have been avoided.
provided by the tools used, field tests might
be necessary to confirm some root causes.
2.2 Statistical Considerations
Based on the results obtained, the RF
availability was evaluated for the systems In other words, the goal of the present root
analyzed. cause analysis is to obtain the distribution
of the random variables Dropped Call Root
This document does not aim to provide
Cause and Bad Call Setup Root Cause.
solutions for the root causes observed
during the analysis. These solutions are More than that, it is desired to obtain
part of the next phase of the project. distributions that apply to all Motorola GSM
systems. This would be possible if samples
from all Motorola GSM systems could be
2.0 Main Analysis Philosophy randomly acquired and analyzed. With a
2.1 Root Cause Definition proper number of samples, and assuming
that the systems would be in their
The main philosophy followed in the stationary state, this global distribution
analysis is that the root cause of a dropped could be obtained.
call or a bad call setup may be found in the
call's characteristics at the moment, some However, with the actual tools, it is difficult
time before and after the drop. to automatically obtain dropped call and
bad call setup samples from all Motorola
In order words, by observing the different GSM systems. Even individual acquisitions
signal levels and exchanged messages are difficult for the following reasons:
between the Mobile Station (MS) and Base
Station (BTS) in a period of time call trace data collection causes a burden
surrounding the moment the MS looses in the network under analysis and may
contact with the BTS, the root cause of the impact system performance.
call failure might be found.

3
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

engineering resources in the field are Maintenance Center of a GSM system),


necessary. root cause distributions could be
automatically obtained. This would help
Motorola might not have access to
optimization and future efforts to solve call
systems, since operators often have their
failure problems.
own engineering teams.
Notwithstanding, thanks to the valuable
collaboration of Motorolas ANDC-Madrid 2.3 Need for Automatic Classification
team, samples of dropped calls and call A software to automatically analyze and
setups were obtained for 3 individual classify samples was designed and built.
Motorola GSM systems. This approach has several advantages:
With the samples from a particular system, Consistency in the analysis;
assuming that it is in an ideal stationary
state, the desired distributions can be Easy reevaluation of results if
obtained for this system. classification criteria is changed or refined;
It is reasonable to consider that Fast classification of large of set of
distributions might change from one system samples;
to another due to the different Ready evaluation of future samples
characteristics, configurations and that might become available.
parameters found in each system; although
all Motorola GSM systems use the same
basic handover algorithm (in spite of 2.4. Pattern Recognition Software
different handover parameter that can be The software used for automatic analysis
configured) and are normally designed and and classification is kind of a pattern
configured following the same general recognition one. Experience was obtained
guidelines. by manually observing samples of dropped
In addition, distributions might change even calls and bad call setups; once
in the same system when parameters or understanding was gained about a
configurations are changed in the field. particular class of dropped calls or setup
With these considerations in mind, failures, classification rules were created to
distributions from individual systems must group calls following these rules. This
be analyzed carefully, specially when process was followed iteratively for any
drawing conclusions for GSM systems as a remaining calls that could not be classified
whole. by the present rules.

This analysis considered 3 Motorola GSM


systems. For the reasons described, the 3.0 Acquisition of Dropped Call Samples
distribution estimates were individually As previously mentioned, the analysis was
obtained for each of the systems. As will be based on field data collected from
seen later in this document, the operational GSM systems using Motorola
distributions obtained did not differ much, infrastructure.
suggesting that the results are not very
sensitive to the differences among the With the valuable help of ANDC-Madrid,
systems analyzed. This suggests that the samples were collected with the Motorola
results obtained from these 3 systems GSM Call Trace Product (CTP) tool [1].
might be used for definition of the main root The CTP tool allows the logging of call
causes in Motorola GSM systems with information during the call. This tool
similar configurations. combines the Measurement Report sent by
Future data collections in additional the MS [2] with the measurements
systems can be useful to confirm the performed by the BTS. CTP also logs the
results obtained in this analysis or to messages exchanged between MS and
determine the impact of different BTS. CTP allows the collection of up to 4
configurations and parameters in the root simultaneous calls in any of the selected
cause distributions. BTSs.
Furthermore, if the analysis and Thus, CTP can provide the temporal
classification criteria presented in this information needed for the present
document could be implemented in analysis. In addition, by collecting data
Motorola OMCs (Operation and

4
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

from the network side, several dropped call store them in the memory. Features are
samples can be obtained. characteristics of the call. Examples of
CTP has powerful presentation tools that features are: quality level (RXQUAL) when
are very suitable for field optimization and handover command was sent to MS, time
analysis of a GSM network. However, CTP when call drops, received level from
analysis tools do not include root cause neighbor cell when call drops, etc. There
analysis. are also features related to the messages
exchanged between MS, BTS, MSC and
CTP can, however, provide a text output BSC. Other features depend on the cell
with all the pertaining information about the configurations and characteristics. The
call. description of the classification criteria in
This text output was used in this analysis appendix A illustrates the features
and was treated as explained in the next extracted by the feature extractor.
section. Based on these extracted features, the
CLASSIFIER then reads these features
and classifies the call.
4.0 Treatment of CTP Output
The Classifier has several pre-programmed
In the output file, CTP formats the classes. Each class corresponds to a Root
information in a way that is very readable Cause (but one Root Cause may have
for humans (labels, formatting spaces, etc). several classes). Each class is defined by a
However, it is difficult for software to read set of conditions or rules involving the
and extract information out of this format.
features. The Classifier tries to fit the call
In addition, CTP outputs several calls into a into each of the classes. If the call features
single text file. satisfy the conditions of a class, it will be
Thus, a Translator PERL script was written classified as being part of it.
to translate the CTP output file and The Classifier was designed allowing
separate the several calls into different files complete flexibility on the definition of class
for separate treatment. rules. It is even possible to define classes
Each call in the CTP text output is that overlap each other.
translated into 2 files for analysis: the DAT Refer to appendix C for more details on the
file, containing measurement information Analysis software.
and the MSG file, containing message
exchange information. The information on
these files are formatted as numeric 6.0 Signal Treatment
matrixes that are easily read by any Some features required signal treatment
software. See appendix B for more details. before extracting the characteristic.
In order to allow easier analysis of the call The main signal treatments used on this
record, if the call had successful handovers analysis were:
in its record, it is separated into different
parts that are separately treated. 6.1. Observation Window

The translated files are then treated by the As explained in the main philosophy,
Analysis Software. information previous to the dropped call or
failed setup event is being used to
characterize the root cause of the failure.
5.0 Analysis Software However, information much before the
The Analysis Software individually reads dropped call / failed setup event looses its
each file containing a call (or part of a call) relevance to the analysis. For example, if a
individually and analyzes it. handover was tried, failed, but the call
recovered on its own from a bad quality
The Analysis Software was especially
situation and it goes on, this information
designed for dropped call and bad call
might not be relevant to the fact that 10
setup analysis. It was coded in C.
seconds after another handover was tried,
The main modules of the Analysis software but failed due to poor coverage and the call
are the FEATURE EXTRACTOR module dropped.
and the CLASSIFIER module.
Thus, an Observation Window was
The FEATURE_EXTRACTOR extracts adopted. This window defines the time
several different features from the call and period in the call record under analysis

5
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

where signals and messages will be The Feature Extractor considered these
considered on the extraction of most aspects when extracting features out of
features. It is important to note that there neighbors.
are some features that do not follow this When the neighbor was present in the
window. Measurement Reports since its first sample
There is a detailed procedure for defining up to the end of the Observation Window, it
the Observation Window. The procedure was considered a VALID NEIGHBOR.
depends on some basic characteristics of Neighbor related features are very
the call, like: time when handover was sent important to the classification criteria (see
(if sent), time when MS enters in bad appendix A). In classes where neighbor
quality state, etc. Generally, the window features are used to derive the conclusion
tries to capture from 4 to 5 seconds before that there was a better candidate or there
the beginning of bad state and 2 to 4 was a neighbor available to receive the
seconds after it. Please refer to appendix D call, only VALID neighbors were
for detailed explanations of all possible considered, giving more confidence to the
observation window configurations. conclusion.

6.2. Signal Averaging 6.4. Other


Some of the features perform signal Received power level (RXLEV) samples
averaging before extracting the
with value equal to 0 (zero) usually means
characteristic. The most important
missing value. In features related to
examples of them are:
received power level (including neighbor
features that extract the received level of levels), up to 3 zero samples that are
serving or neighbor cells in specified times; surrounded by non-zero values are
structural features [3] that extract the substituted by interpolations based on the
general characteristic of a signal over time. immediate surrounding values.

The signal averaging operation works in CTP repeats the last valuable MR
the following way. Considering the received whenever Uplink MR packets are
sequence of signal samples over time, lost. Since this happens when then Uplink
each sample of the signal is averaged with channel is with bad quality, received uplink
the 2 samples before and with the 2 quality (RXQUAL_UL) samples were
samples after it. This averaging procedure modified to the worst value (=7) whenever
avoids the group delay that happens when MRs were repeated.
only previous samples are considered in The Neighbor List information is a very
the averaging. important piece of information for proper
root cause definition; especially because
some handover algorithms used in
6.3. Treatment of Neighbor BTS Signals Motorola systems use especial parameters
It is important to note the proper treatment for each of the neighbors [6]. Due to the
of neighbor signals reported in the amount of cells analyzed, it is difficult to
Measurement Reports: obtain and introduce all these information
in the classifier. Nevertheless, partial
A certain neighbor might be reported only
information regarding the neighbor list was
in part of the call record. In other words, the
extracted from CTP statistical reports. This
MS might have detected different set of
information could be used with relatively
neighbors during the call record.
good results. Refer to appendix E for more
Sometimes the same carrier might be details.
reported with different BSICs [2] in different
moments of the call.
A certain neighbor might be reported in
different positions of the neighbor report. 7.0 Classification Criteria
Before treating the signal levels from a
neighbor, its samples were first extracted Although the classifier allows class
out of the different positions of the neighbor definitions completely independent from
report. each other, the classes used on this
analysis were defined based on a tree
approach. The approach is called tree

6
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

because the rules are tested in a system, it is difficult to obtain and introduce
sequential manner and, depending on the all the details of a particular system
result of the test, the classification process configuration in the classifier. Thus, it was
chooses one branch. Tests are made until not possible to consider these features in
a class (leaf) is reached. This approach the classification criteria. This may be one
allows a more controlled class design, way for future enhancements of the feature
avoiding the lack of classification. (This extractor and classifier.
does not mean that the call must always fit In order to compensate for this limitation,
in a class. Some branches end in the the main cell related parameters were
NO_CLASS class). Figure 1 illustrates the varied between maximum and minimum
approach. reasonable values. The results were
The several detailed rules used in the condensed into a single Pareto chart with
classes definitions are summarized in variation margins. This procedure is not
Appendix A. The conditions described in exact, however, it provides an estimate of
this appendix represent the set of tests that lower and upper limits for the participation
represent this class defined based on the of each class in the Pareto chart.
tree approach. (Note that the tree
approach is a design approach. The tree
is NOT actually implemented in the 8.0 Results
software.) As already mentioned, samples of dropped
calls and failed call setups were collected
from 3 GSM systems using Motorola
infrastructure. In one of the systems, a set
Bad Quality of microcells was separately evaluated and
In Downlink
its results are presented separately in the
Or Uplink?
charts in order to illustrate differences in
Y N the distributions.
The CTP outputs were translated and
Lost inserted into the Analysis Software. The
HO
Samples? Triggered?
following Pareto charts in figures 2 and 3
summarize the classification found in each
Y N of the systems for dropped calls and failed
Y N
call setups. In order to validate the results
No class Any good obtained with the Analysis Software, the
Neighbor? classification of more than 90 samples of
dropped calls and failed call setups were
Y N manually verified.
The percentages in the charts represent
Poor the percentages over all dropped calls (or
Coverage all failed call setups).
Figure 1 A detailed explanation of all this classes
(Figure 1 is just an example of the tree can be found in the appendix A.
concept. Refer to appendix A for details on All systems had around 2% or less of
the classes.) dropped calls / failed call setups over all
As described in detail in appendix A, each the calls in the systems. Thus, it is
class uses several features. Some of the reasonable to accept that they were not
features are related to the cell the call is in, facing bad configuration problems. The
its parameters, its neighbors and systems were in their operational phase
neighbors parameters. Due to the amount during the data collection.
of cells and parameters contained in a

7
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Root Cause of Dropped Calls

Bad Ordering

Handover Delay

Equipment Failure

Lack of Resources

HO Not Triggered

No Time for HO

Poor Coverage
Vienna-289 spl
Poor BSIC config. Czech-355 spl
Ankara-1048 spl
Sudden Power Interrup. Microcells - 143 spl

Region Weak Signals

UL Not Considered

Long Time Decode BSIC

Bad UL: no info

other

no class

0% 5% 10% 15% 20% 25% 30% 35% 40%


% over all dropped calls

figure 2
Bad Ordering: Bad Candidate Ordering or Exclusion in Handover Procedure. Handover
was generated to a cell, failed and dropped while there were other better candidates
available.
Handover Delay: the generation of the Handover Command was delayed due to averaging
or voting procedures, handover margins, delays in decoding and averaging neighbors.
Equipment Failure: Dropped call due to equipment failure.
Lack of Resources: Lack of Resources to receive the call in target cell.
HO Not Triggered: Although neighbors were available, handover algorithm decided to not
generate the Handover Command due to lack of flexibility in the algorithm.
No Time for HO: fast downlink degradation (<1s), with no time for handover before
degradation.
Poor Coverage: serving and neighbor cells with signals below than minimum required.
Poor BSIC Config. Handover not triggered because the good neighbor was reported with
unexpected BSICs.
Sudden Power Interrup. Uplink signal was suddenly interrupted. May be lack of power in
MS.
Region Weak Signals: Region with Weak Signals. Serving and Neighbor cells were not
with enough signal levels to guarantee good communication.
UL Not Considered: Uplink channel not considered during the handover procedure.
Long Time Decode BSIC: Since the MS takes long time to measure the BSIC,
Measurement Reports were probably corrupted due to interferers using same carrier and
wrong decisions were made.
Bad UL: no info: call arrived in cell after handover and dropped with no time for
measurement reports.
(see appendix A for more explanations on each class)

8
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Root Cause of Bad Call Setups

Bad Origination

Bad UL: no info

Delay Reselection

Equipment Failure

Lack of Resources

Vienna (124)
No TCH Evaluation
Czech Rp. (445)
Ankara (2943)
No HO in Setup
Microcells (60)

Poor Coverage

Sudden Power Interrup.

Region Weak Signals

UL Not Considered

no class

0% 10% 20% 30% 40% 50% 60% 70%


% over all bad call setups

Figure 3
Bad Origination: Call was originated in a cell geographically too far and faced problems.
Bad UL: no info: Lack of information to classify because no measurement reports were
reported. Calls from this class may be classified as Poor coverage, Delay in Reselection
or Uplink not considered (UL Not Considered).
Delay Reselection: Delay in Reselection. MS was camped in a bad cell when it started the
call.
Equipment Failure: Call setup failed due to equipment failure.
Lack of Resources: Lack of Resources for Call Setup.
No HO in Setup: Handover between Cells was not triggered during call setup.
No TCH Evaluation: interference in carrier holding TCH channel was not considered
during Assignment procedure.
Poor Coverage: Serving and Neighbor cells were with signal levels lower than the
minimum required.
Sudden Power Interrup.: Received level in Uplink was suddenly interrupted. May be lack
of power in MS.
Region Weak Signals: Region with Weak Signals. Serving and Neighbor cells were not
with enough signal levels to guarantee good communication.
UL not Considered: Uplink not considered during Reselection Procedure. MS was camped
in a cell with good Downlink but bad Uplink channels
(see appendix A for more explanations on each class)

9
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

It was considered that tight frequency call was facing bad RF conditions (bad
reuse plan is a must and cellular systems Quality), there was a good neighbor to
must cope with it. Thus, excessive adjacent receive the call, but the algorithm couldnt
channel or co-channel interference was not generate the handover command due to
2
considered a cause. It is considered that the rigid triggering criteria . If the algorithm
the system should act upon the call before parameters were more flexible, the
it faces these problems. handover could be generated and the call
The systems had similar overall could have been saved.
configuration parameters. Including The microcellular layer showed a much
parameters for handover, call setup and higher percentage of dropped calls in the
reselection algorithms. class Bad Ordering. This is probably due to
The data collection involved 117 cells1 in the modified handover procedures used in
the Vienna system, 158 cells in the Czech the microcellular layer, which employs a
Republic system and 257 cells in the modified ordering and exclusion algorithm
2
Ankara System. Most of these cells were when deciding the target cell to handover
Macrocells. The results from the [6].
microcellular layer refer to 21 microcells in The modified algorithms used in the
the Vienna system. microcellular layer can also be noted in the
The distribution charts represent estimates Handover Not Triggered class, where a call
of the distribution of the random variables drops due to lack of handover command
Dropped Call Root Cause and Bad Call generation. Note that the microcellular
Setup Root Cause for each system. layer showed a much lower percentage
than the other systems. This may be
justified by the reduced handover margins
9.0 Analysis of Results required by the modified handover
9.1. Dropped Calls procedure used in microcells [6].

By observing the Dropped Calls Pareto The high percentage of dropped calls in
Chart, we can reach the following the class Sudden Power Interruption
conclusions: suggests that detailed study of this
phenomenon is necessary. This class may
The 3 systems mainly composed of represent dropped calls due to lack of
macrocells had similar Pareto Charts. The battery power in the MS.
different environments, configurations and
statistical variations justify the differences The Lack of Resource class showed little
in the classification distribution. On the contribution, as expected, since it
other hand, the microcellular layer showed somewhat reflects the blocking probability
differences in the Pareto Charts. This is of the systems.
justified by the more diverse environment The equipment failure distribution showed
faced in this layer. In addition, the relatively low values.
handover algorithms follow different
The variation margins due to the variation
procedures when calls are operating in
of the classification parameters were not
microcells.
significant. This suggests that the
Poor coverage was found to be one of the classification criteria are robust to the
major causes of dropped calls. This is variation of the parameters.
especially true if we consider that Regions
If the classes related to poor coverage,
with weak signals is a form of poor
equipment failure and lack of resources
coverage, since there was not any cell that
were taken out of the chart, the chart on
could have provided good service to the
figure 4 is found.
call.
The 3 systems with mainly macrocells
showed a high percentage of dropped calls
in the class Handover Not Triggered. This
high percentage is justified by the fixed
parameters, like HO_MARGIN, used in the
handover algorithms. In other words, the 2
this does not mean that these handover
procedures are incorrect, it just means that they
1
can not handle all possible handover problems
sectors are considered as cells. that might occur in the field.

10
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Root Cause of Dropped Calls


(excluding Equip. Failure, Poor Coverage and Region with Weak Signals)

Bad Ordering

Handover Delay

HO Not Triggered

No Time for HO Vienna-73 smpl


Czech-104 smpl
Ankara-150 smpl
Poor BSIC config. Microcells-90 smpl

Sudden Power Interrup.

UL Not Considered

Long Time Decode BSIC

0% 10% 20% 30% 40% 50% 60%


% over all RF-related dropped calls

Figure 4
Bad Ordering: Bad Candidate Ordering or Exclusion in Handover Procedure. Handover
was generated to a cell, failed and dropped while there were other better candidates
available.
Handover Delay: the generation of the Handover Command was delayed due to averaging
or voting procedures, handover margins, delays in decoding and averaging neighbors.
HO Not Triggered: Although neighbors were available, handover algorithm decided to not
generate the Handover Command due to lack of flexibility in the algorithm.
No Time for HO: fast downlink degradation (<1s), with no time for handover before
degradation.
Poor BSIC Config. Handover not triggered because the good neighbor was reported with
unexpected BSICs.
Sudden Power Interrup. Uplink signal was suddenly interrupted. May be lack of power in
MS.
UL Not Considered: Uplink channel not considered during the handover procedure.
Long Time Decode BSIC: Since the MS takes long time to measure the BSIC,
Measurement Reports were probably corrupted due to interferers using same carrier and
wrong decisions were made.
(see appendix A for more explanations on each class)

Even though the Sudden Power Interrup. percentages illustrate the importance of
class can be related to user-initiated investigating this class in next steps.
termination, it was included in the RF This distribution chart shows that in the
related distribution chart since we couldnt macrocellular systems analyzed, the RF
confirm this hypothesis. The high related dropped causes are mostly related

11
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

to (1) failures in Handover algorithm that 9.2. Failed Call Setups


decided not to generate a handover Especially in the macrocellular systems,
command (class Handover Not Triggered), there was a high percentage of calls with 1
(2) Wrong handover decisions (Bad or no samples of Measurement Reports.
Ordering class) and (3) Handover Delay. Since the received level from neighbor cells
In the microcellular layer, the main root are usually not reported in the first samples
causes were (1) Wrong Handover of the Measurement Report, the
Decisions (class Bad Ordering) and (2) information about neighbors is missing and
Handover Delay (mainly due to averaging it is risky to take conclusions about this
procedures). The problem of failure of type of failed call setups. These call setup
algorithm to generate the handover failures can be due to: (a) Delay in
command (Handover Not Triggered class) Reselection, (b) Uplink not considered in
was also verified in the microcellular layer, reselection procedure, (c) poor coverage or
but in a much less extent. even (d) user disconnection before sending
Appendix A shows the distribution of the first MR. Thus, further studies on this case
different patterns that contributed to these might be necessary in order to clearly
classes. define the root cause.

Dropped calls from the Handover Not However, it is possible to draw some
Triggered class suggest that the handover conclusions from the remaining of the
algorithm might be too conservative or rigid classes.
in some cases. In the macrocellular In all systems, Delay in Reselection, Poor
systems, especially in the Ankara system Coverage and Sudden Power Interruption
(see appendix A), the HO_MARGIN were the main causes of failed call setups.
requirement [2] was responsible for almost In the microcellular layer, the class UL Not
80% of the dropped calls in this class. Considered showed a very high presence,
These calls could have been saved if the different from the other ones.
handover algorithm were more flexible.
Regarding the Poor Coverage class, it is
Dropped calls from the Bad Ordering class important to observe that this analysis does
show the importance of choosing the right NOT consider the situation that the
handover candidate at first place because Service Request or Paging message
a wrong handover decision might send the was not received; i.e., situations where the
MS to a cell where communication is not MS was completely out of service area.
possible, especially in systems involving The poor coverage situation here
microcells, where a wrong decision to keep considered covers mainly the situations
the call in the microcell layer [6], even in when the channel was with bad quality,
non-imperative handovers, might cause the downlink signals were very low and there
drop of a call. was not any alternative candidate to serve
Dropped calls from the Handover Delay the MS. Remember also that there might
class show that handover algorithms must be some calls with poor coverage in the
decide fast whether a handover decision class Bad UL: no info that couldnt be
should be made or not. Note that most of classified due to lack of samples. So this
these delays might have been introduced in percentage might be higher than what is
order to reduce the signaling load caused shown.
by continuous bouncing that might happen Equipment failure and Lack of Resources
between cells. Although microcellular showed very little or no contribution to the
handover procedures allow very fast distribution.
nd
handovers, this class still was the 2 root
cause. The high contribution of delays Figure 5 shows the chart when classes
caused by the averaging procedure (80% related to poor coverage, equipment failure
of all dropped calls in this class) might and lack of resources are taken out of the
distribution chart.
suggest that these delays relate to
situations where a bad handover decision The class Bad UL: no info were taken out
was made by the fast algorithm, but it was of the distribution chart in order to help the
not fast enough to trigger an additional analysis of the classes that could be
corrective handover. identified; however, it should be
remembered that this class might be
related to the remaining classes.

12
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Root Cause of Bad Call Setups


(excluding Poor Coverage, Bad_UL_no_info, Eq. Failure and Region w/ Weak Signals)

Bad Origination

Delay Reselection

No TCH Evaluation
Vienna (40)
Czech Rp. (113)
Ankara (495)
Microcells (57)
No HO in Setup

Sudden Power Interrup.

UL Not Considered

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
% over all RF-related bad call setups

figure 5
Bad Origination: Call was originated in a cell geographically too far and faced problems.
Delay Reselection: Delay in Reselection. MS was camped in a bad cell when it started the
call.
No HO in Setup: Handover between Cells was not triggered during call setup.
No TCH Evaluation: interference in carrier holding TCH channel was not considered
during Assignment procedure.
Sudden Power Interrup.: Received level in Uplink was suddenly interrupted. May be lack
of power in MS.
UL not Considered: Uplink not considered during Reselection Procedure. MS was camped
in a cell with good Downlink but bad Uplink channels
(see appendix A for more explanations on each class)

Even though the Sudden_Power_Interrupt to 5 seconds. This time is too long for fast
class can be related to user-initiated moving MS in areas with cells covering
termination, it was included in the below small areas [2]. It is important to note that
distribution chart. The high percentages this procedure is defined in the GSM
illustrate the importance of investigating standards. It is expected that this class will
this class in next steps. also be representative in systems with
From this chart, in the macrocellular many microcells.
systems, Delay in Reselection is one of the The Delay in reselection could also be
important classes. If class caused by penalties in reselection to
Sudden_Power_Interrupt werent neighbor cells. Penalties are margins
considered, this class would cover almost added in the neighbor cell measurements.
50% of all the causes. The explanation for Thus, in order to trigger a reselection, the
this is as follows: The time required for the neighbor cell signal must be higher than
MS to reevaluate his selection may take up the serving signal by an additional amount

13
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

(penalty). This procedure delays the Lack of Resources class (Lack of


triggering of a reselection and keeps the Resources class)
MS in the cell it is currently camped on.
With all remaining classes included, the
This procedure is also used to keep a MS
Czech system would have equal to
in a particular cell or layer.
0.75% and the Ankara System would have
The class UL Not Considered showed it equal to 1.61% (data from Vienna system
participation in the distribution of all is not available).
systems, but it was most noticed in the
Assuming that GSMs Call re-establishment
microcellular layer. This suggests that in
[5] would be used and that it would take
microcellular environments the misbalance
approximately 4 seconds to reconnect the
between Downlink and Uplink Interference
call (and that it would be able to reconnect
may be more severe and the reselection
the call 100% of the times3), would be
algorithm suffers since uses only the
downlink for evaluating the neighbors. This equal to 0.083 and 0.078 for the Ankara
class refers to call setup started by paging and Czech systems respectively (Ankara
or service requests that were received in a and Czech systems showed average call
very instable uplink. durations of 48 seconds and 51 seconds
respectively in a sample of 200 good calls).
It is important to remember that this does
not consider cases when the Uplink was so The below table presents the availability of
bad (but the downlink was good) that even both systems in the case considering all
the Service Request message was not call failures and in the case where poor
received by the BTS or cases when the coverage, equipment failure and lack of
resource failures were taken out:
Downlink was so bad that the Paging
Command was not received by the MS.
System all failure PCov, Lck_Rsc
9.3. RF Availability Preliminary causes and EqFail not
Estimation considered

With these results, it is possible to calculate Czech 0.99912 0.99942


a preliminary estimate the RF availability of (3.1-NINES) (3.2-NINES)
the systems studied. Refer to [4] for model
Ankara 0.99828 0.99868
details.
(2.8-NINES) (2.9-NINES)
Consider the following availability
expression [4]:
10.0 Conclusions and Future Activities
A = ____(1+(/2) )____ Even though CTP provides a lot of useful
information, some results still need field
(1+(/2)+ ) confirmation.
Nevertheless, the main dropped call and
...where represents the dropping (and failed call setup root causes could be
failed call setup) probability and identified.
represents the normalized reconnect Although the microcellular layer had much
period. less samples than the macrocellular
If all failure causes were considered, the systems, it is possible to conclude that both
Czech system would have equal to environments have different root cause
1.13% and the Ankara System would have distributions. This is reasonable not only
it equal to 2.10% (data from Vienna system due to the different environments, but also
is not available). because the handover algorithm behaves
differently in these 2 environments.
In order to evaluate the RF-availability of
the systems analyzed, the following From figures 4 and 5, it is possible to
classes were taken out of the calculations: conclude that, in microcellular
Poor Coverage classes (including Region
Weak Signals classes) 3
this might not be true in the availability
Equipment failure class (Equipment calculations for the case where all root causes
Failure class) are considered. These reconnect values were
also used in this case for comparison purposes.

14
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

environments, bad ordering of candidates [3] Nadler, M; Smith, E.P.; Pattern


and delay in the generation of handover Recognition Engineering. John Wiley &
commands are the main dropped call root Sons, 1993.
causes to be worked on. In the [4] Hess, G. C.; An Investigation of Call
macrocellular systems, the main dropped Drop Probability and Availability; Motorola
call root causes were: handover algorithm System Symposium, 1999.
not triggering handover command, bad
ordering of candidates and handover [5] ETSI GSM Recommendations 04.08.
delays. [6] Microcellular Engineering Book, rev.
The main call setup failure root cause is 0.4, Motorola ANDC-Madrid, 1999.
Delay in Reselection in the macrocellular
systems. In the microcellular layer, the
Uplink not Considered class was the main
call setup failure root cause.
Without considering poor coverage or
equipment/resource related causes, and
considering a 4 seconds Call
Reestablishment, RF availabilities of
approximately 3-NINES were found.
The following tasks are among the next
steps on this research project: confirmation
of some conclusions in the field,
exploration of solutions to solve the main
root causes and simulations to confirm
results and validate simulator settings.
Future data collections can be easily
treated using the Analysis software and the
results can be used to refine the
conclusions taken on the analysis
described in this document. The Analysis
Software may be reused in future
enhancements of the Motorolas CTP
Software or of the Operation and
Maintenance software used in Motorola
networks.

12.0 Acknowledgment
The cooperation of ANDC-Madrid team,
especially from Javier Escamilla and Luis
Velarde, in collecting data, providing
parameters and sharing expertise has been
very valuable for the development of this
research project.
The comments, suggestions and revisions
from Jeff Bonta, Gary Pregont, Manny
Kahana and Karl Knutson were very much
valuable.

13.0 References
[1] System Information Call Trace Product
(CTP) GSM Release 4 Motorola
manual number 68P02900W93-A, 1999.
[2] ETSI GSM Recommendations 05.08.

15
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Appendix A: Detail Classification Criteria

This appendix provides more details about the definition of the classes found in this
analysis. Item A.1 outlines the some assumptions and considerations used by these
classification criteria. Item A.2 describes the classification criteria for Dropped Calls and
item A.3 describes the Bad Call Setup classification criteria.
The figures A.2 and A.3 show the classification criteria in a decision tree format, allowing
an understanding of the details in the classification.

A.1. Assumptions and Considerations


The following assumptions and considerations were used in these classification criteria:
the RF channel was considered lost if UPLINK and/or DOWNLINK were showing bad
quality during more than 2.5 seconds from the end of the record. Otherwise, it was
considered that the call was interrupted by network intervention.
As can be seen in some classes, the suitability of neighbor cells were evaluated based
on the thresholds GOOD_70% and GOOD_90%. These thresholds refer to signal levels
received from the neighbors that would provide a good quality channel with 70% and 90%
probability. In other words, if a neighbor cell is measured with a RXLEV in the downlink
higher than GOOD_90% (GOOD_70%), the MS has 90% (70%) chance of having a good
quality channel if it were handed over to this neighbor cell.
The thresholds were empirically set based on the call records being analyzed. They were
defined in the following way:
a) all Measurement Reports (MR) were analyzed, even the ones that did not result
in dropped call.
b) for each downlink received signal level (RXLEV) in the serving cell, the chance of
good quality (Pgood_qual) was derived from the following formula:
Pgood_qual(RXLEVi)= # of MR with RXLEVi and good quality
# of MR with RXLEVi

Good quality was considered when RXQUAL < 6 in both uplink and downlink.
c) GOOD_70% and GOOD_90% were set equal to RXLEVis that corresponded to
Pgood_qual(RXLEVi) approximately equal to 0.7 and 0.9 respectively.
The parameters GOOD_70% and GOOD_90% were among the parameters varied to
derive the variation in the distribution for each class.

A.2. Dropped Calls


A.2.1. Class Bad Candidate Ordering or Exclusion in Handover Procedure: (Bad
Ordering).
Wrong handover decision to a cell while other cells could have successfully received the
call due to ordering / exclusion procedures [6] in the handover algorithm. The wrong
decision led the call to a poor quality state, which ended with the drop of it.
Five patterns lead to this classification:
Wrong handover decision due to Bad Ordering Procedure: successful handover
is completed but as soon as the call arrives in the new cell, it enters in bad state within 5
seconds and the call drops. At least 2 other neighbors were showing better signal levels
than the serving cell. Assuming that these RXLEV values didnt change much since the
handover algorithm evaluation, the handover algorithm preferred to handover the call to a
worse cell. See figure A.2.5 (Bad Ordering Procedure) for details in the classification.

16
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Wrong handover decision due to Bad Ordering Procedure or Handover


Triggered too Early: same class as the Wrong Handover decision due to Bad Ordering
Procedure, but there was just 1 other neighbors showing better signal level than the
serving cell. This can be a wrong handover decision or can be a Handover Triggered too
early, because the signal level of the neighbor being listened too might be the previous
serving cell before the successful handover. See figure A.2.5 (Bad Ordering Procedure or
HO Triggered to Early) for details in the classification.
Handover Delayed due to Bad Ordering Procedure: handover was delayed due to
the fact that neighbor conditions were not being met. Handover is triggered to a cell
chosen by the algorithm as soon as it meets the conditions, however, there was at least
one other neighbor, with signal level higher than the target one, that would satisfy the
neighbor condition before the chosen one. If the handover algorithm were not excluding
this neighbor, the handover would probably have been triggered before and the MS would
have a higher chance of listening to the Handover Command. See figure A.2.4
(Bad_Ord_delay) for a detailed classification.
Handover failure when handing over to a wrong cell: handover algorithm decided
to handover the call to a cell but the handover failed. Call returned to previous cell and
drops with no time for another handover. There were other neighbors with better signal
than the one chosen, showing that the handover algorithm made a bad decision. See
figure A.2.3 (Bad_Ord_hf) for a detailed classification.

nd
Bad Ordering Procedure to 2 tier cell: handover algorithm decided to handover
the call to a cell probably located geographically too far. Call entered in bad state but
couldnt handover to another cell due to the fact that the BSICs being reported by the MS
didnt match the ones expected by the cell. See figure A.2.2 for a detailed classification.
In the systems analyzed, the patterns described have the following contribution on the
final Bad Ordering class.

Distribution of Class : Bad Ordering Procedure

Wrong HO decision

Wrong HO or HO too early Vienna


Czech
HO Delay
Ankara
HO failed to wrong cell Microcells

HO to 2nd tier cell

0% 20% 40% 60% 80% 100%


% over all Bad_Ord Dropped Calls

17
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

A.2.2. Class Poor BSIC configuration: (Poor_BSIC_config)


There was a good neighbor available in an area, but Handover Algorithm did not consider
it because it had a BSIC that did not match the BSIC defined in the Neighbor List.
This class has 3 patterns:
Poor_BSIC_config_no_HO: no handover command was generated and call dropped.
See figure A.2.2 for details on this class.
Poor_BSIC_config_hf: handover was tried but failed. There was at least one good
neighbor with RXLEV higher than the signal level of the cell to which the handover was
tried. This neighbor was not chosen because it had a BSIC that did not match the one in
the neighbor list. See figure A.2.3 for details on this class.
Poor_BSIC_config_HO_delay: Handover Command was generated but was not heard
by the MS due to delays caused by neighbor conditions (Handover algorithm waits for at
least the 1st average of the neighbor and it normally requires it to be higher than the
serving cell signal). There was at least one good neighbor with RXLEV higher than the
signal level of the chosen cell and it was available for more than enough time to generate
st
the 1 average. The Handover Algorithm did not choose this alternative neighbor probably
due to the fact that the BSIC didnt match the one in the Neighbor List. See figure A.2.4 for
details on this class.
The distribution of calls inside this class is as follows:

Distribution of Class Poor BSIC configuration

Poor BSIC config


no HO
Microcells
Poor BSIC config Ankara
hf Czech
Vienna
Poor BSIC config
HO Delay

0% 20% 40% 60% 80% 100%


% over all Poor BSIC Config. Dropped Calls

A.2.3. Class Handover Delay: Delay in Handover Procedure.


Delayed Handover Command due to internal handover procedures process in the BTS.
These procedures are usually used to avoid the generation of unnecessary handovers. If
any of the requirements of this internal procedure wasnt present, the handover would
have been triggered before and the call would probably have handed over to one of the
available cells.
Six different patterns lead to this class:
Delay in Handover Procedure due to Voting Procedures: if voting werent present
in RXQUAL, the handover would have been triggered before. See figure A.2.4 for details
in the classification.
Delay in Handover Procedure due to Averaging Procedures: if averaging werent
present in RXQUAL, the handover would have been triggered before. See figure A.2.4 for
details in the classification.
Delay in Handover Procedure due to Delay in Decoding Neighbors: target
neighbor chosen recently appeared in MRs. Handover was triggered as soon as the first

18
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

sample of the averaging was available. If averaging in the neighbor samples werent
present, the handover would have been triggered before. See figure A.2.4 for details in the
classification.
Delay in Handover Procedure due to Handover Margin Requirements: handover
was not triggered until chosen neighbor became higher than the serving cell by a
handover margin. See figure A.2.4 for details in the classification.
Delay in Handover Procedure due to Recent TCH Assignment: bad quality
situation started within 2.5 seconds of the TCH Assignment. Handover could be delayed
due to this recent TCH assignment in order to avoid bouncing between cells. See figure
A.2.4 for details in the classification.
Delay in Handover Procedure due to unknown Procedures in the Algorithm:
voting, averaging and neighbor requirements were met but handover was still delayed due
to other procedures/requirements being followed by the algorithm. See figure A.2.4 for
details in the classification.
In the systems analyzed, the patterns described have the following contribution on the
final HO_Dly class.

Distribution of Class Handover Delay

Delay due to Voting


Proc.
Delay due to
Averaging Proc.
Delay in Decoding Microcells
Neighbors Ankara
Delay due to HO Czech
Margin
Vienna
Delay due to
Recent Assignment
Delay due to other
proc. in Alg.

0% 20% 40% 60% 80% 100%


% over all HO_Dly Dropped Calls

A.2.4. Class Lack of Uplink Evaluations of Candidates in Handover Procedure: (UL


Not Considered).
The Handover Algorithm did not consider the uplink conditions of the target cell in its
decision. Handover failed probably due to poor uplink conditions. If uplink conditions were
considered, the decision could have been different and the drop could have been avoided.
This class has 2 patterns:
UL_not_cnsd_hf: Handover algorithm chose the best cell based on the downlink
signal level from the neighbor cells. Handover command was sent and heard by the MS.
However, the handover failed and call had to return to original serving cell when it is too
late for another handover. Since the signal level of the target was good (higher than
GOOD_70%), there is a chance that the failure was in the Uplink. At least one other
neighbor was available with signal level higher than GOOD_70%. Thus, there is a chance
that its uplink was not as bad as in the target one and if the handover were tried to this
other cell, it wouldnt have failed. (This assumes that the BSIC information in the downlink

19
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

was recently decoded, excluding the possibility of a corrupted measurement.). See figure
A.2.3 for detailed classification criteria.
UL_not_cnsd_wrong_HO: Handover is successful but call drops in the first 5s in the
new cell due to poor uplink conditions. Downlink conditions were good, suggesting that the
current Handover algorithm did a correct decision based on the limited information. At
least one other neighbor was available with signal level higher than GOOD_70%. If the
uplink conditions were considered, maybe the handover algorithm would have chosen this
other neighbor. See figure A.2.5 for detailed classification criteria.
The distribution of calls in this class is as follows:

Distribution of Class UL not Considered

UL_not_cnsd_hf
Vienna
Czech
Ankara
Microcells
UL_not_cnsd_wrong_HO

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
% over all Eq. Fail. Dropped Calls

A.2.5. Class Sudden Power Interruption: (Sudden Power Interrup.)


MS was with good quality and more than good signal when call suddenly stops sending
measurement reports. This phenomenon suggests that user might have turned of his
phone (or ran out of power) and call-clearing protocol couldnt be processed. If this
suggestion is confirmed, this type of dropped call is not seen as dropped call from the user
point of view. (This class will need confirmation with field tests). See figure A.2.1 for
detailed classification criteria.

A.2.6. Class Region with Weak Signals (Region Weak Signals).


Call entered in a bad state; received signals from neighbors were higher than the
minimum one, but not enough to guarantee that the call would face good quality in it
(lower than GOOD_70%); received signal from serving cell was higher than the minimum,
implying that co-channel interference was the reason for the bad quality.
This region with unsuitable coverage is similar to the poor coverage case since no
neighbors could provide relatively good signals.
This class can also be related to mistakes or constraints in frequency planning.
Calls are classified in this class through 8 different ways (subclasses):
Reg_WeakSig_Interf_hf: handover was tried but failed due to low signal levels in target
and other neighbor cells. Call went back to serving cell and dropped due to co-channel
interference. See figure A.2.3 for details of classification.
Reg_WeakSig_low_cand_hf: same situation as Reg_WeakSig_hf, but the signal levels
were higher than RXLEV_MIN and lower than GOOD_70%; i.e., the call was in a region
that is not well served by any of the cells. See figure A.2.3 for classification details.
Reg_WeakSig_Interf_no_HO: call quality degraded and alternative neighbors were not
available (not reported by MS) and call dropped. No handover command was triggered.
Serving Signal level was higher than the minimum one, suggesting that the call was
suffering co-channel inference. See figure A.2.2 for details of classification.
Reg_WeakSig_low_cand_no_HO: same situation as Reg_WeakSig_Interf_no_HO, but
the signal levels were higher than RXLEV_MIN and lower than GOOD_70%; i.e., the call

20
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

was in a region that is not well served by any of the cells. See figure A.2.2 for
classification details.
Reg_WeakSig_Interf_wrongHO: handover was successful but call dropped in first 5s
(2.5s also tested) in the new cell. All neighbors had signal levels lower than RXLEV_MIN.
Serving cell level was higher than RXLEV_MIN, suggesting that the call was suffering co-
channel interference. See figure A.2.5 for details of classification.
Reg_WeakSig_low_cand_wrongHO: same situation as Reg_WeakSig_Interf_wrongHO,
but the signal levels were higher than RXLEV_MIN and lower than RXLEV_GOOD_70%;
i.e., the call was in a region that is not well served by any of the cells. See figure A.2.5 for
classification details.
Reg_WeakSig_Interf_HO_delay: handover command was sent but was not heard by the
MS. However, even if it were heard, there is a good chance that it wouldnt succeed due to
the low signal levels in the neighbors. This class could be classified as Handover Delay
but it is difficult to say that if the handover were not delayed, the call would not have
dropped. Serving cell level was higher than RXLEV_MIN, suggesting that the call was
suffering co-channel interference. See figure A.2.4 for details of classification.
Reg_WeakSig_low_cand_HO_delay: same situation as Reg_WeakSig_Interf_HO_
_delay, but the signal levels were higher than RXLEV_MIN and lower than GOOD_70%;
i.e., the call was in a region that is not well served by any of the cells. See figure A.2.4 for
classification details.

In the systems analyzed, the patterns described have the following contribution on the
final Region Weak Signals class.

Distribution of Class Region Weak Signals

Reg_WeakSig_Interf_hf

Reg_WeakSig_low_cand_hf

Reg_WeakSig_Interf_no_HO
Vienna
Reg_WeakSig_low_cand_no_HO
Czech
Reg_WeakSig_Interf_wrongHO Ankara
Microcells
Reg_WeakSig_low_cand_wrongHO

Reg_WeakSig_Interf_HO_delay

Reg_WeakSig_low_cand_HO_delay

0% 20% 40% 60% 80% 100%


% over all HO_Alg_Fail Dropped Calls

A.2.7. Class Adjacent Channel Conditions not considered in Handover Procedure:


(inside other)
Wrong handover decision to a cell with bad uplink conditions due to adjacent interference
from other carriers from serving cell. Handover fails and call returns to original serving
BTS when it is too late for another handover. Other cells could have received the call
successfully. The algorithm did not account for this during the handover procedure.

21
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Thus, if adjacent channel conditions were considered during the handover algorithm, the
target neighbor would not have been chosen, another good neighbor would have been
chosen instead and the drop could have been avoided.
This class is similar to the Uplink conditions not considered class.
See figure A.2.3 for detailed classification criteria.

Information required to confirm this class:


How was the uplink channel during the handover?
Was any user using the carrier that is adjacent to the BCCH of the target cell?

A.2.8. Class Poor Coverage:


MS entered in area where signal levels from serving cell drops below minimum required
and no other neighbor cells were available for handover.
Three patterns were identified in this class:
Poor_Coverage_std: call dropped because no cell was with enough signal levels. No
handovers were tried. See figure A.2.2 for detailed classification criteria.
Poor_Coverage_hf : Handover was tried but Failed probably due to the low target
neighbor signal level. No other neighbors were available. See figure A.2.3 for detailed
classification criteria.
Poor_Coverage_ho: Handover was tried but was not heard probably due to the low
target neighbor signal level and bad quality since the beginning of the record. (This pattern
is related to a wrong handover decision since the bad situation was since the beginning of
the record and there was no way of sending the Handover Command before the bad
situation.) See figure A.2.5 for detailed classification criteria.
Poor_Coverage_delay: Handover was tried but was not heard; however, even if it
were heard, the call would still drop because all neighbors (and the serving cell) were with
signal levels lower than the minimum required. See figure A.2.4 for detailed classification
criteria.
All of these patterns could be caused by the lack of BCCHs in the NLIST. In other words,
there could be a BCCH with strong received level that was not being monitored by the MS.

In the systems analyzed, the patterns described have the following contribution on the
final Poor Coverage class.

Distribution of Class Poor Coverage

No HOs
(standard)
HO not heard in Microcells
Poor Cov. Area Ankara
Poor Coverage Czech
during HO Vienna
Poor Coverage in
HO failure

0% 20% 40% 60% 80% 100%


% over all Poor Coverage Dropped Calls

22
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

A.2.9. Class Abrupt degradation of signal: (No Time for Handover)


Signal was in good state (very good quality) and within 1 second passes to a very bad
state, with no time for a handover. This situation suggests the need for algorithms that
could forecast a degradation of the call in order to send a handover command before the
degradation happens. See figure A.2.4 for details in the classification.

A.2.10. Class Lack of Resources:


There are 3 types of patterns related to Lack of resources.
Lack Resources std: Lack of Resources in target cell during a handover between
BSCs. This pattern can be recognized through the messaging logged in the CTP. See
figure A.2.1 for details in the classification.
Lack Resources - NoHO: Lack of Resources during handover inside the BSC, where
several HO_REQUESTs were requested by the BTS but no Handover Command was
ever sent to the MS. The detailed classification for this case can be seen in figure A.2.2.
Lack Resources - Delay: Lack of Resources during handover inside the BSC caused
a delay in the generation of the Handover Command. This delay is indicated by the
HO_REQUEST messages sent before the handover command. If the Handover
Command were generated before, the MS might have heard it. See figures A.2.3 and
A.2.4 for detailed classification.
Distribution of these patterns in the class:

Distribution of Class Lack of Resources

Lack Resources
delaying HO
Microcells
Lack Resources Ankara
- noHO Czech
Vienna
Lack Resources
- std

0% 20% 40% 60% 80% 100%


% over all Poor BSIC Config. Dropped Calls

A.2.11. Class Equipment Failure:


This class includes calls that show messages that explicitly refers to equipment failure
(EqFail_msg) and also includes calls that was interrupted by the network without any
reasonable messages while the RF channel was on ( EqFail_no_msg).
See figures A.2.1 for detailed classification.
The distribution of calls in this class is as follows:

23
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Distribution of Class Equipment Failure

EqFail_msg
Microcells
Ankara
Czech
Vienna
EqFail_no_msg

0% 20% 40% 60% 80% 100%


% over all Eq. Fail. Dropped Calls

A.2.12. Class Handover Message lost in Downlink fading: (inside other)


Handover message is sent when MRs show that the Donwlink is still good (RXQUAL < 5),
but it is not heard by the MS. This suggests that the message was probably lost due to a
momentary fading in the downlink. See figure A.2.4 for detailed classification criteria.

A.2.13. Class Long Time to Decode BSIC: (Long Time Dec BSIC)
The MS is not able to decode the BSIC of the neighbor being measured every time that it
measures it. The MS decodes it periodically, however, interference might be happening in
the period of time when the BSIC is not being decoded and wrong measurements are
present in MRs. These wrong measurements might cause a wrong handover decision to a
cell that is facing interference in the downlink.
This situation might happen more often in cases where the Neighbor List has too many
neighbors listed.
Calls in this class can be classified through 2 different ways:
Long_Time_dec_BSIC_wrong_HO: handover is executed to a cell with poor
downlink quality since the moment the call entered in this cell. The downlink signal level
was good enough, suggesting that interference was present. If the MS tried to decode the
BSIC of this signal, it probably wouldnt be able. Since it is not able to decode the BSIC in
every measurement, there is a good chance that this wrong handover decision was due to
corrupted measurements. See figure A.2.5 for detailed classification.
Long_Time_dec_BSIC_hf: handover was tried to a cell that has fewer occurrences
(see appendix E) than other BSIC/BCCH combinations. Thus, there is a good chance that
the MRs that triggered the handover to this cell were corrupted. See figure A.2.3 for
detailed classification.
The distributions of calls among this 2 subclasses is as follows:

Distribution of Class Long Time to Decode BSIC

Long_Time_dec_BSIC_wrong_HO
Vienna
Czech
Ankara
Microcells
Long_Time_dec_BSIC_hf

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
% over all Eq. Fail. Dropped Calls

24
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

A.2.14. Class Handover Not Triggered : Failure to Generate Handover Command


Algorithm failed to generate a handover command even though there was a good
neighbor being reported by the MS. After little time, the call drops.
Calls in this class can be classified through 2 different ways:
HO Margin not Satisfied: the good neighbor was higher than the minimum level, but
was not better than the serving cell. See figure A.2.2 for detailed classification.
Failure in Algorithm Procedure: the good neighbor was with signal level higher than
the serving cell signal level and higher than GOOD_70% (relatively good level). Even with
these conditions, the algorithm did not trigger handover. This behavior can be justified by
the exclusion procedures taken in place in the handover triggering algorithm in the BTS.
See figure A.2.2 for detailed classification.
The distributions of calls among this 2 subclasses is as follows:

Distribution of Class NoHO Alg. Failure

Failure in
Algorithm Microcells
Ankara
Czech
HO Margin not Vienna
Satisfied

0% 20% 40% 60% 80% 100%


% over all HO_Alg_Fail Dropped Calls

A.2.15. Class Bad UL: no info : Information not Available due to Bad Uplink
MS handed over to a new cell but uplink was bad since the beginning and no
measurement reports could be reported to BTS and the call dropped.
This class may have calls that could fit in the UL not considered class if there were a
different neighbor capable to receive the call; however, there is no information about
neighbors. This class may also have calls that could fit in the Poor Coverage class in case
no neighbors were available and the handover was just the last resort to save the call.
See figure A.2.1 for details on the classification criteria used.

25
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Handover performed
TCH Allocated or Loss of UL time Any error message
n y n Bad UL, no info.
or Normal Clear msg? == indicating equipment failure
available
(without RF loss msg) Time of 1st MR? ?
Ongoing call ? y
n
y Equipment Failure
(EqFail_msg) Lack Resources
Good Call

y
y
RF Loss?
Any error message Any error message
(>2.5s of bad quality (UL or DL) n n
indicating equipment failure Indicating lack of resources
or
? ?
Lack of MRs for > 2.5s)

Could be due to lack y Eq. Fail. no msg.


n
of power in MS
n
good Any error message
Sudden Power y y
RXQUAL indicating radio interface
Interruption
in both UL and DL? failure ?

n
Handover Command Wrong
Handover not n Generated Call entered in bad state y Call Setup Failure: Handover
(inside eval. window) when changing carriers No TCH eval.
Triggered during TCH assign? n Decision
?
y
n
n

HO_Failure y
Handover Failure
Beginning of bad state time
Handover Cmd y Last of good state time
Messages >
message found ? minus y not heard
1 st MR sample?
TCH Assignment time By MS
n > 5 sec?
n y
n
HO_Failure Handover Command
y n y
message not heard by MS? Ongoing call? Beginning of bad state time < 5 sec?
(ho_time ~= loss_UL time)
detected

Figure A.2.1

26
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

# of HO_Requests
Handover not y Lack Resources
within 7.5s of
Triggered (noHO)
HO_time > 1 ? HO alg. preffered to run the risk of loosing the call
by leaving it in current cell than to run the risk of
n
a handover to a not-so-good neighbor

Any valid neigh. w/ avg Any valid neigh. w/ avg Handover not
y n
RXLEV>RXLEV_MIN RXLEV> Serving cell RXLEV Triggered due to
@time UL is lost ? @time UL is lost ? HO_MARGIN
No candidates available and n
Serving RXLEV very low Bad Ordering Proc.
Poor BSIC
y caused ho to a
Bad RXQUAL and Configuration
2nd tier cell
Poor Coverage n RXLEV<RXLEV_MIN (Poor_BSIC_conf_
that couldnt sustain
(Pcov_std) at end of window noHO)
the call
(in DL or UL) ?
y
User suffering co-channel y
interference but there was 1st Timing Advance sample >5km
and n
no handover option. Region Weak Signals Beginning of bad state time < 5sec
(Reg_WeakSig_Interf_noHO) ?

y
Region Weak Signals n Any of these neighbors with y n
Any of these neighbors
(Reg_WeakSig_lowcand RXLEV > RXLEV_GOOD_70% On-going call?
In Neighbor List?
_noHO) ?
n
y
MS reported neighbors that n
Call was in a region 1st Timing Advance
were not expected!
not well served by any cell sample >5km ?
MS might be connected
to a geographically far cell y
There was good neighbor
available and no HO was
Triggered! (Bad Call Setup)
Handover not triggered
Bad Origination
due to Algorithm failure
or
Delay in Reselection

Figure A.2.2

27
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

call in poor Poor Coverage


Lack of Channels
coverage (Pcov_hf)
(delay)
situation y
HO_Failure y
message found Bad RXQUAL and
# of HO_Requests all valid neighbors w/ y Any invalid neighbor
n RXLEV<RXLEV_MIN
within 7.5s of HO_time avg(RXLEV) < RXLEV_MIN w/ RXLEV > RXLEV_MIN
n at end of window
HO_Failure >1? @ HO_time? @ HO_time?
(in DL or UL) ?
message not n y
Long_Time_dec_ n Co-channel
detected BSIC_hf interference
is the target neigh (from Delay in Recog.
n
the failed HO) in the new neighbor Region Weak Signals
There are other neigh NLIST ? (Reg_WkSg_hf)
There was w/ same BCCH w/
better neigh y
more occurances than y
not chosen due the target BCCH. MR
to an invalid with high chance of is there any other
BCCH+BSIC being corrupted y n is there any non-valid neighbor with
valid neighbor with
combination RXLEV>RXLEV_target
avg(RXLEV) > avg(RXLEV_target)
@ ho_time?
is there any of these @ ho_time ?
Poor BSIC n
neighbors in Based on DL measurements,
Config. (hf) n
the NLIST ? the target was the best choice.
y HO might have failed due to
Is there any neigh Is BCCH of target bad UL conditions in the
y n
different than target neigh adjacent to target. (If this is the case, the
Bad Ordering Proc. w/ RXLEV>Good70% any of the carriers choice was NOT the best one).
(Bad_Ord_hf) UL not Considered ? in use in serving cell?
(UL_not_cnsd_hf)
Excessive adj-channel
n y
Interference might have happened
HO alg. chose If it reaches here, it means
target neigh that the HO failed, although Is there any neigh
although other the DL path was very good. n y
Region w/ Weak Signals different than target Adjacent Channels
better neighs Maybe the HO wouldnt fail if (Reg_WkSg_low_cand_hf) w/ RXLEV>Good70% not considered
were available. UL were considered in the ?
HO proc.

All signal levels are low and


there might not be any other
neigh to receive the call

Figure A.2.3

28
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Bad RXQUAL and n Poor Coverage Even if HO were listened by MS,


Region Weak Signals Any neigh. w/
y n RXLEV<RXLEV_MIN (Pcov_dly) The call would be in bad coverage area
(Reg_WeakSig_ RXLEV > RXLEV_MIN
at end of window y
low_cand_dly) @ beginning of bad state?
(in DL or UL) ? Co-channel
n
interference
Any valid neigh. w/ avg # of HO_Requests
Handover Cmd RXLEV>GOOD_70%
y
within 7.5s of
y Lack of Channels
Region Weak Signals
not heard by MS (delay)
@beginning of bad state? HO_time > 1 ? (Reg_WeakSig_Interf_dly)

<3 n If other neigh were


Unknown chosen, HO would have
2<,<6 Test RXQUAL n Did HO happen when been triggered before
HO command lost
in DL UL contact already lost?
pby. Fading in DL
Bad Ordering Proc.
>5 y HO delayed due
causing HO delay
Assuming time of beginning to recent TCH
(Bad_Ord_delay)
of bad state as the last Poor BSIC assignment
time to send the ho_cmd Configuration
(Poor_BSIC_conf_dly) 1st average sample
Ho delayed due
NoTime Time between beginning of still not available
n y to other procedures
bad state and n
in algorithm
last good state > 0.6 sec? HO delayed due
even fastest ho would Any of these neighs. to time required
not save the call in NLIST? y n
y to decode neighs.

time when voting would n Beginning of bad state time


y n
trigger the HO_CMD if >
averaging wasnt present Any other valid TCH Assig. Time + 2.5 sec?
Any of these valid neigh.
HO delayed due > neigh. with RXLEV >
y with 1st average sample available y
to voting proc. time when averaging would Serving cell RXLEV
before the target chosen? n
in RXQUAL trigger the HO_CMD if + 5dB
or before ho_time 2sec?
voting wasnt present ?
time when average
Imperative Hos are && > Ho_time 0.75sec There might y sample of target neigh
first triggered by ? be other > Serving cell RXLEV
RXQUAL conditions n time when
better + HO_MARGIN
(thats why they are 1st average
y candidates <
checked first) sample of target n
time when averaging would Ho_time 0.75 sec
becomes available
trigger the HO_CMD if ?
<
HO delayed due y voting wasnt present n Any other valid neigh. with
n Ho_time 0.75 sec y
to averaging proc. > RXLEV>RXLEV_target
?
in RXQUAL Ho_time 0.75 sec @ time of ho?
? HO delayed due
Delay caused by neighbor to HO_margins
conditions requirements

Figure A.2.4

29
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

unknown
Bad Ordering Proc.
or n
HO triggered too early y Uplink not
Bad RXQUAL_UL
considered
in end of window ?
y in HO decision
Wrong Handover Just one neighbor 1st sample of Serving cell RXLEV n
decision with RXLEV>RXLEV_GOOD_70% < n
1st sample of this neighbor Bad RXQUAL and Wrong HO
y
? RXLEV< RXLEV_MIN due to
at end of window Long Time to
good neigh might be the
(in DL) ? Decode BSICs
previous serving cell
these tests tries to infer
Signal level that made HO
what was the condition
choose this cell was
before the HO
corrupted by interference
n
More than 2 neighbors 1st sample of Serving cell RXLEV
with RXLEV>RXLEV_GOOD_70% < y Bad Ordering
Evaluate Neighbors
1st sample of (at least 1) of these 2 neighbors Procedure
?

There was other better


neighbor candidate
neighbors with
RXLEV>RXLEV_MIN
Region Weak Signals
but <RXLEV_GOOD70%
(Reg_WeakSig_
low_cand_wrongHO)

call was in area where no


neigh provides good service
Co-channel
interference
All neighbors with Bad RXQUAL and
RXLEV < RXLEV_MIN RXLEV<RXLEV_MIN y Region Weak Signals
at end of window (Reg_WeakSig_Interf_wrongHO)
(in DL or UL) ?
(of call in serving cell)
n

Poor Coverage
(Pcov_wrongHO)

Figure A.2.5

30
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

A.3. Bad Call Setups

A.3.1. Class Uplink not considered in Reselection Procedure: (UL not Considered)
MS was camped in a cell with bad uplink quality due to the fact that GSM reselection
procedure considers only downlink received level measurements [3]. If uplink
measurements were considered, MS would have searched for another cell.
See figures A.3.1 and A.3.2 for detailed classification criteria.
The fact that other neighbors were available implies that there is a chance that if the MS
reselected to this neighbor before initiating the call, the call setup would not have failed.

A.3.2. Class Delay in Reselection:


MS was camped in a cell in a position where excessive interference was present. MS
probably did not reselect because of long delays in the reselection procedure. Cases
when interference was not present and neighbors with better signal were present were
also considered in this class; in these cases, reselection delay was caused by
measurement and averaging delays of neighbor measurements [3]. This class also
includes cases where the reselection was delayed due to penalties in the reselection
algorithm; in these cases, a better neighbor was detected but reselection was not
triggered due to the penalty imposed.
(Penalties are margins imposed in neighbor cell measurements. Thus, the neighbor signal
must be higher than the serving signal plus the margin. This procedure delays the
triggering of a reselection and keeps the MS in the currently camped cell. This procedure
is normally used to keep a MS in a particular cell or layer.)
See figures A.3.1 and A.3.2 for detailed classification criteria.

A.3.3. Class Poor Coverage:


Call was initiated in an area where signal levels from serving cell were not enough for call
establishment. Neighbor cells werent available for handover and call setup was
interrupted before TCH allocation.
This class is subdivided in 2 subclasses:
Poor Coverage before call initiation: even if reselection were tried, it would not have
found any option. See figures A.3.1 and A.3.2 for detailed classification criteria.
Poor Coverage during call setup: even if direct retry were tried, it would not have
found any option. See figures A.3.1 for detailed classification criteria.
In the systems analyzed, these 2 subclasses had the following contribution on the final
Poor Coverage class.

Distribution of Class: Poor Coverage

Poor Coverage
before Access Vienna
Czech
Ankara
Poor Coverage Microcells
during Acces

0% 20% 40% 60% 80% 100%


% over all Poor Coverage Bad Call Setups

31
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

A.3.4. Class Lack of Resources for Call Setup:


Service Request was denied due to lack of free channels in current BTS. A particular
message identifies this class. See figure A.3.1 for detailed classification.

A.3.5. Class Sudden Power Interruption:


Signaling in control channel was occurring and call was showing good quality and good
received signal level when suddenly measurements reports cease and setup fails. This
can be due to user turning of his radio when it rings or mobile ran out of power. Field tests
are necessary to confirm this class. See figure A.3.1 for detailed classification.

A.3.6. Class TCH Condition not considered in Assignment: (No TCH Evaluation)
Call is allocated a channel in a carrier different from the BCCH, and call drops due to bad
quality within 2.5 seconds. There is a chance that this drop would have been avoided if
TCH interference condition were evaluated before assignment. See figure A.2.1 for
detailed classification.

A.3.7. Class Equipment Failure:


Service Request was denied due to equipment failure. See figure A.3.1 for detailed
classification.

A.3.8. Class Region with Weak Signals:


Call entered in a bad state moments after TCH allocation; received signals from neighbors
were higher than the minimum one, but not enough to guarantee that the call would face
good quality in it; received signal from serving cell was higher than the minimum, implying
that interference was the reason for the bad quality. This region with unsuitable coverage
is similar to the poor coverage case since no neighbors could provide relatively good
signals. See figure A.3.1 for detailed classification.

A.3.9. Class Handover between Cells during Setup not triggered: (No HO in Setup)
Quality degrades during call setup, neighbors are available but no handover is triggered.
See figure A.3.1 for detailed classification.

A.3.10. Class Lack of Information from Uplink: (Bad UL: no info)


This class groups the records that couldnt be evaluated due to lack of samples. These
samples could mean a very bad Uplink (then Measurement Reports did not reach the
BTS, which would be a UL_not_cnsd problem) or a Delay in Reselection or a Poor
Coverage problem.
See figure A.3.1 for detailed classification.
The relative high rate of this group requires confirmations in the field.

A.3.11. Class Bad Origination


Call was initiated in a cell far located geographically (>5km), went into a bad situation but
no handover was triggered. BSICs being reported by MS were found to be out of the
Neighbor List (see appendix E for details on how the neighbor list was obtained). The call
shouldnt have initiated on this cell. This class can also be a Delay in Reselection. See
figure A.2.2 for detailed classification.

32
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Handover performed RF Loss?


Any error message Any error message
or user disconnected n (>2.5s of bad quality (UL or DL) n n
Bad Call Setup while quality was or Lack of MRs for > 2.5s
indicating equipment failure Indicating lack of resources
? ?
good? or RF failure message)
y y
y y Equipment Failure Lack Resources
Good Call
y y
Loss of UL time y Any error message Any
y error message
n
Call was in bad == indicating equipment failure Indicating lack of resources
conditions since Time of 1st MR? ? ?
the beginning n n
Can be UL not considered
Or Poor Coverage
Bad UL, no info.
Or Reselection Problem
Bad RXQUAL available
Reselection y
In UL or DL
Problem @ first MR sample?
Could be due to lack
of power in MS n

Good RXQUAL
Sudden Power y
DL and UL
Interruption
@ last MR sample?
No reason to fail since
RXQUAL was good in
n
both links

neighbors with
RXLEV>RXLEV_MIN 1 or more neighbors
Region with but <RXLEV_GOOD70% with RXLEV>RXLEV_GOOD_70% Handover not
Evaluate neighbors
Weak Coverage Triggered in Setup

All neighbors with


Poor Coverage RXLEV < RXLEV_MIN
(Pcov_dur)

Figure A.3.1

33
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Reselection Problem

Delay in
Check 1st sample of Reselection
Bad RXQUAL DL
RXQUAL UL and DL
in window

Bad RXQUAL UL
&& 1 or more neighbors with
Good RXQUAL_DL 1st sample of
RXLEV >RXLEV_MIN

Check first
< RXLEV_MIN
sample RXLEV DL Evaluate Neighbors
in window
Downlink
in bad situation No neighbors with
RXLEV > RXLEV_MIN

> RXLEV_MIN

Poor Coverage
1 or more neighbors with No neighbors with
1st sample of RXLEV > RXLEV_MIN
RXLEV >RXLEV_MIN
Evaluate Neighbors

UL not
considered
in Reselection

Figure A.3.2

34
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Appendix B: This common format enables it to be read


B.1 General Description by many different software, including
MATLAB, Excel, XMGR Graphic tool, etc.
CTP text output (raw data) provides
information that humans can read very If a call contains successful handovers
easily (with titles, subtitles and during the call, the "splitter_pg_pg.pl"
explanations). However, its format is not software is used. This software separates
suitable for a program to read. Thus, before the call in several set of files based on the
analyzing the data, it must be translated to number of handovers during the call. For
an easier (common) format. In addition, example, if a call starts in Cell A, hands
CTP text output may have several calls in over to Cell B and drops, this call will be
it. treated as 2 calls, one with a successful
handover and another with a drop (future
The translator software ("t_gsmctp.pl") will versions will consider the information from
thus separate each call and will generate 3 the origination cell before the handover).
text files for each call.
measurement data file (*.DAT)
B.2 Information extracted from the CTP
messages file (*.MSG) output
original text file (*.TXT). The output text file of CTP provides
The 2 first files are numeric matrixes where basically 2 types of information:
each column represents a parameter being Measurement Reports (MR) from MS and
reported and each line represents an signaling information exchanged among
instance in time. The third file (*.TXT) is a MS, BSC, BTS and MSC.
reproduction of the original CTP text output The information provided in the MRs is:
for messages occurring in that file (this file (The (*) sign following each information
is just for aid purposes and is not used by indicates that this information is being
other parts of the software. The reasons for extracted from the raw output text file;
TXT file are: (a) be able to extract otherwise the information is being ignored)
information that is not normally extracted in
(*) Time stamp
the MSG file; and (b) avoid the search of a
particular call in a very long file, like the Hour, minute, second and millisecond
one produced by the CTP output.) when the call occurred
The only requirements in the Common (*) Call duration (relative to the time when
Matrix Format are: the Call Trace begun)
ASCII text file format Location Area code (LAC)
each line must refer to a time instance (*) Cell ID
(lines are separated by "new-line"
(*) Carrier being used
characters)
(*) Timeslot being used
each column must refer to a particular
measurement / characteristic in every line DTX (Discontinuous transmission) in
(columns must be separated by a space Uplink and Downlink
character or tabulation). Channel type being used
every line must have the same number of TMSI
columns.
SCCP
the 1st column must be the time reference
of the information in other columns Received level in Uplink, in serving BTS,
when power control (PC) is not active
no text information (i.e. columns must (RXLEV_UP_NON_PC);
contain only numeric values)
(*) Received level in Uplink, in serving
Note that there are not limitations in the BTS, when PC is active (RXLEV_UP_PC);
number of lines neither in the number of
columns. Received level in Downlink, from serving
BTS, when PC is not active
(RXLEV_DOWN_NON_PC);

35
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

(*) Received level in Downlink, from is examined and the translator tries to
serving BTS, when PC is active match several different pre-defined strings.
(RXLEV_DOWN_PC); Once a string matches, its corresponding
numeric is assigned to the type of the
(*) Received Quality in Uplink in serving
message. The following are the strings that
BTS (RXQUAL_UP)
are searched in the actual implementation,
(*) Received Quality in Downlink from with its corresponding meaning:
serving BTS (RXQUAL_DOWN)
"Cause: Downlink quality": represents
(*) BTS transmitted power handover due to bad downlink quality
(*) MS transmitted power "Cause: Better cell": represents handover
Path balance triggered by a better cell

(*) Timing advance [GSM ref] "Cause: Uplink quality": represents


handover due to bad uplink quality
(*) BSIC and BCCH used from 1 to 6
neighbor BTSs "Cause: Uplink strength": handover
triggered by weak uplink received level
(*) Received level in Downlink from 1 to 6
neighbor BTSs (RXLEV_NEIGH[1..6]) "Cause: Downlink strength": handover
triggered by weak downlink received level
Difference between Received level from
neighbor BTSs (1 to 6) and serving BTS. "RLM Cause: timer T200 expired": error
message meaning that handover command
was not answered by MS;
This information is provided by the MS "BSSMAP: Clear request": currently not
every 0.5s in every tracked call. As being used;
indicated, not all information is being
collected. "RLM Cause: Loss OF SACCH from
Handover": error message;
The information provided in the signaling
messages is repeated in the TXT file as "RLM Cause: sequence error": error
already explained. This information is also message;
examined and a numeric matrix is also "Cause: Uplink interference": handover
generated (MSG file). From the signaling caused by uplink interference;
messages, the following information is
extracted: "Cause: Downlink interference": handover
caused by downlink interference;
Time
"DTAP: Authentication request": message
Type of message (see below) used to determine call setup instances;
BSIC, BCCH and RXLEV_NEIGH of the 3 "ABIS: Encryption command": message
first neighbors in the Candidate List used to determine call setup instances;
generated from the BSC to the MSC
whenever handover messages is detected. "RR: Assignment complete": message that
(Note that not all neighbors reported by the indicates that mobile is going to TCH;
MS are put on the Candidate list to the "DTAP: Alerting": currently not being used;
MSC).
"ABIS: Trace request": currently not being
Cell ID used;
Carrier being used "RR: Handover failure";
BSIC and BCCH of chosen neighbor to "ABIS: RF channel release acknowledge":
handover (when handover command is currently not being used;
sent from the MSC to the MS)
"Radio interface failure"
"Paging response": indicates beginning of
Note that some of the information above is the call setup when MS answers the paging
not contained in the MR generated by the command;
MS.
"Service request": indicates beginning of
The type of message is a numeric value the call setup when MS originates the call;
that tries to represent the message that is
being exchanged. The actual text message

36
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

"Cell Description": used in the handover


command to indicate the cell for the MS to
handover;
"Handover performed"
"Cause: Normal to Extended Range TS":
handover caused due to higher time
advance required;
"Assignment failure": different meanings:
failure to handover, failure to allocate TCH
channel;
"DTAP: Disconnect (network -> MS)": call
clearing initiated by network;
"DTAP: Disconnect (MS->network)" call
clearing initiated by MS.
(obs: strings are considered individually,
when more than one string matches, the
last matched string will be considered as
the type of the message)
Notice that the type of message just means
that a particular string was found on that
particular instance of time (this means that
the translator might be adjusted whenever
changes in the description of the messages
occur). This information, combined with
others, may help the classifier in finding out
the cause of the dropped call/bad call
setup.
It is important to mention that not all
messages are being considered. The
actual implementation considers just the
messages that are considered to be
relevant for the problem of determining the
cause of the dropped call/bad call setup.

37
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Appendix C: Details of Analysis READER


Software
TOOLS
As explained in appendix B, each call
record in the CTP text output generates GSM_TOOLS
one or more sets of output files. FEATURE_EXTRACTOR
The Analysis software is built from the CLASSIFIER
following modules:
The following picture will help in the
understanding.

*.DAT files
(1 per call)

CTP Translator
raw Sw (PERL)
data (t_gsmctp.pl) READER

*.MSG files
(1 per call) vectors matrixes

TOOLS

GSM_TOOLS
Time value Time col1 col2 col3 colN
1.0 10 1.0 10 0 40 . -5
5.0 13 5.0 13 0.5 42 . -4
FEATURE 10.0 18 10.0 18 0.1 48 . -8
. .. ..
EXTRACTOR
100.0 15 100.0 15 -0.1 37 .. -2
. .. ..

CLASSIFIER

The READER module has functions that FEATURE_EXTRACTOR just sends the
read the set of files generated by the pointer to the vector object containing the
Translator Software and allocates them in signal values to be treated and TOOLS
the memory. The treatment is object returns the pointer to the vector object
oriented. Whenever any other module containing the output of the treatment.
needs to treat a call record, it uses the The TOOLS module also provides a
functions of the READER module. The function to extract structural features [3] of
READER treats and creates two kinds of a signal that has variations in amplitude
objects: matrixes and vectors. Matrixes are over time. The idea is to reduce any signal
considered a linked list of arrays with a to a word that can describes the structure
certain number of columns, the first one of the signal over time, allowing easy
being the time reference. Vectors are analysis of the signal. Briefly, the function
considered a linked list of values, each with will read a signal in pre-defined instances
its time reference (it can also be seen as a of time and will fit the signal amplitudes in
matrix with 2 columns). Thus, the READER pre-defined ranges. For example, if 2
is just an interface with the set of files instances of time (t0 and t1) and 2 ranges
generated by the Translator software. of values are considered (range 0: v0 to v1
The TOOLS module has functions that can and range 1: v1 to v2), any signal will be
be used by the FEATURE_EXTRACTOR reduced to a 2-bit word (00, 01, 10, 11).
module. FIR filters, functions to average or The Module GSM_TOOLS works as the
extract the derivative of a signal and TOOLS module, but it contains functions
function to suppress zeros were that are to be used exclusively in analysis
programmed during this first version. The

38
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

of GSM signals. This module has functions represents a class. The function receives
that will treat signals from neighbors the list of features corresponding to a call,
reported by a GSM Mobile Station. These performs several tests in the features and
functions are necessary because neighbor returns FALSE if the call fails one of the
signals are not organized in Measurement conditions. The definition of each class is
Reports; in order words, the set of completely independent from the definition
neighbors reported in each instance of time of other classes.
can be different. These functions were
separated from the TOOLS module in order
to make this last one more generic.
The FEATURE_EXTRACTOR is the
module responsible for feature extraction
from the call. In order to allow future use,
this module was separated in 2 modules:
one that controls the feature extraction and
other that has the definition of the features.
The module that controls the feature
extraction will receive a list of the calls to
be treated, will invoke customized feature
functions (defined in the features definition
module) for each of the calls and will
generate a matrix in memory with each line
referring to a call and each column
referring to a feature. This matrix is used by
the classifier and is also saved in memory
for possible future treatment by outside
software (for example, a data mining
software).
The module that has the definitions of the
features is a customized module. Features
are coded in C and use functions from the
READER, TOOLS and GSM_TOOLS
modules.
Based on the matrix of features generated
by the FEATURE_EXTRACTOR, the
CLASSIFIER module classifies each call
based on the classification criteria. The
CLASSIFIER module is also based in 2
functions: one that controls the
classification and other that has the
definitions of the classification criteria for
each class.
The control part of the module will receive
the matrix of features and, for each line of
the matrix, will check if the corresponding
call has features that fit in a defined class.
A new matrix of features is created
containing just the calls that are part of the
defined class. The control part generates
one matrix of features for each class and
generates a basic report on each of the
classes (number of calls classified in each
class, number of calls in more than one
class, number of calls not classified).
The part of the module that has the
definitions of each class can be customized
as needed. Basically each function

39
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Appendix D: Observation Windows used


in the Analysis
TIME_WINDOW_NOT_HEARD (8s)
The definition of the observation Window 4s | 4s

depends on general characteristics of the time


call under analysis. Note that just one HO_TIME
window is used for each call. (a)

TIME_WINDOW_NO_HO (5s)
The figure below illustrates the 3s | 2s

characteristics of major importance for the


time
definition of the Observation Window (and BEGIN_BAD_STATE_TIME
thus for the extraction of other features): (b)

TIME_WINDOW_HO_FAIL (8s)

time
HO_FAILURE_TIME
(c)
Other signals

time
First sample LOSS_UL (or last sample)
(d)
RXQUAL=6 (a): Observation Window when handover
command is sent in the record, but no
RXQUAL=2
handover failure message is found. (used
time
ASSIGNMENT_TIME LOSS_UL when the record refers to a dropped call)
LAST_GOOD_STATE_TIME BEGIN_BAD_STATE_TIME (b): Observation Window when handover
HO_TIME
HO_FAILURE_TIME command is not found. (used when the
record refers to a dropped call)
(c): Observation Window when handover
HO_TIME: time of the first command is sent and handover failure is
found. (used when the record refers to a
HANDOVER_COMMAND that happens
dropped call)
during the last 6 seconds of the call.
(d): Observation Window when the record
LOSS_UL: time when Measurement
is related to a failed call setup.
Reports start repeating in the report for at
least 2.5 seconds. In all cases, the Observation Window might
have shorter length.
HO_FAILURE_TIME: time after HO_TIME
when a Handover Failure message In dropped call records (a,b,c), the window
happens. is upper limited by the LOSS_UL (or last
sample) and is lower limited by
LAST_GOOD_STATE_TIME: last time
ASSIGNMENT_TIME or LAST_GOOD_
when call was in a good state. A good state
STATE_TIME.
is considered when uplink and downlink are
with RXQUAL < 3 (this parameter ranges
from 0 to 7).
BEGIN_BAD_STATE_TIME: time when
call enters in bad state. A bad state is
considered when either uplink or downlink
is with RXQUAL > 5.
ASSIGNMENT_TIME: time when a TCH is
assigned when the record contains the
setup portion of the call.
The figure below illustrates the 4 types of
observation windows:

40
Motorola Confidential Proprietary

Root Cause Analysis of Dropped Calls and Bad Call Setups in


GSM Systems

Appendix E: Extraction of Neighbor List needs to scan. The Measurement Reports


information contains the BSIC decoded for each
As previously explained, since the analysis BCCH; however, a particular combination
is based on data coming from several cells, of BCCH+BSIC might not be considered a
it is difficult to obtain, incorporate and valid combination by the BTS and it would
consider all the information related to each be discarded for the handover algorithm.
cell. This would justify the lack or delay of
handover commands in some dropped call
The use of standard parameters and the situations.
study of parameter variation tried to deal
with this limitation. However, it is not The following reasoning was used: if a
possible to use this artifice with regards the certain BCCH+BSIC combination were
neighbor list. reported very often, it is reasonable to infer
that this combination is in the neighbor list,
CTP does not provide the neighbor lists because the system is operating in its
used in each cell; in other words, it is not optimal state and it is expected that the
possible to obtain from CTP which BCCHs most majority of reports might contain the
are present in the Neighbor lists sent to the right combination.
MS. This information would be useful to
confirm Poor Coverage classes. On the other hand, BCCH+BSIC
combinations that were seldom reported
However, it does provide information that suggest that they are not being expected
might provide at least partial Neighbor by the BTS, and thus, are not part of the
Lists. CTP gathers all Measurement neighbor list.
Reports and creates a report summarizing,
for each cell, which BCCH and BSICs were It is important to observe that this neighbor
reported in the Measurement Reports and list summaries must be generated
how many times each combination was considering the good calls that were part of
reported. the data collection.

These Neighbor List Summaries were used


to extract information of whether a
particular BCCH+BSIC combination was in
the neighbor list. This information is
important to characterize poor BSIC
configurations in the system. See the
following explanation: The Neighbor list
that is sent to the MS by the BTS contains
only the BCCHs from the neighbors that it

41