Advanced

Handover
Analysis
using A-SVS

Actix Ltd, 2004

Page 1 of 27

CONTENTS

INTRODUCTION ....................................................................................................................... 3
INTRACELL HANDOVERS....................................................................................................... 4
REPEATED HANDOVERS ....................................................................................................... 6
DRAGGED HANDOVERS......................................................................................................... 8
PING-PONG HANDOVERS .................................................................................................... 11
ANALYSIS PACK STATEFORMS.......................................................................................... 15
SUMMARY............................................................................................................................... 16
ANNEX

ADVANCED HANDOVER ANALYSIS PACK........................................................ 17

Actix Ltd, 2004

Page 2 of 27

Introduction
Handovers fulfil a number of roles in any GSM network. Not only do they allow for loadbalancing of resources, thus maximising the capacity of a cell at any one time; but they allow
the fundamental feature of being able to sustain a call whilst on the move. All resources that
are assigned to a subscriber, whether it is on the Um interface or the Abis/A circuit further
back into the switch are controlled by various network elements. Therefore to change any of
these resources, whether it is due to the physical movement of the subscriber, degrading
signal strength and/or quality, or load balancing, involves communication between these
network elements.
All this highlights a key network performance optimisation area to offer subscribers the ability
to seamlessly move around inside each location area, and one that cannot be described by
just one traditional KPI such as Handover Success Rate .
As such, Actix A-SVS includes 4 new types of handover analysis:
Intracell handovers
Repeated handovers
Dragged handovers
PingPong handovers
These are explained in detail in this paper below. The scenario is explained, with the Actix
implementation fully documented. Examples are included where relevant, and finally the
stateforms allowing detailed synchronisation are explained. The Annex gives examples of the
KPI reporting layer available with this Advanced Handover Analysis Pack in Actix A-SVS
solution.

Actix Ltd, 2004

Page 3 of 27

Intracell handovers
Intracell handovers refer to the mobile being transferred from one BTS resource to another.
The main reason for this is for load-balancing on a cell. The resource can be either the
current timeslot or the current traffic channel that the mobile is using to communicate with the
BTS. Therefore, the options for an intracell handover can be timeslot only , traffic channel
only or both timeslot and traffic channel .
5 new attributes have been added to the Workspace Explorer:
Message
Intracell handover command
Successful intracell handover
Failed timeslot intracell handover
Failed traffic channel intracell handover
Failed combined timeslot/traffic channel intracell handover

Attribute
Event_Intra_HO_Command
Event_Intra_HO_OK
Event_Intra_TS_HO_Fail
Event_Intra_TCH_HO_Fail
Event_Intra_TCH_TS_HO_Fail

The intracell handover command is triggered by an RR Assignment Command Layer 3

message and can occur while the handset is in dedicated mode or in-call. At this point, a new
attribute Event_Intra_HO_Command is set depending on whether the command is to change
either the Timeslot only, the TCH only or both the TCH and timeslot using the following
algorithm and event diagram:
If current TCH is equal to previous TCH then
Set attribute to TS only command
Else
If current TS is equal to previous TS then
Set attribute to TCH only command
Else
Set attribute to TCH and TS command
End if
End if
The format of the RR Assignment Command (hopping / non-hopping) is as follows:
L3 DL RR Assignment Command
Channel Type: TCH/F + FACCH/F and SACCH/F
TimeSlot: 5 TrainingSeq: 4
Hopping: Yes, MAIO: 1 HoppingSeq (HSN): 0
MsTxPower Ordered: (2 GSM)
CA List: 9 13 19 71 (Bit Map 0)
Channel Mode: Speech full rate or half rate version 1
MA: 1 2 3 4
or
L3 DL RR Assignment Command
Channel Type: TCH/F + FACCH/F and SACCH/F
TimeSlot: 4 TrainingSeq: 2
Hopping: No, ARFCN: 88
MsTxPower Ordered: (5 GSM)
Channel Mode: Speech full rate or half rate version 1

Actix Ltd, 2004

Page 4 of 27

Intracell Handover event diagram at RR Assignment Command message is as follows:

If the handset mode is unknown at the beginning of the drivetest file, the event diagram waits
in the Unknown @ start of file / idle state. Once a dedicated channel has been assigned to
the handset, the event diagram moves into the Voice/data channel assigned state. Any
following RR Assignment Command (before the handset returns to idle mode) results in
either a timeslot, traffic channel or both re-allocation attempt. At this point, the event diagram
moves into the Intracell HO state. From the Intracell HO state, it is possible to
drop/complete the call, but a typical result would be for the RR Assignment Complete or RR
Assignment Failure message to be found. If an RR Assignment Complete message is
found, the Event_Intra_HO_OK event is set. If an RR Assignment Failure message is
detected, depending on the type of intracell handover command, it sets the corresponding
failure event: Event_Intra_TS_HO_Fail / Event_Intra_TCH_HO_Fail /
Event_Intra_TCH_TS_HO_Fail.

Actix Ltd, 2004

Page 5 of 27

Repeated Handovers
Repeated handovers are situations where the network instructs the MS handover to a new
cell. This handover fails, but the network continues to request that the MS hands over into
the same cell. Actix triggers the Repeated Handover commands, and also any associated
failures, until either the MS succeeds in its attempt, the call is terminated, or the network
requests the MS to handover to a different cell.

At the first message, the handset moves into the Normal state. Only when it finds the first
handover failure does it move into the HO_Window state. If the handover succeeds or a
handover command to a new cell is detected, the MS returns to the Normal state. The MS
also moves back to the Normal state at a dropped call, a channel release or a call setup
failure. From the HO_Window state, any further handover commands to the same cell as
the previous command that has just failed, result in the Event_Rpt_HO_Commands event
being triggered. If another Handover Failure is found, it can only have resulted from a
repeated handover command, so it sets the Event_Rpt_HO_Failures event.
In this way, it will identify the following scenarios:
HO
Commands

HO
Fails

Rpt HO
Commands

Rpt HO
Fails

HO OK
HO
Command

HO Fail

Rpt HO
Command

HO OK

HO
Command

HO Fail

Rpt HO
Command

Rpt HO
Fail

Rpt HO
Command

HO OK

HO
Command

HO Fail
HO
Command

Rpt HO
Command

Rpt HO
Fail

HO Command
(new cell)

If the final Handover Command to the new cell fails, the process is repeated, with the new
handover command being the initial command of the new sequence.

Actix Ltd, 2004

Page 6 of 27

This can be clearly seen when synchronising the Layer 3 Message Browser with the table
view (plotting Target BCIC/BCCH and the Layer 3 message), where multiple RR Handover
Failures are triggered, all being requested in the same target BCCH/BSIC at the previous RR
Handover Command.

Actix Ltd, 2004

Page 7 of 27

Dragged Handovers
This situation exists when the MS loses its dominance, but for whatever reason the network
either doesn t instruct it to handover, or it fails to handover successfully. If this loss of
dominance situation persists for longer than a specified time window, and either a Handover
Failure or even a Dropped Call occurs, then these failures/drops are also triggered as two
new events: EventDragHOFail or EventDragDrop.
Dragged Handover
Region
Cell 1 coverage

Planned Handover
Region

Cell 2 coverage

-47

-47

-110

-110
X-axis = distance from site and time

And in more detail at the loss of dominance:

Planned Handover
Region

Dragged Handover Region

Hysteresis

Window Size
Therefore, any dropped call or Handover Failure that occurs within the dark blue Dragged
Handover Region will be triggered as a Dragged Drop, or a Dragged Handover Failure.
This scenario is useful to investigate as the symptoms to the problem could occur in a
different location to the root cause of the problem. The lack of successful handover during
the initial loss of dominance should be investigated, instead of the causes of the dropped call,
and depending on the speed of the MS at the time, these 2 situations could occur in different
areas. Therefore, this type of analysis allows engineers to target the problem area correctly
with any resulting handover parameter changes being made to the correct cell.
The loss of dominance in this scenario is defined as:
Serving_RxLevel_Sub < (strongest_neighbour_RxLevel

hysteresis)

This is to ensure this event is not triggered unnecessarily, and is this hysteresis is defined
inside the Tools > Display Thresholds
The time window after which a handover can be
describe as dragged is also controlled from the thresholds settings. Default values of 5dB
for the hysteresis and 10000 milliseconds are suggested, but can be modified before a file is
loaded.
Actix Ltd, 2004

Page 8 of 27

The event definition below shows how the MS moves from the Normal state to the Poor
Dominance state when the server is weaker than the strongest neighbour (minus the
hysteresis). From here, if a handover is successful, the call completes, the call is dropped, or
the server regains dominance, the MS returns to the Normal state. If the window expires
while the MS is still in the Poor Dominance state, it moves into the Should have handed
over state. Any RR Handover Failure message will trigger the EventDragHOFail, and any
dropped call detected will trigger the EventDragDrop. However, if a handover is successful,
the call completes, or the server regains dominance, the MS returns to the Normal state.

Actix Ltd, 2004

Page 9 of 27

To illustrate this situation, the following Dragged Handover will be analysed. Here it is
possible to see the previous Handover Failure which occurred while the MS was still in the
Poor Dominance state, but once the window expired, the next failure triggered the
EventDragHOFail event.

Actix Ltd, 2004

Page 10 of 27

Ping-Pong Handovers
Ping-Pong handovers are situations where the MS is handed over from one cell to another,
but is handed back to that original cell within a certain time window. This causes
unnecessary signalling on the Um, Abis and A interface, and can give a clear indication of
either incorrect handover parameter settings or a dominance problem in the area. This
window size whereby a handover is considered as a ping-pong handover varies between
operators, and the default window size in Actix SVS solution is 6 seconds.

So why should this type of handover be analysed individually? This type of handover will not
be visible from a simple handover success rate KPI. To analyse the distribution of handover
frequency would give an indication towards whether Ping-Pong handovers are occurring, but
Actix new EventPingPongHandover event allows engineers to configure the window size,
investigate the original and intermediate cells, inter-handover time, and report on trends of
cells where this occurred.
The event definition is as follows:

When a successful handover occurs from cell A to cell B, the MS moves from the Normal
state to the Ping state. If the window times-out, or the MS returns to idle (through either a
call completion or a dropped call) the MS moves back into the Normal state. If a successful
handover occurs before the window times-out, the MS moves to the Pong state. From here,
the same conditions apply.

Actix Ltd, 2004

Page 11 of 27

This can be explained using the following algorithm:

MS_state = Normal
If HandoverOK from cell A to cell B then
MS_state = Ping
If timeout window expires OR MS returns to Idle mode then
MS_state = Normal
Else if HandoverOK within timeout window then
If target cell = new cell C then
EventPingPongHandover is not triggered.
MS_state = Pong
Else if target cell = cell A
EventPingPongHandover is triggered
MS_state = Pong
End if
End if
End if
The following screenshot shows two Ping Pong Handovers, the first from cell 12424 to cell
12368 and back; and the second from cell 12424 to cell 12366 and back. The route shows
the ServCI parameter with underneath the route denoting the new CI at a handover.

which can also be clearly visualised when the lines to cells are enabled for all datapoints, and
coloured using the ServCI parameter:

Actix Ltd, 2004

Page 12 of 27

When synchronising the second Ping Pong Handover with the stateform, the handover back
to BCCH/BSIC: 79/13 can be analysed in more detail. It occurred 5 seconds after the
previous (within the 6 second window), and the actual handover itself was executed in 130
milliseconds. However, the dominance of the strongest neighbour at that point was only 1dB.

The main cause for this handover was the poor dominance of cell 12366 in its main lobe area,
which can be seen by plotting the histogram of ServRxLevSub NborRxLev[0], and applying
a regional filter to this area. The average dominance was -3.1dB compared to a side-lobe of
cell 12424 (seen by writing a statistical query on the same expression).

Actix Ltd, 2004

Page 13 of 27

There was a handover back to cell 12366 after the second Ping Pong Handover, but this was
outside of the defined time window, and the change in dominance after the handover would
be 9dB a much healthier handover.

Actix Ltd, 2004

Page 14 of 27

Analysis Pack Stateforms

Four stateforms are provided for individual analysis, accessible from the View menu, or by
right-clicking on a device. Chart views can be zoomed using the drop-down selection at the
bottom right of the panel. Mouse hover-over tips change, giving useful summaries eg:
timestamps or serving & neighbour levels.

The top-left Dragged form shows two traces (Serving Level and strongest neighbour Level),
coloured according to the serving dominance (x). Red: x<-10dB, Yellow: -10<=x< -5dB,
Orange: -5<=x<0dB, Green: 0<=x<5dB, Cyan: 5<=x<10dB, Blue: x >=10dB. The panels
describe the RR and CC cause codes for handover failures and drops, the distance to the
server and strongest neighbour, dominance of server and Radio Link Timeout value.
The top-right Intracell form shows the CI, site and sector names, BCCH, BSIC, TCH, TS and
intracell handover type. The coloured bar shows the CI and the columns show quality.
Yellow = intracell attempt, grey = TS+TCH failure, cyan = TCH failure, magenta = TS failure.
The bottom-left PingPong form shows Timing Advance and CI, with successful (green) and
PingPong handovers (red). Panels show previous BCCH/BSIC and current BCCH/BSIC, time
from previous handover, time to complete handover, handset mode and server dominance.
The bottom-right Repeated form shows CI, Serving and Target BCCH/BSIC, RR Cause at
handover failure and a chart showing Serving Level, Quality and Timing Advance, along with
yellow Repeated Commands, and red Repeated Failures.

Actix Ltd, 2004

Page 15 of 27

Summary
While traditional handover KPIs have sufficed for many GSM operators to tune their network
to the current state, a more detailed approach should be undertaken when the network
reaches a mature state. For this reason, Actix SVS has introduced the Advanced Handover
Analysis Pack to allow diagnosis and troubleshooting of 4 types of handover commonly
overlooked: Intracell, Repeated, Dragged and Ping-Pong.
Through Actix reporting layer, problems can be identified in individual files, with enough
engineering data to allow the root cause of the problem to be identified. The individual data
file can then be analysed, using the available stateforms synchronised with any map, chart,
table or Layer 3 Message Browser view to give the engineer full troubleshooting capability.

Actix Ltd, 2004

Page 16 of 27

Annex

Advanced Handover Analysis Pack

In order to allow trends to be studied on larger volumes of data, reports can be run from the
Advanced HO Analysis pack. These reports can be run on singles files, or superstreams of
merged files. Examples of these reports are shown below.

Actix Ltd, 2004

Page 17 of 27

The Ping Pong Handover Statistics report shows a histogram of the time between ping-pong
handovers within the defined window, and also the change in serving level either side of the
handover.

Actix Ltd, 2004

Page 18 of 27

The Ping Pong Cell Breakdown report allows top-level KPIs to be reported and when used
with a superstream, which file they occurred in, timestamp, and BCCH & BSIC either side of
the handover.

Actix Ltd, 2004

Page 19 of 27

The Repeated HO Target Cells report shows KPIs for repeated handovers, and the BCCH
and BSIC distribution for the file (height of column = count of occurrences of commands).

Actix Ltd, 2004

Page 20 of 27

The Repeated HO Quality report shows the distribution of serving cell quality during a 5
second window before the Repeated Handover Command. The second histogram shows the
distribution of level and quality against Timing Advance, showing trends of how far away from
the serving cell these commands occurred.

Actix Ltd, 2004

Page 21 of 27

The Intracell Type report shows the distribution of the Intracell Handover attempts throughout
the file(s) and also the count of failures for each type. The table below shows the individual
file KPIs broken down by Timeslot Only , TCH Only and Combined timeslot & TCH .

Actix Ltd, 2004

Page 22 of 27

The Intracell Attempts report shows KPIs for the Intracell handover health, and also the
breakdown of timeslot and traffic channel for the target cells. Clicking the Show Excel
Report button allow the engineer to load the report into Excel and modify the pivot table to
identify new trends.

Actix Ltd, 2004

Page 23 of 27

The Intracell Fail Analysis report shows the breakdown of failed intracell handovers, and the
actual TS or TCH which was requested for each failure.

Actix Ltd, 2004

Page 24 of 27

The Dragged Time Delay report shows the KPIs for Dragged Handovers and Dragged
Dropped Calls, and the time distribution between the handover failure or dropped call and the
initial loss of dominance.

Actix Ltd, 2004

Page 25 of 27

The Dragged Dominance report allows the engineer to view the dominance of the server over
the strongest neighbour cell (filtered for only valid Measurement Reports). The second
(composite) histogram shows the distributions of serving level of the server and strongest
neighbour overlaid on the same chart. Finally, the list of Cell IDs and their dominance
throughout the data file is given (highlighted red if negative), with the count of measurements
allowing statistical weighting to be applied to the actual results.

Actix Ltd, 2004

Page 26 of 27

The Individual Drag Analysis report allows the engineer to analyse each individual dragged
handover or dropped call in detail, showing the filename, call ID, CI, target BCCH/BSIC,
distance to the serving cell, dominance, time to failure, timestamp and Radio Link Timeout
value (not shown in screenshot).

Actix Ltd, 2004

Page 27 of 27