A Handover Analysis

The problem
In a complex GSM network—and even more so in a
multi-vendor system—OMC counters are sometimes
insufficient to allow the detailed investigation of
handover problems down to their roots. OMC
counters may provide enough information to detect
problems, but rarely enough to solve them. Moreover,
in a multi-vendor environment, the handover counters
are often specific to each vendor infrastructure. It is
sometimes difficult or even impossible to match
information from different vendor sources, even for a
simple analysis. This is because the way the counters
are triggered and the way performance indicators are
computed differ from one equipment manufacturer to
another.

Solution
A-interface trace analysis brings a uniform approach
to handover quality evaluation and troubleshooting, as
this interface is fully standardized and its
implementation is mandatory. In multi-vendor
networks, this type of analysis is independent from
the equipment data source. Finally, A-interface tracing
and analysis allows the investigation of the problem
from the general BSC level down to cell- or even
individual call level.

Handover Cause
HO Performed and HO Required-Attempt cause
counts, percentages and graph.
Analyzing the cause breakdown of Handover
Performed messages (BSS controlled handovers) and
Handover Required messages (SSS controlled
handovers) brings information on the overall validity of
the handover parameter settings and handover
efficiency in the network, but it is also a good indicator
of the quality of the RF design (frequency plan, cell
design).
In fact, the cause breakdown will clearly indicate if all
types of handovers (quality, level, distance, traffic,
better cell) are effectively taking place (or not), and
their relative proportions. It is thus easy to verify that
(for example) level handovers based on UL receive
level are effectively not happening if this mechanism
has been disabled in the parameter setting. It is also
possible, by comparing two traces before and after a
parameter tuning, to verify that for example there is a
greater percentage of DL level handovers if the
threshold for this handover type has been increased.
Unless a specific mechanism has voluntarily been
implemented, better cell handovers should be the
dominant type of handover. The proportion of other
types of handovers should reflect the handover
scenarios that have been imagined by the RF
engineers when setting or tuning the handover
parameters.
The absolute proportions of the different handover
types are also important, as they reflect the quality of
the network design and frequency plan. In a well-
designed network, and unless specific handover
mechanisms have been put in place, better cell
handovers should represent a minimum of 85 to 90%
of the handover causes. In fact, the better cell
handover is the only type of normal handover. All
other types are imperative ‘rescue’ handovers that
could put the call in potential danger of drop if not
executed in a timely manner. The traffic handover can
also be considered a rescue handover at macroscopic
level, as it prevents other calls from being blocked or
improperly handed over because of a lack of
resources in a cell.

Handover Reject and Fail Cause

Counts, percentages and graph for HO Request
Reject and Failure.
As a complement to the analysis presented above,
cause breakdown for filtered Handover Required
Reject or Handover Failure messages will help
identify the source of the problems.
Additionally, some A-interface causes such as ‘Radio
interface failure, reversion to old channel’ clearly
indicate that the call has not been lost in the process.
It is therefore possible to evaluate the importance and
potential impact of these problems on the subscribers.
The workspace template provided with this
engineering note also contains queries that are
suitable to extract individual calls where handover
rejection or failures have been detected. This allows
very detailed analysis, using the Message Browser
and Chart visualization tools. Note that additional
specific queries can be run on these individual calls.

BSS Handover Cause by Cell

Intra-BSC handover statistics for each cell.
As described above, handover causes will help
validate scenarios imagined by RF engineers. The
cell-by-cell analysis allows a deeper understanding of
(for example) multi-layer mechanisms where specific
types of cells, such as micro-cells, should show a
behavior that is clearly different from that of a macro-
cell.
Investigation of handover causes at cell level (rather
than at BSC level) also brings a geographical
dimension to the analysis. It is possible to identify
which cells are more subject to imperative ‘rescue’
handover types and thus potentially not well
designed. This may point to a frequency plan problem
(lots of quality handovers) or coverage issue (high
proportion of level handovers).

SSS Handover Cause by Cell

Inter-BSC handover statistics for each cell.

Handover Messages by Cell

Inter-BSC outgoing and incoming statistics for each
cell.
Handover message distribution per cell
The cell-by-cell analysis of all handover-related
messages in a cell gives a good view on the
mechanisms of the handover procedures and the
eventual problems.
The handover messaging on the A-interface can be
divided into three groups:
• Messaging related to outgoing handovers: these
are MSC controlled handovers where the calls are
redirected to another BSC.
• Messaging related to incoming handovers: these
are also MSC controlled handovers where the
calls are originating from another BSC.
• Messaging related to intra BSC handovers: these
handovers are entirely controlled by the BSS. The
MSC is only informed that a handover has been
performed successfully, and the identification of
the new serving cell is communicated. Note that
there is no information on the A-interface about
handover failures for BSS controlled handovers.
Note that the operator also has the option to force all
handovers to be MSC controlled.
Outgoing handovers
When HO conditions are detected by the BSC, based
on measurement from the MS (for the DL) and the
BTS (for the UL), the BSC sends a HO Required
message to the MSC. The MSC then enquires with
the target BSC if this handover may be accepted (see
Incoming handovers, below). If the target BSC
acknowledges the request, the MSC then sends a HO
Command message to the source BSC (the BSC that
originally sent the HO Required message).
The MSC may also respond to the source BSC with a
HO Required Reject message in case the handover is
not possible.
Note that if the handover to the new BSC fails and the
MS returns to the old channel (on the source BSC),
the source BSC sends a HO Failure message to the
MSC.
If the handover fails and the mobile is lost, the source
BSC will indicate this to the MSC and the connection
will be closed via a Clear procedure sequence.
Incoming handovers
When the MSC has received a HO Required
message from the source BSC, it enquires with the
target BSC by sending a HO Request message. If
resources are available and the handover may be
accepted, the BSC replies to the MSC by sending a
HO Request Acknowledge message.
The BSC may also reply to the MSC with a Handover
Failure Message if the handover cannot be accepted.
The BSC then waits for the MS to access the new
radio channel. At the first attempt by the MS to access
the channel, the BSC sends a HO Detect message to
the MSC. When the MS has successfully seized the
radio channel, the BSC sends a HO Complete
message to the MSC.

BSS Handover Matrix

Intra-BSC Handovers by Source and Target.
BSS and SSS controlled HO matrices
One of the most common applications of A-interface
analysis is the generation of handover matrices.
A handover matrix is a double-entry table that gives a
clear view on the flows of traffic between cells in the
network.
The interpretation of a handover matrix covers many
aspects of network design and optimization, for
example:
Neighbor relation cleanup
As a GSM network grows, cells are regularly added to
enhance the network capacity and coverage. Every
time a cell is added, new neighbor relations are
created in order for the traffic moving to (or away
from) the new cell to be correctly handed over.
However, because of the presence of the new cells,
the border between existing cells change and older
pre-existing neighbor relations may become obsolete.
These are rarely deleted from the neighbor lists.
Consequently, neighbor lists tend to grow over time,
making handover mechanisms unreliable or
inappropriate.
It is therefore necessary to verify all neighbor lists at
regular intervals (for example, every three to six
months), and delete unnecessary relations.
This is easily achieved using a handover matrix. For
each cell, the number of HO to each neighbor
appears clearly in the matrix; it is therefore easy to
identify relations that are rarely used. Note that
identification of relations that are not used at all
requires comparing the HO matrix with the real (full)
list of neighbors from the OMC.
As rule of a thumb, an efficient neighbor list should
never exceed 10 to 12 neighbors.
Neighbor list validation
When adding a new cell into the network, it is not
always easy to estimate what the optimum neighbor
list for this new cell should be. RF propagation
planning tools produce best-server and second-best
server plots that can be used for this purpose;
however, these tools rarely consider traffic in
generating a list of neighbors.
A better engineering practice is therefore to put the
new cell on air with a neighbor list that is purposely
too long (including obvious necessary neighbors and
all other potential neighbors). The new cell can be
monitored, and a handover matrix will reveal which of
the neighboring relations are rarely used or not used
at all. The unnecessary neighbors are then deleted
from the cell neighbor list.
Localization of traffic hotspot
The handover matrix may be used to identify cell
couples with very high handover flow. If a cell shows
one or more important handover flows (relative to the
other flows from that cell), it typically indicates that
some kind of traffic spot is localized between this cell
and the concerned neighbors.
Of course, the handover matrix should not be
considered the only source of information in the
localization of traffic spots. Other indicators such as
total cell traffic, congestion time, traffic maps, clutter
databases and field observations all need to be
considered in the process.
Location Area design
Designing a proper Location Area is all about
balancing paging load with location updating load,
both procedures making use of different radio
resources. One of the key elements in this design
process is a view of the idle-mode MS flows between
cells in the network.
In general, there is relationship between idle-mode
flow and traffic (dedicated-mode) flow that is stable
enough for the purpose of Location Area design.
Therefore, a handover matrix is an ideal source of
information to assess these idle mode MS flows
necessary for the cell grouping calculations.
 SSS Handover Matrix
Inter-BSC Handovers by Source and Target.