184 IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, VOL. 9, NO.
2, JUNE 2012
An Automatic Detection and Diagnosis Framework
for Mobile Communication Systems
Péter Szilágyi and Szabolcs Nováczki
Abstract—As the complexity of commercial cellular networks
grows, there is an increasing need for automated methods de-
tecting and diagnosing cells not only in complete outage but with
degraded performance as well. Root cause analysis of the detected
anomalies can be tedious and currently carried out mostly
manually if at all; in most practical cases, operators simply reset
problematic cells. In this paper, a novel integrated detection and
diagnosis framework is presented that can identify anomalies and
find the most probable root cause of not only severe problems
but even smaller degradations as well. Detecting an anomaly is
based on monitoring radio measurements and other performance
indicators and comparing them to their usual behavior captured
by profiles, which are also automatically built without the need
for thresholding or manual calibration. Diagnosis is based on
reports of previous fault cases by identifying and learning their
characteristic impact on different performance indicators. The
designed framework has been evaluated with proof-of-concept
simulations including artificial faults in an LTE system. Results
show the feasibility of the framework for providing the correct
root cause of anomalies and possibly ranking the problems by
their severity.
Index Terms—Fault management, key performance indicator,
network management automation, root cause analysis, self-
healing.
I. I NTRODUCTION
T HE joint and rapid growth of mobile broadband data
rates, offered services and user terminal capabilities
challenge network operators in several ways. Smartphones
with high-end multimedia applications require not only high
bandwidth but low call setup delay and round trip time com-
parable to fixed line access as well, demanding capacity boost
and QoS improvements via continuously upgrading existing
radio access technologies (RAT) such as High Speed Packet
Access (HSPA) and introducing new ones such as Long Term
Evolution (LTE) and beyond. Deploying new cells on top of
older technology leads to heterogeneous networks with co-
existing radio access technologies (GSM, UMTS, (I-)HSPA,
LTE) and different layers of the same technology (LTE macro-,
pico- and femto-cells as well as relays) often sharing a large
part of the same IP-based backhaul. As a consequence, not
only the number of network elements are increasing at a fast
pace but also their interactions are becoming more complex.
Increasing complexity of mobile networks has impacts on
the management of these networks as well. Configuration,
optimization and troubleshooting of network elements are not
Manuscript received June 17, 2011; revised January 17, 2012. The associate
editor coordinating the review of this paper and approving it for publication
was A. Sethi.
The authors are with Nokia Siemens Networks, Budapest, Hungary (e-mail:
peter.1.szilagyi@nsn.com).
Digital Object Identifier 10.1109/TNSM.2012.031912.110155
1932-4537/12/$31.00 
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
only more difficult but also impose higher cost both on capital
investment and operational expenditures (CAPEX and OPEX).
The solution for these problems is to a significant degree
seen in network management automation, voiced by operator
community representative Next Generation Mobile Network
(NGMN) Alliance [1] and adopted by telecommunications
standards body 3rd Generation Partnership Project (3GPP) by
starting to develop standards covering self-configuration, self-
optimization and self-healing for LTE, collectively referred
to as Self-Organizing Networks (SON) [2], [3]. As the most
mature one of the three domains, self-configuration focuses
on automatic connectivity and commissioning of network
elements, implementing functions like plug-and-play LTE
base stations [4], neighbor cell discovery [5], collision and
confusion-free assignment of physical cell identity [6] or
relay node auto-connectivity [7]. Most of these functions are
contained by 3GPP Release 9 standards, thus they are part
of even the first LTE deployments. Self-optimization provides
operational time functions like energy saving, load balancing
[8] or automatic coverage optimization [9]. Self-healing aims
at automated fault discovery, mainly focusing on the detection
of problems like cell outage (i.e., if a cell is completely
unusable) [10], [11] and to a smaller extent also diagnosis
[12], [13].
Study on self-healing is behind the other two areas for
obvious reasons. The need for self-configuration is clear as
it deals with the earliest phase in the life-cycle of a network
element, operating with relatively straightforward algorithms,
providing cost saving already in initial deployments. The
goal of self-optimization is also well understood although the
implementation is not that mature. Self-healing, however, is
the most complex of the three domains, bearing difficulties
arising from different functions, vendors, software versions
and hardware types co-existing in a single network, with
all their specific fault cases. Tedious manual troubleshooting
processes used by operators usually produce no fault records
and statistics to be analyzed later, rendering automation of
troubleshooting more difficult. For these reasons, previous
self-healing studies have focused mainly on simple use cases
like detection of complete cell outages; however, root cause
analysis of degradations would also bring tremendous benefits
for operators, not only by making troubleshooting simpler but
saving a lot of cost as well.
In this paper, we contribute to self-healing by proposing
an automated detection and diagnosis framework for mobile
networks. In our work, diagnosis is approached as an intu-
itive process, applying the reasoning and thinking of human
diagnosis to mobile networks. Diagnosis for humans and for
c 2012 IEEE
 SZILÁGYI and NOVÁCZKI: AN AUTOMATIC DETECTION AND DIAGNOSIS FRAMEWORK FOR MOBILE COMMUNICATION SYSTEMS
networks are compared in order to understand and identify the
key challenges of the latter. Based on that, the requirements
for a practically usable automated diagnosis framework are
provided as well as the detailed design of a baseline solution
created along these requirements. The proposed framework
automatically generates profiles of performance indicators to
capture the faultless behavior of a network and later uses them
as a basis of comparison to identify significant deviations from
the usual behavior. Diagnosis is made by learning the impacts
of different faults on different performance indicators. We
evaluated our work in a simulated LTE environment featuring
artificial fault cases. Results indicate that the framework could
be a feasible alternative for root cause analysis.
The rest of this paper is organized as follows: in Section II,
the definition of detection and diagnosis are given that will
be consistently used throughout the paper and we outline the
challenges of diagnosis in cellular networks. In Section III, the
proposed automated detection and diagnosis framework is pre-
sented including automated profile creation, detection based
on these profiles and the diagnosis process. Section IV gives a
study on using the framework in a simulated LTE environment
for identifying different faults with detailed simulation results
and observations. Section V is dedicated to the management
of the framework itself and to identify synergies with other
automated network management functions. In Section VI, re-
lated work on fault diagnosis automation is discussed. Finally,
in Section VII, we conclude our paper and outline possible
directions for future work.
II. OVERVIEW OF D ETECTION AND D IAGNOSIS
Detection and diagnosis are not sharply separated in com-
mon speech. By the phrase “detecting a problem” one often
means two things actually: first, the confirmation that there
is a problem at all and second, the verification of the nature
or type of the problem itself. An example is to say to detect
that the car does not start because the plug is generating no
spark. The correct terminology in this example would be to
say that an unusual behavior has been detected (i.e., the car
does not start) and it is diagnosed that, e.g., the cause is a
cracked spark plug that has to be replaced. Detecting that the
car will not start does not necessarily mean that there is a
problem with the car itself; nevertheless, simply looking at
the symptom level with this granularity it is impossible to
tell if there is a serious problem with the car or it just has
to be refilled. Therefore, if an unusual behavior is detected,
a more thorough diagnosis has to be conducted in order to
find out if there is actually a problem and what is the root
cause behind it. Since the terms “detection” and “diagnosis”
often carry an implicit duality and thus appear overloaded in
common speech, they have to be precisely defined before used
in an engineering system such as a cellular network:
Detection basically means to identify something unusual
in the network. However, in the context of the proposed
integrated framework, the role of the detection process is only
to provide a common view of possible indicators (symptoms)
to the diagnosis to facilitate their correlation but deciding if
there is a fault at all or what it is will be left to the diagnosis.
The interface between the detection and diagnosis part is
discussed in Section III-A.
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
185
Diagnosis means to investigate the root cause that could
have caused the detected symptoms. In the proposed frame-
work, the input of the diagnosis is the output of the detection.
The output of the diagnosis might as well be that there is
in fact no problem at all. Usually, after the diagnosis of
the root cause is done, certain corrective actions have to be
performed in order to resolve the problem. Sometimes the root
cause is harder to investigate than providing the action without
knowing the underlying mechanisms; e.g., several failures can
have a common corrective action (like restarting the cell) but
the root cause is unknown for the network operator. It is even
possible that the associated action is not a direct correction of
the fault but the recommended escalation (e.g., calling vendor
support line). Therefore, using the corrective action instead of
the specific root cause is also acceptable. The root cause or
the corrective action are what the diagnosis returns and they
will be jointly referred to as the target of the diagnosis.
Based on the established terminology, human diagnosis is
now taken as an example of a successful diagnosis system and
it is compared to diagnosis for mobile networks in order to
understand the challenges behind the latter.
A. Human diagnosis
In medical diagnosis cases, the patient usually has already
detected the presence of a couple of symptoms (such as
fever, headache or sore throat) but there are also symptoms
detectable only by a doctor due to the required apparatus
(e.g., ECG, X-ray, etc.). These symptoms correspond to Key
Performance Indicators (KPI) in a mobile network, which
would be examined by the operator’s troubleshooter. From the
anamnesis and further measurements, the doctor formulates
the diagnosis, e.g., concluding that the patient’s disease, i.e.,
the root cause, is flu. This diagnosis step is based on a good
understanding of the underlying methodology of infections;
it is well-known, widely studied and educated to specialists
throughout their medical training. The corresponding treat-
ment that solves the problem in the vast majority of the cases
is also available, e.g., the medicines to take in order to relieve
pain and reduce fever. So the route taken by the doctor can
be referred to as:
DETECTION ( SYMPTOMS ) → DIAGNOSIS → ACTION
Making a root cause diagnosis first and then having a cor-
responding treatment at hand is possible due to the following
circumstances:
1) Human beings react to diseases the same way since they
have the same KPIs to examine and the same root cause
has impacts on the same KPIs across humans; thus, the
results of studies made on one population are directly
applicable to another.
2) Results are not deprecated by time since the evolution
of the human genome is very slow compared to the pace
of the evolution of technology. The knowledge acquired
fifty years ago on the symptoms of flu is still valid today.
3) Huge amount of systematic and researchable data has
been collected, stored and published.
Now let us examine the differences between the medical
and the mobile network scenarios from the same perspective:
 186 IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, VOL. 9, NO. 2, JUNE 2012
1) Mobile communication systems are versatile, have dif-
ferent KPIs, react differently to the same root cause;
the results of studies made on one system are not
applicable to another (not even within the same RAT).
Also, the processes and practices of the network operator
influence this behavior.
2) Results are deprecated quickly as technology evolves.
3) Very little data, if any, is being recorded by operators
and even that is seldom disclosed to equipment vendors
or research institutes. Usually, operators only try a
few basic actions to fix a seemingly wrong cell (e.g.,
resetting it) then instead of detailed root cause analysis
they rather call technical support of the vendor of the
network element. Measurement data from live networks
do not contain any annotation regarding if it has been
collected during faultless state or there were some faults.
In summary, automatic diagnosis in a mobile communi-
cation system seems to be more challenging than human
diagnosis, so it is important to have realistic goals for such
systems. Generally, if even the network operator is unable to
deliver the correct diagnosis in a reliable manner, it cannot be
expected from an automatic framework to learn from such an
inconsistent input and outperform the human troubleshooter.
Especially, defining unsuitable KPIs that provide the same
symptoms for different faults is not a problem of the frame-
work but that of the selection of the KPIs.
B. Performance monitoring in mobile systems
Performance monitoring provides data by which the state
of a mobile system can be evaluated. As already mentioned,
the performance and status (i.e., faultless, degraded, etc.)
of mobile networks are monitored through Key Performance
Indicators (KPI). A KPI is a metric ranging from low level net-
work measurements to higher level quality indicators through
which a specific aspect of the network can be measured. Some
KPIs are user behavior (and consequently time) dependent,
such as downlink traffic in a cell; others, such as Channel
Quality Indicator (CQI), Random Access Channel (RACH)
attempts or call drop ratio have lower correlation with user
behavior as they do not depend on the application run by the
user. The latter KPIs are usually better for evaluating the state
of the system because the randomness introduced by users is
not that apparent. Note that in this paper, the term KPI is used
in a wider meaning (i.e., any observable piece of performance
information available in the system) as opposed to the KPI
definition found in [14].
A data set describing the usual (i.e., faultless) behavior of
a KPI is called the profile of the KPI. A profile can be as
simple as the average of the measured KPI values during
fixed time slots (e.g., hourly aggregated and averaged channel
quality reports in LTE) or it may be statistically more advanced
representation of the behavior of the KPI. Profiles of KPIs can
be built per-cell, per-base station (BTS) or even on a wider
aggregation layer, e.g., considering traffic in a whole Radio
Network Controller (RNC).
It needs to be identified if a KPI behaves according to its
profile or there is a statistically significant deviation from
it. An established way to do it is to define thresholds on
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
KPIs and divide the state of the KPIs into two substates
based on whether there is a threshold violation or not. This
can be combined with more advanced techniques, e.g., only
considering the KPI if it has been violating the threshold
continuously for some time or it has crossed the threshold
for a given number of times. However, all these common
techniques applied on top of thresholding have the same
problem: they quantize the KPIs into a binary space, losing
information and thus being unusable for reliable diagnosis. In
the next section, we introduce a framework that overcomes
this limitation and utilizes also the quantity of deviation from
the profile, operating without any thresholds.
III. I NTEGRATED D ETECTION AND D IAGNOSIS
F RAMEWORK
In the previous section, we defined what is meant by the
terms detection and diagnosis, introduced KPIs and profiles,
and showed not only the motivations but also the challenges
of automated diagnosis in cellular networks. Now we turn
to present our own work in detail, describing an automatic
framework that integrates detection and diagnosis.
In our opinion, the principles along which a successful and
practically feasible diagnosis framework should be built can be
summarized in three requirements. First, the framework should
have realistic prerequisites regarding the type and amount of
data it requires from operators. Second, the framework has to
integrate into the operator’s network seamlessly, without being
obtrusive or interfering with the operator’s existing deployed
workflows. Failure to do so would require the operator to
perform major modifications of the existing infrastructure and
established processes, which could result in the rejection of
the framework. Finally, every deployed mobile network and
various parts of the same network are different in several ways:
the set of available KPIs, the radio environment (e.g., rural
vs. urban areas), equipment vendors, software versions; the
framework has to be flexible enough so that it is able to adapt
to these different environments.
The high-level operation of both the current manual trou-
bleshooting process and the proposed automatic framework
is shown in Fig. 1. In the current manual process, low-level
HW/SW alarms are provided by the platform and additional
measurement-based KPIs may be available as well; these can
also be subject to thresholding and profiling via Operations
Support Systems (OSS) tools that can raise alarms in case
thresholds are violated. This approach can result in lots of
uncorrelated alarms presented directly to the operator who
has to do the diagnosis manually, usually requiring to look at
current KPI values directly. Alarm correlation [15] can help
reduce the volume of the alarm flow; however, as the input
for alarm correlation depends on the quality of the available
alarms in the first place, useful troubleshooting information
that could be inferred from KPIs but not visible from alarms
may still be missed.
The framework consists of two building blocks, detection
and diagnosis, with automated functionalities. Detection oper-
ates on a per-KPI basis and its goal is to maintain a measure
of how much the current value of the KPI deviates from its
profile. It is also a wrapper around different kinds of KPIs,
 SZILÁGYI and NOVÁCZKI: AN AUTOMATIC DETECTION AND DIAGNOSIS FRAMEWORK FOR MOBILE COMMUNICATION SYSTEMS 187

Manual troubleshooting process KPI measurements

and HS/SW alarms
Automatic troubleshooting with our proposed
detection and diagnosis framework KPI1 KPI2 KPI|K|

Detection
KPI per−KPI detection
KPI values Operator ϕ ϕ ϕ computes KPI levels
Measurement Thresholding
(using profiles)
Low−level manual KPI level interface
ALARMs diagnosis
Diagnosis
initiate active measurements

HW/SW alarms
manual
troubleshooting Fig. 2. Overview of the detection process and its input and output interfaces.
Detection interface
(using profiles) reports of
previous
KPI level
interface
fault cases overlapping are averaged to obtain samples ai of variable K̄
as follows:
Diagnosis query
(automatic) x1 , . . . , xn , xn+1 , . . . , x2n , . . . , x(k−1)n+1 , . . . , xkn (1)
        
automatic avg avg avg
High−level ALARMs
troubleshooting ↓ ↓ ↓
interface reports
Operator a1 a2 ak
(supervise) (training feedback)
The profile is built from k samples of K̄, a1 , . . . , ak , by
Fig. 1. Overview of the troubleshooting process with the current manual calculating the sample mean μ0 (K̄) and sample variance
troubleshooting workflow and the proposed automatic detection and diagnosis σ02 (K̄) from which the sample deviation is σ0 (K̄):
framework.
1 1  2
k k
μ0 (K̄) = ai ; σ02 (K̄) = ai − μ0 (K̄) (2)
providing a uniform interface called KPI level (to be explained k i=1 k i=1
shortly) towards the diagnosis, which is responsible for root According to the central limit theorem, if the xi samples are
cause analysis with the help of a database containing previous independent and identically distributed (i.i.d.), the resulting
fault cases. Instead of sending an alarm on each occasion the ai samples are normally distributed as n → ∞. If the xi
detection process finds a suspicious KPI (introducing false samples are originating from different users or from the same
positives), only the output of the diagnosis is sent to the user but based on independent events (e.g., handovers or
operator in case a fault has been diagnosed. In the rest of independent calls), the i.i.d. assumption is practically satisfied,
this section, the detection and diagnosis steps are described d  
thus K̄ → N μ0 (K̄), σ02 (K̄) . The parameters n and k are
separately in detail, starting with the detection process. KPI dependent; as a rule of thumb, n > 40 is needed for
independent xi samples to make sure K̄ is normally distributed
A. Detection and k > 20 is needed to obtain a statistically significant
Traditional detection methods rely on predefined thresholds population of ai samples. In case there is serial correlation
configured separately for each KPI and when a threshold is vi- between the xi samples (e.g., consecutive channel quality
olated, an alarm is generated. However, there is a fundamental reports of the same user), n should be much higher. Fig. 3
problem with this approach: threshold violations only facilitate shows the distribution of average CQI samples obtained from
binary indications about the state of the KPI. With a threshold a real HSPA network and the corresponding Quantile-Quantile
set to x0 for a certain KPI, a KPI value x0 −ε is still considered (Q-Q) plot that demonstrates normality of the averaged sam-
perfect whereas x0 + ε is already the worse possible (ε → 0). ples. Similar graphs are given for LTE CQI data obtained from
The problem still exists if the threshold is not an absolute one the simulator used for evaluation as presented later in this
but calculated from observing the statistical distribution of the paper. Common normality tests such as Anderson–Darling,
KPI during a faultless period of the system. Shapiro–Wilk, etc. all accept the normality of both the real
Instead of the current process, we propose a novel unified and simulated average CQI samples with level α = 0.05.
KPI interface that returns a real number from the continuous During operational phase, i.e., after the profiling of K
range [0, 1] called the level of the KPI, denoted by ϕ, describ- has been completed, the current average sample mean of K,
ing how well the current behavior of the KPI corresponds to denoted by X (K) , is continuously composed of the latest n
the profile. Level 0 means perfect conformance to the profile samples of K with a sliding detection window as follows:
and the level asymptotically approaches 1 as the deviation . . . , xt−n , xt−n+1 , . . . , xt (3)
from the profile increases. As shown in Fig. 2, the level   
of each KPI is fed directly (without any thresholding) into avg
↓
the diagnosis process, which uses these levels in order to
X (K)
determine the root cause of the fault (if any) for the cell.
Since the current behavior of a KPI is to be compared to where xt is the latest sample of K. The variable X (K) can be
its profile, first the profile of the KPI has to be obtained as transformed into a standard normal variable Z (K) as follows:
detailed in the following. Let the individual samples (measure-
ments) of KPI K be xi . Each n consecutive samples without Z (K) = X (K) − μ0 (K̄) /σ0 (K̄) (4)
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
 188
Data density and fitted normal pdf Q-Q plot
0.3 4
Real CQI data
0.2
(a) 2 (b)
0 0.75
0.1
−2
0 −4
13 15 17 19 21 23 25 −4 −2
0.25 3
Simulator CQI data
0.2 (c) 2 (d)
1 −8
0.15
0.1 0 Difference of X (K) from the profile in σ0 (K̄) units, Z (K)
−1
0.05
−2
0 Fig. 4. Asymmetric level functions for KPI K with C = −4. The graph of
−3
5 6 7 8 −3 −2 −1 0 1 2 3
Fig. 3. (a) CQI histogram from a real HSPA cell showing the density and
fitted theoretical normal distribution of average ai samples obtained as hourly
averages throughout 14 days (336 samples); (b) corresponding Q-Q plot to
demonstrate normality; (c) similar CQI histogram of 100 samples from the
LTE simulator used in this paper for evaluation; (d) corresponding Q-Q plot.
Based on the above defined Z (K) and Φ(·), the cumulative
distribution function of N (0, 1), the level of K, generally
denoted by ϕ(K), is defined in three cases as follows. If K
denotes a quantity that should not increase (i.e., increasing is
an anomaly) compared to the profiled value but decreasing is
acceptable (e.g., call drop ratio), the level function is ϕ+ (K)
as given below. If K denotes a quantity where decreasing is
a problem but increasing is not (e.g., handover success rate),
the level function is ϕ− (K). Finally, if K should sustain a
value same as or close to the profile (i.e., either more or
less is undesirable) then the proper implementation is ϕ± (K).
The first two level functions are called asymmetric level
functions, the latter is called symmetric level function. The
level functions are shown in Fig. 4 and defined as follows:
ϕ+ (K) = Φ C + Z (K)
ϕ− (K) = Φ C − Z (K)
ϕ± (K) = ϕ+ (K) + ϕ− (K)
where C is a constant that controls the horizontal shift of
the Φ function; intuitively, −C gives the number of standard
deviations by which the current average sample mean of K
should deviate from the profile to result in level 0.5. The value
is implementation dependent with C = −4 recommended
by the authors as this transforms the sensitive part of the
level function to 2–6 standard deviations and gives negligible
ϕ± (K) ∼ 10−4 |Z (K) =0 . Note that C is not a KPI specific
threshold; it is rather a uniform property of the level function.
If there is no problem in the cell, X (K) has the same
distribution as K̄, thus the level of K would be close to 0
since X (K) is close to μ0 (K̄). However, if there is a fault or
an unusual circumstance that affects the KPI in question in a
bad way, the level function moves towards 1. The advantage
of the level function compared to raising an alarm at some
threshold is that the level function gives a continuous feedback
that is sensitive to the amount of deviation of the recent KPI
samples from the profile. Also, the level function provides a
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, VOL. 9, NO. 2, JUNE 2012
ϕ− (K) ϕ+ (K)
1
Level of KPI K
0.5
0.25
0 2 4
0
−6 −4 −2 0 2 4 6 8
the symmetric level function ϕ± (K) is composed of the graph of ϕ− (K)
for Z (K) < 0 and ϕ+ (K) for Z (K) ≥ 0.
uniform approach to any KPI without need for the operator to
fine-tune KPI specific parameters and algorithms.
KPIs are different with regards to how well their usual
behavior can be captured by a profile. The best is if a KPI
is a system invariant whose change can only be due to some
anomaly. These KPIs can have single profiles taken at any
faultless period of time and used afterwards for detection. This
kind of KPI, however, is quite rare; most KPIs depend on the
behavior of users (e.g., throughput depends on the application
a subscriber chooses to use and the content downloaded
or uploaded) and, therefore, more or less follow complex
patterns. Since most aspects of a user’s behavior are time
dependent, these user behavior dependent KPIs are also time
dependent. Constructing a single profile for these KPIs would
yield a large σ0 (K̄) that may not be sensitive enough later
in the detection phase to respond to any fault with increased
KPI level. Therefore, multiple profiles can be constructed from
samples taken at different times (or, alternatively, not depend-
ing on time but the application subscribers use). Computing
(5) the KPI level is then based on the appropriate profile (same
time of day, same applications). Additionally, interpolation
(6) between the profiles is possible: if there are two profiled means
(7) μ0 (K̄, t1 ) and μ0 (K̄, t2 ) with t1 and t2 as their respective
central time (i.e., the middle of the time interval during which
the samples built in the profile were taken), the interpolated
profile mean used for detection at t where t1 < t < t2 can be
(t − t1 )μ0 (K̄, t2 ) + (t2 − t)μ0 (K̄, t1 )
μ0 (K̄, t) = (8)
t2 − t1
Time values t1 , t2 and t are meaning times of the day,
therefore they are wrapping over at 24h 00m each day.
The integration of existing low level binary indicators (e.g.,
HW/SW alarms) into the KPI level interface can also be done
in a straightforward way. Each alarm can be transformed into a
special KPI with no conventional profile; instead, the detection
should produce level 0 if the alarm or other indicator is off
and 1 if it is on (formally, the detection window size is n = 1,
i.e., the latest sample completely determines the KPI level).
Note that the presented way of computing the KPI level is
a plugin in a sense that it is not the only possible way to map
original KPI values to [0, 1]. The strengths of the proposed
method are its simplicity, flexibility and low computational
 SZILÁGYI and NOVÁCZKI: AN AUTOMATIC DETECTION AND DIAGNOSIS FRAMEWORK FOR MOBILE COMMUNICATION SYSTEMS
TABLE I
F ORMAL DEFINITIONS OF TYPES AND VARIABLES USED BY THE
DIAGNOSIS PROCESS
K set of all KPIs
K a particular KPI, K ∈ K
T set of diagnosis targets (actions and root causes)
|K|, |T| cardinality of set K and T, respectively
R̂ list of all reports (the same report can be present more
than once); see (9) for the formal definition of reports
κ(R) KPI set of report R
τ (R) target of report R
R̂T list containing all reports associated with a given target
T , i.e., R̂T = {R : τ (R) = T, ∀R ∈ R̂}
K̂T list containing the KPI subsets from all reports associated
with a given target T , i.e., K̂T = {κ(R) : ∀R ∈ R̂T }
ϕ(K) current measured level of KPI K
T(K) likelihood of KPI K, given target T
cost. Other, statistically more advanced techniques could also
be employed to compute a KPI level as long as they satisfy the
KPI level interface, i.e., maintain the range of the mapping.
Further study in this direction would be interesting but it is
out of scope of this particular paper.
B. Diagnosis
The diagnosis process operates directly on the KPI levels
supplied by the detection process; there is no thresholding that
classifies KPIs into two or more states, sparing the operator
from having to calibrate each threshold manually. Now, the
details of the diagnosis process are introduced; the symbols
and notations used in the formal discussion are collected in
Table I for reference.
1) Diagnosis target: So far it has been understood that the
target of the diagnosis means either a root cause or a corrective
action. However, not all targets are required to identify an
actual fault case or a real corrective action: it is possible that,
based on the KPI levels, one would suspect a failure but it
turns out that there is no fault, only an unusual but perfectly
valid distribution of the KPI levels (e.g., the majority of the
users are moving towards the cell edge, which results in worse
channel conditions to be reported although there is nothing
wrong with the antenna equipment itself). These corner cases
can also be made into specific targets by the operator to let
the diagnosis process explicitly recognize those circumstances
as non-faulty thus increasing the accuracy of the diagnosis.
Besides the targets specified by the operator, there is a special
built-in target used by the diagnosis process called the null
target and denoted by T0 , which has the semantic of “no
problem” (if interpreted as root cause) or “nothing to do” (if
interpreted as corrective action).
2) Expert knowledge: Any data requested from the operator
in order for an automatic framework to work is commonly
referred to as expert knowledge. In our case, expert knowl-
edge is deliberately kept simple: it contains diagnosis targets
associated with KPIs that deviate from their usual behavior
(i.e., profile) when the corresponding target root cause occurs
or the KPIs that return to their usual behavior after performing
the target corrective action. Each association is represented
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
189
TABLE II
KPI SUBSETS ASSOCIATED WITH A DIAGNOSIS TARGET T . E ACH ROW
REPRESENTS A DIFFERENT KPI SUBSET Ki ∈ K̂T WITH FULL BULLETS
MARKING EACH Ki ∈ K PRESENT IN THE CORRESPONDING SUBSET.
KPI subset K1 K2 K3 ··· K|K|
K1 • • ◦ ··· •
K2 • ◦ • ··· ◦
K3 ◦ ◦ • ··· •
.. .. .. .. .. ..
. . . . . .
K|K̂T | ◦ • • ··· •
by a structure that is called a report. Reports can be obtained
based on a priori expert knowledge on target-KPI relation (not
mandatory) or can be added based on analyzed previous fault
cases from fault history (if exist) and continuously as faults
happen during network operation. When the same fault with
identical symptoms happens multiple times, the same report
has to be added each time in order to model the relative
occurrences of the target associated with the report so that
the diagnosis can take into account the frequency of targets as
well. Formally, a report R is a pair that consists of the KPI
subset of the report, denoted by the operator κ(R), and the
diagnosis target of the report, denoted by the operator τ (R):
R = (κ(R), τ (R)) (9)
where κ(R) ⊆ K and τ (K) ∈ T.
Table II shows a generic example of KPI subsets associated
with a given target T . Each row corresponds to a different
report. Since the target of the reports is the same, the target
is not indicated in the table. The number of columns equals
to the number of KPIs, |K|. The number of reports associated
with target T (i.e., number of rows) is |R̂T | = |K̂T |.
A special report called the null report, denoted by R0 , is a
built-in report that is always present. The null report is defined
as follows:
R0 : κ(R0 ) = ∅, τ (R0 ) = T0 (10)
Apart from the null report, no other report R should have
κ(R) = ∅. The null report is used to identify the state of the
system when there is no problem at all, obviously associated
with the empty KPI subset.
3) Scoring system: The diagnosis process monitors the
KPI levels and, based on the expert knowledge that describes
which KPIs are characteristic to which targets, lists the targets
in descending order of relevance. At the top of the list is
the winning target that is the most relevant at the time the
diagnosis was run. The process is based on a scoring system
that gives a score to each diagnosis target based on how
well the reports associated with the target collectively match
the KPIs currently showing significant deviation from their
respective profile, i.e., having high KPI level. The more exact
the match, the higher the score that is given to that target.
Different reports for the same target do not necessarily have
identical associated KPI subsets. Therefore, the target specific
likelihood value is introduced for KPIs. For each target T and
KPI K, it can be derived from the expert knowledge how likely
it is for KPI K to have high level (i.e., observed with high
deviation from the profile) given that T is in the system. This
conditional probability, denoted by T(K), can be calculated as
 190 IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, VOL. 9, NO. 2, JUNE 2012

Consistency value 1   Detection

0.75 cf T(K) KPI level
interface

0.5 weighted continuous Hamming distance

0.25 separately
s(K1 ) s(K2 ) s(K|K| ) for each

Diagnosis
0 target
0 0.25 0.5 0.75 1 
T s(Ki )
Likelihood of KPI K given target T ,  (K)
score
Fig. 5. The consistency function returns 0 at 0.5 (total inconsistency) and S(T1 ) S(T2 ) S(T|T| ) of each
1 at the edges of its definition domain (full consistency). In between, it is target
piecewise linear.
Fig. 6. Overview of the diagnosis process and its relation to the detection
process; |K| and |T| denote the cardinality of set K and T, respectively.
the relative frequency of occurrence of K under the condition
that T is present:
 KPI is the more likely for the target:
 (K) =
T 1
· 1Ki (K) (11) 
S(T ) = s(K) (14)
R̂T ∀Ki ∈K̂T ∀K∈K
 
where 1Ki is an indicator function: s(K) = cf T(K) · dT(K) (15)
1 if K ∈ Ki where dT(K) ∈ [0, 1] is a continuous Hamming distance
1Ki (K) = (12)
0 if K ∈
/ Ki defined as
T ϕ(K) if T(K) ≥ 1/2
Note that the likelihood function is target specific, since d (K) = (16)
1 − ϕ(K) if T(K) < 1/2
the relative frequency of occurrence of a given KPI can be
different for each target. If T(K) is closer to 1 than to 0 (i.e., the KPI is included in
The likelihood value is used to determine how consistently the KPI subset of at least half of the reports for target T ),
a KPI is associated with any given target. If KPI K is always the expected level of the KPI in order to be a good match is
present in (or missing from) the KPI subsets of the reports high, thus higher score should be given as the current level
for target T , the association of K with T is fully consistent. approaches 1. On the other hand, if T(K) is closer to 0 than
It means that, upon observing the KPI level of K, it can be 1 (i.e., the KPI is not included in the KPI subset of most of
decided with high confidence whether the KPI behaves as if T the reports for target T ), the expected level of the KPI in order
was present or not: if K is included in all KPI subsets reported to provide a good match is low, thus higher score should be
for T , the diagnosis process recognizes a high KPI level of given as the current level approaches 0.
K as a confirmation for the presence of T , and does it with a The ordering of the targets is done by their respective score.
high confidence, since it has happened in all reported cases so If two targets have the same score, the one having the higher
far when T was diagnosed. For measuring how consistently number of overall reports is considered more relevant as that
a KPI appears with a given target, the consistency value is is a more frequent fault. Let S1 = S(T1 ) and S2 = S(T2 ).
introduced, which also takes its value from the range [0, 1]. Formally, the binary operator T1 > T2 is defined on T as
With the previous examples, the consistency value of the KPI follows:
would be 1 meaning the highest possible consistency. The
other extremity would be if a KPI was present in exactly half S1 > S2 ∨ S1 = S2 ∧ R̂T1 > R̂T2 (17)
of the reports associated with a given target; that corresponds Note that there is no separate mechanism in the diagnosis
to a consistency value 0, which basically means that one process that decides whether there is a fault or not in the first
can neither reason for nor against the presence of that target place; instead, the null target is put to fair competition with
regardless of the current level of the KPI. The consistency the other targets and may come out as being the most relevant
value easily follows from the likelihood value through the one by the same measure as a faulty target would.
following consistency function cf(·), shown in Fig. 5: An optional normalization of the scores can be performed
1 by using the following normalized score function:
cf : [0, 1] → [0, 1]; cf(x) = 2 x − (13)
2 S  (T ) = S(T0 )−1 · S(T ) (18)
Note that the consistency function itself, contrary to the The normalized score of the null target is by definition 1.0.
likelihood function, is not target dependent. If the diagnosis is run on the cell layer (with per-cell profiles
The score S(T ) given for target T is simply the sum of the of KPIs), normalized scores are useful to rank the cells based
so-called per-KPI scores, as visualized in Fig. 6. A per-KPI on the severity of the faults. A target with higher normalized
score, denoted by s(K), is based on the distance of the current score (i.e., more deviation from the normal behavior) is more
level of K (at the time running the diagnosis) from either 0 urgent to fix. The framework can also be used to diagnose
or 1, depending on whether the presence or the absence of the on other layers, e.g., on base station or even RNC layer by
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
 SZILÁGYI and NOVÁCZKI: AN AUTOMATIC DETECTION AND DIAGNOSIS FRAMEWORK FOR MOBILE COMMUNICATION SYSTEMS
TABLE III
P ROFILES OF THE THREE KPI S ; n IS THE NUMBER OF SAMPLES IN A
WINDOW AND k IS THE NUMBER OF AVERAGED SAMPLES , ACCORDING TO
(1); t IS THE TIME IT TOOK TO CREATE THE PROFILE .
K n k t μ0 (K̄) σ0 (K̄)
CQI 10000 100 0h 59m 7.651 0.302
CD 100 100 21h 11m 0.016 0.013
HO-TADV 50 50 9h 59m 2.914 0.048
using KPIs, profiles and expert knowledge on those layers.
With normalized scores, the severity of problems on the same
layer can be ranked.
Due to the mechanism of likelihood and consistency values,
the scoring system performs better in identifying the correct
root cause or corrective action if the KPI subsets reported
for the same target are similar. If this is not the case (i.e.,
contradictory reports are put in the database), it can result
in close-to-zero consistency values for lots of KPIs and the
diagnosis system would always give low score to this target.
Therefore, when adding a new report R for target T , it can be
checked automatically how well the KPIs in the new report
match that of the reports already existing for T . The check can
be made, e.g., by constructing a virtual ϕ KPI level for each
K ∈ K according to whether K ∈ κ(R) (ϕ (K) = 1) or K ∈ / dover Timing Advance (HO-TADV). CQI was reported by
κ(R) (ϕ (K) = 0) and running the diagnosis on these virtual
KPI levels as if they were coming from the detection process.
If the winning target is T , the new target can be accepted as
being consistent with the knowledge collected so far. If not,
it can be a sign of having an underlying fault case different
from what triggered the previous reports for T , even if T is the
same corrective action that the operator would perform in all
cases. If that happens, the system can automatically advise the
operator to introduce a new target or use a different existing
one for R instead of T .
In order to have access to low-level fine granularity mea-
surements, the detection (providing KPI levels) should be
preferably located at the BTS. The diagnosis may also be run
there on a per-cell level, in which case the KPI level interface
is intra-node. In case some KPIs are retrieved from the OSS
or the diagnosis is run in the OSS, care should be taken not to
avoid overloading the OSS and the transport network with KPI
or KPI level queries; for example, the diagnosis of different
cells should be run in randomized time slots to balance traffic
and load on OSS.
IV. E VALUATION
In the previous section, we have presented the theoretical
considerations behind the detection and diagnosis framework.
In this section, we evaluate the feasibility of the work with
a simulator capable of producing per-cell KPIs and per-cell
profiles in an LTE radio access network.
A. Overview
The detection and diagnosis framework presented in the
previous section was tested using an LTE simulator we de-
veloped for this purpose. The simulator was implemented
fully in C++ on Linux platform and its main goal was to
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
191
generate air interface related KPIs and also to be able to model
artificial fault cases. In order to fulfill these requirements, the
simulator features a detailed LTE air interface implementation
including Okumura-Hata path loss model, per-BTS shadowing
and fast fading (COST 207 channel model, Typical Urban,
alternative 6-tap channel) assuming 20 dB penetration loss.
The simulation scenario followed the reference system sim-
ulation scenario specified by 3GPP [16] with 19 LTE base
stations placed at 500 m inter-site distance in a triple-ring
layout (with 1, 6 and 12 base stations in each ring), each
BTS powering 3-sectored cells with proper horizontal antenna
characteristics, operating in SISO mode at 20 MHz bandwidth.
There were 500 users in the system randomly distributed,
moving at 3 kmph according to the random way-point mobility
model. The 12 outer base stations in the layout were used
for interference generation only but no users were allowed to
actually connect to any of them; if a user was about to do
so (i.e., making a handover to one of those cells), the user
was relocated to a random position instead. Handover was
implemented between the cells accessible to users according
to the standard A3 trigger mechanism with 3 dB handover
offset, 0.5 dB hysteresis and 320 ms time to trigger interval.
The following three KPIs were modeled in the simulator:
Channel Quality Indicator (CQI), Call Drop (CD) and Han-
active users, i.e., during test calls, in each ms according to
the LTE standard. Calls were modeled as Poisson processes
(exponentially distributed call length and waiting time) with
drop probability modeled as a function of average channel
quality on a per-second basis. If the average SINR was below
the threshold of the lowest usable CQI = 1 (≈ −7 dB) for
one second, the call was dropped. Otherwise, the probability
of dropping the call exponentially decreased towards higher
SINR values so that at the SINR threshold of CQI = 1 and
CQI = 7 (≈ 4.7 dB) the drop probabilities were 0.05 and
10−5 , respectively. Finally, Handover Timing Advance is a
KPI showing the LTE Timing Advance of a user according
to its source cell before inter-site handovers. This is a KPI
invented by us, not standardized or used by any prior art as
is. Intuitively, it gives a measure of the cell radius: the higher
the mean of the HO-TADV values measured in a cell, the
larger the corresponding coverage area. Note that a handover
only provides a sample of HO-TADV in the source cell;
an incoming handover deliberately delivers no sample in the
target cell. The reason is that due to the handover offset and
hysteresis, the mean of the timing advance would be different
in a cell for incoming and outgoing handovers, and mixing the
two would result in a profile with higher deviation. Choosing
the outgoing handovers over the incoming ones delivers more
samples thus gives faster reaction after a degradation when
users are handing away from the affected cell.
Although we modeled only three KPIs, in real mobile
networks there could easily be as many as 50 KPIs or more
including radio and transport measurements, alarms, OAM
states, etc., some of which may be available only at a specific
network deployment or at a specific operator. This is, however,
not a problem for the diagnosis framework; it is part of its
flexible design that the KPI portfolio can be arbitrary; there
are no mandatory KPIs in order for the diagnosis to work.
 192 IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, VOL. 9, NO. 2, JUNE 2012

TABLE IV TABLE V
R EPORTS FORMING THE EXPERT KNOWLEDGE OF THE SIMULATION . T HE TARGET- SPECIFIC LIKELIHOOD VALUES , AS PRE - COMPUTED BY THE
LAST ROW CONTAINS THE NULL REPORT WITH ITS EMPTY KPI SUBSET. DIAGNOSIS PROCESS AFTER THE REPORTS HAVE BEEN COLLECTED .

KPI subset target number of reports target CQI CD HO-TADV

{ CQI } UE 3 UE 1.0 0.0 0.0
{ HO-TADV, CQI } TX 4 TX 1.0 0.0 1.0
{ CD } SH 4 SH 0.2 1.0 0.0
{ CQI, CD } SH 1 T0 0.0 0.0 0.0
∅ T0 1

The level functions for the KPIs also have to be defined.

Asymmetric level functions were used for each of the three
KPIs. Level function (6) was used for both CQI and HO-
TADV where decreasing tendency of KPI values is considered
an anomaly. On the other hand, level function (5) was used
for CD, which should be sensitive to increased KPI samples.
As the first step in preparing the simulation, a profile
was created (as explained in Section III-A) for each KPI in
each cell separately by collecting and processing a number
of samples listed in Table III. Note that although CQI was
reported by active users in each ms, only every 100th of
the reports from the same user was taken as a sample for
the CQI KPI in a particular cell in order to decrease serial
correlation between consecutive CQI samples. Also, the size
of the window for CQI was set to be relatively high compared
to the other two KPIs that are based on truly independent
events. The simulation time needed to create the profile as
well as the profile mean and average are also present in the
table. Note that in the simulator it was enough to create one
profile for each KPI due to the stable radio environment and
the uniform user behavior; in a real deployment, it can be
necessary to create multiple profiles (and possibly interpolate
between them, as explained in Section III-A).
The diagnosis process has been tested in four different
scenarios, constructed as follows. The first scenario, referred
to as “UE”, modeled an unusual (but valid) user behavior
by forcing the users to the cell edge, not allowing them to
approach the serving base station closer than 200 m. This is
obviously a justified user behavior and not a consequence of
a fault of any equipment or network element but it can have
an effect on certain KPIs (most likely on CQI) that could be
mistaken for a symptom of a real fault case. Our intention with
this scenario was to test if this case can be reliably identified
by the diagnosis process. The second scenario, denoted by
“TX”, employed reduced transmission power in a cell from
the normal 46 dBm level to 34 dBm. In a real network deploy-
ment, this could happen for example due to damaged cabling
(via increased power dissipation) but too much downtilt of an
antenna has effectively the same symptom. The third scenario
called “SH” was a high shadowing case, when a relatively
small part (about 5%) of a cell’s coverage area was under high
shadowing. This can happen due to changed radio propagation
environment (construction work, buildings, etc.). The fourth
scenario, bearing the name of the null target T0 , was the
reference case without any fault or unusual behavior in the
system. In scenarios UE, TX and SH, only one cell (the same
in each scenario) was affected by the corresponding fault or
anomaly at a time.
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
The diagnosis process in the faulty cell is expected to be
able to differentiate between these four scenarios. In order to
keep the number of symbols down, the above defined scenario
names are also used as the diagnosis targets in the system.
Although in case of UE there is no actual fault in the network,
these three cases will be collectively referred to as faults
nonetheless to maintain simplicity.
Now that the scenarios and targets have been defined, the
only thing left for the diagnosis process to have is the expert
knowledge, i.e., the reports linking KPIs to diagnosis targets.
This expert knowledge was collected by conducting shorter
interactive simulations in the different scenarios, placing the
faults in different cells, monitoring KPI levels through the
detection process (without the diagnosis part) and observing
which KPIs are sensitive to the different fault cases (i.e., their
level has increased above 0.5 in accordance with Section V-B)
and submitting reports accordingly; this is the same process an
operator would use in a real network deployment. The reports
collected this way are summarized in Table IV. Instead of
writing out multiple identical reports, it is just put in the table
how many times they have been added. Note that there could in
fact be several reports with the same KPI subset and diagnosis
target, but, as it is demonstrated by the SH target, the same
diagnosis target does not necessarily receive the same KPI
subsets all the time. This is expected and that is exactly why
the likelihood values have been introduced in the diagnosis
procedure.
The expert knowledge collected is by no means surprising
if one considers the KPIs in the environment. If the users
move away from the serving base station, their channel quality
becomes lower due to the increased path loss and interference;
however, it has no impact on call drop ratio or how far
handovers are made in the affected cell. On the other hand,
if some parts of the cell are under high shadowing, the call
drop probability is expected to increase in the cell, but again,
it does not make the cell shrink or deteriorate the average
channel quality (this is due to the small area occupied by
the shadowing compared to the whole coverage area of the
cell). However, sometimes (e.g., when there are more users
walking into the shadowing area) their obviously lower CQI
reports can gain majority in the sliding detection window (see
(3)), resulting in higher KPI level also for CQI. Finally, the
reduction of the transmission power in a cell results in lower
channel quality and also handovers to be made closer to the
base station as the coverage area of neighbor cells penetrate
into the coverage area of the faulty cell.
 SZILÁGYI and NOVÁCZKI: AN AUTOMATIC DETECTION AND DIAGNOSIS FRAMEWORK FOR MOBILE COMMUNICATION SYSTEMS
TABLE VI
N ORMALIZED SCORES OF THE TARGETS IN EACH SCENARIO IN THE
MONITORED CELL AT 1 h 00 m SIMULATION TIME .
scenario T0 scenario TX scenario SH scenario UE
T0 1.00 TX 2.05 SH 1.20 UE 1.33
UE 0.75 UE 1.53 T0 1.00 TX 1.00
SH 0.65 T0 1.00 UE 0.67 T0 1.00
TX 0.50 SH 0.58 TX 0.33 SH 0.67
B. Simulation results
After the expert knowledge has been collected, the diagnosis
process was activated in the system. As the first step, the target
specific likelihood values of each KPI were pre-computed
according to (11). The numerical results are given in Table V.
For each of the four scenarios outlined before, there was
a simulation covering two hours of network operation. For
the first 30 minutes, there was no fault in the system in any
of the scenarios. Then, the fault according to the scenario
was deployed in one of the cells (except for the reference
scenario of course) and the simulation proceeded with one
hour of simulation time, during which the fault was present.
After that, the fault was withdrawn (an action corresponding
to deploying a solution in a real network) and the simulation
continued for another 30 minutes before it terminated. For the
reference case, the simulation was running without any change
in the radio environment for the whole two hours simulation
time. During these simulations, the faults were deployed in
different cells than in any of the previous interactive sessions
with the purpose of collecting the expert knowledge. Also, the
random seed for each simulation was altered uniquely.
The diagnosis process was run once every second in the
monitored cell, i.e., the one affected by the fault or, in the
reference case, one of the cells of the central BTS. The current
KPI levels and the output of the diagnosis (each target with its
normalized score) have been logged each time. As an example
for the output of the diagnosis, Table VI shows the normalized
scores of each target in descending order. Snapshots were
taken at 1h 00m simulation time, when the faults have already
been deployed for 30 minutes. It is clear that the target with
the highest score matches the scenario in each case, which
means that the diagnosis was able to correctly identify the
target corresponding to each scenario. Since these scores are
normalized as per (18), the severity of the fault cases can also
be ranked as TX > UE > SH (actually, since UE requires no
action from the operator, it boils down to TX > SH). Hence,
if these faults were to appear simultaneously in a network and
the operator was to go after one fault only at a time, it would
be better to take TX first.
The KPI levels of CQI, CD and HO-TADV were also
recorded periodically during the simulations. The curves for
scenario UE are shown in Fig. 7. After the fault deployment at
0h 30m , the level of CQI starts increasing rapidly and shortly
approaches 1.0. During the fault deployment, it stays close
to 1.0, occasionally dropping for short periods. This is due
to the user movements and handovers; if a user moves to a
position within the main lobe of the antenna, the received
signal will be still good despite the increased distance from the
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
193
CQI diagnosis: UE (0h32m – 1h33m)
Call drop
HO-TADV presence of fault (0h30m – 1h30m)
1.0
KPI level
0.8
0.6
0.4
0.2
0.0
0h00m 0h15m 0h30m 0h45m 1h00m 1h15m 1h30m 1h45m 2h00m
time
Fig. 7. KPI levels of the monitored cell in scenario UE (users are not allowed
to approach the serving base station closer than 200 m).
base station. These are obviously reflected in the CQI level but
the diagnosis maintained a steady outcome nonetheless. This
is also due to a time to trigger mechanism applied on top of the
diagnosis: if the winning target changes, it becomes official
and reported to the operator only if its number one position
remains stable for at least t = 60 s. Although this brings a
latency in the diagnosis, it also stabilizes it. Other (typically
even higher) time to trigger values may be more suitable in real
deployments, also depending on how frequently the diagnosis
is run and how often KPI samples are collected. Alternatively,
if the output of the diagnosis is one of the faulty targets,
the frequency of running the diagnosis can be automatically
increased to find out if it is a stable situation.
After the fault is withdrawn, the CQI level soon falls back
near to zero. Again, the same time to trigger mechanism is
applied here: the diagnosis process only reports the return of
the normal (faultless) state after the null target has been the
winning target for at least t seconds. One can observe that
the CD level slightly increases towards the end of the fault
deployment period; this can be due to the users continuously
having worse channel quality (as it can be seen from the CQI
level sticking to 1.0) but its significance is negligible and
does not bother the diagnosis at all. It is an advantage of
the diagnosis process that no exact match is required between
the KPIs with high level and the KPI subset of a target. In
traditional systems without diagnosis, the operator could get
an alarm signaling high call drop level only to be canceled
soon, just adding more noise to the anyway quite dynamically
changing alarm list. Overall, the fault deployment has been
in the system from 0h 30m to 1h 30m and the diagnosis was
reporting the correct target from 0h 32m to 1h 33m . Considering
the one minute latency introduced by the time to trigger
mechanism, this result means that the diagnosis follows the
state of the system quite closely.
Similarly to scenario UE, Fig. 8 shows the KPI level curves
for scenario TX. This time both the CQI and HO-TADV levels
jump up after reducing the transmission power of the cell.
The CQI level is due to all users experiencing worse channel
quality compared to the profile (since the power reduction
affects everybody in the cell, no matter how far they are from
the base station). This symptom alone could easily be mistaken
for scenario UE; what indeed differentiates the two scenarios
is the behavior of HO-TADV. Its rapid ascent is due to the
relatively large number of users handing over to neighbor
 194 IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, VOL. 9, NO. 2, JUNE 2012

target throughout the whole simulation. In summary, the KPI

CQI diagnosis: TX (0h32m – 1h35m)
Call drop levels reacted quickly to the faults deployed in the system and
HO-TADV presence of fault (0h30m – 1h30m)
1.0 also after the faults have been withdrawn. It was due to the
large number of active users, the choice of KPIs and the high
KPI level

0.8
0.6 quality profiles. The latency of the detection is determined
0.4 by the rate at which KPI samples are collected at a cell. In
0.2 case of KPIs based on radio measurements and mobility or
0.0
traffic parameters, it depends on the number of active users,
0h00m 0h15m 0h30m 0h45m 1h00m 1h15m 1h30m 1h45m 2h00m which can have significant variations in a real network within
time a day. From the KPIs chosen in the simulator, CQI is by far
the fastest and HO-TADV is the slowest since handovers were
Fig. 8. KPI levels of the monitored cell in scenario TX (transmission power
degradation from 46 dBm to 34 dBm).
the rarest events compared to calls and and CQI reports.

V. N ETWORK I NTEGRATION
CQI diagnosis: SH (0h33m – 1h36m)
Call drop After the evaluation of the feasibility of the detection and
HO-TADV presence of fault (0h30m – 1h30m)
1.0
diagnosis framework, we discuss practical and implementation
issues and identify possibilities for the extension of the frame-
KPI level

0.8
0.6
0.4
0.2
0.0
0h00m 0h15m 0h30m 0h45m 1h00m 1h15m
time
Fig. 9. KPI levels of the monitored cell in scenario SH (high shadowing in
some small spots of the coverage area).
cells after the power reduction; and what is more, these are
not only the users who were already close to the cell edge
but some of those closer to the base station as well. They
would have a lower timing advance before the handover, which
yields increased HO-TADV level (note that the level function
of HO-TADV is the same as that of the CQI, i.e., sensitive
to decreased KPI samples). After the power was reset to its
original value at 1h 30m , the channel quality reports soon put
the CQI level back to zero. The HO-TADV level follows with
some lag; the reason for this is that each handover updates
HO-TADV in the source cell only but the monitored cell is
the target of those handovers that happen due to restoring
the power. Therefore, the HO-TADV catches up due to the
handovers of users actually moving out of the monitored cell,
which is a slower process. Nevertheless, the diagnosis has
already picked up the correct target (in this case, the null
target) sooner, since the increased level of HO-TADV alone
already matches the null target best (according to the provided
expert knowledge). The level of CD stays low through the
whole simulation as expected.
The KPI curves of scenario SH are shown in Fig. 9. In
this case, it is the CD level that reacts to the high shadowing
deployed in 0h 30m . The CQI level stays low since the high
shadowing area is relatively small (5%) compared to the
coverage area of the whole cell. Also, the HO-TADV level
is low because the radius of the cell has not shrunk. However,
the high shadowing was strong enough to increase the call
drop ratio, because each user walking into it with an active
call was likely to have it dropped.
In the reference case, the levels of all three KPIs were close
to zero all the time; the diagnosis reliably delivered the null
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
work and key cooperation points with other network functions.
A. Active measurements
The assumption so far has been that KPIs in a system
1h30m 1h45m 2h00m are measured regularly and their value is always up-to-date.
However, in reality it is not the case for all KPIs (e.g.,
because they would generate too much logging if they were
enabled all the time); therefore, additional steps are needed
when these missing KPIs could indeed play a key role in
delivering the correct diagnosis. The level of KPIs that are
not regularly measured should be ignored by the diagnosis
process; however, the impact of different faults on these KPIs
should be part of the expert knowledge so that measuring them
when actually needed (i.e., when they can be the differentiator
between targets) gives a result directly processable by the
diagnosis process. An on-demand measurement for a KPI like
this is called an active measurement.
Active measurements can be made for KPIs that are not
measured regularly, for KPIs with missing measurements (due
to error in data transport or processing), or even for KPIs that,
although measured and updated regularly, are more outdated
compared to other KPIs (e.g., their regular measurement
interval is one hour and there would be still 20 minutes until
the next measurement at the time the diagnosis is taken). If
the active measurement can be initiated automatically by the
diagnosis process, there is no interruption in the automation.
On the other hand, some KPIs cannot be measured without
human assistance (e.g., they require switching on additional
equipment or the measurement has to be taken at a specific
location on the field). In these cases, the diagnosis process
can send an alarm with the semantics “measurement required”
to the operation including the list of KPIs for which a
measurement is needed.
In order to decide which KPI to take for active measure-
ment, one can take into account the relevance of the KPI and
the cost of the active measurement. From relevance point of
view, if targets T1 and T2 are close, it is better to select the
KPI arg maxK∈K T1(K) − T2(K) because it is expected to
be the best tie-breaker by effectively panning away the scores
of those targets in opposite direction. For the cost part, each
KPI can have an associated cost reflecting the effort required
 SZILÁGYI and NOVÁCZKI: AN AUTOMATIC DETECTION AND DIAGNOSIS FRAMEWORK FOR MOBILE COMMUNICATION SYSTEMS
for its active measurement or the time it takes to conduct
the measurement. KPIs that can easily or quickly be subject
of an active measurement should have lower cost than those
requiring human interaction or take long to obtain.
There can be KPIs that are so specific to active measure-
ments that they are never measured otherwise at all, e.g.,
making a test call to a specific cell. Similarly to low level
alarms integrated into the detection process, these KPIs have
no profile, enabling one sample to generate an up-to-date KPI
level in the detection; their association with targets, however,
should be included in the expert knowledge as with other KPIs.
Section VI discusses active measurements in related work.
B. Management of expert knowledge
An advantage of the framework is that it can start off even
with an empty expert knowledge base and have it populated
gradually as faults happen and the operator supplies the root
cause or the corrective action if the former is unknown. Iden-
tifying the KPI subset for the reports can also be automated
by running the detection process and taking those KPIs whose
level is greater than, e.g., 0.5 at the time the fault was manually
diagnosed. Note that this is only an example for a semi-
automatic report creation and it is not the only possibility to
create mapping between KPIs and targets; however, if such a
threshold is indeed chosen to be used, it can be a common
one for all KPIs due to the unified level concept and it is by
no means the reestablishment of the legacy KPI thresholding.
As the number of reports grows, the diagnosis framework can
be put into operation. First, the operator is likely to still do
the diagnosis but also consult with the automatic diagnosis
and compare the results. If the framework has stabilized in
supplying the expected diagnosis, it could be entrusted with
doing the work alone.
Central management of the expert knowledge in the OSS
system could be a practical implementation of the knowledge
database, with regular synchronization to a local cache in each
base station. The expert knowledge should be stored in a form
that enables editing of existing reports, e.g., complementing a
corrective action target with the corresponding root cause or
correcting the KPI subset or the target of a report that was
based on mistaken observations.
While the KPI levels can be continuously updated as
new KPI samples arrive, the diagnosis does not need to be
constantly active; it can be run periodically (e.g., hourly or
even daily if it is considered to be enough) and send an
alarm containing the ordered list of targets in case the winning
target in a cell is different from the null target. Sending the
complete list (or, alternatively, the top-five or top-ten targets)
gives options to the operator if the diagnosis turns out to
be wrong. Even if that happens, there are right away further
targets provided to the troubleshooter to check for validity.
C. SON coordination
The automated diagnosis will certainly not be the only
automated function in a network, only one of the many differ-
ent SON and other automated functions. As a consequence,
changes in the radio environment and network configuration
can be due to deliberate actions carried out by other entities but
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
195
may produce symptoms similar to fault cases. Care should be
taken not to mistake one for the other. Therefore, coordination
[17] between the diagnosis and other functions is important.
Deploying a new base station would introduce so much
change in the radio environment of the new cells that it would
render existing profiles unusable, necessitating re-profiling
during which automated diagnosis in the affected cells should
be turned off. Switching off a cell for energy saving produces
the same symptoms as a power failure. However, by adding
the administrative state of the cell as a KPI (possibly to be
checked as an active measurement if a faulty target comes up),
the diagnosis process can automatically recognize the situation
and avoid false alarms.
The diagnosis process is not always the one being instructed
by other SON functions but it can be the other way around:
the diagnosis can also trigger other functions in the network
such as cell reset or automatic cell outage compensation.
VI. R ELATED W ORK
There have been several approaches published aiming at
providing a solution to the requirement of automated diagnosis
in systems with increasing complexity and, consequently,
increasing number of potential fault cases; this subsection
gives an overview of these techniques.
Rule-Based Systems (RBS) were used in several technology
areas to address automated fault diagnosis [18]. These are
expert systems that consist of a set of “IF condition THEN
action” rules to store and maintain knowledge. Rule-based
systems can effectively handle small, static and deterministic
domains; however, the rule set grows exponentially with the
domain size and it is hard to create rules in dynamic or
non-deterministic fields, which makes rule management a
challenging task. Therefore, RBSs have not been seriously
considered for diagnosis automation in cellular networks.
Bayesian Networks (BN) can be effectively used in do-
mains where RBSs fail due to the uncertain nature of expert
knowledge. A BN is a probabilistic graphical model usually
represented by a Directed Acyclic Graph (DAG). The nodes of
the DAG are random variables with discrete states and each of
its edges represents conditional (usually causal) dependence
between the connected nodes. Each node is associated with
a conditional probability table, which could be filled based
on either expert knowledge [19] or analysis of previous fault
cases [20] (similarly to the reports in this paper) as well. The
table is used to compute the actual conditional probability
of the nodes given the current state of its parents. When
applied in the fault diagnosis domain, one set of nodes can
represent symptom variables while another set can represent
faults that have effect on the symptoms. Thus, in a BN,
uncertain relationships between faults and their symptoms can
be effectively represented by the conditional probability tables.
Methods exist that enable the BN to learn the parameters as
well as its structure from observed data. In the work presented
in [21], a naı̈ve Bayesian classifier is introduced for automated
diagnosis in UMTS networks. Using Bayesian classifier with
continuous KPIs has also been proposed, which demonstrates
the capability of BNs to represent not only discrete variables
but continuous ones as well. Study on comparison of contin-
uous and discrete BN diagnosis systems [22] shows that the
 196 IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, VOL. 9, NO. 2, JUNE 2012
continuous model produces better diagnosis accuracy and less
sensitivity to imprecise model parameters if a large number
of training cases are available. However, the discrete model is
preferred in limited training set scenarios.
Several competitive Neural Network (NN) algorithms are
studied and compared in [23] for fault detection and diag-
nosis of a simulated CDMA2000 network. The system is
represented by one global and several local normality profiles
(i.e., the expected distribution of quantization errors). The
joint application of global and local profiles results in a more
robust and efficient diagnostic tool. In [24], the authors present
their results of applying another variant of NN called Self-
Organizing Maps in cell performance data analysis to enhance
traditional manual troubleshooting process in 3G mobile net-
works. The method effectively visualizes and groups cells
based on their performance, which helps experts be more
effective in troubleshooting and parameter optimization.
In [25], the authors describe an anomaly detection and
fault diagnosis framework using a bi-cycle Auto Regressive
(AR) model and evidential reasoning of Dempster–Shafer
(DS) theory. First, a change detection algorithm is applied
to all observed performance variables where a dedicated AR
model is used to determine the profile of each variable as well
as the deviation of the actual observation from the model.
Second, the pattern of deviations is fed into a classification
engine based on DS reasoning to determine the most probable
root cause of the actual anomaly. The authors applied their
framework for IP networks focusing on packet forwarding
anomalies.
In [26], the authors present a novel approach to detect
anomalies affecting several mobile users with dynamic profile
identification. The proposal is based on analysis of unidimen-
sional distributions of certain features across individual mobile
users using multiple timescales. Important conclusion is that
while an automated detector can help recognize the statistical
anomalies (significant deviation for expected behavior), their
semantic interpretation (diagnosis) is still up to human experts.
Another main approach to fault detection in complex sys-
tems is Case-Based Reasoning (CBR). The CBR approach is
fundamentally different from RBSs, BNs and NNs in the way
it addresses fault diagnosis and problem solving in general.
The main differentiator is that CBR systems do not require
a structured knowledge base that must be acquired from
domain experts. There is no need to define any associations
or general relations between symptoms and fault cases and
use this knowledge to build a model. Instead, CBRs store
specific knowledge extracted from previously observed fault
cases to form a continuously updated knowledge base. In order
to solve a given problem, a similar former case is retrieved
from the case base and applied to the current situation.
Another characteristic that makes CBR different from other
expert systems is that the knowledge is continuously updated
during operation, since every new case is incorporated into the
database after it has been resolved. The CBR has been applied
for several problem domains for diagnosis (e.g., for software
systems [27]) but there has been no proposal to address
cellular systems. The diagnosis framework described in this
paper shares some basic concepts with CBR systems. The
most important common point is that the proposed framework
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
builds its knowledge base by learning from earlier fault cases
observed and diagnosed and it finds the most similar earlier
case to diagnose a new fault (i.e., by summing the weighted
continuous Hamming distances). Note, however, that unlike
the traditional CBR approach, the proposed framework does
not compare a new case directly to individual previous cases
(i.e., reports) but to the cumulative KPI footprint of all reports
associated with a common target, represented by the likelihood
and consistency values.
The concept of active measurements appears in other pro-
posals as part of diagnosis; however, none of these proposals
focus on mobile communication systems. In [28], the au-
thors integrate service-level monitoring with fault management
functions such as event correlation and fault diagnosis for
interconnected Ethernet networks. As part of this work, they
proposed a method for root cause analysis based on Petri-
nets that schedules so-called active investigation checks (e.g.,
specialized measurements, database queries, etc.) to narrow
the set of potential root causes for the actual fault. The
constructed Petri-net defines an active action plan (i.e., a
sequence of measurements) that drives the diagnosis from
a triggering alarm towards finding its root cause by acquir-
ing necessary information on the fly. An earlier work [29]
combines Bayesian networks with decision theory to achieve
the same goal; active investigations have also appeared with
incremental alarm correlation for fault diagnosis [30].
VII. C ONCLUSION
In this paper, we presented an integrated detection and
diagnosis framework where the detection process is based
on automatically built profiles. Diagnosis follows a reasoning
similar to the thinking of an operator, looking at previous
fault cases and trying to find the best matching root cause.
Detection and diagnosis are connected via a unified KPI level
interface that integrates different kind of KPIs and eliminates
the need for manual adjustment and threshold calibration.
Active measurements can help in tie resolution or reassuring
the output of the diagnosis. The framework is KPI and RAT
agnostic; although its feasibility has been tested using KPIs in
a simulated LTE system, it could be used in 2G, 3G or HSPA.
Future work should be devoted to further evaluation of the
system with more KPIs and more complex fault cases as well
as comparison with other fault detection and diagnosis meth-
ods. Working on real network KPI data instead of simulations
is also a priority. The investigation of the impact of a dynamic
network environment on expert knowledge is also needed.
R EFERENCES
[1] N. Alliance, A Requirement Specification, Dec. 2008. Available:
http://www.ngmn.org/uploads/media/NGMN Recommendation on
SON and O M Requirements.pdf
[2] 3GPP, “Telecommunication management; Self-Organizing Networks
(SON); Concepts and requirements,” 3rd Generation Partnership Project
(3GPP), TS 32.500, Oct. 2010.
[3] 3GPP, “Evolved Universal Terrestrial Radio Access Network (E-
UTRAN); Self-configuring and self-optimizing network (SON) use
cases and solutions,” 3rd Generation Partnership Project (3GPP), TR
36.902, Apr. 2011.
[4] H. Sanneck, Y. Bouwen, and E. Troch, “Context based configuration
management of plug & play LTE base stations,” in Proc. 2010 IEEE
Network Operations and Management Symposium, pp. 946–949.
 SZILÁGYI and NOVÁCZKI: AN AUTOMATIC DETECTION AND DIAGNOSIS FRAMEWORK FOR MOBILE COMMUNICATION SYSTEMS
[5] 3GPP, “Telecommunication management; Automatic Neighbour Rela-
tion (ANR) management; Concepts and requirements,” 3rd Generation
Partnership Project (3GPP), TS 32.511, Apr. 2011.
[6] T. Bandh, G. Carle, H. Sanneck, L. Schmelz, R. Romeikat, and B. Bauer,
“Optimized network configuration parameter assignment based on graph
coloring,” in Proc. 2010 IEEE Network Operations and Management
Symposium, pp. 40–47.
[7] P. Szilágyi and H. Sanneck, “LTE relay node self-configuration,” in
Proc. 2011 IFIP/IEEE International Symposium on Integrated Network
Management, N. Agoulmine, C. Bartolini, T. Pfeifer, and D. O. Sullivan,
editors, pp. 841–855.
[8] A. Lobinger, S. Stefanski, T. Jansen, and I. Balan, “Load balancing in
downlink LTE self-optimizing networks,” in Proc. 2010 IEEE Vehicular
Technology Conference – Spring, pp. 1–5.
[9] I. Siomina, P. Varbrand, and D. Yuan, “Automated optimization of
service coverage and base station antenna configuration in UMTS
networks,” IEEE Wireless Commun., vol. 13, no. 6, pp. 16–25, Dec.
2006.
[10] 3GPP, “Telecommunication management; Self-Organizing Networks
(SON); Self-healing concepts and requirements,” 3rd Generation Part-
nership Project (3GPP), TS 32.541, Mar. 2011.
[11] P. Zanier, R. Guerzoni, and D. Soldani, “Detection of interference,
dominance and coverage problems in WCDMA networks,” in Proc. 2006
IEEE International Symposium on Personal, Indoor and Mobile Radio
Communications, pp. 1–5.
[12] P. Szilágyi and S. Nováczki, “Radio channel degradation detection
and diagnosis based on statistical analysis,” VTC-2011 Spring IWSON
Workshop, vol. 15.
[13] R. Barco, V. Wille, L. Dı́ez, and P. Lázaro, “Comparison of probabilistic
models used for diagnosis in cellular networks,” in Proc. 2006 IEEE
Vehicular Technology Conference – Spring, vol. 2, pp. 981–985.
[14] 3GPP, “Telecommunication management; Key Performance Indicators
(KPI) for Evolved Universal Terrestrial Radio Access Network (E-
UTRAN): Definitions,” 3rd Generation Partnership Project (3GPP), TS
32.450, Apr. 2011.
[15] H. Wietgrefe, “Investigation and practical assessment of alarm corre-
lation methods for the use in GSM access networks,” in Proc. 2002
IEEE/IFIP Network Operations and Management Symposium, pp. 391–
403.
[16] 3GPP, “Physical layer aspect for evolved Universal Terrestrial Radio
Access (UTRA),” 3rd Generation Partnership Project (3GPP), TS 25.814,
Oct. 2006.
[17] H. Sanneck, C. Schmelz, T. Bandh, R. Romeikat, G. Carle, and B. Bauer,
“Policy-driven workflows for mobile network management automation,”
in 2010 International Wireless Communications and Mobile Computing
Conference.
[18] C. Angeli and A. Chatzinikolaou, “On-line fault detection techniques
for technical systems: a survey,” International J. Computer Sci. & Appl.,
vol. 1, no. 1, pp. 12–30, 2004.
[19] R. Barco, P. Lázaro, V. Wille, L. Dı́ez, and S. Patel, “Knowledge
acquisition for diagnosis model in wireless networks,” Expert Syst.
Appl., vol. 36, no. 3, pp. 4745–4752, 2009.
[20] R. Barco, V. Wille, L. Dı́ez, and M. Toril, “Learning of model parameters
for fault diagnosis in wireless networks,” Wireless Networks, vol. 16, pp.
255–271, Jan. 2010.
[21] R. Khanafer, B. Solana, J. Triola, R. Barco, L. Moltsen, Z. Altman, and
P. Lázaro, “Automated diagnosis for UMTS networks using Bayesian
Authorized licensed use limited to: NATIONAL INSTITUTE OF TECHNOLOGY ROURKELA. Downloaded on November 04,2023 at 09:10:29 UTC from IEEE Xplore. Restrictions apply.
197
network approach,” IEEE Trans. Veh. Technol., vol. 57, no. 4, pp. 2451–
2461, July 2008.
[22] R. Barco, P. Lázaro, L. Dı́ez, and V. Wille, “Continuous versus discrete
model in autodiagnosis systems for wireless networks,” IEEE Trans.
Mobile Comp., vol. 7, no. 6, pp. 673–681, June 2008.
[23] G. Barreto, J. Mota, L. Souza, R. Frota, and L. Aguayo, “Condition
monitoring of 3G cellular networks through competitive neural models,”
IEEE Trans. Neural Networks, vol. 16, no. 5, pp. 1064–1075, Sep. 2005.
[24] J. Laiho, K. Raivio, P. Lehtimäki, K. Hätönen, and O. Simula, “Ad-
vanced analysis methods for 3G cellular networks,” IEEE Trans. Wire-
less Commun., vol. 4, no. 3, pp. 930–942, May 2005.
[25] N. Samaan and A. Karmouch, “Network anomaly diagnosis via statisti-
cal analysis and evidential reasoning,” IEEE Trans. Network and Service
Management, vol. 5, no. 2, pp. 65–77, 2008.
[26] A. D’Alconzo, A. Coluccia, F. Ricciato, and P. Romirer-Maierhofer,
“A distribution-based approach to anomaly detection and application
to 3G mobile traffic,” in Proc. 2009 IEEE Global Telecommunications
Conference, pp. 1–8.
[27] S. Montani and C. Anglano, “Case-based reasoning for autonomous
service failure diagnosis and remediation in software systems,” in
Proc. 2006 European Conference on Case-Based Reasoning (ECCBR),
Lecture Notes in Artificial Intelligence 4106, pp. 489–503. Springer-
Verlag, 2006.
[28] P. Varga and I. Moldován, “Integration of service-level monitoring
with fault management for end-to-end multi-provider Ethernet services,”
IEEE Trans. Network and Service Management, vol. 4, no. 1, pp. 28–38,
June 2007.
[29] D. Heckerman, J. S. Breese, and K. Rommelse, “Decision-theoretic
troubleshooting,” Commun. ACM, vol. 38, pp. 49–57, Mar. 1995.
[30] Y. Tang, E. Al-Shaer, and R. Boutaba, “Efficient fault diagnosis using
incremental alarm correlation and active investigation for Internet and
overlay networks,” IEEE Trans. Network and Service Management,
vol. 5, no. 1, pp. 36–49, 2008.
Péter Szilágyi received an M.Sc. degree in Software
Engineering from the Budapest University of Tech-
nology and Economics (BUTE), Hungary, in 2009.
Currently he is a research engineer at Nokia Siemens
Networks, focusing on Self-Organizing Networks
including self-configuration solutions for LTE-A Re-
lay nodes and contributing to 3GPP RAN3 standard-
ization. His interests include self-healing in 3G and
LTE systems as well as developing proof-of-concept
and performance simulations for LTE.
Szabolcs Nováczki received an M.Sc. degree in
Electrical Engineering from the Budapest University
of Technology and Economics (BUTE), Hungary,
in 2006. Szabolcs is a research engineer at Nokia
Siemens Networks, focusing on Self-Organizing
Networks solutions, particularly self-healing aspects
of cellular networks. He currently studies the appli-
cability of machine learning techniques to achieve
automated fault detection, diagnosis and prediction
in 3G and LTE radio access networks.