Advanced Handover Analysis Using a-SVS

8/4/2019 Advanced Handover Analysis Using a-SVS

1/27

Actix Ltd, 2004 Page 1 of 27

Advanced

HandoverAnalysisusing A-SVS


2/27


CONTENTS

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


3/27


IntroductionHandovers fulfil a number of roles in any GSM network. Not only do they allow for load-balancing of resources, thus maximising the capacity of a cell at any one time; but they allowthe fundamental feature of being able to sustain a call whilst on the move. All resources thatare assigned to a subscriber, whether it is on the Um interface or the Abis/A circuit furtherback into the switch are controlled by various network elements. Therefore to change any ofthese resources, whether it is due to the physical movement of the subscriber, degradingsignal strength and/or quality, or load balancing, involves communication between thesenetwork elements.

All this highlights a key network performance optimisation area to offer subscribers the abilityto seamlessly move around inside each location area, and one that cannot be described byjust one traditional KPI such as Handover Success Rate .

As such, Actix A-SVS includes 4 new types of handover analysis:Intracell handoversRepeated handovers

Dragged handoversPingPong handovers

These are explained in detail in this paper below. The scenario is explained, with the Actiximplementation fully documented. Examples are included where relevant, and finally thestateforms allowing detailed synchronisation are explained. The Annex gives examples of theKPI reporting layer available with this Advanced Handover Analysis Pack in Actix A-SVSsolution.


4/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 theBTS. Therefore, the options for an intracell handover can be timeslot only , traffic channelonly or both timeslot and traffic channel .

5 new attributes have been added to the Workspace Explorer:

Message AttributeIntracell handover command Event_Intra_HO_CommandSuccessful intracell handover Event_Intra_HO_OKFailed timeslot intracell handover Event_Intra_TS_HO_FailFailed traffic channel intracell handover Event_Intra_TCH_HO_FailFailed combined timeslot/traffic channel intracell handover Event_Intra_TCH_TS_HO_Fail

The intracell handover command is triggered by an RR Assignment Command Layer 3message and can occur while the handset is in dedicated mode or in-call. At this point, a newattribute Event_Intra_HO_Command is set depending on whether the command is to changeeither the Timeslot only, the TCH only or both the TCH and timeslot using the followingalgorithm and event diagram:

If current TCH is equal to previous TCH thenSet attribute to TS only command

ElseIf current TS is equal to previous TS then

Set attribute to TCH only commandElse

Set attribute to TCH and TS commandEnd if

End if

The format of the RR Assignment Command (hopping / non-hopping) is as follows:

L3 DL RR Assignment CommandChannel Type: TCH/F + FACCH/F and SACCH/FTimeSlot: 5 TrainingSeq: 4Hopping: Yes, MAIO: 1 HoppingSeq (HSN): 0MsTxPower Ordered: (2 GSM)CA List: 9 13 19 71 (Bit Map 0)Channel Mode: Speech full rate or half rate version 1MA: 1 2 3 4

or

L3 DL RR Assignment CommandChannel Type: TCH/F + FACCH/F and SACCH/FTimeSlot: 4 TrainingSeq: 2Hopping: No, ARFCN: 88MsTxPower Ordered: (5 GSM)Channel Mode: Speech full rate or half rate version 1


5/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 waitsin the Unknown @ start of file / idle state. Once a dedicated channel has been assigned tothe handset, the event diagram moves into the Voice/data channel assigned state. Anyfollowing RR Assignment Command (before the handset returns to idle mode) results ineither a timeslot, traffic channel or both re-allocation attempt. At this point, the event diagrammoves into the Intracell HO state. From the Intracell HO state, it is possible todrop/complete the call, but a typical result would be for the RR Assignment Complete or RRAssignment 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 isdetected, depending on the type of intracell handover command, it sets the correspondingfailure event: Event_Intra_TS_HO_Fail / Event_Intra_TCH_HO_Fail /Event_Intra_TCH_TS_HO_Fail.


6/27


Repeated Handovers

Repeated handovers are situations where the network instructs the MS handover to a newcell. 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 associatedfailures, until either the MS succeeds in its attempt, the call is terminated, or the networkrequests the MS to handover to a different cell.

At the first message, the handset moves into the Normal state. Only when it finds the firsthandover failure does it move into the HO_Window state. If the handover succeeds or ahandover command to a new cell is detected, the MS returns to the Normal state. The MSalso moves back to the Normal state at a dropped call, a channel release or a call setupfailure. From the HO_Window state, any further handover commands to the same cell asthe previous command that has just failed, result in the Event_Rpt_HO_Commandsevent

being triggered. If another Handover Failure is found, it can only have resulted from arepeated handover command, so it sets the Event_Rpt_HO_Failuresevent.

In this way, it will identify the following scenarios:

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

HOCommands

HOFails

Rpt HOCommands

Rpt HOFails

1 0 0 0

1 1 1 0

1 1 2 1

2 1 1 1

HOCommand

HO OK

HO FailRpt HO

Command HO OK

HO FailRpt HO

CommandRpt HO

FailRpt HO

Command HO OK

HO FailRpt HO

CommandRpt HO

Fail

HO Command(new cell)

HOCommand

HOCommand

HOCommand


7/27


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


8/27


Dragged HandoversThis situation exists when theMS loses its dominance, but for whatever reason the networkeither doesn t instruct it to handover, or it fails to handover successfully. If this loss ofdominance 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 twonew events: EventDragHOFail or EventDragDrop.

And in more detail at the loss of dominance:

Therefore, any dropped call or Handover Failure that occurs within the dark blue DraggedHandover 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 adifferent location to the root cause of the problem. The lack of successful handover duringthe 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 differentareas. Therefore, this type of analysis allows engineers to target the problem area correctlywith 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 definedinside 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 5dBfor the hysteresis and 10000 milliseconds are suggested, but can be modified before a file isloaded.

Cell 1 coverage Cell 2 coveragePlanned HandoverRegion

Dragged HandoverRegion

X-axis = distance from site and time

-47

-110

-47

-110

Hysteresis

Window Size

Dragged Handover RegionPlanned HandoverRegion


9/27


The event definition below shows how the MS moves from the Normal state to the PoorDominance state when the server is weaker than the strongest neighbour (minus thehysteresis). From here, if a handover is successful, the call completes, the call is dropped, orthe server regains dominance, the MS returns to the Normal state. If the window expireswhile the MS is still in the Poor Dominance state, it moves into the Should have handedover 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.


10/27


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

EventDragHOFail event.


11/27


Ping-Pong HandoversPing-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 causesunnecessary 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. Thiswindow size whereby a handover is considered as a ping-pong handover varies betweenoperators, 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 handoverfrequency would give an indication towards whether Ping-Pong handovers are occurring, butActix new EventPingPongHandoverevent allows engineers to configure the window size,investigate the original and intermediate cells, inter-handover time, and report on trends ofcells 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 Normalstate to the Ping state. If the window times-out, or the MS returns to idle (through either acall 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.


12/27


This can be explained using the following algorithm:

MS_state = NormalIf HandoverOK from cell A to cell B then

MS_state = PingIf timeout window expires OR MS returns to Idle mode then

MS_state = NormalElse if HandoverOK within timeout window then

If target cell = new cell CthenEventPingPongHandover is not triggered.MS_state = Pong

Else if target cell = cell AEventPingPongHandover is triggeredMS_state = Pong

End ifEnd 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 showsthe 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, andcoloured using the ServCI parameter:


13/27


When synchronising the second Ping Pong Handover with the stateform, the handover backto BCCH/BSIC: 79/13 can be analysed in more detail. It occurred 5 seconds after theprevious (within the 6 second window), and the actual handover itself was executed in 130milliseconds. 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 applyinga regional filter to this area. The average dominance was -3.1dB compared to a side-lobe ofcell 12424 (seen by writing a statistical query on the same expression).


14/27


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


15/27


Analysis Pack Stateforms

Four stateforms are provided for individual analysis, accessible from the View menu, or byright-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


16/27


Summary

While traditional handover KPIs have sufficed for many GSM operators to tune their networkto 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 HandoverAnalysis Pack to allow diagnosis and troubleshooting of 4 types of handover commonlyoverlooked: Intracell, Repeated, Dragged and Ping-Pong.

Through Actix reporting layer, problems can be identified in individual files, with enoughengineering data to allow the root cause of the problem to be identified. The individual datafile 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.


17/27


Annex Advanced Handover Analysis PackIn order to allow trends to be studied on larger volumes of data, reports can be run from theAdvanced HO Analysis pack. These reports can be run on singles files, or superstreams ofmerged files. Examples of these reports are shown below.


18/27


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


19/27


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


20/27


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


21/27


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


22/27


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


23/27


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


24/27


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


25/27


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


26/27


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


27/27

The Individual Drag Analysis report allows the engineer to analyse each individual draggedhandover 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 Timeoutvalue (not shown in screenshot).

Documents

Advanced Handover Analysis Using a-SVS